На React Amsterdam был хороший доклад от создателя MobX о разделении состояния и представления приложения — https://youtu.be/3J9EJrvqOiM

Лучший момент в этом докладе — когда Мишель закомментировал строчку с ReactDOM.render(...) и как ни в чём не бывало продолжил пользоваться демо-приложением прямо через консоль браузера, без UI.

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

Помимо прочего из доклада вы узнаете, как перестать зависеть от lifecycle-методов Реакта (да, можно запрашивать данные не только в componentWillMount).

Кроме этого доклада есть подробная статья, в которой пошагово демонстрируется разработка приложения с роутингом, загрузкой данных, аутентификацией и юнит-тестами без привязки к представлению — https://hackernoon.com/cc90b787aa37

Крутая демонстрация принципа работы экранов, от кинескопических до жидкокристаллических LED и OLED — https://youtu.be/hclQc7nzpN8

В package.json есть поле engines, в котором можно указать используемые в проекте версии Node и NPM. Однако установка соответствующих версий остаётся на совести разработчиков.

Чтобы у всех разработчиков использовалась одинаковая версия Node, установите нужную версию как зависимость:

npm install node@8.9.0 -DE

Все NPM-скрипты запускаются в той версии Node, которая указана в списке зависимостей

Крутой блог и рассылка (там ещё книга есть, но её я не читал) о том, как тратить на работу меньше времени, при этом делая и получая больше — https://codewithoutrules.com/

Юридические документы не должны быть длинными и непонятными. Ребята из wheely сократили свой трудовой договор в 5 раз, просто убрав всю воду — https://wheely.com/blog/cut-the-contract/

Онлайн-журнал, работающий только в офлайне, чтобы читателя ничего не отвлекало — https://thedisconnect.co/

Если вы пишете тесты на Редакс-редьюсеры так же, как это делается в документации Редакса, не мучайтесь: http://andrew-r.ru/notes/simplified-redux-reducer-tests

Если вам или вашим детям скоро заканчивать школу, попробуйте отложить поступление в ВУЗ на год — https://mel.fm/vypuskniku/6903285-gap_year

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

Я поступил в ВУЗ сразу после школы, как и большинство моих одногруппников. При этом более чем из 30 человек в группе реально интересовались программированием ну от силы 5 человек. При таком уровне заинтересованности нет вообще никакого смысла тратить бюджетные деньги, а главное, время студентов. Зачем тогда все поступали, да ещё и на специальность, в которой не заинтересованы? Потому что так принято — после школы приличный человек должен идти в ВУЗ. А из этого следует то, что выпускники поступают не куда им действительно хочется, а куда хватает баллов.

Ваня Акулов (@iamakulov_channel) наоборот доволен тем, что пошёл в ВУЗ раньше:

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

Оказывается, на официальном сайте правительства РФ можно скачать нескучные обои для рабочего стола и даже для телефона — http://gov.ru/main/page2.html

Пару лет назад я пытался пользоваться RSS-читалкой для отслеживания новых материалов по фронтенду, но забросил это, потому что помимо неё я читал email-рассылки и ленты ВК/Твитера — получалось слишком много источников информации. Недавно обнаружил идеальный способ подписки на RSS: сервис https://blogtrottr.com позволяет подписаться на любой фид и получать по почте дайджест материалов этого фида с нужной частотой. Я так подписался на Хабр и несколько технических блогов.

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

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

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

​​Я не очень люблю хайповые статьи в духе «Пишем список дел на (название фреймворка или технологии)». Значительно полезнее оказываются статьи и доклады о боевом опыте разработки фронтенда в реальных компаниях. Собрал большой список таких материалов: https://github.com/andrew--r/frontend-case-studies

История о том, как я радовался, что SMIL задепрекейтили и поэтому можно не тратить время на его изучение, а потом его решили РАЗДЕПРЕКЕЙТИТЬ

Как капитализм может помочь техническому отделу большой компании

В мою коллекцию материалов о разработке фронтенда в реальных компаниях недавно прислали пулреквест с рекомендацией статьи Free-market software development Мэтта Чедбёрна из Financial Times (ранее The Guardian и BBC). Я проникся этой статьёй, потому что она совпадает с моими наблюдениями за время работы в Avito.

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

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

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

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

В одной из статей Яндекса наткнулся на иллюстрацию к одному из их заданий на собеседованиях: сверстать такую иконку, используя минимальное количество HTML-элементов