Небольшая заруба для всех участников конференции 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к :)

Буду на JavaScript fwdays 2020 с докладом "Эффективная разработка NodeJS приложений"

JavaScript fwdays 2020 пройдет 14-го марта в Киеве. Как уже говорил, организаторы, специально для подписчиков канала, дали 15% скидку. Используйте промокод JABASCRIPT.

Я уже сделал ряд докладов про рабочую архитектуру Web приложений, но это все лишь часть пазла эффективной разработки. В этот раз я покажу весь процесс от старта проекта и до запуска его в продакшен. Расскажу, как мы подходим к идеям "12 Factor App", как мы используем докер, обсудим вопросы развертывания окружения, вопросы безопасности, тестирования, обсудим нюансы SDLC и много всего другого.

Реальный опыт часто отличается от теории, поэтому я всегда стараюсь делиться тем, что работает на практике.

Будете на конфе, пишите! Всегда рад пообщаться вживую! 🙂

Уже постил про этот канал и думаю большинство уже там, но сделаю это еще раз. Я знаю как тяжело регулярно писать в канал. Не знаю, как у Сереги это получается, он как робот) Если интересно, как развивается сам JavaScript, то это лучшее место, чтобы следить за этим. Подписывайтесь! Это моя личная рекомендация)

Несколько дней назад число подписчиков превысило 5000 человек! Это очень мотивирует не останавливаться и постить интересные новости и статьи и дальше. Оказывается, я занимаюсь этим уже более полутора лет 😮. Большое спасибо всем читателям! Если Вам нравится, то делитесь с коллегами и друзьями :)

Напомню, что я принципиально отказываюсь постить здесь всякую рекламу. Если хочется поддержать канал, то это можно сделать на Patreon.

Yet another JSON RPC Library

Что может быть проще JSON-RPC? Мы делаем проект по автоматизации умного дома и нам нужна была JSON RPC библиотека, но в результате оказалось, что ничего подходящего в экосистеме NodeJS найти нельзя. Основная проблема в архитектуре этих библиотек.

JSON RPC это один из самых простых вариантов RPC, с минималистичной и простой спекой, протокол не зависит от транспорта. Хотелось найти что-то, что следует этим же идеям.

Нам нужно было:
✅ Независимость от транспорта (WebSockets, MQTT, WebRTC, HTTP etc).
✅ Динамическая регистрация транспортов.
✅ Двунаправленная коммуникация через один канал.
✅ Современный API.
✅ Сервер и клиент, которые могут работать и в браузере.
✅ Простую реализацию, идеально, чтобы ядро без внешних зависимостей.
✅ Простой способ добавлять новые транспорты (все сложные части должны быть абстрагированы).
✅ Простой способ тестировать новые транспорты.

В итоге, более года назад появился Mole-RPC, который решил все эти проблемы. Могу сказать, что выстроить правильные абстракции часто бывает не просто и не всегда получается с первого раза.

Доклад про это на KyivJS - https://www.youtube.com/watch?v=84Y5n32tX5E.

В докладе я рассказал про задачу, показал проблемы ряда популярных JSON RPC библиотек и постарался продемонстрировать, как мы подходим к проектированию и как выстраивать абстракции.

Рекомендую к просмотру всем, кто пишет свои библиотеки 🙂