Сделал страницу на Github со списком моих докладов на предстоящих конференциях и с материалами по прошедшим (контент все еще добавляю). Если вдруг тоже окажетесь на какой-то из этих конференций, буду рад пообщаться 🙂

Обновляемый список моих докладов: https://github.com/koorchik/my-talks

Сейчас мы делаем несколько проектов для автоматизации умного дома. Софт на NodeJs, запускается в докер-контейнерах на наших хабах. Хабы это железяки по типу raspberry/orange pi. Флеш память приходится сильно экономить и стал вопрос оптимизации размера докер образов.

Если взять стандартный образ node:10 и сделать все без оптимизаций, мы получим образ в 700МБ или больше. Базовый образ будет 600 МБ и 100 МБ слой с приложением.

Ребята из компании решили поделиться опытом и написали отличный пост про оптимизацию размера докер образов для NodeJS приложений.

Статья: Docker image size optimization for your Node.js app in 3 easy-to-use steps.

Результаты:
Размеры образов до оптимизации:
* 600 МБ базовый образ с NodeJS
* 100 МБ на каждый новый образ

Размеры образов после оптимизации:
* 100 МБ базовый образ с NodeJS
* 2.5 МБ на каждый новый образ

Как работает Google со своим кодом или немного про монорепозитарии.

Google использует монорепозитарий. Это значит:
✅ Что весь код хранится в одном репозитории. Это несколько миллиардов строк кода. Размер репозитория 86 ТБ.
✅ Это значит, что каждый сотрудник имеет сразу доступ ко всем проектам Google.
✅ Все всегда вливается в HEAD (master/trunk).
✅ Все зависимости также находятся в репозитории.

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

Теперь вопросы и ответы:

Вопрос: Как это влияет на деплоймент?
Ответ: Деплоймент это независимая процедура и деплоить они могу свои микросервисы раздельно.

Вопрос: Получается у Google нет ревью кода?
Ответ: Ревью кода и тесты есть, и это ключевая часть процесса разработки. Просто, для этого есть отдельный инструмент/инфраструктура.

Вопрос: Как такой репозитория клонировать на локальную машину?
Ответ: Репозиторий не клонируется, а используется виртуальная файловая система.

Вопрос: Как происходит работа над Chromium, если это open source проекты?
Ответ: Chromium и Android не находятся в этой монорепе.

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

Вопрос: Если двум разным версиям приложения нужны разные версии рантайма/языка?
Ответ: В Google всегда используется одна версия. Если переводят на новую версию, то все продукты будут переведены на новую версию рантайма/языка. Вместо того, чтобы каждая команда искала инструменты и способы перевести весь код на новую версию рантайма/языка, это сделает централизованно одна команда.

Вопрос: Кто еще использует монорепозитарий?
Ответ: Из того, что я знаю - это Facebook и Twitter

Вопрос: Нравится ли сотрудникам такой подход?
Ответ: Да, большинство сотрудников Google поддерживают такой подход.

В целом, преимущества монорепозитарий сродни преимуществам монолита - это выше консистеность кода.
✅ Использование одного стиля (общий стайлгайд и правила статического анализа)
✅ Зависимость от одной версии рантайма/языка.
✅ Зависимости от одинаковых версий библиотек.

То есть даже, если вы пишите микросервисы, старайтесь по максимуму стандартизировать подходы к разработки.

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

Но консистеность кода для нас очень важна:
✅ Мы используем единый подход к архитектуре на большинстве проектов (описывал тут https://t.me/jabascript/36)
✅ Мы начинаем проекты с единого бойлерплейта.
✅ Мы активно используем инструменты для статического анализа кода. Мы не просто используем eslint и его плагины по максимуму, мы еще имеем конфиг eslint на всю компанию. И ко всему этому, мы пишем еще свои плагины для eslint
4. Мы используем общий набор библиотек. К примеру для валидации мы создали LIVR, который работает одинаково в JavaScript, PHP, Perl (и на многих других платформах).

Если хотите знать больше про монорепозитарии, вот ряд интересных ссылок:
1. Why Google Stores Billions of Lines of Code in a Single Repository
2. Monolithic Repositories with Ciera Jaspan
3. Monorepos in the Wild
4. Monorepos: Please don’t!

И еще немного про монолиты и микросервисы в продолжение https://t.me/jabascript/50.

Фейсбук это огромный монолит на PHP, раньше просто собирался 1.5 ГБ бинарь, которые просто деплоился на все сервера. Почему так? Неужели они не знают про микросервисы?

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

Но все это актуально не только для кода, но и для самой компании. Часто структура ваших микросервисов полностью соотносится со структурой команд в компании (вспомним тот же закон Конвея) . И это очень логично, когда каждая команда работает над своей частью (тут мы можем углубится в идеи code ownership, но не будем 🙂). Но по факту, по мере развития компании, в ней постоянно происходят изменения и мы заранее не знаем, какие они будут. Эти изменения ведут к реорганизации внутренней структуры компании и команд. В результате мы получаем, что в какой-то момент наша микросервисная структура не совпадает со структурой компании и это создает проблемы в поддержке.

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

Про координацию отлично сказал Пит Хант (помните парня, который показал миру React):

It's all about Amdahl's Law: you're going to be limited by how much coordination you need, and how much it costs.
Mono: coordination is cheap/free👍 But might encourage more coordination 👎
Poly: less required coordination👍 But if you need to coordinate, it's very expensive 👎

Это касается не только работы с репозиториями, но и вопроса монолит/микросервисы.

Все эти различные подходы могут отлично работать. И если у вас что-то работает, не гонитесь за хайпом, здраво смотрите на задачу. Замена технологий, подходов, процессов - это всегда замена одних проблем на другие, всегда взвешивайте стоит ли оно того.

Ко всему этому могу порекомендовать послушать интервью с Питом Хантом - Facebook Engineering with Pete Hunt

Как я переезжал с Webpack на Parcel.

Для различных небольших демо я постоянно использую Parcel. Parcel - "zero configuration bundler" и это правда. Никаких конфигов, все работает из коробки и очень быстро. Если ты не пробовал Parcel, то обязательно попробуй.

Можно ли использовать Parcel в крупном проекте? Сложно ли переехать с Webpack на Parcel?
У меня выпала возможность это проверить.

Был у меня один проект для сборки которого использовался еще Webpack первой версии. И когда я начал обновлять Webpack и лоадеры, я понял, что проще написать все с нуля, чем исправлять существующую конфигурацию и зависимости. Если уже все равно все делать с нуля, то почему бы не подключить Parcel? 🙂

Что у меня было: Babel, JSX, ES6 modules, Less. Точкой входа был файл main.js.
Задача перевести все на Parcel с минимальным количеством плагинов и конфигурацией по умолчанию, с точкой входа index.html.

Делал я это в 2 этапа:
Этап 1: Перевести все на Parcel, но оставить точкой входа main.js
Этап 2: Поменять точку входа на index.html

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

Первый этап оказался сильно проще, чем второй и возникло всего 2 проблемы 🙂.
1️⃣ Перевести все на Parcel, но оставить точкой входа main.js

Проблема №1: В некоторых случаях перестал работать импорт функций (локализации и других утилит).

Этот код перестал работать, хотя до этого работал:

import { l } from '../i18n';

Проблема оказалась в том, что в модуле i18n экспорт выглядел вот так:

export default {
  l(text) {
    return jed.gettext(text);
  }
};

Соответственно нужно было бы переписать на:

export function l(text) {
  return jed.gettext(text);
};

но после этого перестал работать код вида:

import i18n from '../i18n';

Чтобы это завелось, пришлось привести модуль i18n к такому виду:

export function l(text) {
  return jed.gettext(text);
};

export default {
  l
};

По сути нужно было привести модули ES6 к корректному виду (их было 2-3 таких).

Проблема №2: Загрузка статики с неправильных путей.

В проекте была такая структура директорий для статики:

public/
   index.html
   static/
      3d-party/
      lang/
        en.json
        ru.json
        uk.json
      favicon.ico   
      build/
        main.js
        main.css
        ...

и соответственно пути в index.html выглядели так /static/build/main.js .
Все, что нужно было - это указать нужные аргументы командной строки для Parcel.

Финальная команда выглядела так:

parcel watch \
    --out-dir publiс/static/build \
    --public-url /static/build \
    src/main.js

и после этого с точкой входа через main.js все заработало.

Осталось запустить http сервер для раздачи статики из папки public. Я использую для этого node-static (всегда установлен у меня глобально в систему).

cd public
// запустить в режиме SPA
// если запрашиваемого файла нет, 
// то всегда возвращает index.html
static --spa -p 8090

Со вторым этапом все сложнее оказалось, опишу завтра 🙂

Небольшая заруба для всех участников конференции OdessaJS и подписчиков @jabascript, да и просто желающих. Играем в JavaScript Golf. Есть простая задача, нужно написать решение и чье решение будет содержать меньше всего символов, тот и победил.

Описание задачи - https://gist.github.com/koorchik/867460697526af0d84940960ee82652b
Правила тут (подключайтесь в чат) - @jsgolf

Как сабмитить результаты еще думаю 🙂

Долго думал нужен ли чатик для обсуждения постов. Я долго сомневался, но все таки пришел к выводу, что имеет смысл его сделать по нескольким причинам:
1️⃣ Возможность ответить на вопросы подписчиков или получить какие-то комментарии.
2️⃣ Определиться с темами, которые интересны подписчикам.
3️⃣ Иногда есть вещи, которые не сильно подходят для канала. Например, я часто выступаю на конференциях и постоянно кидать в канал, что на следующей неделе буду с таким-то докладом там-то вне сильно хочется. В канал планирую уже скидывать видеозаписи самых интересных докладов с какиме-то комментариями, но не анонс. А вот чатик для этого подходит 🙂.

Ссылка на чат - https://t.me/jabascript_chat

Как я переезжал с Webpack на Parcel - часть 2

Лето оказалось перегружено поездками и конференциями. Наконец-то добрался до канала и решил опубликовать вторую часть про переезд на Parcel.

Первым этапом было перевести все на Parcel, но оставить точкой входа main.js.

Этап 2️⃣: Поменять точку входа на index.html и отказаться от лишних аргументов командной строки. Сборка должна выглядеть вот так

parcel index.html

и никаких конфигов.

Проблема №1: Перестали работать локальная статика типа jquery.js и пара других библиотек.

Parcel находит все теги script и собирает файлы в бандл(кроме файлов с внешних серверов). JQuery плагины перестали находить JQuery. Похоже, что проблема с тем, что модули уже объявляются не в корневом скоупе. Я долго не заморачивался, просто подключил все с CDN.

Проблема №2: перестали загружаться файлы локализации.
Для каждого языка в директории public/static/lang есть свой json файл. И был код, который загружал нужный файл локализации:

function loadLocaleData(locale) {
  const url = `/static/lang/${locale}.json`;
  return fetch(url);
}

В итоге, когда поменяли entry point на index.html, Parcel начал результат сборки помещать в dist. Естественно, он ничего не знает про статические файлы, которые не участвовали в сборке и loadLocaleData не может загрузить файлы локализации.

Тут есть несколько вариантов:
✳️ Использовать плагин parcel-plugin-static-files-copy (я решил не подключать лишний плагин).
✳️ Использовать динамический импорт (я пошел по этому пути).

По сути, я переписал код на такой:

const localeImports = {
  ru: import(`../static/lang/ru.json`),
  uk: import(`../static/lang/uk.json`)
};

export function loadLocaleData(locale) {
  return localeImports[locale];
}

Может показаться, что я загружаю все файлы локализации сразу, но это не так. Import возвращает Promise, но загрузка файла начнется только, если вы запросите результат с промиса и загрузится только нужный файл. Подход с динамическим импортом лучше, чем c plugin-static-files-copy еще по нескольким причинам:
✅Файл будут минифицирован.
✅Имя файла будет содержать хеш сумму и я могу кешировать файл навечно (без проверки etag или last modified), что особенно актуально в данной ситуации (браузер не может показать интерфейс пользователю, пока не загружен файл локализации).

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

parcel index.html

Но нет 😬, осталась еще одна проблема - я не хочу, чтобы Parcel упаковывал конфиг приложения в билд. И на эту проблему я потратил больше всего времени.
Продолжение следует...

Как я переезжал с Webpack на Parcel - часть 3

✳️Часть 1
✳️Часть 2

Я обычно не пакую файл конфигурации в билд. Конфиг я загружаю таким образом:

<script type='text/javascript' src="/config.js"></script>

сам "/config.js" выглядит так:

window.APP_CONFIG = {
  // my configuration here
};

и прячу его за модулем "src/config.js", чтобы код не ходил в глобальную переменную.

// src/config.js
export default window.APP_CONFIG;

такой подход позволяет использовать один и тот же билд в разных окружениях. Билд один, но для каждого окружения свой конфиг (по модели 12 factor app). Идея - выкатывать в прод только те билды, которые были протестированы.

И вот такое практически невозможно заставить работать в Parcel. Это оказался целый квест :)

То есть, если вы напишите:

<script type='text/javascript' src="/config.js"></script>

И вас нет файла config.js, то Parcel ругнется ошикой, а если config.js есть, то он попадет в бандл, что нас тоже не устраивает.

Я начал искать решение и оказалось, что на эту тему много issues (например, https://github.com/parcel-bundler/parcel/issues/144), но разработчики не добавляют такую фичу. Кто-то пытается писать дополнительные плагины для решения проблемы, но плагины оказались не сильно высокого качества.

Затем я попробовал posthtml с плагином "include", но в итоге все, что мы инклудим точно также процессится Parcel-ом.

Потом я подумал, почему не грузить динамически конфиг и написал такой код:

const script = document.createElement("script");
script.async = false;
script.type = "text/javascript";
script.src = "/config.js";
document.head.appendChild(script);

Но этот код не заработал, поскольку файл с конфигом выполнялся после main.js даже с опцией async=false.

В итоге, вот такое решение заработало:

<script type='text/javascript'>
    document.write(`<${"script"} src="/config.js"> </${"script"}>`);
</script>

Что дальше? Сейчас для меня Parcel - это вариант по умолчанию, использую webpack только когда появляется необходимость в специфических фичах (например, для изоморфных приложений).

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

Надеюсь, что этот опыт будет полезен читателям канала 🙂

"NodeJS и OpenCV... однажды в Голливуде" - еще один интересный пост в блоге WebbyLab.
В одном из наших проектов возникла задача находить лицо человека на видео и замыливать его. Сегодня вся эта магия уже сугубо инженерная задача, просто нужно знать какие инструменты скомбинировать (OpenCV, ImageMagick, NodeJS, прямые руки). В продакшене это уже почти год и мы решили поделиться этим контентом с комьюнити. Возможно задача немного нестандартная для JS, но не только же CRUD клепать 🙂

ССЫЛКА НА ПОСТ: - https://medium.com/@WebbyLab/face-blurring-with-nodejs-and-opencv-once-upon-a-time-in-hollywood-f3b8e09669e8

Ну, и подписывайся на наш блог на Medium 🙂

Мы создаем еще одну IoT платформу для управления умным домом. Это еще один проект по автоматизации, который мы стартовали буквально пару месяцев назад.
В проекте: Docker, событийная модель работы, WebSockets, NodeJS, MQTT, много всяких интересных железяк, крутая команда.

➜ Я лично в нем тоже активно участвую, помогаю команде в решении архитектурных задач.

➜ Сейчас расширяю команду в Киеве и есть возможность взять 2х людей (фултайм в офис). Нужны NodeJS разработчики уровня Junior+/Middle. Если у кого есть желание, то приходите к нам, всему научим, но думать и работать придется 🙂

Детальное описание вакансии тут - http://bit.ly/2muaYCW
Также мы регулярно обновляем список вакансий в канале @webbylab, подписывайтесь.

Если есть любые вопросы относительно вакансии, то пишите мне лично или в чат, или нашим рекрутерам на почту, или в @webbylab_recruiter.

ХАК: пишите, что узнали про вакансию на канале "Жабаскрипт", тогда на вас обратят внимание в первую очередь 🙂

Я всегда топлю в разработке за здравый смысл и всегда против догматичности.

1. Мое видение Шаблонов проектирования: это не некое сакральное знание, а набор подходов, которые работает а конкретных ситуациях и ребята типа Фаулера не придумали что-то уникальное, а просто классифицировали то, что отлично работает в проектах. Это дало нам общую терминологию и описание стандартных подходов. Нужно ли знать паттерны? Да, нужно. Нужно ли им следовать? Следовать нужно здравому смыслу, а паттерны могут подходит, а могу не подходить.

2. Мое видение Best Practices. Лучшие практики - это не то, что лучшее в 100% случаев. Best practices - это обычно не возможность сделать лучшим образом, а скорее не сделать хреново. Если вы не просто знаете конкретные Best Practices, а понимаете причины их появления, то в некоторых проектах вы можете сознательно их нарушать, поскольку у вас может быть более оптимальное решение для вашей конкретной ситуации.

К чему я это все? К тому, что нужно понимать программирование, а не "верить" в него. Вместо догматичного следования каким-то идеям - прислушивайтесь к здравому смыслу.
Например, многие говорят, что TDD это только для полностью изолированных юнит-тестов, иначе это не TDD, но TDD не про изоляцию, а про red green loop.
Аналогично CQRS и Event Sourcing. Народ увидел пример, который показал Greg Young и считают, что Event Sourcing может быть только таким, но все не так на самом деле.

Я недавно посмотрел интересный доклад Грега "Greg Young — A Decade of DDD, CQRS, Event Sourcing" https://www.youtube.com/watch?v=LDW0QWie21s И он как раз рассказывает про проблемы этой догматичности (вторая половина доклада) и что иногда фразы сказаны для примера, а народ потом верит в это и следует как догме, что не есть правильно.

Я очень часто замечаю эту проблему в нашем комьюнити. Банальный пример из жизни. В документации по React, когда-то была фраза, что есть антипаттерн использования this.props в getInitialState (в старом API) для определенных случаев. Потом на одной из конференций я показываю кусочек кода и мне говорит разработчик, что использование this.props в getInitialState это антипаттерн. Я спрашиваю почему - ответ “так написано в документации”. Но если внимательно читать документацию, то там хорошо описано, когда это является антипаттерном, а когда нет. И даже, если не описано, задумайся о причинах. И таких случаев у меня было множество, когда вместо “понимания” - ”вера” :)

Это моя ода здравому смыслу!

Послушал отличный подкаст с Кентом Беком. Прям в продолжение моего поста про догматичность и веру в программирование 🙂

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

Кент Бек - создатель TDD и экстремального программирования, написал кучу книг по разработке. В 2011 году он пришел в Facebook и был удивлен тем, как там ведется разработка. Разработка там была устроена таким образом, что она не должна была работать в принципе, но на практике оказалось, что все работает отлично. Сначала он решил сделать тренинги по TDD внутри компании, но оказалось, что никому это не нужно. Кент понял, что лучше попробовать осознать новый для него процесс и начал пилить фичи. Его подход с TDD, там себя плохо показывал, иногда его тесты просто удаляли. И только через 4 года работы в Facebook Кент понял все нюансы и почему такой иной процесс так хорошо работает в ФБ. Сейчас чувак говорит, что в вещах, которые вы пробовали, вы можете быть уверены только в определенном контексте (в том, в котором вы и пробовали). Разный контекст - это разный инпут. И нельзя сказать, что тот же подход будет работать в другом проекте, если инпут (контекст, проект) уже другой.

Все что написано в книжках - хорошо и полезно, но это не значит, что не может быть по другому. Но также это не значит, что у вас заработает процесс, как в Facebook (возможно, он почти ни у кого в мире не заработает, поскольку не так много проектов типа Facebook).

ССЫЛКА НА ВЫПУСК ПОДКАСТА: https://softwareengineeringdaily.com/2019/08/28/facebook-engineering-process-with-kent-beck/

На этих выходных я в Харькове на https://kharkivjs.org/ с классным докладом. Предыстория такова. Представь себе, что к тебе пришли со сложными математическими моделями (миллионы ячеек, сотни тысяч формул) в Excel. Твоя задача запустить их в браузере и на мобильных устройствах, но уже без Excel. Это одна из тех задач, когда лучше не знать заранее насколько это сложно, иначе и не возьмешься за нее :). В итоге, мы создали движок электронных таблиц, совместимый с MS Excel, который позволил нам запускать практически любую математическую модель. В докладе я расскажу как это было, с какими проблемами мы столкнулись, как их решали, расскажу про архитектуру, алгоритмы, оптимизации производительности JavaScript и ошибки, которые мы допустили вначале.
Если кто в Харькове, приходите, буду рад всех видеть. ХарьковЖС - одна из самых моих любимых конференций, уже 5-й год подряд выступаю там (ну и "фабрика" - классное место) 🙂

RPN vs AST
Забавная история. Когда-то мы создали свой движок электронных таблиц (про это делал доклад в Харькове) и каждая формула представлена в движке в виде абстрактного синтаксического дерева (AST). Я когда-то делал бенчмарк для разных языков - https://github.com/koorchik/formula-evaluation-benchmark . Сегодня я вдруг задумался, почему формулы представлены в виде AST, а не в формате обратной польской записи (RPN). В целом, RPN вычисляется итеративно без рекурсии (нужен правда свой стек для операндов и результатов). Мне понравилась эта идея и начал думать, как загнать в RPN эксель формулу. Основной вопрос - функции с изменяемым количеством операндов. Решил, что буду просто в RPN хранить арность рядом с токеном операнда. Начал уже руками переписывать свое тестовое дерево в RPN, но тут решил загуглить, вдруг кто-то уже тестировал перформанс AST против RPN. И как же я удивился, что первой ссылкой нахожу гитхаб гист в котором бенчмарк на JavaScript. В гисте уже решена проблема арности и даже есть функция для конверта AST в RPN (а я хотел делать это руками). Читаю гист и тут до меня доходит, что я автор этого гиста - я 😂. Я написал этот бенчмарк больше года назад , увидел, что RPN медленее и забыл про него :)

ГИСТ - https://gist.github.com/koorchik/9717b893ae2134e21dbe

Относительно перформанса, то можно RPN вариант ускорить, но он все равно не будет быстрее, чем AST (это касается только JS имплементации).

Циклические импорты в ESM

В 13-й версии ноды ESM уже доступны и без флага "--experimental-modules". Мы готовися к полноценному переходу на mjs в наших бэкендах. Многие преимущества ESM и так очевидны, но есть некоторые, про которые не так много говорят. Одна из классных фич - это нормальная отработка циклических зависимостей. Обычно циклических зависимостей стоит избегать, но иногда они полезны. В нашем случае они полезны при работе с Sequelize. Для описания моделей Sequelize мы используем ES6. Допустим, у нас есть пользователь и его сообщения, описание моделей может выглядеть так:

Класс User:

import Message from './Message';

class User extends Base {
  static schema = {
    id : { 
      type: DT.UUID,  
      defaultValue: DT.UUIDV4,
      primaryKey: true 
    }
  };

  static initRelations() {
    this.hasMany( Message,{ 
      foreignKey: 'userId', 
      as: 'messages' 
    });
  }
}

export default User;

Класс Message:

import User from './User';

class Message extends Base {
  static schema = {
    id : { 
      type: DT.UUID, 
      defaultValue: DT.UUIDV4, 
      primaryKey: true 
    },
    userId : { 
      type: DT.UUID, 
      references: { 
        model: 'User', 
        key: 'id' 
      }
    }
  };

  static initRelations() {
    this.belongsTo(User, { 
      foreignKey: 'userId', 
      targetKey: 'id', 
      as: 'user' 
    });
  }
}

export default Message;

Мы видим, что у нас есть циклический импорт, но зависимости нам нужны уже в рантайме. Метод initRelations вызывается во время инициализации. Вот такая схема отлично работает в ES6, но не будет работать в CommonsJs.

Набросал пару отдельных примеров для теста: https://github.com/koorchik/node-import-vs-require

Наконец-то настоящий кейс-стади CSS-in-JS-библиотек и того, как они влияют на рантайм-производительность: https://calendar.perfplanet.com/2019/the-unseen-performance-costs-of-css-in-js-in-react-apps/

Что почитать в празднкики?! :)

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

Самое удивительное, что это скилл не улучшается с годами опыта, если этому не уделять должного внимания.

Собственно, книги:
1️⃣ Patterns of Enterprise Application Architecture - Martin Fowler.
2️⃣ Clean Architecture - Robert Martin.
3️⃣ Domain Driver Design - Eric Evans.

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

С моей точки зрения, наиболее полезными будут "Clean Architecture" и "Domain Driver Design", поскольку это то, что полезно при написании любого нового проекта. В свою очередь, "Patterns of Enterprise Application Architecture" просто позволит вам увидеть определенные паттерны в существующих фреймворках (и полезно, если вы создаете фреймворк).

Для многих DDD было взрывом мозга и переворотом мышления :)

С Новым Годом! 🥳

Cindy Sridharan пишет про lsof и его полезные флаги с точки зрения разработчиков.

Тулза действительно полезная, но всё же, если система уже хорошо нагружена, лучше напрямую по /proc шариться, чтобы не усугублять.

#toolz

Simple Made Easy

Для меня простота системы является одним из ключевых признаков качества и хорошей архитектуры. Систему, которую легче понять, проще ментальная модель, прозрачней решения (принятые и которые нужно принимать), почти всегда легче развивать. В то же время, создать простую и стройную систему всегда сложнее, а сложную - проще :). Простые системы часто имеют меньшую вариативность состояний и более предсказуемы. Это касается и тулинга и бизнес-логики. Также это перекликается с идеей, что если ты не знаешь в какой слой разместить кусок кода, то скорее всего у тебя проблемы с архитектурой (ее нет, ее сложно осознать и тд). Но иногда я встречал решения, которые оптимизированы под легкость использования. Можно ли сказать, что легкость использования и простота системы это одно и то же? По ощущениям эти понятия перекликаются, но часто уклон в легкость использования делается, когда системы слишком сложная. А сложность часто продиктована чрезмерной связаностью частей системы, в результате получается комбинаторный эффект от взаимодействий/состояний. Почему я про это все говорю? Мне просто попался хороший доклад на эту тему :). Докладов, которые не про пересказывание документации, а про осмысление подходов не так много. Сам доклад 2012 года, но актуальности он не потерял. Рекомендую.

ССЫЛКА НА ДОКЛАД - https://www.youtube.com/watch?v=oytL881p-nQ

Эффективная разработка на NodeJS или чего ждать в этом году

В разработке софта я уже более 15 лет и за этот период удалось поучаствовать в огромном количестве проектов для различных компаний, включая проекты для 5 компаний из списка Fortune 500. Сейчас мы делаем несколько проектов по автоматизации умного дома, платформу для AMG Mercedes, ряд проектов для фарма-компаний, несколько FinTech проектов, различный e-commerce. Большинство проектов написаны на NodeJS.

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

Что планируется?

✅Доклады (и промокоды для подписчиков)
В этом году не планирую слишком много выступлений, пока подтвердил 6 докладов. Прошу у организаторов отдельные скидки для подписчиков канала. Все идут на встречу, промокоды и анонсы докладов буду публиковать отдельным постами. Первым будет доклад будет на JavaScript fwdays 14-го марта в Киеве (анонс с промокодом сделаю отдельным постом).

✅Книга
Изначально я думал, что я просто сделаю доклад на тему Эффективная разработка на NodeJS, но когда начал составлять план, то оказалась, что контента на десяток докладов. В итоге, появилась идея все это оформить в книгу. Ко мне подключился Андрей Кучеренко (тот, который сделал jscpd). Книга будет бесплатная, изначально на русском языке, в открытом доступе. Будет отдельный пост, посвященный книге.

✅Посты в телеге
Сейчас я готовлю серию постов по работе с сессиями (JWT, Cookie, Security, force logout и тд). Хочу двигаться блоками. Контент с канала, по сути, станет основой для книги. Ну, и подписчики канала будут первыми получать доступ к содержимому книги и будут иметь возможность повлиять на нее. В целом, идея канала остается прежней - создавать полезный контент для JavaScript разработчиков, хотя сам контент может быть совсем не про JavaScript :).

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