Node.js в 2020: Выйди и зайди нормально
За последние 5 лет Node.js очень изменился, но знания о платформе у сообщества остались на уровне 2013-2015 годов, все те же подходы, все те же проблемы. Сообщество плохо следит за новыми возможностями, а если и узнает про них, то это не влияет на написание ежедневного кода. В Node.js, да и в JavaScript, слабо проникают фундаментальные знания по программной инженерии и архитектуре, параллельному программированию, GRASP, SOLID, GoF, а если и проникают, то не подвергаются адаптации и переосмыслению. Поэтому, среди других языков программирования JavaScript воспринимается, как несерьезный, а в среде разработчиков Java, C++, C#, распространено мнение, что Node.js, это платформа для малограмотных людей. Как преодолеть эту тенденцию и как изменить подход к разработке на Node.js в 2020 году, с использованием всех современных возможностей и знаний, а так же, что нужно изменить в ежедневных практиках написания кода, эти и другие вопросы рассматриваются в трех бесплатных вебинарах «Node.js в 2020: Выйди и зайди нормально» 11, 14 и 21 апреля, накануне выхода Node.js v14.
Товарищи инженеры, докладываю вам об успехах в подготовке научно-технических кадров в области программной инженерии на 
Началось все с того, что я оптимизировал отдачу ошибки 
Это не первая вводная статья про 
В JavaScript существует множество разных способов наследования, классового и прототипного, фабричного и через примеси, прямого и непрямого, а так же гибриды нескольких методов. Но у Node.js есть его родной способ с применением util.inherits(ChildClass, ParentClass). До недавнего времени я использовал нодовский способ только для встроенных классов (когда нужно сделать своего наследника для EventEmitter, Readable/Writable Stream, Domain, Buffer и т.д.), а для моделирования предметной области применял общеупотребительные для всего JavaScript практики. И вот, впервые, понадобилось реализовать собственную иерархию системных классов, не наследников от встроенных, но и не классов предметной области, а классов, массово поражаемых в системном коде сервера приложений 
Эта статья, еще одна попытка переосмысления 
«Только со смертью догмы начинается наука.»
Предоставляю вам краткий отчет об изменениях в 
Речь пойдет, о технических стандартах, т.е. протоколах, спецификациях, паттернах, конвенциях, интерфейсах, форматах данных, нотациях и других отраслевых и особенно внутренних нормах, которые мы используем или изобретаем при разработке программных систем. Очевидных вещей я не буду повторять, каждый знает, что стандарты — это хорошо и правильно, что они способствуют унификации и, следовательно, совместимости систем и их модулей. Надеюсь, мои обобщения опыта, в форме «заметок для себя», будут полезными и нетривиальными.
Кто пишет на Node.js и использует MySQL, тот непременно знает, что наш дорогой товарищ 
Несмотря на заметные успехи, 
У меня сложилось впечатление, что в обществе все же есть предубеждение против использования глобальных переменных в служебных целях. В связи с этим, хочу дать некоторые разъяснения с примерами, которые снимут всякие сомнения и будут полезны всем, кто жаждет модульности и гибкости в JavaScript разработке. Я не могу проследить источники всех идей, приведенных ниже, но я не претендую на их авторство, а лишь на творческое обобщение. Так же я отказываюсь от претензий на один универсальных паттерн определения модулей для всех случаев жизни, надеюсь, всем ясно, что такого не может быть никогда. Все это существенно отличается от подходов RequireJS, CommonJS и того, как модули оформляются в node.js через module.exports, однако, каждый из этих паттернов имеет свое место, если подходить к задаче без фанатизма и предубеждений.