abcd0x00

Сначала делишь всё по пробелам, а потом эти лексемы проходишь и склеиваешь обратно в даты части, которые можно в них склеить.

>>> p = [1, 2, 3, 4, 5, 6, 7, 8, 9]
>>> it = iter(p)
>>> list(map(list, zip(it, it, it)))
[[1, 2, 3], [4, 5, 6], [7, 8, 9]]
>>>

>>> import random
>>> 
>>> def g(start=1, end=1000000):
...     n = random.randint(start, end - 1)
...     return (n % 2 == 0 and n) or n + 1
... 
>>> [g() for _ in range(10)]
[841196, 137368, 240392, 14588, 431038, 737926, 203080, 678028, 694386, 154716]
>>> 
>>> [g(5, 20) for _ in range(10)]
[14, 10, 8, 8, 18, 8, 6, 14, 12, 12]
>>> [g(5, 20) for _ in range(10)]
[10, 16, 18, 6, 18, 8, 10, 8, 8, 14]
>>>
>>> [g(6, 20) for _ in range(10)]
[18, 6, 18, 6, 20, 8, 10, 16, 12, 16]
>>>

>>> import datetime
>>> 
>>> date_time = datetime.datetime.now()
>>> date_time_2000 = date_time.replace(year=date_time.year + 2000)
>>> date_time.strftime("%Y-%m-%d %H:%M:%S")
'2017-02-26 17:55:44'
>>> date_time_2000.strftime("%Y-%m-%d %H:%M:%S")
'4017-02-26 17:55:44'
>>>

Замени это:

int N;
scanf("%d",&N);
N++;
N *= N;
printf("%u",N);

На это:

int n;

scanf("%d", &n);
n = (n + 1) * (n + 1);
printf("%d", n);

Потому что там нет порядка. Словарь характеризуется скоростью поиска значений по ключам. При любом количестве пар ключ-значение в словаре поиск значения стремится к O(1).

import itertools

with open('file.txt', encoding='utf-8') as fin:
    for line in itertools.islice(fin, 0, None, 2):
        print(line, end='')

Есть Unicode - это огромная таблица всех символов в мире. У них там свои номера, которые никак не меняются (все символы пронумерованы). И вот для этого юникода есть кодировки, одна из которыз UTF-8 (а другие - UTF-16, UTF-32). Что такое кодировка - это таблица из последовательностей байт, отображаемых на символы. Одна последовательность байт ставится в соответствие одному символу. Соответственно, одна последовательно байт с помощью UTF-8 ставится в соответствие одному символу в Unicode (по его номеру). И наоборот, одному символу в Unicode (его номеру) ставится в соответствие одна последовательность байт в кодировке UTF-8. То есть туда-сюда можно переводить.

Дальше ты читаешь последовательность байт и её можно превратить в одно число по определённому алгоритму и потом это число уже берётся в юникоде и там смотрится символ.

Сама кодировка UTF-8 (закон преобразования) очень просто устроена: она берёт первый байт, в нём записано, сколько там ещё байт нужно взять. Потом эти байты берутся и целиком рассматриваются в виде непрерывной последовательности бит, из которой можно составить число. И потом это число ищется в юникоде уже.

Дальше ты хочешь понять, а что же такое cp1251. Это тоже кодировка, но она никак не связана с Unicode. Вместо Unicode там используется другая таблица (очень маленькая табличка на 256 символов), поэтому там хватает одного байта, чтобы получить код любого символа в этой таблице. И в ней как раз есть своя кириллица, поэтому для неё кириллица помещается в один байт.

Подскажите какие технологии,или что почитать о парсинге текстового файла?

wiki. автоматное программирование

На C ты просто открываешь файл (fopen() + fclose()), читаешь его построчно (fgets()) или посимвольно (getc()) и подаёшь данные в конечный автомат для анализа. Когда же нужно работать со строками, то ты используешь разные функции из string.h.
Это общий подход, но есть и готовые библиотеки для работы с конретными форматами. Но вот когда библиотек нет никаких или их невозможно поставить, тогда ты должен сам всё написать, а сам ты будешь писать через конечный автомат, потому что библиотеки обычно через него и пишутся.

Есть робот-игрушка, назовём его Петей. Пользователь, пройдя игру в мобильном приложении "Поле чудес" от лица Пети, заработал ему 10 баллов интеллекта. Данная заслуга сохранилась на сервере компании-производителя Пети. В любой момент, с сервера может поступить одна из команд доступных для его 10 баллов и он, к примеру, скажет своему хозяину "давай играть". В случае поломки Пети, хозяин идет в магазин и покупает нового робота, идентифицирует его на сервере и безымянный робот опять становится Петей со всеми его заслугами.

Мобильное приложение разработает лучше ТА КОМАНДА, которая разрабатывает мобильные приложения. Под мобильным приложением, видным пользователю, лежит такой айсберг работы, что один человек либо напишет нефункциональное окно, на которое можно будет только смотреть и радоваться, либо кучу плохо проработанных функций, где всё ломается с каждым днём и превращается в снежный ком из ошибок, которые надо исправлять, а исправлять их не так-то просто. Не надо думать, что если ты легко используешь приложение, то и пишется оно легко.

Сервер компании лучше сделает тот человек, который их постоянно делает. Благо, это больше относится к сисадминству (легче найти специалиста, так как их много). Делает сисадмин, консультируясь с программистом, потому что сервер должен просто предоставлять API (интерфейс), через который с сервером общается робот и через который с сервером общается мобильное приложение. То есть сисадмин должен просто всё установить, подключить и настроить.

На сервере будет стоят служба, которую разработает лучше всего тот, кто их постоянно разрабатывает, - системный программист. Там надо понимать в нагрузках, отказоусточивости и во всём таком. Он просто делает устойчивый сервис и реализует в нём API для взаимодействия с мобильным приложением, приходящим клиентом-роботом и внутренней базой.

Искусственный интеллект я как-то у тебя не наблюдаю. Но если он понадобится, тебе подойдёт любой игродел, там постоянно надо применять методы принятия решений. Ты его делаешь снаружи, а потом сисадмин подключает его к серверной службе через API. И служба к нему обращается и спрашивает "как мне вот поступить с такими-то данными?". Так ты можешь много всяких интеллектов делать и подключать снаружи к основному балансировщику.

То есть самое главное в этом всём - правильно разделить разботу между конкретными специалистами. Нельзя, например, сваливать на мобильщиков, которые не шарят в нагрузках, а больше привыкли картинки лепить в интерфейсе, работу с десятками тысяч роботов, коннектящихся к серверу. Они просто ничего в этом не понимают (и не должны понимать) и сделают всё плохо. И наоборот, нельзя на системщика сваливать работу с интерфейсом в мобильном, потому что он этим никогда не занимался. Ну, и регистрировать домены программисты у тебя не должны, этим должен заниматься тот, у кого есть время лазить по хостингам.

Конкретные языки узнаешь сам.

не совсем понимаю как интерпретировать этот кусок
(struct sockaddr_in *)&serv_addr
то ли указатель на сруктуру, то ли ссылка, то ли ещё что...

Это берётся адрес структуры в памяти определённого размера и этот адрес приводится к типу адреса структуры другого размера. Адрес тот же самый остаётся, а размер данных по этому адресу как бы меняется. На самом деле она уже там лежит в правильном размере, просто сама структура является как бы составной. И чтобы компилятор не ругался, что структура не того типа подаётся, делается такое приведение.

В лине адреса делаются таким образом: берётся общая структура, которая подходит под все адреса, потом к ней в конце привязывается (дописывается в памяти) адрес в определённом виде. А так как адреса бывают разных размеров, то и размер конечной структуры может варьироваться. Сам язык по стандарту допускает дописывание в конец структуры каких-то данных, поэтому эта возможность языка и используется в POSIX-системах для составления адресов перед их использованием.

Начал изучать Python, следующим на очереди Django.

Без изучения питона в джанго лучше не лезть, иначе будешь элементарные однострочные вещи писать в виде небоскрёбов по десять строк или вместо библиотечных функций, про которые ты не знаешь, писать свои велосипеды. Питон можно поверхностно изучать тогда, когда знаешь глубоко какой-нибудь похожий на него по своему устройству язык (Ruby, Perl).

Как же написать программу, меняющую текущий каталог (если это возможно О_о)?

#!/bin/bash

cd /

echo "I'm in `pwd`"

bash

exit 0

[guest@localhost ~]$ echo "H4sIACqNc1gAA/NNLCnKrOACAG/TSfYHAAAA" | base64 -d | gunzip
Matrix
[guest@localhost ~]$

Вот git развивает Junio C Hamano, он японец. Если бы он тебе по-японски написал что-то или ты ему по-русски, вы бы друг друга не поняли. А так он пишет по-английски свои идеи, ты их можешь прочитать и ему ответить по-английски своими идеями.

Но дело даже не в том, что в мире 7 миллиардов человек с сотнями разных языков, а в том, что весь компьютерный мир возник и развился в США и Европе, поэтому вся основная документация была написана на английском изначально. А основная документация - это описание всего, что сейчас происходит за кадром (сетевые протоколы, форматы файлов и так далее). Переведено из этого на русский процентов 25, многое переведно не очень качественно (лучше читать в оригинале).

Поэтому без английского у тебя будут обрывочные знания в целом и не всегда точные и полные в частности.

Суть в том, что каждый раз, когда начинаю читать какую-нибудь книгу по программированию или смотреть курсы, прохожу какую-то часть и дальше интерес пропадает.

Надо структурировать информацию об обучении для долгих отрезков времени. Это очень важная составляющая, если собрался чем-то заниматься серьёзно. Чтение книги - не такой уж быстрый процесс. Написание программы - это не только долгий, но и запутанный процесс. А написание нескольких программ и чтение нескольких книг - это всё вместе. Ты никак не обойдёшься без органайзера. Поэтому потрать время на организацию долгих процессов. Изучи, чем и как ты будешь это делать. Что значит "чем" - это средство, программа или несколько программ, потому что разные вещи делаются разными программами. Что значит "как" - это то, как ты будешь пользоваться средствами, потому что использовать их тоже можно как эффективно, так и неэффективно.

Твоя задача: ты записывал информацию на протяжении года, потом был перерыв и через пять лет ты открыл эти данные и ты должен всё понять и вспомнить только по этой информации.

Вот у меня, допустим, книга появляется. Я решил, что я должен её прочитать и пройти всю, потому что мне это даст то-то и то-то. Я готов на это потратить год или два. Я создаю для неё её индивидуальную среду - как бы проект по изучению этой книги. Дальше в нём распределяю, где я буду хранить закладки прохождения книги, заметки по главам, примеры кодов из самой книги по главам, тренировочные коды для экспериментов по главам. Важно бэкапить этот проект, чтобы в один прекрасный день не потерять информацию, копившуюся полгода - настраиваешь бэкап, находя под него место, делая скрипты автоматического бэкапа, чтобы быстро всё было (скрипты готовы с прошлых книг). Вот у тебя получается такая заготовка для изучения книги. И после этого ты начинаешь, например, переносить все пункты в отдельный файл пройденных пунктов. Прочитал первый пункт первой главы - сохранил по нему важные моменты в отдельный файл с конспектом первой главы. Отмечаешь в файле пройденных пунктов, что пункт прочитал. Заметки по этому пункту пишешь в отдельный файл с заметками для первой главы. В общем, первая глава превращается в такую папку с данными только для неё, вторая глава превращается во вторую папку с данными только для неё. Не надо ничего мешать в кучу. Лучше максимально раскидать по индивидуальным папкам и файлам, а потом создать шапку-центр, который это всё объединяет воедино где-нибудь наверху. Это как html-файл со ссылками на главы, где каждая ссылка ведёт на html-файл со ссылками на пункты. Всегда надо знать (видеть), что ты прошёл и что ты не прошёл, чтобы ты мог посмотреть на пройденное и сказать "пройдя вот это всё, из нового я узнал вот это, это и это". Если нужно что-то перечитать, не бросайся на это сразу, запиши себе заметку в файл с заметками, прямо так и пиши себе на будущее "перечитай такой-то пункт, чтобы узнать про ту вещь поподробнее". Когда пишешь себе заметки, не оставляй моментов, где надо вспоминать или догадываться о деталях, помни, что когда ты это будешь читать, ты не сможешь ничего вспомнить из того, что сейчас кажется очевидным, так что пиши себе заметки, как незнакомому человеку писал бы. Если задание выполнил из заметки, запиши себе дату и "я задание выполнил". Всё, после этого ты можешь читать книгу как угодно, вся регистрация по её прохождению идёт и даёт полную картину.

С программами потяжелее всё, так как надо ещё подробнее всё писать там и оно может меняться по сто раз. Это наука не простая, нужно много изучать и про версионирование, и про системы по слежению за багами. Может пройти какое-то время и старая система может показаться безграмотной, надо будет всё переделывать. Где-то ты работал по водопаду, потом оказалось, что есть скрам. Где-то ты работал напрямую, потом оказалось, что есть юнит-тесты до кода. Потом ты начинаешь тесты писать, а вся программа останавливается. А потом идеи, которые были, уже не подходят, потому что ты решил всё переделать, так как для тестов будет лучше определённым образом всё писать. Если же ты этого не делаешь, то надо программу продолжать писать безграмотно и результат получается совсем неприятный (программа идёт в тупик шаг за шагом и потом её только заново написать остаётся, чтобы хотя бы продолжать её развивать). Так что лучший совет здесь - всегда смотри за другими проектами, смотри, как ими управляют, если даже сложно это всё, изучай это сложное управление. Имея все эти знания, вырабатывай свой стиль управления проектом, потому что модные стили тоже не являются гарантией эффективности, и фуфло может быть модным и признаваться с умным видом на конференциях, но потом все скрупулёзно всё равно ищут что-нибудь получше (сами сделать не могут же ничего обычно ;-) только разговоры разговаривать).

Очень много книг надо прочитать очень медленно и очень много программ надо написать не самых простых. Надеюсь, всё это ты не собрался держать в голове.

Что посоветуете для более-менее быстрого парсинга такого файла?

Ты должен перегнать это в базу данных, у которой есть средства для SQL запросов. Это сейчас тебе надо найти вот это вот по этому, а завтра понадобится найти совсем другое по совсем другому. И для всего этого (всех возможных вариантов) подходит именно гибкий язык запросов. Поэтому тебе нужно написать перегонщик исходных данных в хорошую базу данных, который ты потом привяжешь к скрипту, который проверяет, изменился ли этот файл с исходными данными, чтобы автоматически составить новую базу. И для того, чтобы его написать, нужно сначала подготовить исходный файл (удалить лишние пробелы), потом проанализировать его на отдельные записи (это лексический анализатор нужно сделать), а потом этот поток лексем сохранить уже в виде записей в таблице базы данных. Но в базе данных у тебя уже должно быть всё по уму сделано, чтобы любые поиски выполнять можно было и ничего не путалось. Возможно даже, что тебе нужно будет сделать разные таблицы (для русского и для английского и связать их). Работы немало.

Как оказалось, важное замечание: этот файл мы не сами редактируем, его присылает другая организация (государственная) изменить его формат невозможно.

А ты вызвался упростить работу? Зря, всё равно не оценят. Будешь бесплатно работать за грамоту и похлопывание по плечу.
Если есть возможность, вообще в такие вещи не лезь, пусть ищут хоть руками, хоть ногами. Говори, что так и должно быть, а сам занимайся полезными вещами, чтобы не деградировать.