Приветствую, это Денис из команды BagrovChibirev, и в статье я на простом примере расскажу об автоматизации процессов в Linux с помощью bash скриптов (сценариев командной строки).

Этот материал для тех, кто только рассматривает для себя инструменты автоматизации рутинных процессов. Я не буду вдаваться в подробности работы оболочки или терминологию (на знания чего и не претендую), но я пошагово пройдусь по написанному скрипту и расскажу своё мнение почему вообще их стоит использовать. Приятного чтения :)

Рассматривать я буду свой минималистичный скрипт для разворачивания простого python Django проекта при помощи системных юнитов (демонов) на удалённом сервере. Для тех, кто не в курсе: демоны - это специальные системные сервисы, которые следят за состоянием сторонних процессов и поддерживают их работоспособность. В современном мире для таких целей на микросервисах применяется Docker, но когда проект небольшой и состоит из пары-тройки процессов, их намного легче, проще и дешевле для системы (в разы), развернуть при помощи встроенных в линукс демонов.

На дворе 2023 год, и мы выпустили Node.js v20. Это значительное достижение, и цель этой статьи — использовать научную оценку состояния производительности Node.js.

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

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

Интро: почему я написал эту статью

Меня зовут Виктор, я разрабатываю страницу результатов поиска Яндекса. Несмотря на внешнюю простоту, поисковая выдача — сложная штука: на каждый запрос генерируется своя уникальная страница, на которой в зависимости от запроса может присутствовать блок Картинок, Карты, Переводчик, видеоплеер и многие другие компоненты. Все они должны запускаться и работать в памяти обычных бюджетных телефонов, которые использует большинство наших пользователей. Браузерам должно хватать ресурсов, чтобы пользователь не видел вот такого:

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

Разрабатывая проект на JavaScript (TypeScript, ClojureScript или каком-то другом языке, транслируемом в JavaScript), мы привыкли создавать объекты, массивы, строки и вообще писать код, как будто память бесконечна. Это не так. Я расскажу о видах проблем с памятью, о том, какие ограничения мы часто забываем и как их можно преодолеть. В ответ браузеры и пользователи скажут вам спасибо.

• Категории проблем с памятью
• Ограничения по памяти для разных типов данных
  　Heap
  　Buffer, TypedArray
  　String
  　Map, Set
  　Call stack
  　Типичные задачи, в которых можно наткнуться на ограничения по памяти
• Soft-утечки
  　Пример из продакшена
  　Как получаются soft-утечки
  　Как их обнаружить
  　Как найти причину
  　　1. Memory Allocation Timeline
  　　2. Техника трёх снапшотов
  　　3. queryObjects
  　　Тренируемся находить утечки
• Hard-утечки
  　Пример из продакшена
  　Как бороться
• Нестандартные оптимизации памяти в Node.js
  　Исходный код
  　Module._pathCache
  　Несколько версий пакета в node_modules
  　require('./data.json')
• Заключение

Когда мы имеем дело с большим проектом, в репозитории которого накопились десятки тысяч строк кода, иногда единственным здравым решением кажется все переписать с нуля, а не оптимизировать. С точки зрения бизнеса может возникнуть вопрос: а почему вообще нужно оптимизировать или даже переписывать приложение, если оно работает? Дело в том, что по мере роста кодовой базы есть вероятность увеличения дублирующихся компонентов/фрагментов кода, появления устаревших участков, которые тормозят сборку, но полезной нагрузки уже не несут. Это негативно влияет на скорость работы приложения и увеличивает срок разработки.

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

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

Статья будет полезна тимлидам и техлидам проектов, а также разработчикам, которые столкнулись с развертыванием крупных неоптимизированных React-приложений.

Все мы знаем про, или слышали про практики и паттерны проектирования SOLID, GRASP, MVC, MV** и даже применяем их с переменным успехом, стараясь нащупать эффективный подход к построению приложений. Но это лишь приводит к разнообразию реализаций наших приложений и частей функционала. Уже долгое время пытаюсь понять по каким правилам должно строиться фронтенд приложение чтобы оно удовлетворяло следующим критериям:

- легкое расширение функционала приложения;
- безболезненное внесение изменений в существующий функционал;
- унифицированная структура приложения;
- быстрый onboarding новых разработчиков на проект;
- понятный и прозрачный код;
- всегда понятно где в структуре файлов расположить ту или иную функциональность. 

Какие у нас есть варианты?