Блог Хекслета

Изучать современный JavaScript — болезненно, если вы не знакомы с ним с самого его рождения. Экосистема разрастается и меняется с такой скоростью, что сложно разобраться с тем, какие проблемы пытаются решить разные инструменты. Я начал программировать в 1998 году, но к серьёзному изучению JavaScript приступил только в 2014. В то время я помню как анализировал Browserify и изумлённо смотрел на его слоган:

Browserify позволяет запрашивать (require) модули в браузере, объединяя все зависимости.

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

Цель этой статьи — показать исторический контекст развития инструментов JavaScript до их уровня в 2017. Начнём с самых первых моментов и построим шаблон веб-сайта, как бы это сделали динозавры — без инструментов, чистый HTML и JavaScript. Затем мы будем пошагово вводить различные инструменты, чтобы на практике видеть, какие задачи они решают — поочерёдно. Благодаря историческому контексту у вас будет больше возможностей изучить и лучше адаптироваться к бесконечно меняющемуся JavaScript. Давайте начнём!

Я написал это руководство, чтобы помочь любому присоединяться или выкладывать свои (contributing) open source проекты на GitHub. Одна из причин крутости open source — в желании людей помогать друг другу.

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

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

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

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

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

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

Это перевод статьи Climbing the infinite ladder of abstraction от Алексис Кинг.

Я начала программировать ещё в начальной школе.

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

Это перевод статьи 7 Ways to Improve Your Code Reading Skills от A. N. M. Bazlur Rahman.

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

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

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

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

Если сказать проще — навыки чтения кода совершенствуют навыки написания кода.

Специалисты Facebook обнаружили, что их боты общаются на новом языке. И остановили их.

Боб: “I can can I I everything else.”

Элис: “Balls have zero to me to me to me to me to me to me to me to me to.”

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

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

«Не было никакого смысла придерживаться английского», — говорит Дхрув Батра, инженер Georgia Tech из Facebook AI Research (FAIR). Учитывая то, что эти два агента конкурировали за лучший результат — это такая высокоэффективная схватка ИИ против ИИ — инженеры модифицировали «генеративно-состязательную сеть», и ни у одного из ботов не стало стимула общаться как люди. Поэтому они стали отклоняться от нормы и смешивать реальные слова в кажущиеся бессмысленными предложения.

«Агенты будут отклоняться от понятного языка и изобретать кодовые слова для себя», — говорит Батра, высказываясь в пользу уже предсказуемого явления, которое встречается тут, тут, и тут. «Как если бы я сказал «оно» пять раз, а вы бы поняли, что мне нужны пять копий определённого предмета. Это не сильно отличается от того, как сообщества людей придумывают сокращённые понятия».

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

Определение

Global mutable state содержит в себе три слова, каждое из которых имеет важное значение:

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

Mutable — означает изменяемый (в русскоязычной среде часто говорят «мутабельный», — прим. ред.). Часто можно заметить: все, что может прочитать значение, может так же и изменить его. Два считывания данных, следующих одно за другим, могут возвращать разные значения. Или, что еще хуже, сами возвращаемые структуры данных изменяются после чтения.

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

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

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

Григорий Грудинин прошел все 4 проекта на Хекслете и рассказал о своем интересном опыте. Вот его история:

Всем привет! Хочу рассказать о своем опыте прохождения проектов. Сразу оговорюсь, что узнав о таком интересном нововведение, бросил свой почти законченный путь по стеку PHP и окунулся в мир nodejs. Сделал я это только по одной причине: проекты - это самое важное, что даёт этот образовательный ресурс. Можно долго решать какие-то задачки, проходить курсы, без этого никуда, но основной толчок в собственном понимании того, к чему всё это идёт, дают именно проекты. Признаюсь честно, после прохождения курсов по PHP, курсы по nodejs казались гораздо более продуманными, более ориентированными на новичка. Проходил их достаточно быстро (никогда не делал больше 1-2 шагов в день, иначе решение дается очень легко, но в голове ничего не остается), кроме нескольких довольно сложных моментов, на уроки по которым запросто могло уйти несколько дней, а то и неделя.

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