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

Такой вопрос был в одном из комментариев к посту. Речь идет про написание фронтенда с помощью React.

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

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

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

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

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

Насколько сложно быть фулстеком? Этот вопрос не раз становился яблоком раздора между разными людьми. Одни говорят, что это невозможно, другие — что компании просто хотят экономить. Третьи же пишут фронт, бэк и еще успевают заниматься администрированием. Разберемся и подискутируем?)

Короткий ответ: конечно да, таких людей вокруг нас полно.

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

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

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

У меня этот путь занял около семь лет, что довольно долго. То есть я пять лет занимался только бэкендом. HTML/CSS туда немного входили, но JS — нет. И только потом я взялся за фронтенд. Правда, справедливости ради, до фронтенда я изучил администрирование и функциональное программирование. Сейчас же написать бэк на Elixir, настроить Kubernetes кластер или запилить приложение на React — как раз плюнуть :) На это хватило «всего-то» 15 лет жизни.

Есть несколько распространенных заблуждений, которые транслируют, если речь заходит про фулстеков. Вот некоторые из них:

> Фулстек — это недопрограммист, он плохо разбирается и в бэке, и во фронте.

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

> Понятие «фулстек» придумал бизнес, чтобы экономить.

Фулстек — это часть профессионального пути. И на самом деле, человек с 10 годами опыта должен быть уже не только фулстеком, но и всестеком + тимлидом и, может быть, техническим директором.

Хотел поделиться видео, в котором Саша, который делал хекслет очень много лет, показывает в прямом эфире как он разрабатывает платформу https://www.youtube.com/watch?v=SKLH1C1sl0o

Написал большую статью про то как организовывать доски в ноушене. Рекомендую для прочтения https://vc.ru/services/605683-kak-pravilno-organizovyvat-doski-v-notion-i-ne-tolko

Одна из краеугольных тем в программирование это состояния системы. Тема глубокая, повсеместная и ее понимание может сильно изменить взгляд на вещи. Разберемся с ней на примере страницы курса на Хекслете. Откройте для примера этот https://ru.hexlet.io/courses/js-ddd

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

Возьмем кнопку справа. Что у вас там отображается прямо сейчас? Например я сейчас вижу “зарегистрироваться”. Но если я залогинюсь, то увижу уже другую кнопку, там будет что-то другое. Причем это другое тоже будет зависеть от того, вступал ли я в этот курс или нет, платил ли я за него или нет.

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

Кнопка о которой мы говорим имеет 5 состояний! Это значит, что даже для банальной проверки, того как она выглядит, нужно проделать множество действий. А кроме кнопки на странице множество других элементов. Если уроки пройдены, то они отмечаются специальным образом. Если пользователь вступил в курс, у него добавляется сверху блок, который показывает статистику прохождения этого курса. Суммарно все это может приводить к десяткам состояний на одной странице. С точки зрения сроков разработки, стоимости поддержки и сложности тестирования, изначальная оценка вырастает сразу в несколько раз как минимум. А может даже на порядок.

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

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

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

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

Со стороны может показаться, что тренажер — это просто редактор кода, который умеет запускать его на выполнение. Это будет правдой, если мы говорим про https://code-basics.com. Там тренажер устроен действительно просто: по кнопке «запустить» написанный код отправляется на сервер, где он и запускается. Результат отправляется обратно в браузер, где уже выводится пользователю.

На Хекслете тренажер устроен значительно сложнее. Он включает в себя множество элементов:

Редактор, у которого есть фронтенд и бэкенд часть
Фронтенд-код для взаимодействия с редактором со стороны Хекслета. Он получает от редактора различную информацию — например, успешность прохождения тестов.
Сами задания, которые разрабатывает выделенная команда внутри Хекслета
Бэкенд-код для обслуживания заданий внутри Хекслета. Он загружает задания внутрь системы, обновляет их, запускает и выполняет другие служебные задачи.
Инфраструктуру из примерно 10 серверов, на которых запускается практика.

Зачем все это нужно? Тренажер Хекслета специально создавался как универсальный инструмент, с помощью которого можно запускать практически любую задачу — от простого выполнения функций до разработки полноценных приложений с базами данных и веб-серверами. И у нас это получилось.

Каждое задание на Хекслете представляет из себя мини-сервер (технически, это Docker-контейнер), который запускается при старте практики. Редактор запускается внутри этого сервера для каждой задачи. С его помощью можно не только писать код в каких-то файлах, но и получить полный доступ к внутренностям «сервера» через терминал.

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

Вот примеры задач, которые мы создаем для наших пользователей:

Написать кусок кода в рамках приложения
Разработать приложение с использованием какого-то фреймворка
Научиться пользоваться командами Bash
Изучить работу Git
Протестировать сайт
Изучить инструменты управления конфигурацией, например, Ansible
Изучить команды SQL

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

Как-то здесь написали, что пет-проекты — это всё, что нужно, чтобы стать мидлом. В реальности всё чуть сложнее, поэтому пришлось встать с дивана и написать этот пост.

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

Но есть другая сторона, которая намного более важная, так как прокачать ее самостоятельно не получится. Сюда входят:

>> Риски и ошибки, связанные с обслуживанием приложения, которым пользуются в реальном времени

Пет-проекты не несут никаких рисков. Упал сайт? Просто перезапустили. Случайно стерли базу данных? Ничего страшного. Нужно обновиться? Остановили сайт.

Всё это невозможно в реальной среде, где есть настоящие пользователи. Остановка сервиса может повлечь за собой потери миллионов, уничтожение инфраструктуры — потери всего бизнеса. Здесь нужно думать о бэкапах, о том, как новые изменения отразятся на старых пользователях.

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

Как говорится: «Не ронял прод, не мидл».

>> Процессы разработки.

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

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

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

В любом случае, на пет-проектах получить такой опыт не удастся.

>> Взаимодействие с другими членами команды: программистами, тестировщиками, администраторами.

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

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

Кстати, на эту тему есть хорошая книга от Роберта Мартина, называется «Идеальный программист»: https://ru.hexlet.io/pages/recommended-books

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

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

На всё это накладываются инструменты проектного менеджмента, такие как jira или trello.

Где-то здесь появляются слова Agile, Scrum и Kanban, которые превращаются в конкретные процедуры того, как движется процесс разработки.

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

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

Из-за этого организовать обучение “до мидла” достаточно сложно. Фактически, ни у кого пока это не получилось. Но есть луч надежды. Когда-то подобное обучение на продакшене было организовано в компании андев, в 2011 году. Мы сейчас работаем над тем, чтобы повторить этот опыт уже для Хекслета.


p.s. В нашем блоге есть статья, дополняющая этот пост https://ru.hexlet.io/blog/posts/developers-business-value

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

Исходные данные: ребята из компании Undev, в которой я работал в Москве, связались со мной и попросили помочь выстроить техническое представительство в Ульяновске. Мне предстояло собрать большую команду Ruby-разработчиков, так как именно Ruby был основным языком в компании. Засада была в том, что во всем городе было ровно 3 Ruby-разработчика. Было понятно, что для планируемого роста нужно искать перспективных ребят из других компаний, переманивать их и растить.

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

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

Обучение я строил так. Первые две-три недели было изучение самого языка + сопутствующих технологий — например, Git, командная строка и так далее. Для этого были подобраны книги, интернет-ресурсы и различные обучающие сервисы. Не курсы, скорее это были либо специализированные тренажеры, либо Kata

Почему на язык так мало времени? Тут все прост: в отличие от студентов на курсах, эти ребята пришли работать работу, и если задержать обучение, то резко падает мотивация. Им хочется быстрее переходить к задачам, и эти люди в целом способны находить проблемы и самостоятельно их решать. Поэтому доучивать язык в процессе для них совершенно естественно.

Самое интересное — это то, что происходило во время этого обучения. Фактически я проводил 70% своего времени с этими ребятами, которых могло одновременно обучаться до 15 человек. Два раза в день я проверял, что происходит, направлял, подсказывал с настройкой окружения, давал дополнительные задания, если надо. Если у них были общие вопросы или какие-то затыки, мы собирались у доски и вместе разбирались с этими вопросами в бурных обсуждениях с рисованием.

Как только заканчивался этот этап, мы начинали погружаться в Ruby on Rails — наш основной рабочий фреймворк. Ребята делали тестовое приложение, которое постепенно обрастало разными функциями. Здесь мы часто работали в парах и проводили время у доски. Обычно они изучали возможности фреймворка через онлайн-туториалы, затем мы обсуждали концепции и после этого приступали к реализации.

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

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

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

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

https://vk.com/hexlet?w=wall-54520471_16838 Ответьте на опрос)

Дал большое интервью про то как я шел к айти и вошел в него https://www.youtube.com/watch?v=iM-gFlCLcLk

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

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

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

Если вам самостоятельно сложно выбрать конкретные книги, то можно начать с нашего списка, который содержит только самое важное для всех программистов: https://ru.hexlet.io/pages/recommended-books

p.s. Как эффективно читать профессиональную литературу https://ru.hexlet.io/blog/posts/how-to-read-books

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

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

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

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

#заметки

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

Начнем с того, что популярных языков, которые подходят новичкам достаточно мало. Вот небольшая классификация:
* Массовые и базовые: java, php, js, python, c#.
* Менее массовые и обычно идут как вторые языки: go, ruby
* Особняком Swift для IOS
* Языки обертки, построены на базе других: typescript/js, kotlin/java. Идут как дополнение при трудоустройстве
* Тяжелые языки, из универской среды: c, c++

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

Дальше обычно говорят, выбирай что тебе по душе, фронтенд, мобильная разработка, геймдев или бекенд. Если вы способны на этом этапе выбрать, то действительно за каждым направлением есть более менее определенные языки: фронтенд - js/typescript, ios - swift, android - kotlin (но надо знать java), бекенд - в принципе любой из списка кроме swift. Но не все могут вот так взять и выбрать. Что делать в этом случае? На этом этапе нужно исходить из локации. Смотрите компании в своем городе их вакансии. Обычно разные города имеют разную специфику. Например в Казани много Python, а в Ульяновске много Ruby.

Ну и последний критерий, когда все что выше не работает. Я предлагаю вот такую последовательность: php, js, python, java. Почему именно так? Скриптовые языки (php, js, python) значительно проще остальных. Да кто-то жалуется что с ними не копнешь базы, но надо понимать что копание базы зависит не от языка, а от программы обучения. В этом отношении у Хекслета все в порядке. Я затрону эту тему в одном из следующих постов. А почему php раньше чем js и python? В регионах это наиболее массовый язык, где большая нехватка спецов. Более 70% всех сайтов написано на PHP. JavaScript вторым, потому что это и бек и фронт. А фронт нужен везде, на каком бы языке не был бек. То есть он почти всегда присутствует как второй язык. С питоном чуть сложнее, он популярен да, но далеко не всегда для веб-разработки. Например питон используется для дата аналитики, машинного обучения и так далее. Это требует спец знаний и спец обучения. Ну а Java массовая, поэтому она в этом списке, хотя и кривая обучения у нее сильно выше. Не потому что она глубже, а потому что в самой Java много концепций и подходов специфичных только для Java или статически типизированных языков.

#заметки

По идее я тут должен снова написать "Привет, это Кирилл", но не хочется повторяться) А давайте потренируемся. Задача с собеседования, которую мне задавали в далеком 2009 году. Сейчас такие задачи встречаются редко.

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

Вопрос: как сделать так, чтобы он сгорел ровно за полчаса. Линейки у вас нет.

#заметки

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

Мы обучаем программистов с 2012 года, и вопрос про математику всегда был одним из популярных. Сначала короткий ответ:

Математика для прикладного программирования не нужна!

Теперь чуть подробнее. Основная математика, которая есть в программировании, — это арифметика, немного логики (если A, то B), нахождение остатка от деления или проверка числа на четность. Согласитесь, не рокет сайнс? :) Даже если вы про это не знали или забыли, это легко учится в процессе.

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

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

Когда говорят про то, что математика нужна, имеют ввиду обычно две вещи:

1. Это говорят люди с вышкой. Тут скорее история “мы потратили 5 лет на это, значит, это было не зря”. Причем такие ребята не признаются в этом никогда. Но будут всегда говорить, что математика нужна.

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

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

Недавно мы с вами говорили о том, что первый язык не принципиален. Какой бы язык не был выбран, новичок встречается с одними и теми же ключевыми понятиями. Что к ним относится?

Литералы, Операции, Типы данных, Переменные, Логические выражения и Логика, Циклы и Вызов и Определение Функций.

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

На изучение этих концепций, для минимального уровня понимания, понадобится от 2 недель до месяца при условии хорошо проработанного материала как на code-basics. Как и всегда, главное в этом процессе практика, а не сухая теория.

Приведу пример простой программы на нескольких языках, чтобы вы увидели похожесть. Задача состоит в том, чтобы вывести на экран yes или no в зависимости от того, больше ли пяти сравниваемое число (находится в переменной) или меньше. На псевдокоде это выглядит так: Если a больше 5 то печатай yes иначе no. Вот как выглядит этот код в разных языках:

PHP
$a = 9;
print($a > 5 ? 'yes' : 'no');

JavaScript
let a = 9
console.log(a > 5? : 'yes' : 'no');

Java
var a = 9;
System.out.println(a > 5 ? "yes" : "no");

Python
a = 9
print('yes' if a > 5 else 'no')

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

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

Почему Хекслет перестал делать видеокурсы и переключился на текст?

Когда-то в далеком 2012 году Хекслет пытался быть Курсерой и делал видеокурсы. Спустя несколько лет мы заметили, что с видео есть немало проблем, которые мешают и пользователям, и нам как разработчикам курсов. В чем проблема видео?

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

Так что же не так с рядовым видео? Поехали по пунктам:

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

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

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

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

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

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

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

Текст ускоряет анализ и потребление. Можно больше времени рассматривать или читать ту часть, которая интересна. И наоборот, можно пропускать то, что понятно и неинтересно.

Возможно, у вас возникает вопрос, почему бы не объединить и не делать и текст, и видео? Ответ очень простой: стоимость. Производство хорошего видео стоит бесконечно дорого.
#заметки