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

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

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 с большой. В таком случае, можно сделать вывод - стоит написать архиватор который будет в зависимости от веса файла решать какому алгоритму его скормить.