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

Дабы канал не был пуст, я перепощу первый выпуск своего «дайджеста для изучающих программирование»

https://pikabu.ru/story/dlya_izuchayushchikh_programmirovanie_chast_0_gde_nayti_idei_i_realizatsii_slozhnyikh_proektov_7534176


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

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

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

Канал несколько дней пустовал, так получилось, что я был дико загружен последние несколько дней. Но уже готовлю новые посты, они выйдут завтра. Спасибо, что подписались)

P.S. Новый выпуск дайджеста только что вышел на пикабу

Воу, вас уже 160, честно сказать - не ожидал, Спасибо)

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

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

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

3. Чуть попозже, проведу опрос, чтобы понять примерно кто какого уровня, и какой материал более востребован. Но при этом, буду стараться делать посты для разного(от 'полный ноль' и до 'пора на собес').
#о_канале

Снобизм и наслоение

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

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

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

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

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

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

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

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

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

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

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

Gamedev от cs50

Думаю, многие знают о cs50. https://www.youtube.com/watch?v=SW_UCzFO7X0 [ссылка на переведенную версию]- наверно это самый популярный курс по вводу в computer science. В одном из постов, я говорил о нем, как о примере, правильной/интересной подачи сложного материала. 

Так вот, оказывается, у него есть очень неожиданное(по крайней мере, для меня), ответвление. Gamedev, т.е. разработка игр - https://www.youtube.com/watch?v=GfwpRU0cT10 [англ]

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

Карта computer science. Нравятся подобные видео, видно взаимодействия в cs, при этом выдержан баланс между достаточно подробным(для 10 минут, уж точно) и интересным повествованием, ну и разумеется визуалка на уровне.

Ну и самый приятный момент - есть русские субтитры.  

https://www.youtube.com/watch?v=SzJ46YA_RaA

#cs #youtube

Приветствую.

Две недели назад, я начал вести этот канал. Даже предположить не мог, что на него подпишется более 200 человек. Это внушительная цифра, спасибо)

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

У меня немного 'гудит' мозг, что бы писать, что то серьезное. Поэтому набрасал небольшую заметку, о фишке, которая в свое время помогла мне сдвинуться с мертвой точки при изучении английского.
https://pikabu.ru/story/angliyskiy_yazyik_uchitsya_ponimat_yazyik_a_ne_perevodit_dlya_izuchayushchikh_programmirovanie_7598240

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

GPT-3 | Это стоит видеть

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

Собственно, случилось. Со вечера вчерашнего дня только и обсуждаем GPT-3. Мягко сказать - впечатляет. Наверно, нужно больше рассказать о ней, но есть проблема - даже описание может стать спойлером, потеряется этот момент удивления.

Поэтому, просто оставлю ссылку на перевод: https://habr.com/ru/company/itsumma/blog/511690

Здесь оригинал: https://maraoz.com/2020/07/18/openai-gpt3

На том же Хабре, вышел пост, где специалист по ИИ делится мнением относительно статьи выше. Очень хорошо дополняет картину: https://habr.com/ru/post/511764

На vc вышла подборка, с примерами применения GPT-3. Наверно самый впечатляющий, для меня, пример - подается словесное описание приложения, нейронка сама его создает: https://vc.ru/ml/143516

#ии #нейронки #habr #vc

Написал пост, о том, как с помощью сочетания отличных учебных материалов, перейти к сложным проектам

https://pikabu.ru/story/python__dlya_izuchayushchikh_programmirovanie_chast_2__luchshiy_simbioz_uchebnyikh_materialov_kak_pereyti_k_bolshim_proektam_7610905

Интересные проекты из скучных

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

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

Сама формула: добавить реализаций >> сравнить их между собой(проанализировать) >> возможный шаг - изменить масштаб. Для примера, рассмотрим "крестики-нолики", кажется, в каждой второй книге по вводу в ЯП предлагают написать эту игру. 

Добавить реализаций
В чем суть программы? В игре, в реализации алгоритма игры, самый простой вариант - рандомно ставится крестик/нолик в незанятую ячейку, и так до выполнения условия для победы. Очевидно, рандом - так себе реализация. Можно зайти в википедию и узнать про метод минимакса, комбинаторику, разные стратегии, дерево игровых ситуаций и т.д. Можно в гугле найти "как выигрывать в 'крестики-нолики'", и попробовать реализовать разные варианты самому. Да даже, просто первый ход в центр поля, дает преимущество, и улучшают метод полного рандома(кстати, в игре разные варианты реализаций, можно представить как уровни сложности).

Тут важно сказать одну вещь, она как раз относится к таким простеньким играм, если в игре реализовано взаимодействие человек vs компьютер, то ОБЯЗАТЕЛЬНО, должно быть вариант компьютер vs компьютер, кажется мелочь, но на деле архиважная штука, особенно, если взаимодействие происходит в окошке терминала. 

Сравнить их между собой(проанализировать)
Именно на этом шаге, проект становится интересным. Что в данном случае сравнивать? Очевидная метрика игры - победа/проигрыш/ничья, еще на ум приходит количество ходов. Пару счетчиков, и у нас уже есть цифры которые можно сравнивать. Самый простой пример: в позапрошлом абзаце, я написал, что 'первый ход в центр поля, дает преимущество', вроде бы логично, но нет примерной цифры, насколько это большое преимущество, нужно это проверить. Запускаем, предположим 1000 итераций игры, игрок A всегда начинает с занятия центра поля, дальше идет рандом, смотрим какой процент игр, в итоге, выиграл игрок A.

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

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

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

Эти же правила применимы к некоторым cs проектам(хотя они и так самодостаточны). К примеру, возьмем все тот же архиватор, разные варианты сжатия, разные алгоритмы.

Какие лучше работают на большом изображение, а какие на мелких, все те же? Анализ может, например, показать: алгоритм A быстро и хорошо справляется с небольшой картинкой, алгоритм B с большой. В таком случае, можно сделать вывод - стоит написать архиватор который будет в зависимости от веса файла решать какому алгоритму его скормить.

Вышла первая часть - ‘плана изучения программирования’.

Pikabu - https://pikabu.ru/story/_7790900
Reddit - https://www.reddit.com/r/Pikabu/comments/jhvuqx

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

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

План изучения программирования| Часть 1 (кратко)

1-4: об уч. материалах
5,6: о самом процессе программирования

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

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

Почему автоматизация рутины?
Что бы как можно раньше прикоснуться к процессу программирования. Это не строгое ограничение, скорее рекомендация на какие задачи стоит обратить внимание в самом начале. Книга Свейгарта породила огромную волну материалов по "автоматизации". Если вбить на ютубе "python automation", темы роликов будут от работы в Excel до знакомств в Tinder(десяток подобных видео, и алгоритм рекомендаций избавит от нехватки новых идей).

3. https://stepik.org/course/575 - курс по автоматизации тестирования, нам интересны первые две его части. Там про selenium - инструмент, для автоматизации в браузере(это про - зайти на страницу, заполнить форму, нажать кнопочки, оставить комент и т.д. и т.п.).

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

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

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

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

5.1.Самое важное: Контроль происходящего
Ищем ответ на Stackoverflow, видим - понятный, но в 10 строк или не понятный, но небольшой, сразу хочется забрать, пригреть в своем коде. Так делать не стоит. Проблема в том, что на уровне планирования, контроль, не будет потерян(код что то делает, не знаем что именно, но знаем результат), но вот на уровне реализации - теряется, мы не понимаем что происходит, и это - прямой путь к говнокоду(lkz рутинных проектов, это скорее всего будет работать, но вот дальше, создаст кучу проблем).

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

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

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

6. Уровень планирования. Какого-то строго перехода/переключения, с одного уровня на другой - нет(понимание придет на практике). Главное помнить - этап планирования происходит постоянно, он не заканчиваться блок схемой/псевдокодом, он параллелен написанию кода.(в 'большой' версии поста следующие 2 пункта основаны на примере, здесь - только вывод)

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

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

Вышла вторая часть - ‘плана изучения программирования’.

Pikabu - https://pikabu.ru/story/_7869855
Reddit - https://www.reddit.com/r/Pikabu/comments/k4nj7z

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

План изучения программирования| Часть 2 (кратко)

Жалел, что не поделился этими 2 ссылками в прошлом посту, они сложнее - выбивались подхода, о котором писал выше

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

2.https://youtu.be/g6zzZxxifAw - один из лучших каналов для изучающих python. Ссылка на видео, где разбирают исходники одной python библиотеки. Отдельно стоит отметить стримы с code review.

3. DRY [Don't repeat yourself(не повторяйся)]
Не повторяйтесь, скорее всего это не нужно. Если в коде, подряд повторяется одно и тоже - нужен цикл, если повторяется, но в разных местах - нужна функция.

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

Очень естественным путем становится понятно зачем нужно все вышеперечисленное(те же, комментарии - ровно в тот момент, когда сам себе впервые задаешь вопрос - "почему/как/что я здесь написал?"), и если надобности в этом нет - то стоит задать вопрос "действительно ли задача этого требует?".

5. Самый верный способ понять 'что не так/где проблема' - построчный 'проход' кода(смотрим и объясняем себе же, что конкретно происходит в каждой строке)

6. Программирование всегда про рациональный подход

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

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

7. Язык программирования это инструмент, книги/курсы по япам это инструмент для изучения инструмента

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

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

https://pikabu.ru/story/_7878526
https://www.reddit.com/r/Pikabu/comments/k7zowk

Как то я уже делал пост-список учебных материалов для изучающих python, они не были в рамках какого то плана, просто разделены на 3 уровня сложности. 

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

Все в одном месте, думаю это удобно, время от времени, по ходу плана буду делать подобные посты. 

https://pikabu.ru/story/_8003435

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

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

Про цепи Маркова и Как делать учебные проекты.

Перед тем, как рассказывать об интересных идеях для проектов, я подумал, надо бы расписать как их вообще делать. 

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

Для примера, прогнал через нее небольшое количество(≈50-100) цитат Аристотеля(алгоритм работает до символа точки, т.е. выдает по предложению), из осмысленного она сгенерировала:

Шутка есть самый верный признак дружбы.
Свойство добродетели состоит, скорее, в досуге.
Разум - это довольство собою.
Благодарность быстро стареет.

(из 20 примерно 3 удачных(15%), но никаких условий, кроме остановки на символе точки нет, можно эту цифру значительно повысить, к примеру, исключить слишком короткие предложения(меньше 2 слов), убрать их подаваемых данных слишком отличающиеся по стилю, и т.д и т.п)

Хотя рассматриваем все на примере цепи маркова, сами шаги везде одинаковы.

1. Понять как эта штука работает.
Цепь Маркова, в данном случае, очень показательна. Она не то, чтобы сильно известна, придется проделать небольшую работу по исследованию/изучению, но при этом, она достаточно понятным образом работает.

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

Мне кажется, лучшее объяснение цепей Маркова написал Alexander Dejeu
Оригинал: https://hackernoon.com/from-what-is-a-markov-model-to-here-is-how-markov-models-work-1ac5f4629b71
Перевод: https://tproger.ru/translations/markov-chains/

2. Реализация.
Вот здесь псевдокод/блоксхемы, как никогда уместны. Набрасываем шаги, от которых и будем отталкиваться. Для цепи маркова - 2 шага: 1 - делаем данные удобными для алгоритма, 2 - алгоритм идет по данным(сам алгоритм считает следующий шаг на основе настоящего,игнорируя предыдущие). Далее отталкиваемся от этих шагов.

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

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

3. Code review
Ревью кода - архиважная вещь, наверно самая большая потеря в самостоятельном изучении. Но все равно, неплохой идеей, будет смотреть ревью чужого. Дело в том, что ошибки плюс/минус у всех похожи. И читая о чужих о чужом коде, можно узнать многое о своем. 

Хороший пример крутого code review: https://codereview.stackexchange.com/questions/193419/markov-chains-to-generate-text
Запрос в гугле: code review + markov chain + python, скорее всего выдаст первым сайт выше(этот сайт относить к той же сети, что и stackoverflow)

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

Это имеет мало смысла в учебных проектах, поскольку одна из причин их делать - научиться переводить свои идеи в код(а чтобы они стали своими, сначала нужно понять принцип работы(п.1), а потом самостоятельно выстроить реализацию(п.2)).

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

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


Что из этого можно сделать?
Цепи Маркова - настоящий простор для интересных идей. К тому же, они довольно эффектно работают, и скажем так, опережают ожидания.

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

Довольно интересный вариант: чат-бот, с анализом тональности(т.е. программа оценивает эмоциональный окрас сообщений собеседника) Обе эти темы относятся к задачам обработки естественного языка(Natural Language Processing). Крутой курс об этом: https://youtu.be/5BVebXXb2o4 [англ.] 6 уроков, как раз включая цепь маркова и тональность текста.

Разумеется, можно генерировать не только текст, программе все равно что за данные ей подаются. Один из самых примечательных вариантов - музыка. К слову, по запросу “markov chain music” гугл на первой же странице выдает ссылки на университетские статьи. 

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

Вообщем, применение цепей Маркова - необъятная и очень интересная тема, куча возможностей для экспериментов и крайне занимательная штука. 
#идеи_для_проектов #цепь_маркова