Development

Хорошая статья про ререндеры react-компонентов. В статье описываются основные источники ререндеров и как нужно структурировать код, чтобы избежать лишних ререндеров. Плюсы статьи: - Это не просто заметка в стиле "вот проблема, вот 2 решения". Тут достаточно подробно описаны как причины, так и решения. Описано много способов, как можно решить проблему лишних ререндеров. - Очень хорошая визуализация. Даже если вы все знаете о рендере в реакте или, наоборот, реакт вам вообще не интересен, советую хотя бы глянуть визуализацию. Выглядит потрясающе

Статья про то, почему нужны import maps и как они работают. На момент введение ES-модулей сообщество уже привыкло использовать пакеты из npm. При этом мы хотим писать код в браузере также, как пишем его обычно. И тут то и кроется конфликт. Например, вы хотите импортировать библиотеку `import lib from 'lib'` - это то, как мы обычно делаем с npm. Однако в браузере нам бы необходимо было написать что-то вроде `import lib from 'https://some.cdn.com/lib@1.0.0'`. Вот этот конфликт и решаются Import Maps. Они позволяют писать импорты в браузере также, как при использовании npm. Например, на нашем примере это будет выглядеть так ``` script type="importmap" { "lib": "https://some.cdn.com/lib@1.0.0" } /script script type="module" import lib from 'lib'; /script ``` При этом скрипт с Import Map должен быть вставлен до первого скрипта с type=module. Также, вместо того, чтобы описывать объект с мапингом прямо в тэге script, можно подтягивать Import Map через src, но при этом заголовок `Content-Type` должен быть выставлен в `application/importmap+json` `script type="importmap" src="/importamap.json"/script` Кроме того у Import Maps есть несколько фишек Во первых, можно делать Import Map на группу пакетов. Например, на lodash ``` script type="importmap" { "imports": { "lodash/": "/node_modules/lodash-es/" } } /script script type="module" import toUpper from 'lodash/toUpper.js'; import toLower from 'lodash/toLower.js'; /script ``` Во вторых, можно сделать алиасы на разные версии одного пакета ``` script type="importmap" { "imports": { "lodash@3/": "https://unpkg.com/lodash-es@3.10.1/", "lodash@4/": "https://unpkg.com/lodash-es@4.17.21/" } } /script ``` Либо, можно предоставлять разные версии пакета для разных скриптов на основе path скрипта ``` script type="importmap" { "imports": { "lodash/": "https://unpkg.com/lodash-es@4.17.21/" }, "scopes": { "/static/js": { "lodash/": "https://unpkg.com/lodash-es@3.10.1/" } } } /script ``` Кроме того, можно формировать Import Map динамически ``` script const importMap = { imports: { lazyload: 'IntersectionObserver' in window ? './lazyload.js' : './lazyload-fallback.js', }, }; const im = document.createElement('script'); im.type = 'importmap'; im.textContent = JSON.stringify(importMap); document.currentScript.after(im); /script ```

Статья от создателя фреймворка Qwik про идею фреймворка. Что должны делать фреймворки, чтобы создавать приложения, которые стартуют моментально? Две вещи: - Загружать и исполнять только тот код, который нужен для обработки взаимодействия пользователя - Не делать работу дважды на сервере и на клиенте Все текущие фреймворки основаны на клиентском рендере и гидрации, а поэтому не могут исполнить оба условия моментально открываемых приложений. Работа над Qwik началась в 2021 году с идеи "а насколько мы можем отложить исполнение кода на клиенте?". В итоге это переросло в 2 механизма, которые лежат в основе Qwik: - Рендерить все на сервере.Пока все фреймворки используют SSR как дополнительную фичу для улучшения пользовательских метрик, qwik делает основную ставку на SSR. Для большинства сайтов qwik отдает чистый HTML без JS. Дополнительный код загружается только тогда, когда этот код становится нужен (например, пользователь кликнул на кнопку). - Подгрузка клиентского кода только тогда, когда он реально нужен. В текущих фреймворках за ленивую подгрузку отвечают разработчики, в то время как в qwik она из коробки предоставляется фреймворков (по умолчанию, все подгружается лениво)

Продолжение сравнения bun и node.js. Статья от того же чувака, которого я уже постил. И даже кейс тот же - он переводит свой сайт. Но эта статья - она типа v2.0 прошлой статьи про bun vs node.js Что тут нового: - Разбор перформанс тестов. Например, там есть набор тестов, тестирующих скорость доступа к sqlite, т.е. тестируются библиотека для nodejs, библиотека для deno и встроенное в bun нативно решение на rust - Автор чуть более подробно рассказывает про то, как он тестировал совместимость bun и node.js на своем проекте. К чести bun, автор оформлял им реквесты в github и к моменту публикации статьи некоторые уже были пофиксены. - Автор сделал свой бенчмарк (или он у него уже был), где проверяются основные инструменты, использующиеся в его проекте (рендер блога). Из 11 сценариев на bun он смог перенести всего 6. Но при этом те, которые были перенесены - в целом выполнились быстрее (в среднем на где-то 10%, но один бенч выполнился в 2 раза быстрее) Далее автор описывает свой опыт работы в Java, где есть спека и есть куча рантаймов, его имплементирующих. И есть тесты для этих рантаймов. И вот как было бы круто, если бы была спека node.js (хотя он не язык и ему незачем) или хотя бы какая-то хорошая табличка совместимости, за которой можно следить.

Еще один рантайм для JS приложений. Опять V8, опять обвязка на Rust. Но теперь узкоспециализированный кейс - рантайм написан специально для построения распределенных систем (например, лямбды) Также, по классических маркетинговых стратегиям, есть график сравнения холодного старта blueboat (17мс) vs deno (30мс) vs node+express (140мс) (естественно Из коробки много API, достаточного для того, чтобы строить сервисы без зависимостей - sql клиент, web-сервер с роутингом, pubsub, s3 В общем такой узкоспециализированный комбайн для распределенного бекенда, поддерживающий основные хотелки из коробки

Дебаг в JS, традиционно, осложняется тем, что многие функции являются анонимными и не имеют имен. Движки даже пытаются по максимуму помочь разработчикам и сами дают имена анонимным функциям, если это возможно в кейсе Например, ходит поверье, что все стрелочные функции анонимны и имя им нужно задавать явно Но это не так Например, попробуйте выполнить в консоли браузера ``` const myNameIsA = () = {} console.log(myNameIsA.name) // "myNameIsA" ``` Однако, движок нам не может помочь с React кодом. В статье описывается, что нам следует более внимательно следить за тем, как мы заводим контексты и используем React.memo и React.forwardRef, т.к. при обычном использовании мы в React DevTools получим непонятное название компонентов. Для контекстов нужно явно указывать `displayName`, тогда вместо непонятных `Context.Provider` мы в DevTools сможем увидеть `MyAwesomeContext.Provider` С React.memo и React.forwardRef есть разные способы решения проблемы, но самый простой и эффективный - также явно указывать displayName ``` const HeavyComponent = React.memo(() = (props) { ... }) HeavyComponent.displayName = "HeavyComponent" ``` Хотя можно вынести колбек в отдельную переменную и это тоже сработает.

Sentry уменьшили размер своего SDK на 29%. Что они сделали для этого: - Теперь код поставляется как es6. Если кому-то из пользователей sentry требуется es5-версия кода, то он может затранспайлить sentry на своей стороне - Удалили лишний код - Удалили лишние абстракции. В некоторых случаях были выделены абстракции, для, например, разделения контекстов. Однако профит был малым, а лишние байты отсылать не хотелось. - В sentry теперь можно самим определять некоторые фичи. Например, многим клиентам не нужны ВСЕ фичи sentry. Достаточно базовых. Или не нужны какие-то интеграции. Но вот это все, что не нужно - оно встроенно в класс клиента Sentry. В новой версии клиент Sentry не содержит в себе вообще всё, теперь есть возможность прямо провайдить те фичи и интеграции, которые нужны вашему проекту, что снижает количество бесполезных импортов, что снижает вес SDK - Включили тришейкинг webpack. Т.е. внутри кода sentry теперь расставлены разные *магические* константы типа `SENTRY_DEBUG`, которые вырезаются webpack'ом (или другими инструментами сборки, умеющими в dead code elimination и tree-shaking). Кроме служебных фич, можно отключить и фичи sentry Из этого всего, мне показалось достаточно интересным, то что для уменьшения размера SDK помог Inversion Of Control - теперь клиенту sentry надо самим провайдить транспорт, интеграции и прочие сущности. А также то, что часть функционала можно отключить через ENV переменные во время сборки. Если у вас есть свои либы - возможно это даст вам какой-то инсайт

В продолжение предыдущей статьи про staff-инженеров. Эта статья о дисфункциях в организациях, которые не позволяют staff инженеру работать эффективно. Мне многие поинты показались до боли знакомыми **Нанимают ведущих разработчиков, потому что они самостоятельны. Но на деле это озночает "без нашей поддержки"** В данном случае менеджеры хотят закрыть проблему онбординга и процессов, наняв "самостоятельных" крутых разработчиков. Проблема в том, что в такое место некрутых разработчиков действительно сложно нанимать, но считать что ведущим разработчикам не нужна поддержка - это также ошибка. **"Лидер с влиянием"** Лидерство это в целом штука вокруг влияния. Но данный пункт про ситуации, когда менеджмент ищет лидера, который должен влиять на людей вокруг, но при этом выстроена строгая структура управления, где у нанятого сотрудника нет инструментов для влияния на других людей. **Микроменеджмент лидеров** Очень похожий на предыдущий поинт. Смысл в том, что для масштабирования компании мы взяли и наняли лидеров (ну или вырастили внутренних). И с одной стороны от них ожидается это самое лидерство, с другой стороны руководство может начать делать микроменеджмент (что сделано? когда будет сделано? почему Вася работает так медленно?). Но зачем тогда нужны лидеры, если мы продолжаем заниматься микроменеджментом? **Каждый должен кодить"** Довольно частая мысль, что руководители разработки (любого масштаба) тоже должны писать код. Отдельная ветвь этой "болезни" - тимлиды как играющие тренеры. У этой дисфункции несколько проблем. Во-первых, люди, которые утверждают, что лид должен кодить - вероятнее всего считают, что управление - это не настояшая работа. Что это так, вдовесок. Многие вещи, которые нужно делать лиду - никак не сделать с помощью кода. Например, поставить эффективный процесс разработки. Во вторых, работа лида не в том, чтобы писать какую-то часть системы. Да, возможно этот человек пишет божественный код без багов и с 100% покрытием автотестами. Но есть одна проблема. Это банально плохо масштабируется. Вмест того, чтобы самому быть "крутым", лид должен заниматься тем, чтобы все вокруг стали "крутыми". Это и есть его работа - делать культуру, растить команду, людей. **Вы наняли человека супер-звезду чтобы он что-то изменил в компании. Но ничего не изменилось** Если вы действительно наняли такого человека, а через пару лет он уволился и, вроде, сделал много полезного, но стратегических целей в этом направлении компания не достигла, то, как правило, это вина компании. Возможно компания не готова к изменениям, о которых сама говорит и для которых нанимает людей. Возможно, вновьприбывшим звездам не дают рычагов управления, для проведения изменений. Если супер-крутой чувак не смог сделать то, для чего его нанимали - стоит искать проблемы внутри компании. **Единственный инженер - он же СТО** Часто так бывает, что единственный сеньористый сеньор в маленькой компании становится СТО. Однако, это совсем разные роли. Нельзя ожидать от самого крутого кодера, что он будет крутым лидером. Эта проблема усугубляется в кейсах, когда крутого кодера нанимают из-вне, проверяют что он по настоящему крутой кодер, а потом пытаются сделать из него СТО. **В вакансии указано "ищем ведущих разработчиков, лидов, СТО" на одну роль с едиными требованиями** Компания не понимает, кого она ищет. **Нам не нужны архитекторы, но...** Это ловушка в быстрорастущих компаниях. Когда у вас было мало людей - все было хорошо. Все знали всё и не было проблем с контекстом. Но когда компания выросла, вы еще можете чувствовать, что вам не нужен выделенный архитектор. Но тем временем система утрачивает единую целостность. **Кастомная система уровней** Это когда компании отказываются от общеупотребительных терминов и строят свою карьерную лестницу, со своим блэкджеком и слухами. **Люди не вовлечены\ не мотивированы** Кейс с этой ошибкой: вы наняли человека, который умеет проектировать и поддерживать сложные системы, а затем даете ему простой проект, не требующий таких навыков. Из-за этого несоответствия человеку быстро станет скучно и он потеряет мотивацию. Подобное несоответствие (взяли лида - не дали команду, взяли крутого спеца - не дали крутых задач) - ведет к потери мотивации и вовлечения **Более 20% персонала - staff+ инженеры** Здесь проблема в том, что эта конфигурация - неустойчива. Много лидов, но мало людей, которыми нужно руководить. Действительно ли вам нужно так много лидов? **Что же делать?** В статье все эти пункты описаны подробнее (часть я не стал описывать). Также там описана корневая причина этих проблем (например, в компании не определена роль лида или у лидеров нет поддержки). Если что-то из дисфункций в статье относится к вам, то найдите корневую причину (возможно подходит, указанная в статье) и ищите как ее вылечить.

Чем же занимаются staff-инженеры? Термин staff engineer я встречал только в англоязычном интернете. В русскоговорящей среде, как будто, нет аналога. Есть старшие разработчики, ведущие, техлиды, архитекторы. И в разных компаниях они занимаются совершенно разными вещами. В статье описываетс, чем же обычно занимается Staff инженер. Если сильно утрировать, то staff инженер занимается стратегически важными направлениями в рамках технического развития и развития команд. В статье выделяются следующие направления работы **Техническое лидерство (в оригинале Setting technical direction)** Технологии не могу говорить за себя, поэтому нужен человек, который будет выступать адвокатом технологии. Эти адвокаты прагматичны и мыслят стратегически. Иногда staff инженеры нанимаются для ведения специальной области, такой как проектирование API. В целом в рамках этой роли нужно уметь принимать стратегические технологические решения, которые, в первую очередь, следуют от нужд организации. **Менторство** Многие инженеры избегают менторства, считая это "ненастоящей" работой. Однако, это одна из самых важных работ staff инженера. Staff инженер должен распространять свои знания в организации, менторить других людей, давать советы. Staff инженер должен растить людей вокруг себя **Представляет инженерный взгляд (в оригинале Providing engineering perspective)** При принятии решении о том, что и как нужно делать, всегда необходим взгляд инженера на проблему. Это позволяет принимать решения, которые могут быть лучше для пользователя (например, инженер может увидеть, что фичу можно улучшить без дополнительных затрат), или проще реализовать, при этом не потеряв в функционале. **Исследование** Организациям нужно уметь исследовать. Исследовать и экспериментировать с новыми фичами, рынками, возможностями. При этом крупные исследования - всегда риск. В таких исследованиях, как правило, принимают участие staff инженеры. **Быть клеем (в оригинале Being Glue)** Делать нужные, но невидимые другим, задачи, которые позволяют команде делать работу и релизить задачи. Этим особо не похвастаешься, но как правило 1 или несколько Staff инженеров работают где-то на невидимом фронте, позволяя командам работать быстро и эффективно. **Пишут ли staff инженеры код?** it depends. В целом пишут, но не в том объеме, что на более ранних позициях и, скорее всего, не тот код. Если, будучи разработчиком в продукте нужно писать разные продуктовые фичи, то staff инженер изредка пишет продуктовый код, но пишет много кода "вокруг" - автоматизация, аналитика, эксперименты **Медленная обратная связь** Работа staff инженера - она про стратегию. Поэтому цикл обратной связи очень долгий - недели, месяцы, годы. Это, с одной стороны деомтивирует, т.к. ты работаешь, но можешь не видеть результата месяцами. С другой стороны, когда результат виден - он значимый. Например, можно вырастить самостоятельную самоорганизаванную команду, управляющую своими процессами. Можно внедрить сложный подход к разработке (разработка через контракты например). Оба этих действия делаются долго, скорее всего месяцы. Но зато, когда в итоге получилось изменить систему - результаты от изменений дают значительное влияние на организацию.

Недавно вышел выпуск подкаста подлодки про оценки. А точнее про то, что в большинстве случаев - оценки не нужны и даже вредят. Виталий рассказывает, почему оценки не работают, почему оценки не нужны в большинстве случаев и когда они все таки нужны, а когда они конкретно вредят. В этом выпуске нет прям откровений, но есть интересные мысли и отсылки на разные теории\исследования. Отсюда и ниже идет мое мнение про оценки Вообще с оценками в разработке все очень сложно. Чем больше неопределенность, тем хуже с оценкой. Поэтому, по моему мнению, мы можем оценивать работу только в двух случаях: - мы это уже делали (нет неопределенности) - задача маленькая, например не больше недели (скоуп работ малый = неопределенности мало) Достоверно оценивать что-то иное (большая задача, делаем что-то новое, внедряемся в новый контекст) - практически невозможно. Конечно придумано много разных техник, которые даже немножко работают - story points, майки, no estimates, PERT. Но все они разбиваются об то, что разработка, практически всегда содержит неопределенность (иначе бы разработка не понадобилась - взяли бы конструктор\шаблон). Поэтому единственный способ быть результативными - резать скоуп задач. Все практики разработки построены вокруг решения кучи маленьких задач, а не огромных проектов

Статья про борьбу с выгоранием у лидера. За основу берётся библейская история о Моисее - там рассказано, как тесть Моисе предостерег его от выгорания. Итак, три способа избежать выгорания, будучи лидером: Учить. Лидеры часто считают, что обучение не является частью их работы, либо не выделяют на это времени. Однако же обучение команды позволяет команде эффективней решать проблемы и разгрузить лидера. Поэтому, будучи лидером, нужно найти время на обучение команды. Делегирование. Лидер не может делать все сам на всех уровнях. Поэтому следует подготавливать лидеров на следующем уровне. Обработка сложнейших кейсов Делегирование не означает, что можно больше не заниматься сделегированной ответственностью. Лидеру следует принимать участие в решениях сложнейших кейсов. Так он поможет команде и поддерживает свои навыки работы Статья достаточно короткая и чем-то похожа на "успешный успех", но советы простые и рабочие: - обучай - делегируй - принимай участие в сложнейших кейсах

Оказывается, в NodeJS есть возможность определять кастомные загрузчики для esm файлов. Пока, правда, это фича считается экспериментальной Что это значит и как это работает? NodeJS поддерживает ES modules. Но некоторые модули мы не можем заимпортировать в nidejs просто так. Например, нельзя просто так, без уважения, делать импорт css-стилей для реакт приложения или импорт TS файла. Для решения этой задачи можно взять какой-нибудь инструмент типа babel, webpack, vite etc. Но также в NodeJS есть возможность указать кастомные загрузчики модулей, которые могут помочь в этой ситуации. В статье рассматривается загрузка css-кода в рамках запуска тестов в mocha.js. Для решения этой задачи мы могли бы заиспользовать какие-нибудь плагины к mocha или сделать обвязку вокруг mocha, которые подготовят все файлы, предсобрав их с помощью какого-нибудь препроцессора. Но решения для этой задачи можно написать свой кастомный загрузчик. Для тестов нам не нужно получать честный css, достаточно получить только имена классов. Такой загрузчик относительно легко написать, при этом не нужно заводить сложные инструменты для решения этой простой задачи. В рамках статьи также добавляются лоадер на TS файлы и лодар для загрузки сетевых ресурсов (`import blabla from 'https://blabla.com'`). Само применение лоадеров выглядит вот так ``` node \ --loader typescript-loader \ --loader css-loader \ --loader network-loader \ app.tsx ``` Применение этих лоадеров позволило в 8 раз ускорить работу тестов. Также в статье приводятся ссылка на другие интересные лоадеры. Рекомендую посмотреть статью, если вы интересуетесь nodejs или кастомными решениями для автоматизации (возможно кастомные лоадеры помогут вам решить какие-то проблемы)

И вот подошли первые независимые тесты перформанса нового рантайма Bun. David Herron попробовал запустить на Bun свой генератор статических сайтов AkashaCMS на примере реальных проектов. Один из них остоит из 1600 страниц - достаточно внушительный размер. Для того чтобы запустить свой проект на bun, пришлось сделать немножко приседаний. Например, bun не предоставлял некоторых значений в `process`, а также не умеет скачивать зависимости из package.json, которые ведут на github. В целом это минорные проблемы и их должны порпавить в ближайшее время. Затем David Herron провел сравнение bun и nodejs для двух сценариев: - копирование статики (более 2000 файлов для одного из сайтов) - рендер статики В обоих сценариях bun имеет примерно тот же перформанс, что и nodejs. Какие выводы из этого можно сделать? - bun в бета и поэтому еще поддерживает не все (значения в process, зависимости ссылкой) - пока что супер перформанс bun'а не подтвержден - тем не менее, то что bun версии 0.1.0 по перформансу такой же как nodejs - это очень круто. Ждем еще независимых исследований.

Вышел Vite 3.0. Если вы вдруг не знаете, что такое Vite - то пару лет назад создатель Vue решил сделать свой бандлер на основе современных подходов и назвал его Vite. С тех пор Vite обзавелся хорошей документацией и экосистемой. Vite - это, в первую очередь, аналог webpack, но только легче и быстрее. Что интересно, в экосистеме Vite также есть аналоги, которые тоже просто легче и быстрее оригиналов, например vitest (аналог jest) и vitebook (аналог storybook). В общем, очень крутой инструмент и один из лучших вариантов для выбора бандлера в новый проект Вернемся к релизу 3.0, что изменилось: - Новая документация (сделана с помощью VItePress) - Для разработки - Добавлены стартовые шаблоны для самых популярных кейсов (vue, svelte, react, etc) - Ускорена первая сборка в dev режиме (холодная сборка) - Собирается в ESM по дефолту для SSR сборки. - NodeJS 12 более не поддерживается Также в блог-посте есть график с фиксом багов в репозитории Vite. И этот график внушает уважение к команде разработки. Если вы хотели попробовать vite - вот вам еще один повод. А если вы уже используете vite - можете в комментариях рассказать, как он вам. Лично у меня есть 1 пет-проект, который собирается с помощью Vite и после webpack'а это как глоток свежего воздуха. Что приложение что storybook (с vite внутри) собираются очень быстро.

Короткий гайд про то, как найти утечку памяти в nodejs приложении. Рекомендуемый алгоритм такой: - Взять один из инстансов прод приложения после старта, вывести его из под трафика, сделать снапшот. Создание снапшота - ресурсоемкая операция. Поэтому мы выводим инстанс из под трафика и также нужно следить, чтобы инстансу хватило памяти так как для создания снапшота необходимо примерно столько же памяти, сколько уже используется приложением - Ввернуть трафик на инстанс - Снова вывести, сделать второй снапшот, сравнить их и провести анализ При этом в статье есть ссылки на инструменты для этого и ссылки на три больших и полных гайда по устранению утечек памяти

Помните времена, когда каждый день появлялся новый стейт менеджер для React? Это происходилл, потому что React, с одной стороны, не дает никаких рекомендаций по управлению состоянием, а с другой стороны, нужно решить несколько проблем: - прокидывать данные через дерево компонент или напрямую в компонент? - мутабельный или иммутабельный стор? - один глобальный стор или много маленьких? - а как оптимизировать ререндеры? - как работать с сетью? Каждый вопрос решается по-разному в разных решениях. Статья подробно описывает и проблемы и решения, эволюцию подходов к управлению данными в React, и даже есть поверхностное сравнение каким образом решены одинаковые проблемы разными инструментами

Огромный и подробный туториал по тому, как сделать свои шахматы на JS. Здесь проектируется именно алгоритм игры, сама же доска и движок (то что обсчитывает, как могут двигаться фигуры, а как не могут) - берутся готовые. В статье сначала разбирается простейшая задача - как сделать так, чтобы компьютер играл сам с собой, выбирая случайные ходы. Это красиво, но лишено смысла. Поэтому автор постепенно делает более жесткие требования к движку и по-немногу добавляет логику. Сначала учит алгоритм выбирать ходы, где есть взятие фигуры. Но такие ходы тоже не оптимальны. Поэтому затем собирается min-max алгоритм для определения наилучшего хода. Затем мы начинаем упираться в перформанс и автор погружает читателя в разные оптимизации. В конце получается движок, который, по заверениям автора, может играть на ELO-рейтинге больше тысячи (кажется это уровень любительской игры обычного человека) Если вам интересны алгоритмы или вы хотели когда-то сделать свои шахматы - обязательно к прочтению. Очень хорошая стать

Вышла версия 2.0 notion-sdk-js. Не знал, что вообще есть что-то подобное для автоматизации notion, а тут аж вторая версия. Если вы активно пользуетесь notion (как я знаю, он достаточно популярен), то можно поиграться и сделать что-то полезное.

Bun - новый рантайм для JS (типа как NodeJS и Deno), который используется движок JavascriptCore, а обвязка вокруг написана на zig - это язык уровня C - низкоуровневый, ручное выделение памяти. Из интересного в Bun встроен бандлер, транспайлер (поддерживает JSX и typescript), тестовый фреймворк, клиент для sqllite, менеджер пакетов. Также из коробки поддерживается большинство NodeJS API, что позволяет использовать пакетов из нпм (да и вообще переиспользовать существующий nodejs код). В документации написано, что много чего написано с нуля (например транспайлеры). Также приводятся замеры, в которых bun просто разносит nodejs и deno по перформансу (разница в разы). Однако, если провалится в бенчмарк по рендеру реакта - то к нему есть вопросики. В общем, новый рантайм, но теперь на языке zic. Обещают что работает blazing fast, все есть из коробки и при этом совсестимо с NodeJS API. Однако 01.0 бета версия и пока никто не пробовал в продакшне. В целом развитие новых рантаймов считаю хорошим делом, но Bun на главной странице так себя продает, что появляется скепсис к нему. Посмотрим, что будет дальше.

Кент Бек, создатель Extreme Programming и популяризатора многих лучших практик, написал статью, в которой рассматривает вопрос минимального размера изменений. Блокирующее асинхронное код-ревью является, на текущий момент, стандартом индсутрии. Про пользы и минусы код-ревью написано уже много, но мы выделим один минус - если мы используем блокирующее (нельзя влить код без апрувов) асинхронное (непонятно когда мы получим апрув) код-ревью, то мы не можем делать маленькие изменения в систему т.к. это приведет к огромноу количеству код-ревью и взаимных блокировок. Поэтому, как бы не были хороши практики про частые изменения, при блокирующем код-ревью разработчики мотивированы группировать свои изменения, чтобы снизить издержки на код-ревью. Но даже если мы откажемся от код-ревью, у нас останется вопрос "а какой возможен минимальный объем изменений при применении CI и CD?". В рамках эксперимента по достижению минимального объема изменений Кент Бек с другими разработчиками попробовали схему из двух практик при разработке небольшого пет-проекта. Первая практика - Test-Commit-Revert (TCR) Она заключается в том, что если мы пишем код и хотим его закомитить, то если тесты прошли - коммит создается, а если не прошли - все изменения удаляются. ``` python sample.py && git commit -am "working" || git reset --hard ``` Звучит дико, но это мотивирует делать очень маленькие и безопасные изменения. Применение этой практики изменило подход к разработке - вносимые изменения были не просто небольшими, они были крошечными. И частыми. Вторая практика - это постоянный пуш и подтягивание изменений В рамках эксперимента это было реализовано простым скриптом ``` while(true); do git pull --rebase; git push; done; ``` В результате совместной работы в рамках 1го репозитория участники получали чужие и отправляи свои изменения моментально. Код всех разработчиков моментально становился синхронизированным. Конечно, такие практики нельзя просто взять и начать применять в реальных проектах. Для этого нужно менять культуру, нужные новые инструменты, нужны иные подходы к разработке. Решение проблем, блокирующих применение этих практик - ключ к быстрой разработке.

Статья о проблемах приоритезии фич для составления родмапа. Наверное все сталкивались с таким, что хотелок по улучшению продукта, намного больше чем возможностей. Ситуация усугубляется, когда источников хотелок становится много (продажи, маркетинг, 3 продакта с трех направлений). Есть различные фреймворки по тому, как взять и оценить выхлоп и стоимость задач, потом это все определенным образом вставить в формулу и получить число. Ну а числа то мы сортировать умеем! Это фреймворки типа RICE, WSJF и прочих. Однако, проблема в том, что в реальности они плохо работают. Причин тому много: - Невозможно корректно посчитать денежный профит от задачи. Вообще не от любой задачи можно посчитать прямой профит - Невозможно корректно посчитать усилия, требуемые на реализацию хотелок. На этапе оценки хотелки, к тому же, максимально абстрактные (нет смысла детально описывать фич-реквест, если мы не уверены, что будем брать его в работу) В итоге приоритезация проводится по фреймворку, но ее итог все равно никого не удовлетворяет и, как правило, берутся задачи, которые нравятся, а не те, у которых итоговый score - лучше. Автор статьи описывает вещи, которые, по его мнению, помогают и мешают работать Мешают: - Посадить людей оценивать огромный список задач. Это не работает т.к. как правило в таком списке смешаны разные типы работ, люди плохо работают с большими списками - Объяснения о процессах разработки. Можно долго распинаться об Agile, итеративности, законе Литла. Но вас не услышат - Ожидание, что фреймворк приоритезации решит все проблемы Помогают: - Разделение типов работ и выделение отдельных "бюджетов" на них. Т.е. условно у нас есть бизнес-фичи, на них мы отводим 50% всех работы. На тех развитие 20%, на баги 15%, на остальное - еще 15%. Это всего лишь пример из головы. Важно выделить разные типы работ и закладывать на них какой-то процент. Дальше правда встанет вопрос "а как мы проверим, что действительно X% тратится на такой тип работ" - Ограничить длину списка фич-реквестов от каждого реквестера очень коротким числом. Например 3 или 4 фич-реквеста - Еженедельно просматривать, что делается сейчас и что будет делаться в ближайшее время. Новые "небольшие" запросы появляются всегда. При еженедельном просмотре можно принять решение о том, чтобы убрать что-то менее важное, чем новый запрос. - Обозначать запросы как Now, Next, Later, Never - Определить, какую работу можно аутсорсить. Статья, во многом, выражает лишь мнение автора ( и он это явно выделяет через IMO), но интересные мысли есть. Если у вас болит процесс приоритезации бэклога - рекомендую к прочтению. Супер важной информации там нету, но какие-то тезисы могут вас натолкнуть на мысли об изменении своих процессов.

Вышла 2 версия библиотеки sigma.js. Sigma.js это библиотека, которая умеет рисовать графы. В релиз-посте описывается краткая история таких инструментов, почему понадобилась 2 версияя sigma и что в ней нового. Если коротко, то первая версия Sigma была написана в 2013 году и ее стало тяжело интегрировать с современным JS. Также было сложно имплементировать некоторые алгоритмы из теории графов и были возможности для оптимизации перформанса Во второй версии библиотека переехала на современный JS, из коробки имеет разные методы обработки графа (по-крайней мере я так понял, что они доступны из коробки, а также рендер теперь в WebGL. В посте пишут, что теперь можно рисовать огромные графы из десяток тысяч узлов и сотен тысяч связей.

Список фич, вошедших в ES2022 (большинство из них ддолжны быть вам уже знакомы): **`arr.at()` позволяет получить элемент по индексу (включая кейсы `arr.at(-1)` для взятия последнего)** ``` const cart = ['🍎', '🍌', '🍍']; cart.at(0); // '🍎' cart.at(-1); // '🍍' ``` **матчинг по RegExp возвращает индексы сопоставленных строк** ``` let input = "12,34"; let match = /,(\d+)/.exec(input); let indices = match.indices; // Первый элемент отдает индексы всего сопоставления indices[0]; // [2, 5]; // Второй элемент отдает индексы первой сопоставленной группы indices[1]; // [3, 5]; ``` **Object.hasOwn** ``` const obj = { prop: true } Object.hasOwn(obj, 'prop') // true Object.hasOwn(obj, 'toString') // false 'prop' in obj // true 'toString' in obj //true ``` **Error cause** Фича, которую лично я ждал давно - возможно указать источник ошибки. Иногда в коде приходится перехватывать ошибки, обрабатывать их и кидать другие ошибки. Из-за этого изначальный стактрейс теряется. Эта фича позволяет нам явно указать, что мы кидаем ошибку, источник которой - другая ошибка ``` try { someCode() } catch (err) { const newError = new Error('Новая ошибка', { cause: err }) newError.cause === err // true throw newError; } ``` Раньше, в общем-то, тоже никто не мешал заполнять поле `cause` и были разные подобрые решения или паттерны. Но они были разобщены и поэтому были несовместимы друг с другом. Также, т.к. это были нестандартные решения, то многие инструменты из коробки их не поддерживали (например, вывод ошибки в консоли браузера, обработка ошибки системой sentry) **Top-Level await** await теперь официально можно использовать на верхнем уровне модуля. ``` const result = await someAsyncFunction(); export { result } ``` **Class field declarations** ``` class SampleClass { publicID = 42; // public field static staticPublicField = -1; static #staticPrivateField = 'private'; #privateMethod() {} static { console.log('выполняется при создании инстанса класса' } } ``` **ergonomic brand checks for private fields** Возможность проверять наличие приватных свойств инстанса класса. Когда предлагали ввести приватные методы в ES, то была большая дискуссия на счет того, как правильно проверять существование приватного поля. Ведь вне кода этого класса не должно быть информации о том, есть поле или нет поля. В итоге в ES2022 можно проверять наличие приватных свойств через static методы ``` class C { #prop; static isC(obj) { return #prop in obj } } ```

Кто верстал письма, тот в цирке не смеется. Верстка писем - достаточно непрочто занятие. Мало толо, что там в целом достаточно большие ограничения, так еще и разные почтовые клиенты ведут себя по разному. Какие-то переписывают все ваши стили, какие-то вырезают шрифты, другие автоматически применяют темную тему и меняют все ваши цвета. А кроме этих приколов хочется еще уметь в локальное тестирование, DRY. В статье автор рассказывает, как он делает email-рассылки и решает эти проблемы. 90% проблем, конечно, решает mjml. Mjml - это библиотека, которая адаптирует react-подход к верстке писем. Он позволяет выделять и переиспользовать компоненты, а также забирает на себя сложность низкоуровневой верстки писем (таблички через таблички). Из интересного в статье, кроме mjml автор использует разные примочки вокруг. Например, сами письма он пишет в MDX, а для отправки через системы доставки писем рендерит на next. Это позволяет ему реализовать веб-версию письма за ноль усилий. В общем, если у вас есть задача верстки писем и вы хотите использовать хорошие подходы из разработки (DRY, хранение в коде, возможно даже автотесты) - рекомендую взглянуть на подходы, упомянутые в статье

Вышел Fresh 1.0 - фреймворк для приложений на Deno. Под капотом используется Preact. Даже есть файловый роутинг. Из интересных осоьенностей: - только тайпскрипт - нет этапа сборки - 0КБ js в браузер по умолчанию Фреймворк использует Islands Architecture. Это паттерн, когда мы считаем, что почти все на сайте статично, а значит может рендерится на сервере, кроме островов (islands) интерактивности. По умолчанию все рендерится на сервере и только острова поставляются на клиент.

Статья от ЛАНИТ, про то, как они пришли к частым релизам при разработке всяких гос-систем. Это статья хорошая по двум причинам Во первых, очень хорошо раскрывается, почему в целом в индустрии пришли к бест-практисам вида малых и частых релизов, автоматического тестирования, devops-культуры Во вторых, автор рассказывает, как они эти практики применили при разработке гос-систем. Для меня то, что разработка гос-системы применила бест-практисы для разработки, а многие коммерческие команды не могут - достаточно интересное явление. Очень кратко про посыл статьи: - Чем больше задача, тем сложнее ее делать, сложнее тестировать. А стоимость разработки возрастает нелинейно - Поэтому нужно уметь разрабатывать и доставлять функционал часто и маленькими кусками. Маленькие задачи проще делать, быстрее тестировать, при релизе маленькой задачи легче найти причину проблемы, в случае ее возникновния - Чтобы научиться делать маленькие частые релизы надо научиться работать определенным образом - Делить бизнесовые задачи на мелкие (в статье - пара дней разработки, но при этом задача понятна заказчику) - Разрабатывать через фиче-флаги. Фиче-флаги помогают одновременно часто релизить приложение, но при этом не доставлять неготовые фичи до пользователей. - Писать авто-тесты. Авто-тесты необходимо постоянно писать и постоянно запускать. Авто-тесты отлавливают регрессы, а если ни один авто-тест не упал - это может служить сигналов к релизу. - Автоматизировать инфраструктуру. Необходимо, чтобы каждый член команды разработки мог сам вносить необходимые изменения в инфраструктуру. Но чтобы это делалось просто и надежно, должна быть сделана автоматизация для изменений инфраструктуры.

Просто великолепная статья про разработку в целом, написанная в шутливой манере. По-началу может показаться, что это какое-то несерьезное чтиво, но на самом деле очень хорошо написано про основные принципы хорошей разработки. В целом, ИМХО, похоже на "Идеальный программист" Роба Мартина, но короче и веселее. Часть тезисов в тексте спорная, но в большинстве своем они весьма хороши. Будь как груг!

Статья, сравнивающая использование Map и {} для хранения данных. В целом все сводится к следующему: - Map имеет более удобное и богатое API. Например, в Map можно использовать как ключи что-угодно и удаление всех ключей делается просто через вызов метода clear. Также для некоторых операций для объектов нужно писать дополнительный код, чтобы они отрабатывали корректно. Например, необходимо сделать несколько приседаний, чтобы проверить, действительно ключа нет в объекте, или он есть, но там undefined - Для большинства кейсов Map работает быстрее, чем объект - Для объектов, у которых ключи - небольшие целые числа, работа с объектами - эффективнее в разрезе скорости и потребления памяти. Последний пункт оказался неожиданным. В статье можно увидеть сравнение, где сравнивается скорость вставки и итерации по объектам\Map, у которых 100 ключей и эти ключи - случайные целые числа от 0 до 1000. И в этом сравнении обьекты значительно выигрывают. Но если поменять ключи на случайные целые числа от 0 до 1200, то Map становится в разы быстрее. Для разных значений количества полей в объекте будет разная "точка слома производительности" объекта. В целом конечно есть вопросы к методике оценки производительности, также стоит учитывать, что скорость работы кода зависит от реализации в движках, а движки а) могут реализовать по-разному и иметь свои нюансы б) разработчики движков постоянно оптимизируют разные части движка. Но в статье также указаны преимущества Map перед объектами с точки зрения Developer Experience. Имейте их в виду, при выборе между Map и объектом.

Дмитрий Карловский, он же nin-jin, он же автор фреймворка $mol, выложил на хабре краткий обзор свой последней статьи про реактивность. На хабре она получилась очень обрезанная и поэтому неинтересная, но в оригинале статья весьма хороша. Дмитрий рассказывает, как построить супер крутую систему реактивности, которая, как водится в статьях Дмитрия, уделывает всех :) В целом статья очень хороша по нескольким причинам: - Настоящий хардкор. Таких хардкорных материалов мало - Дмитрий показывает, как построить супер-реактивность по шагам, начиная с самых простых примитивов, а затем композируя их в во все более сложные - Материал очень насыщен. Настолько, что некоторые части необходимо перечатывать. Но при этом - все понятно. Рекомендую к прочтению, если вас заинтересовало мое краткое описание статьи

Moon - еще один тулинг для организации monorepo для фронтенд-проектов.