108.2
Karma
152.7
Rating
Джехи @jehy

Веб разработчик

Node.js или Java: производительность, ресурсы, управление потоками, популярность и личный опыт

+7

Статья полна сравнениями тёплого с мягким, сферическими бенчмарками в вакуме и просто дилентантскими утверждениями.


Лень перечислять всё, для примера "один из минусов Node.JS":


был случай, когда разработчик удалил свою библиотеку из NPM и множество приложений использующих ее перестали работать;

1) NPM и Node.JS это разные вещи. Как можно делать вывод о платформе на основании менеджера пакетов?
2) Вот уже много лет с этого случая как в NPM запрещено удаление пакетов.
3) Есть альтернативы NPM и в виде менеджера пакетов и в виде хранилища.
4) Есть решения в виде локальных кеширующих NPM серверов.
5) Самое главное — приложения не "перестали работать". Удаление библиотеки никак не повлияло на работу приложений. А вот собираться они перестали.


О качестве остальной статьи делайте выводы сами.

9 лет в монолите на Node.JS

+1

Если у вас пять разработчиков в компании — то безусловно да. И мотивация "стек — отстой" — крайне плохая.


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

9 лет в монолите на Node.JS

0

Да, часто про molecular слышу хорошее от адекватных людей, но пока ни разу не трогал, о чём жалею.
Порекомендуете по нему хорошей литературы?

9 лет в монолите на Node.JS

0
есть потребность бизнеса и конкуренты не будут ждать идеальный код перфекциониста.

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


но стал выстрелом в ногу, даже в две, а потом и в голову

Да, ничего не даётся бесплатно. И при переходе на новые технологии и архитектуру ты обязательно сперва выстрелишь себе в ногу — вообще без вариантов. Нужно просто это пережить.

9 лет в монолите на Node.JS

0

Чуть выше писал — http, redis, rabbit. Обмен по большей части в JSON или ProtoBuf. Наверняка что-то ещё есть, о чём я не знаю. Какой-то единой шины нет — может быть, это принесло бы нам счастье, но навскидку не могу сказать проблемы, которую она бы решила. Но тут как — возможно, я просто не осознаю, что она есть.

9 лет в монолите на Node.JS

+1

Да, это тоже в какой-то момент становится проблемой — когда нужно несколько гигов оперативки на запуск проекта, и вчетверо больше на IDE...

9 лет в монолите на Node.JS

0

Да, как-то так. Главное — вовремя поймать момент, когда первое состояние переходит во второе, и осилить перейти. Но до него ещё нужно дожить, что выходит не так часто, как хотелось бы.

9 лет в монолите на Node.JS

+1

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


  1. Удалось ли при такой поэтапной миграции полностью отказаться отказаться от старого кода в монолите? И была ли такая цель вообще?

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


На сколько больше у вас стало девопсов в итоге?

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


Мс и монолит у вас on-premise?

Да, конечно. Свои облака, мощности, поднимаемые по запросу и в ответ на нагрузку, и прочие радости.

9 лет в монолите на Node.JS

-2
Не получается понять что всё-таки вы имеете в виду под этой необходимостью "проверять много переиспользований". Это какая-то ручная работа?

Ага. Например, замена кода при breaking changes, или проверка использования каких-то deprecated методов.


Так ведь его не меньше, его как минимум столько же. Только теперь вместо "Ctrl+click, Ctrl+click, Ctrl+click, о, всё понятно" это превращается в: "а, тут мы дёргаем другой сервис, окей, пошёл смотреть его код".

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


Я понял, вы имеете в виду: "с микросервисами моя задача, как разработчика, вероятно, будет ограничина одним микросервисом".

Нет, я имею в виду, что много маленьких итеративные правки проще одной огроменной.


Как монолитность-микросервисность влияет на владение кодом?

Снова повторюсь. Обычно известно, какая команда отвечает за тот или иной микросервис целиком.


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

Разделить использование RAM или CPU по исполняемым функциям на продакшне — не такая простая задача. Она тоже решаема, но распределить по микросервисам проще.

9 лет в монолите на Node.JS

+2
Опять же — проблема большого количества людей со своими вкусами. Не все команды были за внедрение TS. Насильно это делать не хотелось. А вот в микросервисах в некоторых командах он отлично зашёл.

9 лет в монолите на Node.JS

0
"использовать криво" — это про людей, а не про монолиты.

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


Это проблема дизайна: как сделать так, чтобы глядя на код было очевидно какие эффекты он вызывает. Микросервисы эту проблему вообще никак не адресуют.

Повторюсь. Меньше кода — проще понять.


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

Повторюсь. Перейти на мажорную версию, поправив 10 строчек — легко. Перейти на мажорную версию, поправив 1000 строчек — кошмар.


Т.к. микросервисы эту проблему даже не пытаются решить, не понятно в чём здесь виноват монолит.

С микросервисами нам стало проще локализовать проблему в конкретном сервисе.


Это проблема JS и к монолитам отношения не имеет. Тут даже наоборот — будь у вас статическая типизация, монолит делал бы любую работу с кодом проще, чем микросервисы.

Это проблема JS+монолита. Я и имел в виду, что при статической типизации было бы порядком проще.


Искушение, конечно, вызвано тем, что зарелизить один сервис "проще", чем два.

В нашем флоу, разработчик делает задачи, и ничего не знает о релизах — так что ему всё равно, сделать правку в одном сервисе, или в двух.


С микросервисами фичи превращаются в "вот этот код, вон тот код, дождаться вон того релиза, и вот потом-то уже сможем зарелизить нашу фичу".

Да нет, просто релизим, но не включаем. Проверить её работоспособность можно и без зависимых микросервисов.


Часто бывает, что проблема в сервисе Z, который вызывает сервис Y, который в цикле дёргает X по 20 раз на каждую транзакцию :-)

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

9 лет в монолите на Node.JS

0
Понять, с какими именно тестами связаны изменения в коммите — задача весьма нетривиальная. Разве что сначала проверить покрытие текущее покрытие тестов. Смайлик.

Так что это время прогона всех юнитов. Наиболее результативным оказался поиск самых долгих тестов и их профилирование. Например, отрыли древний тест, в котором разработчик решил проверить, что несколько тысяч случайно сгенерированных величин будут действительно случайны… И мы проверяли это несколько лет!

9 лет в монолите на Node.JS

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

9 лет в монолите на Node.JS

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

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

9 лет в монолите на Node.JS

0
Чуть ниже поправили, что всё же около 6к. И обработкой запросов занимаются сотни инстансов приложения — запросы у нас тяжёлые, это не выдача какого-нибудь куска статики, а подзапросы в большое количество внешних сервисов, их агрегация и обработка.

Циферки RPS на самом деле мало чего значат без понимания, что именно за запросы идут, и с чем можно их сравнивать, поэтому я их не очень люблю приводить — слишком многие начинают сравнивать тёплое и мягкое.

9 лет в монолите на Node.JS

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

9 лет в монолите на Node.JS

0
23кк/60/60 = 6.3к, если меня не обманывает математика. Про 383 только комментатор выше писал, забыв ещё раз на 60 разделить, а я внимания не обратил. И да — это среднее — у нас по большей части пользователи из РФ, так что ночью нагрузки почти нет.

9 лет в монолите на Node.JS

+3
При монолитной архитектуре никто не говорит, что должен быть единственный инстанс приложения.
Тем более, в случае Node.JS — будь это так — мы бы на одном потоке не пережили бы и открытие сервиса.
Инстансов у нас было большое количество, ещё и с распределением по ролям, окружениям, балансировкой — но это уже отдельная большая история.

9 лет в монолите на Node.JS

+1

Да, lint-staged это прекрасная вещь, мы его тоже используем, и тоже с хаски на прекоммите — потому что линтинг всех корректных файлов монолита занимает около двух минут.


Про slowlint у меня, видимо, плохо получается пояснять. Попробую ещё раз здесь.


Предпосылки такие:


  • У нас было большое количество файлов, которые не проходят линтинг. Почти все, на самом деле.
  • Хотелось, чтобы линтинг был в CI, но при этом не мешал разработчикам.
  • Хотелось, чтобы линтинг шёл постепенно. Прогонять --fix по всему репозиторию — чревато ошибками, грозит потерей верхнего слоя истории, мердж конфликтами, да и не поправит автомат и половины ошибок.
  • Хотелось, чтобы новые файлы обязательно соответствовали нашим стандартам.

Можно было бы вогнать всё в .eslintignore, но тут проблема — если это сделать, то любая IDE сразу применит его и перестанет использовать линтер — так что ничего лучше не станет. Хотелось таки мозолить глаза разработчикам. Поэтому slowlint делает очень простую вещь — он позволяет добавить дополнительный файл а-ля .eslignignore, который не воспринимается IDE, но используется при проверках. К сожалению, из коробки в eslint нет возможности использовать два игнор файла, иначе надстройка была бы не нужна.


В результате, файлы у нас делаятся на три категории:
1) Игонорируется в .eslintignore — те вещи, которые не надо трогать никогда — например, легаси библиотеки. CI, IDE и линтер их игнорирует. В целом, у нас уже нет такого кода в репозитории.
2) Игнорируется в slowlint — те вещи, которые надо исправить. IDE не воспринимает этот игнор, ошибки мозолят глаза разработчикам, код постепенно переписывается и удаляется из игнор листа. А ещё этот список можно автоматически перегенерировать при помощи slowlint, если внезапно куча некорректного кода исправилась или куда-то уехала.
3) Нигде не игнорируются.


Звучит несколько сумбурно, но отлично у нас отработало.


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

9 лет в монолите на Node.JS

Набор для игры в Лазертаг. Посвящается тем, кто играл в войнушку

0
Очень люблю лазертаг. Но проблема — хочется играть компанией человек в 8, при этом хотя бы с несколькими режимами — десматч, командный десматч и захват точки. К сожалению, описанная в статье игрушка всего этого не даёт. Думал какое-то время собрать сам — протокол-то известный, и делается в пол пинка на ардуинах — даже есть соответствующие исходники и схемки — но вот времени на это никак не хватает. А сподвигнуть никого не смог, даже за деньги. Какое-то время думал просто купить готовый набор — но он каких-то совсем несуразных денег везде стоит.

MMORPG в одиночку (2d stalker)

+16
Так почему не вложить в открытый доступ код? Если вы не собираетесь монетизировать проект, то минусов у такого решения нет. Понятно, что стыдно обычно… Но пускай это вас не останавливает.

Плюсы выкладки:
1) Могу найтись ещё энтузиасты, которые вам помогут. Если не разработкой, то может быть контентом или графикой.
2) Возможно, кому-то это поможет понять, как работают игровые движки, или сделать свою игру на основе вашей, что тоже приятно.

Как проходят алгоритмические секции на собеседованиях в Яндекс

+35
Полным аналогом подобных собеседований для разработчиков является прохождение IQ тестов для любой другой специальности. Когда-то это даже было популярно. Но со временем таки большая часть адекватных людей осознала, что результат прохождения IQ тестов зависит только от того, сколько человек тренировался в прохождении IQ тестов.

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

И вдвойне забавно выглядит то, что компания фактически признает то, насколько синтетические у неё собеседования — публикуя советы, рекомендуя leetcode и целый сервис «контекст» исключительно для того, чтобы люди могли проходить эти тренировки.
Не, я не спорю — решать алгоритмические задачи весело и интересно. Как и всякие там IQ тесты, тренажёры для мозгов типа luminocity и так далее. Но у меня есть подозрение, что таким образом компания теряет людей, которые действительно занимаются разработкой, и у которых нет времени или желания тренироваться в прохождении синтетических тестов.

Я прочитал 80 резюме, у меня есть вопросы

0
Да, доверяют. По сути это минимальная проверка на адекватность — что человек в нужном городе, на нужном стеке, с релевантным опытом, с разрешением на работу, смог внятно заполнить резюме и договориться о интервью. А не откликнулся на вакансию, например, с идеей продать нам свою CMS (да, и такое бывает).

Кроме этого, HR так же общаются с человеком на очном этапе на пространные темы. Редко бывает, чтобы что-то насторожило, но в этом случае уже вырабатывают общее мнение со всеми, кто беседовал с соискателями.

Но у нас HR реально крутые. До сих пор (два года уже) приятно, насколько было адекватное общение при устройстве на работу.

Я прочитал 80 резюме, у меня есть вопросы

+73
Прям зацепился глазами за потребность рассказать о себе и обязательно учесть минусы.
Моя личная точка зрения как соискателя и как техлида большой компании, который тоже участвует в HR процессах:

1) Моё хобби и личные увлечения не должны иметь значения для компании. Не то, чтобы мне было что скрывать, но зачем?
2) Сопроводительное письмо я буду писать только если я собираюсь прям в дрим тим. Если компания с моей точки зрения рядовая — я просто буду кидать резюме пачками. Пусть и с более низкой конверсией. Потому что ценю своё время и потому что считаю выдавленное из себя сопроводительное письмо извращённой формой лести — не хочу идти в компанию, где это реально важно.
3) Нет, я не буду указывать минусы. Потому что не знаю, как оценит это читающий, и насколько важно в его глазах это будет. В двух предложениях сложно раскрыть минусы подробно, а эссе я писать не буду — длинные резюме сразу уходят в помойку, большинство людей не осиливает их читать. Если интересно, о минусах можно поговорить на личном собеседовании.

Как не поддаться панике, если в гости нагрянуло много программистов?

+1
Хотел увидеть про проблемы и лайфхаки, увидел только рекламу…

PHP GR8: повысит ли JIT производительность PHP 8

-7
Я к тому что эти «80% рынка» не имеют отношения к разработке, и являются готовыми настроенными решениями. Что никак не должно влиять на решение выбора языка при разработке своего проекта.

Если мы хотим узнать, что именно «на рынке» — можно, посмотреть последний опрос на stackoverflow по используемым языкам, например. Или зайти на hh и сравнить количество вакансий по разным языкам. И увидеть, что там и в помине нет никаких 80% PHP.

PHP GR8: повысит ли JIT производительность PHP 8

-15
Есть ложь, есть наглая ложь, а есть статистика.

Убираем из этой статистики друпалы, вордпрессы, битриксы и так далее — получим совершенно другую картину.
Ну или можно пойти от обратного — как много вы знаете крупных порталов, продуктов и систем, которые написаны на PHP?

Если кто-то правда сидит и думает, на чём ему написать очередной CRUD — да, PHP отлично под это подходит. Но разбрасываться фразами про «доминирование» и «делаете неправильно» — это очень странно. Причём вне зависимости от контекста.

PHP GR8: повысит ли JIT производительность PHP 8

-21
Не хотим хвастаться, но PHP доминирует в вебе. Если вы занимаетесь веб-разработкой и не рассматриваете использование PHP в своём следующем проекте, то вы что-то делаете неправильно.


Простите, при всей моей ностальгической любви к PHP, вы тег «ирония» потеряли. Осторожнее, люди же читают и верят.

12 приемов работы с JavaScript, которых нет в большинстве туториалов

+4
Любопытно — я был чуть ли единственным, кто негативно откомментировал эту статью на медиуме. В основном были восторги. То ли уровень разработчиков на хабре выше, чем на медиуме, то ли там просто не любят негатив писать.

Чеклист для создания и публикации веб-приложений

+7
Выбор автором серверных языков правда является субъективным, без претензии на объективность.
Нету node.js, нету .net core…
А вообще статья с абсолютно непонятной ца. Тому, кто поймёт в ней все слова, она ничего нового не скажет. В тому, кто не поймёт — тем более.

Древности: когда телефоны были странными

0
Ага. Но, кажется, он всё.

Поэтому хотел тупо планшет с двумя экранами — как йотафон, только больше.

Древности: когда телефоны были странными

0
Забавная штука. Не видел. Но на первый взгляд это скорее дорогой небольшой неудобный ноутбук, а не планшет. Хочется что-то на 7-9 дюймов, на андроиде, в пределах 60к и можно не раскладывающееся.

Древности: когда телефоны были странными

+1
Насчёт экспериментов — который год жду планшет с двумя экранами, один из которых на E-Ink. Но пока что был только YotaPhone, мир его праху…

Тестирование смарт-контрактов Ethereum на Go: прощай, JavaScript

0
Ну так бы и написали сразу, что чтение для не Go разработчиков строго воспрещено.

А хейтерство начинается прямо с бессмысленной сопроводительной картинки и вступления:
Однако, у этого подхода есть один важный недостаток: для написания тестов нужно использовать Node.js.

Дальше ещё целый бессмысленный параграф про «ловушки Javascript». Даже комментировать не буду.

Нормально и без хейтерства — это заменить всё это на честное и вполне понятное
Поскольку основную часть команды составляли Go-разработчики, тестирование на Go было предпочтительнее, чем на Node.js.

Ну и в заголовке убрать «прощай, JavaScript». Статья бы ничего не потеряла для смысла ни для какой аудитории. Но выглядела бы адекватно.

Ну и из смешного
Perigord — это надежный инструмент для тестирования, написанный на вашем любимом языке.

Откуда вы знаете любимый язык читателя? Хотя да, я уже забыл — статью разрешается читать только Go разработчикам…

Тестирование смарт-контрактов Ethereum на Go: прощай, JavaScript

+3
Очень хочется порекомендовать автору попробовать программировать вместо хейтинга. По статье складывается ощущение, что продуктивность может вырасти раза в 4.

Как мы моббинг пробовали

+1
Наверное, не стоит называть mob programming моббингом, если никто этого не делает (не просто так в гугле это несвязанные понятия). Ну, если только вы не занимались на работе именно моббингом.

Смены в 5 минут? Серьёзно?
Вывод о том, что навигатор должен быть опытнее драйвера, при условии ротации ролей?

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

История о том, как мы ускорили тесты в 12 раз

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

Окей, Google! Ты добро или зло?

+2
Да, всё так. По этой причине стал выкладывать свои приложения только на гитхаб и обновлять оттуда же. Нервов на этот ад не хватает. На хабре тоже уже писали.

Вот навскидку несколько петиций: раз, два, три. По количеству видей видно, что всем правда больно. Но активности по петициям нет. Желаю удачи вам и вашему юристу от всей души.

Как мы мигрировали базу данных из Redis и Riak KV в PostgreSQL. Часть 1: процесс

0
А в паблике есть? Или может планирует выложить? Наверное, вы уже поняли, что у меня интерес не теоретический…
1 There