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

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 библиотек и постарался продемонстрировать, как мы подходим к проектированию и как выстраивать абстракции.

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

Что можно сделать с JSON-RPC?
В продолжение к предыдущему посту, решил рассказать про варианты использования JSON-RPC.

mole-rpc - это сама библиотека.
✅ Реализует протокол JSON-RPC, но ничего не знает про сам транспорт.Транспорт можете выбрать любой из существующих (https://www.npmjs.com/search?q=keywords:mole-transport) или можете написать свой.
✅ Транспорты максимально простые и ничего не знают даже про сам JSON-RPC.
✅ Полностью совместима с JSON RPC v2 (включая уведомления и пакетные запросы).
✅. Без внешних зависимостей.
✅ В версии 1.0 существенно обновил документацию и доработал обработку ошибок.

mole-rpc-autotester
Если пишете свой транспорт, то можно использовать этот автотестер, чтобы протестировать всю основную функциональность. Решил вынесли его в отдельный пакет.

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

Отправка задачи в веб-воркер
Допустим, вы хотите отправить вычисления в браузере в веб-воркер. Для этого вы используете postMessage и будете отправлять структуру вида {id, method, params}, а в ответ ждать {id, result}. id нужен, чтобы соотнести запрос и ответ, если будет отправлено несколько задач. Так вот, это по сути и есть JSON RPC. Зачем тогда тратить время на свою реализацию, если можно взять готовое решение. mole-rpc-transport-webworker позволяет это сделать в 2 строчки и обработать еще все граничные кейсы.

Коммуникация микросервисов многие ко многим
Обычно для таких случаев вам нужен message broker. MQTT одно из самых легких и достаточно мощных решений. Организовать JSON RPC общение через MQTT можно при помощи mole-rpc-transport-mqtt. Мы используем это решение в продакшене. В документация я постарался описать все детали.

Обход NAT
Допустим, у вас есть сервис в локальной сети и ему нужно посылать команды из интернета. В таком случае можно подключать не клиент к серверу, а сервер к клиенту. Это тоже реализуемо при помощи mole-rpc-transport-ws. Есть пример на Github.

Подключение браузера к серверу через WebSocket
Для этого можно использовать тот же транспорт mole-rpc-transport-ws. Также есть пример на Github.

Напиши свой транспорт :)
На прошлых выходных, for fun, сделал транспорт, которые позволяет использовать telegram, как канал общения между клиентом и сервером (пока в паблик не выкладывал) :).

Если вы пишите свой транспорт и возникли любые вопросы или пожелания - можете писать мне в личку или чат канала 🙂

"The Twelve-Factor Appp" и JavaScript
Неделю назад я делал доклад на fwdays про эффективную разработку NodeJS приложений (через 2-3 недели будет видео) и пообещал сделать серию постов на тему 12-ти факторов в канале. Вроде простая и всем понятная концепция, но не всегда ясно, что должен делать разработчик на практике.

Зачем нужны 12 факторов?
В WebbyLab, когда мы используем различные облачные решения, всегда стараемся минимизировать "vendor lock". Я придерживаюсь идеи, что лучше всего, когда ваше приложение без проблем можно будет запустить в любом облаке или даже на собственном железе. Мне нравится фраза Роберта Мартина, что работа архитектора это не принимать решения, а откладывать их насколько это возможно. Другими словами - сделать систему такой, чтобы критические решения можно было принять позже, когда будем иметь больше знаний о специфике задачи и предметной области. Так вот, ребята из Heroku разработали 12 правил, которые, хоть в контексте деплоймента, позволяют не принимать решения сразу.

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

Правила - https://12factor.net/ru/

Настоятельно рекомендую с ними ознакомиться, даже если ты пишешь только фронтенд.

В следующих постах я пройдусь по каждому правилу и расскажу, как мы применяем их в JavaScript приложениях (фронтенд и бекенд).

Эффективная разработка NodeJS приложений

Не так давно я делал доклад на fwdays на тему "Эффективная разработка NodeJS приложений." Это был мой первый онлайн доклад. Впечатления конечно смешанные. Тяжело, когда не видишь аудитории, но зато удобно было показывать код 🙂

Изначально я хотел поделиться идеями и концепциями, к которым нам в WebbyLab удалось прийти за годы разработки на NodeJS. Я наивно полагал, что смогу уместить это в один доклад, но по факту контента оказалось часов на 8. В резульатате, я взял только часть, но все равно вместо 40 минут доклад занял 90 минут. Хорошо, что мой доклад был последним 😁

В докладе:
✅ Прошелся еще раз по архитектуре.
✅ Показал пример чат-бота на этой же архитектуре.
✅ Рассказал про Sequelize - ряд вещей, которых нет в документации. Как использовать ES6 классы, как работать с конфигами (поскольку примеры из доки противоречат правилам "12 factor app"). Немного про транзакции.
✅ Затронул конфиги для фронтенда.
✅ Прошелся по докеризации и основным вопросам, которые часто возникают у разработчиков.

ЗАПИСЬ ДОКЛАДА: https://www.youtube.com/watch?v=g0I2dNwK1BE

PS: Серия постов по 12-ти факторам на подходе. Уже написал половнину. Будет по 1-му посту в день :)

6 способов взломать твое JavaScript приложение.
В 2019 я несколько раз выступал с докладом на эту тему. Сейчас готовлю версию на англоязычную онлайн конфу, повод выложить оригинальное видео в канал 🙂

Я заметил, что если людям указать на потенциальный вектор атаки, то они не оценят риск пока ты не запустишь эксплоит, который взломает их приложение и уведет аккаунт. В связи с этим я сделал демо приложение на React + NodeJS и написал 6 эксплоитов, чтобы показать, как различные мелкие недочеты приводят к серьезным уязвимостям.

Все случаи мы находили на реальных проектах и все эксплоты настоящие. На KharkivJS были люди, которые думали, что это все фейк, теперь я показываю код эксплоитов 😁

ВИДЕО С JSFest 2019 (доклад попал в Top-3 лучших докладов конфы) - https://www.youtube.com/watch?v=tBXZRC1f34E
Не сильно грузящее видео, чтобы скрасить времяпровождение во время карантина)

Мой доклад занял первое место по результатам голосования (если кто осилит посмотреть, получилось 80 минут, буду рад любому фидбеку):

Вже готовий топ-3 доповідей онлайн-конференції JavaScript fwdays'20 від 21 березня за голосуванням учасників 🤩

1️⃣ @koorchik "Effective NodeJS Application Development"

2️⃣ Олександр Мостовенко " 'Devide et impera' with GraphQL and SSR"

3️⃣ @tshemsedinov "Web Locks API in Node.js and browser"

Посилання на доповіді:
👉 https://www.youtube.com/playlist?list=PLPcgQFk9n9y9jbWCnublMA1D2qbJPLukf