tokovsam

Приветствую, спасибо всем, кто подписался здесь. Спасибо, всем, кто подписался на мой канал в телеге - https://t.me/tobeprog . Обычно я пишу о программировании, этот пост - исключение, после него продолжится запланированный формат дайджестов.

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

Недавно, у меня на канале, вышел пост, где говорилось о явлении наслоения в изучении программирования. Странная побочка этого явления - эдакий снобизм, вытекающий в предположения из разряда: 'если я это знаю - значит все знают'. Приводил пример, что часто ловлю себя на нелепом представлением о том, что все вокруг знают английский.

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

Решение нашлось довольно быстро, и тем страннее почему в школе/вузе об этом "забывают" рассказать.

Сразу скажу, метод абсолютно не академичен(уберите преподов английского от экрана). Но, грубо говоря, это более "естественный" способ изучения языка. Если нужно как можно быстрее, перейти к пониманию каких то материалов на английском - самое то.

Прозвучит немного очевидно, но тут не скажешь по другому - "нужно учиться понимать язык, а не переводить с него".

Как происходит взаимодействие через перевод: слово >> перевод >> образ, проблема в том, что посредник в виде перевода убирает прямое взаимодействие с языком. Довольно часто, в пользу метода, приводят аргумент - посмотрите как дети учат язык, они напрямую связывают слова с образами, у них нет своего детского варианта языка, на который они переводят, нет этого ненужного посредника.

Прямое взаимодействие с языком выстраивает связи, опять таки, ребенок видит взаимодействия между словами, узнает смысл новых из комбинаций известных значений, смотрит на контекст и т.д. Все прошли этот путь, и в большинстве случаев, успешно. Но как только мы вводим в цепь перевод, эти взаимодействия теряются, по сути мы взаимодействуем уже с известным нам языком, при переводе мы стараемся приблизить к своему языку, нежели понять связи оригинала.

Если не взаимодействовать с языком напрямую, не простроить эту связь образов, то при усложнении материала, появляется все больше ненужных посредников.

Пример, слушаем аудио: оригинал >> повторение оригинала в голове(происходит подготовка к процессу перевода) >> перевод >> более правильный перевод(стараемся приблизить к правильному языку, исправляем грамматику) >> понимание сути сказанного. Многовато лишнего, не правда ли?

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

Очевидно, нужно убрать шаг перевода, и напрямую связать слова с образами. Кажется, довольно не простая задача, но есть хорошая новость. Ваш мозг уже умеет идеально это делать, и речь вовсе не о младенческом периоде, этот процесс происходит, буквально, постоянно.

Рассмотрим пример привязки очень сложного образа: К Вам подходит товарищ, и спрашивает "смотрел вчера презентацию Apple?". Что в этот момент происходит? Скорее всего ничего, просто продолжается диалог, вам не нужно останавливаться и осмыслять что же Apple такое. Скорее всего даже нет четкого образа, возможно в голове сразу всплывает множество разных: эмблема, продукция, Стив Джобс, те вирусные видео Mac vs PC и т.д. В зависимости от того насколько много вы знаете об Apple, количество образов у вас и вашего товарища могут значительно отличаться, и это все равно не проблема. Какое то усредненное понимание, усредненный образ есть у в головах у вас обоих. Мозг его сделал, связал с словом и дал возможность спокойно им оперировать.

Можно привести множество подобных примеров, но Apple выбрана не случайно. Хотя ей более 40 лет, многие узнали о ней, именно в сознательном возрасте. В отличии от того же Xerox, название так и не вошло в повседневный обиход, заменив какой то предмет. Само слово apple, все еще имеет прямое значение, если вы увидите его на упаковке сока, то наврятли предположите, что ребята решили выйти на новый рынок. Повторюсь, при всех этих условиях, мозг сам обработал этот образ, связал его со словом и отдал вам. Вам понадобилось им оперировать, и мозг сделал всю работу сам.

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

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

Базу можно взять из 1к-3к самых используемых слов в английском. Такая цифра может пугать, но большинство слов там очень простые: man, woman, friend, cat, dog, you, he, she и т.д. Неплохой идеей будет наложить на это основы грамматики, именно основы, вам не нужно знать все 12 времен, но понимать, что о прошлом/настоящем/будущем идет речь, надо и т.д.

Если пройтись по этим основам, и потихоньку развивать понимание языка, откроется одна, очень эффективная техника - учить язык, используя этот же язык. И вот уже тут можно приступать к серьезному пополнению словарного запаса и глубокому "правильному" изучению грамматики.

Кстати, эффект стирания шага перевода, можно поймать на автомате. К примеру человек, долго изучающий язык, оказывается в среде. Обычно история такая: первый день - ничего не понимаю, последний день - засыпая, ловлю себя на том, что буквально думаю на иностранном языке.

Приветствую, прошлый пост сохранили более 70 раз, это очень круто.

Также, спасибо, подписчикам, вас почти 10, цифра весьма скромная, но две недели назад я вообще не думал, что на меня кто то будет подписан, мотивирует.

Еще я завел канал в телеге - https://t.me/tobeprog , там будет о самих методах обучения и обзоры на материалы. Здесь же, будет еженедельный дайджест.

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

В посте, будет распределение материалов по уровню сложности, но это не учебный план. Почему так, и вообще касательно планов, методов изучения, выбора языка для старта и прочего, я уже делал два больших поста. Возможно, они будут полезны и ответят на какие то вопросы:

Что не так с планами изучения программирования. Что значит программировать, и почему многие не понимают этот процесс

Научиться программировать

1. Самые основы: Автоматизация рутинных задач с помощью Python, Свейгарт + миллион туториалов

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

Сама книга породила огромную волну материалов по "автоматизации" на python. Если вбить на ютубе "python automation", то темы роликов будут от работы в Excel до знакомств в Tinder.

Это может показаться смешным, но когда код сам играет в динозаврика в Google Chrome(это одно из популярных видео), новичок ощущает какую то "крутость" возможных программ. Этот, чисто психологический момент на ранних этапах весьма мотивирует.

По идее, должны быть еще какие то курсы/книги с которых стоит начать. Я посмотрел несколько популярных, и особых преимуществ перед книгой Свейгарта не увидел. Те же темы, те же основы, но нет такого упора на практику. Хорошо иметь несколько источников, но посоветовать что то конкретное не могу, тут наверно стоит смотреть на саму подачу автора/лектора и выбирать что ближе.

2. После основ:

https://stepik.org/course/512 - очень хороший курс по питону, для тех кто прошел основы. Стоит посмотреть хотя бы начало - там небольшой ввод в само устройство языка, стек вызовов, пространство имен, области видимости и прочее.

https://stepik.org/course/4519 курс в котором учат гуглить, искать на StackOverflow, читать документацию и юзать библиотеки. Это тот самый подход, о котором не особо пишут в книжках, однако, это именно про такую - трушную практику.

На этом этапе, встанет вопрос со сложными проектами. Я уже писал про build-your-own-x - репозиторий с кучей туториалов сложных проектов - Для изучающих программирование. Часть 0. Где найти идеи и реализации сложных проектов

На этом же этапе, стоит начать почитывать разные материалы о том, как писать "хороший" код. Особенно хорошо, если на изучаемых реализациях начнут явно прослеживаться недавно вычитанные принципы.

3. Когда пора на собес:

https://www.youtube.com/watch?v=5V7XG1mGiHc - курс по python от Computer Science Center.

После него, уже можно топать на собеседование(на самом деле, далеко не каждый джун сможет пройти этот курс), потому что более глубокого курса, по крайней мере в ру сегменте, я не видел.

Хотя это про язык с самых его основ, он не для новичков, а для уже программистов, к примеру, решивших выучить новый язык или углубить понимание питона. Он сложный, даже очень сложный, но при этом абсолютно потрясающий, разобрано вообще все. Его стоит посмотреть каждому, кто решил связаться с питоном.

Есть более новая запись курса, но эта - 2015 года, мне нравится больше.

Это продолжение поста - Что не так с планами изучения программирования. Что значит программировать, и почему многие не понимают этот процесс

Там было о том, что планы изучения программирования для новичков зачастую игнорируют проблемы новичков. Как пример рассматривалось проблема не понимания самого процесса программирования.

Именно за ней скрывается ситуация, когда какой то учебный материал пройден, но при этом человек абсолютно не умеет программировать, т.е. писать программы, решающие какие либо задачи, выходящие за пределы типовых описанных в учебном материале.

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

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

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

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

1. Самое очевидное - для того чтобы понять процесс программирования, для начала надо его увидеть. В самостоятельном изучении, этот пункт вызовет значительные затруднения(на всякий случай напишу, увидеть процесс программирования и досконально понять код - разные вещи, нам нужно именно само мышление, а вникать в этот процесс можно не понимая кода вообще).

https://www.youtube.com/watch?v=vpyWbpdk3Xs наверно, уникальный пример, где автор показывает именно тот самый процесс мышления при написании программы, к сожалению, в ру сегменте я больше ничего подобного не нашел

https://stepik.org/course/4519 курс в котором учат гуглить, искать на StackOverflow, читать документацию, и юзать библиотеки. Это тот самый подход, о котором не особо пишут в книжках, однако, это именно про такую - трушную практику. Разумеется, в этом случае, нужно не просто смотреть, для чего стоит хотя бы немного знать python. К сожалению, курс небольшой.

2. Важно чтобы ученик понимал куда движется, какую конкретную задачу решаем на определенном этапе. Может показаться что "научиться программировать" - абстрактная задача. Но приведем ее к форме - пока не понял и не научился решать задачи, методом как из видео выше(разумеется не такие сложные и большие), не научился и программировать.

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

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

Пример - "Код" Петцольда. По неизвестной мне причине, у многих новичков слово "архитектура" вызывает ассоциации с перфокартами, чем то старым и заросшим паутиной. Однако, ситуация резко меняется после первой главы "Кода", достаточно сложная тема увлекает просто потому что книга интересно написана.

Более популярный пример - CS50(К слову, CS50 и "Код" Петцольда - идеальное сочетание. CS50 мало про архитектуру, а Код отлично ложится на ввод в computer science).

4. Можно выбрать любой язык, это не столь важно. Однако, для наших целей лучше всего подойдет Python. Он позволяет очень быстро писать сложные программы или их рабочие прототипы, т.е. как можно быстрее прийти к тому самому процессу программирования.

Автоматизация рутинных задач с помощью Python, Свейгарт - интересный вариант с которого можно начать. Книга сосредоточена на практике, решении всякой мелкой рутины. Достать из текста данные, заполнить форму, разослать email-ы и т.д. и т.п. Подобную мелочь можно компоновать в большие программы, это довольно большой шаг в сторону "научиться программировать", тем более учитывая, что это может быть первая книга по программированию.

https://stepik.org/course/512 - очень хороший курс по питону, для тех кто прошел основы, стоит посмотреть хотя бы начало - там небольшой ввод в само устройство языка, стек вызовов, пространство имен, области видимости и прочее.

5. План обучения должен быть динамическим, сложно контролировать скорость обучения и менять материалы в зависимости от нее самостоятельно, но хотя бы подтягивать новые учебные материалы в ваш план стоит. Дайджестов учебных материалов полно(хотя бы тот, который я вроде начал и планирую продолжать), да и просто самостоятельно найденные материалы могут оказаться очень к месту. Пример курса который я нашел случайно:

https://youtu.be/auK3PSZoidc - урок из курса MIT 6.S095 Programming for the Puzzled - наверно лучшее объяснение бэктрекинга, объясняют через решение судоку. Объяснять подобные методы сложно, тем более привязать интересные задачи. Курс справляется на ура. Он на python, и отлично впишется когда основы языка и какие то основы cs пройдены.

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

https://github.com/danistefanovic/build-your-own-x

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

https://codereview.stackexchange.com/questions/204863/caesar... - код ревью шифра цезаря, ищется за секунду, при этом новичок может вынести пару важных вещей.

8. Как делаем практику мы, напомню, что мы только на середине пути(3 месяца), многое еще предстоит.

Опишу на примере: на этой неделе, я дал на разбор цепи маркова, не будем вдаваться в мат аппарат, важно лишь, что с помощью этой штуки можно генерировать разное. Алгоритм идет по данным, считая следующий шаг на основе настоящего и игнорируя предыдущие. Разумеется цепь маркова не может в содержание, но зато может в форму.

Для примера, прогнал через нее небольшое количество цитат Аристотеля, из осмысленного она сгенерировала:

Шутка есть самый верный признак дружбы.

Свойство добродетели состоит, скорее, в досуге.

Разум - это довольство собою.

Благодарность быстро стареет.

Из не очень осмысленного:

Именно смешные повадки людей против немногих хороших людей против множества дурных против немногих хороших.

Поступать правильно можно только человеку выказать свою честность.

Делать вещи, а она отдых.

Ну и огромное количество просто бессмысленного мусора.

Первый этап - объяснить что такое цепь маркова. На этом этапе код не важен, нужно понять сам принцип работы. Ребята примерно набрасывают не сам код, а грубо говоря составные части будущей программы. Относительно цепей маркова - часть должна обрабатывать данные, делая из них удобною для прохождения структуру, другая должна по этой структуре идти, считая следующий шаг на основе настоящего и игнорируя предыдущие. Это может быть псевдокод, какая то схема или даже объяснение на словах, главное - понимание сути будущей программы.

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

Третий - пишут свою реализацию. Даем тесты, если все ок, следующий шаг.

Четвертый - самое интересное, грубо говоря основа проекта готова, нужен сам проект. Происходит питч идей в общий чат. Важно что бы идеи обсуждались, дополнялись или критиковались(этого очень сложно добиться) участниками. В этом процессе количество идей увеличивается многократно.

Пару простеньких примеров:

У нас есть любитель рогаликов, он сразу загорелся идеей сделать систему диалогов, добавив простейшую реализацию анализа тональности текста(прописанная база хороших/плохих слов), в зависимости от которой цепи Маркова подается(хорошая/плохая база ответов), забавно выглядит, когда гневный диалог, вдруг резко меняет тон, поскольку цепь Маркова сгенерировала что то положительно-нейтральное. Разумеется это не окончательный проект, все допиливается, подключение дополнительного собеседника(их n колл-ва) к этому диалогу, изменение самих баз по ходу диалога ну и т.д. в любом случае это становится похоже на довольно интересный учебный проект.

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

Ну и пятый - code review.

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

Что не так с планами изучения программирования

Приветствую, я разработчик. Примерно 3 месяца назад взялся обучать программированию группу моих знакомых. Получилось это довольно спонтанно, началось все с запросов чекнуть найденный план изучения\roadmap.

Далее следовала одна и та же история: в не зависимости от выбранного плана, его сложности и подхода у разных учеников появлялись одинаковые проблемы. Я и до этого помогал с обучением, но только на увеличенной выборке заметил, насколько у новичков похожие затруднения.

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

Чем больше я об этом думал, тем больше мне казалась очевидность надобности подобного материала. План обучения сосредоточенный на новичках, не просто вываливающий список курсов и книг, с минимальными пояснениями, а действительно предупреждающий о возможных затруднениях/ошибках и предлагающий их решения.

Это не казалось сложной задачей, пока не всплыла была очень важная деталь - оторванность от проблем начинающих. Буквально, не знание проблем, к примеру сегодня - о фундаментально важной штуке, которая, как я предполагаю, многих не коснулась вообще(к примеру меня). Вместе с тем, она может полностью обрубить изучение программирования, и привести затраченные усилия к нулю.

Что значит программировать, и почему многие не понимают этот процесс

Давайте начнем с утрированного примера(так проще объяснить). Вот есть манагер абсолютно не понимающий в разработке, и при этом стоящий над разработчиком(так быть, разумеется, не должно). Как он видит процесс работы программиста, насколько он оценивает его профессионализм?

Программист смотрит документацию(он что ее не выучил?), это еще что, он буквально гуглит какие то решения(точно ничего не знает) и смотрит чужой код(ну это уже за гранью наглости), да и к тому же в конце его всегда ждут ошибки(и почему его вообще взяли?) и вообще пол дня сидит, бороду чешет уставившись в экран.

Очевиден сюр подобных умозаключений. Понятное дело, что никто так не думает, и менеджеров таких нет, но если уменьшить градус бреда, то так ли далек этот утрированный пример от отношения к разработке за пределами it?

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

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

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

И чем раньше к этому процессу придет новичок, тем быстрее поймет, что такое программировать и нужно ли оно ему вообще.

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

Приветствую, я разработчик, и так получилось, что за последние 2-3 месяца, некоторые мои знакомые решили приобщится к предмету моей же деятельности. На очередной итерации процесса отсмотра/поиска/вспоминания учебных материалов, пришла очевидная идея - отсортировать ссылки и выпустить за пределы нашего уютного чатика.

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

https://github.com/danistefanovic/build-your-own-x Легендарный репозиторий, который несмотря на огромную популярность(75к звезд на github), все еще многим не известен, и что особенно печально - многим начинающим программистам.

Если кратко - подборка туториалов, основная идея которых - создание с нуля какой то сложной технологии. К примеру: языка программирования, операционки, воксельного движка, физического движка и прочего. Всю эту красоту, оглавляет цитата Фейнмана, которая объясняет философию этой подборки - "Чего не могу создать, того не понимаю".

https://ruslanspivak.com/lsbasi-part1/ - один из туториалов, по моему мнению, лучший во всей подборке. Цикл из 19 статей, в котором автор(Ruslan Spivak), пишет интерпретатор языка Pascal на Python. По сути - полноценная книга с подробнейшим разбором, графическими пояснениями, примерами из жизни, даже юмором, а в конце каждой главы - вопросы для проверки понимания темы и домашнее задание. В данном случае формат блога, в нем есть комментарии(из особенно интересных - переводы на другие языки программирования), и обновления, к примеру, последняя статья вышла совсем недавно - 19 марта.

Очевидно, что это довольно сложная штука, и тут речь даже не о коде(кстати отличный пример ооп на python), дело в сложности самой технологии. Можно привести аналогию с книгой "Код" Петцольда(крайне рекомендую), книгу можно прочесть не умея писать код вообще, однако, это не значит что процесс изучения будет простым. Сама сложность описываемой технологии не даст это сделать быстро, без вникания в тему и процесса осознавания работы сложной системы.

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

Если подытожить, эти туториалы, хорошо вписываются в момент обучения, когда основы пройдены(у многих приступивших к изучению 2-3 месяца назад, этот момент сейчас), условная книга/курс за плечами, и хочется приступить/разобраться/покопаться в каком то сложном и главное - интересном проекте, а идеи или даже понимания того с чего начать нет.