Angulareact

У меня есть проблема. Приложение написано на Angular, а библиотека компонентов на React. Делать клон библиотеки слишком дорого. Значит, нужно использовать React‑компоненты в Angular-приложении с минимальными затратами. Разбираемся как это делать.

19.09.2019 Читать на Habr

Инструкция: хостим сайты

Короткая практическая инструкция по хостингу любых сервисов. Единственное требование — завернуть приложение в Docker‑контейнер, взамен получаем автоматическую генерацию nginx-конфигов, HTTPS из коробки, надёжность и простоту.

27.08.2019 Читать на Medium

Инструкция: бэкап GitHub

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

15.07.2019 Читать на Medium

Кейс: воркер‑треды

Node.js работает в одном потоке. Чаще всего это не создаёт проблем, потому что почти все операции в наших приложениях неблокирующие. Недавно я делал обработку натурального языка на JS и упёрся в однопоточность. Решение — воркер‑треды.

10.07.2019 Читать на Medium

Как мы делаем CI/CD

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

02.07.2019 Читать на Medium

Самый важный навык, который может освоить программист

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

26.06.2019 Читать на Medium

Конфигурация NodeJS приложений

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

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

• идентификаторы подключения к ресурсам типа базы данных, кэш‑памяти и другим сторонним службам;
• регистрационные данные для подключения к внешним сервисам, например, к Amazon S3 или Twitter;
• значения зависимые от среды развёртывания такие, как каноническое имя хоста.

Простой путь

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

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

Правильный путь

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

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

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

Все это и больше

Итак, в большинстве приложений есть три варианта развёртывания:

• боевое, конфигурация передаётся через переменные окружения;
• локальное, конфигурация передаётся через .env файлы;
• тестовое, конфигурация передаётся из констант внутри кода.

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

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

@solid‑soda/config

В мире PHP есть отличное решение — Symfony Config Component. Эта библиотека умеет делать все что нужно для конфигурации приложений. Она вдохновила меня на создание @solid‑soda/config — абстракции над конфигурацией, которая предоставляет удобный и безопасный интерфейс для доступа к параметрам в Node.js.

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

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

Конфигурируйте!

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

11.05.2019Скопировать ссылку

Лёгкий фронтенд

Современный веб пронизан фреймворками. Это не плохо! Проекты запускается быстро, а поддерживать их легко. Но иногда стоит избегать использования сторонних решений.

Сайты должны быстро грузиться при любом интернете и хорошо работать на любом устройстве. Если сайт маленький, то добиться этого легко отказавшись от фреймворков и используя только HTML/CSS/JS.

Довольно просто построить статический сайт быстро, не потерять в поддерживаемости и качестве кода.

Как

Обычно, когда берут генератор статики на React (Vue, etc), хотят получить удобный компонентный подход. Есть способ добиться аналогичного результата без такого большого оверхеда. Для повторного использования разметки лучше взять любой шаблонизатор (twig, pug) и делать в нем миксины. CSS же отлично изолируется БЭМ‑нотацией или CSS-модулями (да, и их можно использовать просто так).

Отказ от фреймворка не означает возвращение в прошлое. Можно все ещё использовать современные возможности JS и CSS, и обрабатывать их Babel и PostCSS (а для разметки возьмите PostHTML).

Хитрый шаблонизатор, пост‑процессоры и транспайлеры нужно как-то удобно запускать, чтобы на выходе получать набор файлов понятных любому браузеру. Тут можно взять абсолютно любой бандлер, но лучше посмотреть на максимально простые в конфигурации — Parcel, Rollup.

Ещё

• Обратите внимание, сколько будет весить JS который вы написали. И сравните с весом любимого фреймворка. Для контроля размеры бандла используйте size‑limit.
• Все это будет бесполезно, если не следить за интерфейсными изображениями на сайте. Посмотрите доклад Вадима Макеева.
• Подумайте о полифилах. При таком стиле разработки сайта никто за вас не включит в бандл полифилы, потому следует чётко понимать какие возможности в каких браузерах есть и следить за этим.

Построение таких сайтов изменяет мышление и будет полезно любому фронтенд разработчику. Попробуйте!

25.03.2019Скопировать ссылку

Как работать с денежными значениями в JavaScript

Деньги везде. Банковские приложения, интернет‑магазины, платформы для фондовых бирж, мы встречаемся с деньгами каждый день. И все чаще мы доверяем работу с деньгами технологиям. Перевод статьи о частых ошибках и принятых шаблонах при работе с денежными значениями.

23.01.2019 Читать на Medium

Процесс подготовки npm‑пакета

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

18.01.2019 Читать на Medium

Чистая архитектура

В процессе чтения книги Дядюшки Боба «Чистая архитектура» писал себе заметки. Для удобства собрал их в единый конспект. О ценностях программы, парадигмах в программировании, принципах SOLID и важности тестирования.

05.12.2018 Читать на Medium

Не решайте воображаемые проблемы

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

07.11.2018 Читать на Medium