​​Вдогонку набор простых приёмов, которые помогут меньше отвлекаться на смартфон — http://humanetech.com/take-control/

• Отключите все уведомления, которые приходят не от людей.
• Переведите телефон в чёрно-белый режим. Цветные иконки провоцируют небольшие выбросы дофамина (нейромедиатор, вызывающий предвкушение удовольствия и счастья), из-за этого вырабатывается привычка.
• Уберите с главного экрана все развлекательные приложения, чтобы их было сложнее бездумно открыть.
• Заряжайте телефон за пределами спальни, вместо него используйте отдельный будильник: так вы не будете начинать утро с тупления в экран телефона.
• Отправляйте голосовые сообщения вместо текстовых. Это требует меньше внимания и сил, и к тому же уменьшает вероятность недопонимания — в текстовых сообщениях теряются интонации.
• Крайняя, но действенная мера: удалите приложения соцсетей с телефона.

​​Если вы публикуете NPM-пакеты, попробуйте утилиту np, которая сильно упрощает процесс релиза — https://github.com/sindresorhus/np

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

​​О состоянии фронтенд-экосистемы

css-loader создан для того, чтобы Вебпак обрабатывал @import и url() в CSS так же, как import в JavaScript. ОДНАКО! В его конфигурации есть опция minimize, которая позволяет включить минификацию стилей. Под капотом для минификации используется cssnano, который, в свою очередь, тоже можно настроить. А в продвинутом режиме cssnano (напомню, минификатор стилей) начинает применять Автопрефиксер, который вообще никакого отношения к минификации не имеет.

Принцип единственности ответственности? Не, не слышали.

Для тех, кто беспокоится о скорости загрузки страницы: bundlephobia показывает размер и время скачивания выбранного NPM-пакета — https://bundlephobia.com

Импорт модулей относительно проекта, а не текущего файла

Обычный подход к импорту модуля в проекте — указание пути к нему относительно текущего файла:

import smoosh from '../../../utils/flatten';

Этот подход хрупкий и неудобный:

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

Эти проблемы решаются использованием путей относительно корня проекта, например:

import smoosh from '~/utils/flatten';

Здесь ~ — это алиас корня проекта (например, /Users/andrew-r/work/personal-site/source). Недостаток такого подхода заключается в том, что он не работает из коробки. Чаще всего этот подход используют с Вебпаком, в конфигурации которого можно указать нужные алиасы:

const path = require('path');

module.exports = {
  entry: './source/index.js',
  /* ... */
  resolve: {
    alias: {
      '~': path.resolve(__dirname, './source'),
    },
  },
};

Документация по настройке алиасов в Вебпаке — https://webpack.js.org/configuration/resolve/#resolve-alias

Полина Немчак делится альтернативой в виде переменной окружения NODE_PATH для тех, кто не использует Вебпак. Эта переменная говорит ноде о дополнительных директориях, в которых нужно искать модули при импортах. Можно прописать в NODE_PATH путь к директории с исходниками проекта, тогда импорты будут такого вида:


import smoosh from 'utils/flatten';


Учтите, что при таком подходе повышается вероятность конфликта имён между директориями проекта и установленными NPM-пакетами.

а как же NODE_PATH=./src ?

​​Дизайн-подорожник

Александр Быков пишет серию статей с пошаговыми примерами улучшения дизайна городской среды. Уже вышли три статьи:

Убитый фасад в Новороссийске → https://zen.yandex.ru/media/id/5a78aa06f03173b1df500be8/5a9019a6256d5cdcf7814bdc
Входная группа в брежневке → https://zen.yandex.ru/media/id/5a78aa06f03173b1df500be8/5a97b81877d0e69928b56b41
Петербург — хорошо. Но можно лучше → https://zen.yandex.ru/media/id/5a78aa06f03173b1df500be8/5ac1c8cc610493acb72f9d00

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

​​Если вам нужно захостить статический сайт (или SPA без серверного рендеринга), что-то лучше Нетлифая вы сейчас вряд ли найдёте. На нём уже хостятся сайты с документацией React, Vue, Lodash, Yarn, и многие другие.

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

Помимо прочего, сервис позволяет:
— в один клик (!) создать и привязать к домену бесплатный SSL-сертификат;
— автоматически разворачивать демо-стенды для каждой ветки в гите;
— собирать данные с форм;
— делать сплит-тесты;
— авторизовывать пользователей;
— автоматически деплоить функции AWS Lambda из репозитория.

Вишенка на торте — базовые возможности сервиса (хостинг, CI, DNS, SSL) доступны бесплатно. Короче, в мире хостингов больше не нужно быть девопсом или вебмастером, можно побыть обычным пользователем.

История пройденных собеседований

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

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

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

Общую информацию о компании вроде структуры и процессов. Это расширит ваш кругозор и сэкономит время на повторных собеседованиях.

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

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

Старайтесь записать всё сразу после прохождения собеседования, чтобы важные детали не успели забыться.

​​На случай, если вы не видели: 3Blue1Brown — годный Ютуб-канал с уроками по математике, основанными не на тупом заучивании формул, а на визуализации и объяснении принципов.

Из самого полезного/интересного там есть курсы по линейной алгебре и математическому анализу, а также серия видео с объяснением устройства нейронных сетей. Посмотрел половину курса по линейной алгебре; по сравнению с тем, что было в моём омском ВУЗе — небо и земля.

​​Прочитал «Красную таблетку» Курпатова и рекомендую её всем, кто хочет разобраться, что движет нами и как мы принимаем решения, какую роль в нашей жизни играют мозг и сознание, как избавиться от страданий и начать жить чуть более осознанно — http://andrew-r.ru/notes/red-pill

​​Почему стоит перейти с поиска Google на DuckDuckGo — https://www.quora.com/Why-should-I-use-DuckDuckGo-instead-of-Google

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

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

​​Программирование без дураков

Книга оказалась довольно общим руководством по работе программистом. Найдёте в ней рекомендации по написанию/чтению кода, работе в команде, поверхностный обзор общих концепций и инструментов. Будет особенно полезна джуниорам, но и мидлы, скорее всего, найдут для себя что-то новое — http://andrew-r.ru/notes/weniger-schlecht-programmieren

Почему браузер читает CSS-селекторы справа налево

Если вы не знали об этом, браузер читает селекторы справа налево, то есть обрабатывая селектор #widget .heading span он в первую очередь найдёт все спаны, затем выберет только те, которые лежат внутри .heading, а затем оставит только спаны, лежашие внутри #widget.

Звучит нелогично, но причина такого поведения в том, что задачи разработчика и браузера несколько отличаются. Задача разработчика при чтении или составлении селектора — получение соответствующего ему набора элементов. А для понимания задачи браузера нужно немного контекста.

Прежде чем отрисовать страницу, браузер строит дерево отображения (render tree). Оно состоит из объектов отображения — визуальных элементов страницы, расположенных в том же порядке, в котором они должны быть выведены на страницу. Дерево отображения строится на основе DOM, но в него не попадают невизуальные элементы вроде head или элементы с display: none;, а сложным элементам вроде select могут соответствовать несколько объектов отображения.

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

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

Рассмотрим тот же пример с селектором #widget .heading span. Предположим, что браузеру нужно определить, подходит ли этот селектор к элементу div. Если бы браузер читал селектор слева направо, ему бы пришлось найти на странице элемент с идентификатором widget, внутри него найти все элементы с классом .heading, а затем найти внутри все span и проверить, есть ли среди них тот самый div. Это очень много работы. А благодаря чтению справа налево браузер может сразу определить, что span и div — принципиально разные элементы и поэтому селектор не подходит.

​​Организация файлов по фичам, а не техническим аспектам

Если вы используете Редакс и в корне вашего проекта есть директории actions, reducers, constants и selectors, попробуйте другой подход к организации файловой структуры (если не используете Редакс, тоже может оказаться полезным) — http://andrew-r.ru/notes/features-not-tech-aspects

​​Атлант расправил плечи

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

http://andrew-r.ru/notes/atlas-shrugged

​​Кастомные элементы ГитХаба

ГитХаб ещё с 2014 года использует веб-компоненты в продакшене. Часть компонентов инженеры ГитХаба выложили в опенсорс:

— custom-element boilerplate, стартовый шаблон для веб-компонента;
— time-elements расширяет возможности стандартного <time>;
— clipboard-copy при клике копирует заданный текст в буфер обмена;
— auto-check автоматически валидирует значение поля через указанную ручку серверного API;
— markdown-toolbar реализует кнопки для форматирования текста в markdown в <textarea>;
— image-crop реализует интерфейс обрезания фоточек;
— include-fragment подгружает фрагмент HTML и заменяет себя им;
— task-lists реализует список задач с поддержкой drag’n’drop;
— auto-complete реализует поле ввода с автодополнением и подгрузкой вариантов с сервера;
— details-menu реализует выпадающее меню на основе элемента <dialog>;
— details-dialog реализует модальное окно на основе элемента <dialog>.

Кажется, это и есть будущее разработки интерфейсов. jQuery-плагины морально устарели, React/Vue/Angular-компоненты сильно всё усложняют и плохо влияют на производительность, а кастомные элементы максимально просты (подключаешь скрипт и используешь их в любом месте разметки) и работают на основе нативных возможностей браузера.

​​Два немецких студента в качестве дипломной работы сделали прототип браузера будущего. Мне особенно понравился концепт истории посещений в виде таймлайна, гораздо лучше обычного списка сайтов — https://refresh.study

​​​​Юридические вопросы

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

Ребята из Т—Ж делают крутое СМИ про деньги, в котором простым языком разбирают юридические вопросы вроде аренды/покупки недвижимости, налоговых вычетов и всего подобного → https://journal.tinkoff.ru/

Ребята из «Модульбанка» ведут «Дело» — издание для предпринимателей, в котором так же просто рассматриваются взаимоотношения предпринимателя и государства → https://delo.modulbank.ru/

Юристы Владимир Беляев и Дарья Тимохина делятся лаконичными шаблонами документов без воды и канцелярита → http://outlaw.center/documents.html