Writable Streams in Node.js: A Practical Guide
В NodeJS есть классная абстракция - stream. Она позволяет удобно работать с потоками и делать приложения, которые лучше работают под высокой нагрузкой. В данной статье разбирается, как создать свой кастомный Writable Stream, т.е. поток в который вы можете писать и интегрировать его во все потоковые-АПИ
К сожалению, имплементацию кода потока записи на S3 в статье не показывают, но показывают какое API верхнеуровнево необходимо поддержать, чтобы заиметь все преимущества стримов.
https://pavel-romanov.com/writable-streams-in-nodejs-a-practical-guide
#development #javascript #nodejs #stream
В NodeJS есть классная абстракция - stream. Она позволяет удобно работать с потоками и делать приложения, которые лучше работают под высокой нагрузкой. В данной статье разбирается, как создать свой кастомный Writable Stream, т.е. поток в который вы можете писать и интегрировать его во все потоковые-АПИ
К сожалению, имплементацию кода потока записи на S3 в статье не показывают, но показывают какое API верхнеуровнево необходимо поддержать, чтобы заиметь все преимущества стримов.
https://pavel-romanov.com/writable-streams-in-nodejs-a-practical-guide
#development #javascript #nodejs #stream
Pavel Romanov
Node.js Writable Streams: A Practical Guide
Learn to confidently use writable streams in Node.js, explore data flows, and understand error handling with this comprehensive guide
👍2
Я в небольшом отпуске, поэтому с постами на этой неделе туго. Думал, что прочту все дайджесты и наберу ссылок, но между прогулками я полносью поглащен игрой Eden Crafters. Про нее и расскажу. Не сильно вяжется с тематикой канала, поэтому #offtop
Eden Crafters - это игра, в которой вас высаживают на безжизненной планете и которую нужно терраформирмировать, т.е. сделать пригодной к жизни. Делать это надо при помощи создания производственных цепочек: добыть руду, переплавить, получить детали А Б В, из деталей А Б сделать деталь Г, из деталей В и Г получить деталь Д. Необходимо также добывать электричество и воду. И из всего этого строить разные механизмы, которые:
- Меняют температуру
- Поглощают радиацию
- Озеленяют местность
- Меняют состав атмосферы
- Отчищают озера
Игра сыровата (и, если правильно помню, в альфа доступе в стиме), но играть можно (хотя некоторые вещи на стимдеке делать не очень удобно). По механике это лайт версия satisfactory (в которую я еще не играл, но наслышан).
Но я хотел рассказать не о самой игре (хотя могу рекомнедовать в нее поиграть), а о том как я вчера в игре реализовывал enterprise service bus pattern.
ESB - если очень сильно утрировать, это когда у вас есть сервисы, но они общаются не напрямую, а через какую-то шину событий. Например, в реальности это реализуется с помощью RabbitMQ и Kafka - одни сервисы отсылают туда события, другие эти события считывают. В JS-мире близко по духу находится Event Bus pattern - это когда у нас есть виджеты\модули, но они общаются через шину событий (которую в браузере можно реализовать через DOM-API - через postMessage или createEvent).
Как я пришел к этому паттерну в игре. Я уже говорил, что в игре необходимо создавать цепочки производства. Например:
- Есть бур, который извлекает 240 золотой руды в минуту
- Есть кузница, которая может превращать 60 руды в 30 слитков в минуту
- Это значит, что оптимально будет разместить 4 кузницы
- Для этого надо поставить разветвители конвейеров. Бур => разветвитель 1 в 3 (из 1 конвеера получается 3) => Кузница, Кузница, разветвитель 1 в 3 (Кузница, Кузница) => 2 соединителя 3 в 1 => на выходе получаем единый конвеер с 120 золотых слитков в минуту
- Дальше по аналогии делаем медные слитки, из них медные пластины (тоже может понадобится не 1 сборщик и потребуются разветвители), из пластин катушку с медной нитью
- Из нити + слитков получаем что-то еще
И таких цепочек - МНОГО. И они открываются по мере развития в игре.
Как итог - моя начальная база превратилась в спагетти из конвейеров (по аналогии со спагетти кодом). Благо игра закрывает глаза на пересечения конвейеров, иначе бы я вообще не смог все необходимое расположить рядом друг с другом. На текущий момент я не могу понять что там и где производится т.к. запомнить все эти хаотичные пути перетекания ресурсов очень сложно - там полный хаос
Вторая база была уже чуть лучше - я заранее поставил все производственные здания по-дальше друг от друга, чтобы было больше пространства для масштабирования и расстановки конвейров. Третья база была построена по такому же принципу.
Вышло чуть лучше, но все равно с какого-то момента начиналось спагетти из конвейеров.
И тут у меня открылась железная дорога. ЖД в игре устроена так, что есть:
- Дорога
- Вокзалы - там можно погрузить что-то одно в какой-то конкретный грузовой вагон, а еще можно выгрузить какой-то конкретный грузовой вагон. На примере: на вокзале можно сгружать золотые слитки в вагон №4 и забирать груз из вагона №3 (куда мы можем загружать на другом вокзале медную нить)
- Собственно поезд, который везет вагоны
- Вагоны
Я сначала не понимал зачем это вообще нужно, когда есть конвейеры. Но потом я понял, что можно реализовать ESB:
- Строим круговую железную дорогу вокруг огромной производственной площадки
- Когда мы хотим что-то сделать доступным на нашей ЖД (шине), необходимо поставить вокзал, поставить рядом с ним производство нужного ресурса, добавить к поезду вагон и сгружать в него поставляемый ресурс
- Когда мы хотим что-то получить из ЖД, необходимо поставить вокзал и сгружать необходимое
Eden Crafters - это игра, в которой вас высаживают на безжизненной планете и которую нужно терраформирмировать, т.е. сделать пригодной к жизни. Делать это надо при помощи создания производственных цепочек: добыть руду, переплавить, получить детали А Б В, из деталей А Б сделать деталь Г, из деталей В и Г получить деталь Д. Необходимо также добывать электричество и воду. И из всего этого строить разные механизмы, которые:
- Меняют температуру
- Поглощают радиацию
- Озеленяют местность
- Меняют состав атмосферы
- Отчищают озера
Игра сыровата (и, если правильно помню, в альфа доступе в стиме), но играть можно (хотя некоторые вещи на стимдеке делать не очень удобно). По механике это лайт версия satisfactory (в которую я еще не играл, но наслышан).
Но я хотел рассказать не о самой игре (хотя могу рекомнедовать в нее поиграть), а о том как я вчера в игре реализовывал enterprise service bus pattern.
ESB - если очень сильно утрировать, это когда у вас есть сервисы, но они общаются не напрямую, а через какую-то шину событий. Например, в реальности это реализуется с помощью RabbitMQ и Kafka - одни сервисы отсылают туда события, другие эти события считывают. В JS-мире близко по духу находится Event Bus pattern - это когда у нас есть виджеты\модули, но они общаются через шину событий (которую в браузере можно реализовать через DOM-API - через postMessage или createEvent).
Как я пришел к этому паттерну в игре. Я уже говорил, что в игре необходимо создавать цепочки производства. Например:
- Есть бур, который извлекает 240 золотой руды в минуту
- Есть кузница, которая может превращать 60 руды в 30 слитков в минуту
- Это значит, что оптимально будет разместить 4 кузницы
- Для этого надо поставить разветвители конвейеров. Бур => разветвитель 1 в 3 (из 1 конвеера получается 3) => Кузница, Кузница, разветвитель 1 в 3 (Кузница, Кузница) => 2 соединителя 3 в 1 => на выходе получаем единый конвеер с 120 золотых слитков в минуту
- Дальше по аналогии делаем медные слитки, из них медные пластины (тоже может понадобится не 1 сборщик и потребуются разветвители), из пластин катушку с медной нитью
- Из нити + слитков получаем что-то еще
И таких цепочек - МНОГО. И они открываются по мере развития в игре.
Как итог - моя начальная база превратилась в спагетти из конвейеров (по аналогии со спагетти кодом). Благо игра закрывает глаза на пересечения конвейеров, иначе бы я вообще не смог все необходимое расположить рядом друг с другом. На текущий момент я не могу понять что там и где производится т.к. запомнить все эти хаотичные пути перетекания ресурсов очень сложно - там полный хаос
Вторая база была уже чуть лучше - я заранее поставил все производственные здания по-дальше друг от друга, чтобы было больше пространства для масштабирования и расстановки конвейров. Третья база была построена по такому же принципу.
Вышло чуть лучше, но все равно с какого-то момента начиналось спагетти из конвейеров.
И тут у меня открылась железная дорога. ЖД в игре устроена так, что есть:
- Дорога
- Вокзалы - там можно погрузить что-то одно в какой-то конкретный грузовой вагон, а еще можно выгрузить какой-то конкретный грузовой вагон. На примере: на вокзале можно сгружать золотые слитки в вагон №4 и забирать груз из вагона №3 (куда мы можем загружать на другом вокзале медную нить)
- Собственно поезд, который везет вагоны
- Вагоны
Я сначала не понимал зачем это вообще нужно, когда есть конвейеры. Но потом я понял, что можно реализовать ESB:
- Строим круговую железную дорогу вокруг огромной производственной площадки
- Когда мы хотим что-то сделать доступным на нашей ЖД (шине), необходимо поставить вокзал, поставить рядом с ним производство нужного ресурса, добавить к поезду вагон и сгружать в него поставляемый ресурс
- Когда мы хотим что-то получить из ЖД, необходимо поставить вокзал и сгружать необходимое
👍7🔥5👎1
Это позволяет масштабировать производство и избегать спагетти конвейеров. В примере с медной нитью и золотым слитком:
- Создаем бур на золоте, перепраплавляем в слитки, строим вокзал, сгружаем туда слитки
- Создаем бур на меди, переплавляем в слитки, строим вокзал, сгружаем туда слитки
- Создаем производство медных пластин, строим вокзал, получаем оттуда медные слитки, загружаем туда медные пластины
- Создаем производство медной нити, строим вокзал, получаем оттуда медные пластины, сгружаем туда медную нить
- Создаем целевую деталь, строим 2 вокзала - получаем золотые слитки и медную нить, производим целевую деталь, выгружаем на 1 из вокзалов
В итоге, по кругу катается поезд и все модули сборки чего-то используют поезд для "публикации" ресурсов и для получения ресурсов.
Я вчера потратил на это около 3-4 часов, но в конце был доволен просто как слон :) Получил и гибкое производство и научился еще связывать несколько ЖД путей (в аналогии с ESB - научился переопубликовывать сообщение из одного инстанса кафки в другой) - это понадобилось для доставки отдаленных ресурсов на основной производственный сектор.
Вот такая небольшая история про то, как я нашел применение архитектурному паттерну из разработки ПО в игре про производство (хотя могу предположить что в реальном мире есть что-то подобное на реальных производствах).
В треде запостю скрины начальной базы (где спагетти конвейры), второй базы (где уже получше) и железной дороги. Скрины со стимдека, поэтому на нормальных экранах они будут выглядеть немного "шакальными"
#note #offtop #edenCrafters
- Создаем бур на золоте, перепраплавляем в слитки, строим вокзал, сгружаем туда слитки
- Создаем бур на меди, переплавляем в слитки, строим вокзал, сгружаем туда слитки
- Создаем производство медных пластин, строим вокзал, получаем оттуда медные слитки, загружаем туда медные пластины
- Создаем производство медной нити, строим вокзал, получаем оттуда медные пластины, сгружаем туда медную нить
- Создаем целевую деталь, строим 2 вокзала - получаем золотые слитки и медную нить, производим целевую деталь, выгружаем на 1 из вокзалов
В итоге, по кругу катается поезд и все модули сборки чего-то используют поезд для "публикации" ресурсов и для получения ресурсов.
Я вчера потратил на это около 3-4 часов, но в конце был доволен просто как слон :) Получил и гибкое производство и научился еще связывать несколько ЖД путей (в аналогии с ESB - научился переопубликовывать сообщение из одного инстанса кафки в другой) - это понадобилось для доставки отдаленных ресурсов на основной производственный сектор.
Вот такая небольшая история про то, как я нашел применение архитектурному паттерну из разработки ПО в игре про производство (хотя могу предположить что в реальном мире есть что-то подобное на реальных производствах).
В треде запостю скрины начальной базы (где спагетти конвейры), второй базы (где уже получше) и железной дороги. Скрины со стимдека, поэтому на нормальных экранах они будут выглядеть немного "шакальными"
#note #offtop #edenCrafters
👍6🔥4❤3👎1
Всем привет! Со следующей недели возобновляется постинг интересных ссылок. А пока еще немного #offtop :)
Давайте расскажу, как проходит отбор в спикеры на конференцию
Обычно люди предполагают, что для того, чтобы податься с докладом на конференцию нужны:
- Идея
- Тезисы
- Флоу доклада
- Слайды
- Возможно запись готового выступления внутри компании
Иметь все это - крайне полезно и значительно повышает шансы пройти отбор, но по-факту необходимы только 2 вещи:
- Идея доклада
- О чем конкретно вы можете рассказать
Как правило, у многих есть о чем рассказать, но т.к. они думают, что податься на конференцию сложно, то не подаются.
Например, если я захочу податься на конференцию с докладом про скриншот-тестирование, то для заявки будет достаточно:
- Идея: скриншот-тестирование позволяет легко покрывать авто-тестами все новые UI фичи, но есть грабли, на которые лучше не наступать
- О чем могу рассказать: как сравнивать скриншоты без боли, как менеджить загрузку ассетов и шрифтов, как работать с анимациями, как "мокать" стейт и почему надо научиться это делать, какие готовые инструменты есть, как их применять и почему у нас выбран именно такой инструмент, практический опыт
Никаких слайдов, флоу, тезисов - просто список идей и моего опыта и знаний, которые я могу тиражировать.
Когда я посылаю заявки на выступление, я обычно в свободном режиме в течение пары вечером думаю, о чем я вообще могу рассказать, а затем формирую вот такие простые заявки (обычно 2-4 штуки на конференцию)
Далее идет встреча с программным комитетом, где ПК расспросит про идею, ваш опыт и даст рекомендации (например, было бы интересно послушать не просто про скриншот-тестирование, но скриншот+ui-тестирование). Ребята из программного комитета реально помогают изменить основу доклада так, чтобы и слушателям было интереснее, и ваш доклад был лучше
Далее программный комитет либо принимает доклад, либо отклоняет
Если доклад принимается, то:
- Назначается стартовый синк, где обсуждается, какой флоу может быть у доклада и что стоит рассказать
- Назначаются регулярные прогоны, на которых программный комитет дает обратную связь по контенту: что надо раскрыть, что слишком сильно раскрыто и надо меньше, что следует поменять, что следует еще происследовать
- На первых прогонах не обязательно должны быть готовы слайды. Вполне можно позволить себе шарить экран с каким-нибудь гугл доком
- С каждым следующим прогоном доклад все больше должен быть готов на итоговый. Т.е. эволюция примерно такая: идея => тезисы + флоу => заглушка контента => слайды-заглушки => рабочие слайды (контент есть, но оформление на уровне джуна) => pre production ready слайды
Программный комитет состоит из крутых инженеров и опытных спикер-коучей, поэтому они дают крутую обратную связь по флоу. Бывало и так, что мне приходилось разворачивать флоу доклада несколько раз во время подготовки (т.к. например углублялся в дебри, которые интересны только мне, но не широкому кругу людей), поэтому черновые варианты долкада должны быть easy to edit & refactor
Ну а дальше приезд на конференцию, выступление, ответы на провокационные вопросы. Программный комитет всегда поможет в том числе и при выступлении на сцене.
Вот как-то так проходит путь от идеи к докладу. Готовить доклад, конечно, не просто, но намного проще чем кажется.
Я верю, что в канале есть много подписчиков, которые имеют крутой опыт и могут рассказать о чем-то интересном. Не бойтесь подаваться на конференции. Большая вероятность того, что ваша тема будет актуальной, а программный комитет поможет вам довести идею до крутого доклада.
Если вы вдохновились этим постом и решили попробовать податься на конференцию, то могу предложить податься, например, на CodeFest (успейте отправить заявку до воскресенья). Ребята из программного комитет по потоку Frontend - очень хорошо помогают готовить доклады, проверено лично несколько раз :)
Конференция проходит в Новосибирске и очень ламповая по своей атмосфере. Приезжайте как слушатель или как спикер - развиртуализируемся!
#codefest #note
Давайте расскажу, как проходит отбор в спикеры на конференцию
Обычно люди предполагают, что для того, чтобы податься с докладом на конференцию нужны:
- Идея
- Тезисы
- Флоу доклада
- Слайды
- Возможно запись готового выступления внутри компании
Иметь все это - крайне полезно и значительно повышает шансы пройти отбор, но по-факту необходимы только 2 вещи:
- Идея доклада
- О чем конкретно вы можете рассказать
Как правило, у многих есть о чем рассказать, но т.к. они думают, что податься на конференцию сложно, то не подаются.
Например, если я захочу податься на конференцию с докладом про скриншот-тестирование, то для заявки будет достаточно:
- Идея: скриншот-тестирование позволяет легко покрывать авто-тестами все новые UI фичи, но есть грабли, на которые лучше не наступать
- О чем могу рассказать: как сравнивать скриншоты без боли, как менеджить загрузку ассетов и шрифтов, как работать с анимациями, как "мокать" стейт и почему надо научиться это делать, какие готовые инструменты есть, как их применять и почему у нас выбран именно такой инструмент, практический опыт
Никаких слайдов, флоу, тезисов - просто список идей и моего опыта и знаний, которые я могу тиражировать.
Когда я посылаю заявки на выступление, я обычно в свободном режиме в течение пары вечером думаю, о чем я вообще могу рассказать, а затем формирую вот такие простые заявки (обычно 2-4 штуки на конференцию)
Далее идет встреча с программным комитетом, где ПК расспросит про идею, ваш опыт и даст рекомендации (например, было бы интересно послушать не просто про скриншот-тестирование, но скриншот+ui-тестирование). Ребята из программного комитета реально помогают изменить основу доклада так, чтобы и слушателям было интереснее, и ваш доклад был лучше
Далее программный комитет либо принимает доклад, либо отклоняет
Если доклад принимается, то:
- Назначается стартовый синк, где обсуждается, какой флоу может быть у доклада и что стоит рассказать
- Назначаются регулярные прогоны, на которых программный комитет дает обратную связь по контенту: что надо раскрыть, что слишком сильно раскрыто и надо меньше, что следует поменять, что следует еще происследовать
- На первых прогонах не обязательно должны быть готовы слайды. Вполне можно позволить себе шарить экран с каким-нибудь гугл доком
- С каждым следующим прогоном доклад все больше должен быть готов на итоговый. Т.е. эволюция примерно такая: идея => тезисы + флоу => заглушка контента => слайды-заглушки => рабочие слайды (контент есть, но оформление на уровне джуна) => pre production ready слайды
Программный комитет состоит из крутых инженеров и опытных спикер-коучей, поэтому они дают крутую обратную связь по флоу. Бывало и так, что мне приходилось разворачивать флоу доклада несколько раз во время подготовки (т.к. например углублялся в дебри, которые интересны только мне, но не широкому кругу людей), поэтому черновые варианты долкада должны быть easy to edit & refactor
Ну а дальше приезд на конференцию, выступление, ответы на провокационные вопросы. Программный комитет всегда поможет в том числе и при выступлении на сцене.
Вот как-то так проходит путь от идеи к докладу. Готовить доклад, конечно, не просто, но намного проще чем кажется.
Я верю, что в канале есть много подписчиков, которые имеют крутой опыт и могут рассказать о чем-то интересном. Не бойтесь подаваться на конференции. Большая вероятность того, что ваша тема будет актуальной, а программный комитет поможет вам довести идею до крутого доклада.
Если вы вдохновились этим постом и решили попробовать податься на конференцию, то могу предложить податься, например, на CodeFest (успейте отправить заявку до воскресенья). Ребята из программного комитет по потоку Frontend - очень хорошо помогают готовить доклады, проверено лично несколько раз :)
Конференция проходит в Новосибирске и очень ламповая по своей атмосфере. Приезжайте как слушатель или как спикер - развиртуализируемся!
#codefest #note
👍9❤3🔥3👎1
A 10x Faster TypeScript
Команда TypeScript решила переписать компилятор на go. Кажется уже обсудили везде где только можно, поэтому я ничего особо нового не добавлю. Если коротко: компилятор typescript не очень быстрый и команде приходится заниматься хитрыми оптимизациями чтобы ускорить его. Логичный шаг - переписать компилятор на другой язык. Сделали прототип на go и он оказался в 10 раз быстрее на крупных проектах (типа vscode)
Уже вышли различные посты и интервью, где объясняется, почему был выбран именно Go (если коротко: на нем легко писать компилятор для языка типа TypeScript, а еще он быстрый и кросс-платформенный). Подробнее расписал artalar на хабре
TypeScript 6 будет еще на TS. Typescript 7 уже будет полностью на Go.
https://devblogs.microsoft.com/typescript/typescript-native-port/
#development #typescript #golang #performance
Команда TypeScript решила переписать компилятор на go. Кажется уже обсудили везде где только можно, поэтому я ничего особо нового не добавлю. Если коротко: компилятор typescript не очень быстрый и команде приходится заниматься хитрыми оптимизациями чтобы ускорить его. Логичный шаг - переписать компилятор на другой язык. Сделали прототип на go и он оказался в 10 раз быстрее на крупных проектах (типа vscode)
Уже вышли различные посты и интервью, где объясняется, почему был выбран именно Go (если коротко: на нем легко писать компилятор для языка типа TypeScript, а еще он быстрый и кросс-платформенный). Подробнее расписал artalar на хабре
TypeScript 6 будет еще на TS. Typescript 7 уже будет полностью на Go.
https://devblogs.microsoft.com/typescript/typescript-native-port/
#development #typescript #golang #performance
Microsoft News
A 10x Faster TypeScript
Embarking on a native port of the existing TypeScript compiler and toolset to achieve a 10x performance speed-up.
🔥11😢4👍3
My LLM codegen workflow atm
Крутая статья, где автор рассказывает, как он используем LLM для разработки небольших приложений и для правок в существующих приложениях
Если коротко, то весь процесс разработки фичи проходит с помощью LLM: генерация спеки, плана, кода, тестов, доки. Автор также использует инструменты, которые сильно облегчают работу с LLM
Если подробнее
Сначала необходимо побрейнштормить вместе с LLM идею
Когда брейншторм окончен, необходимо сгруппировать это все в требования
Вывод сохраняется в файл spec.md
Затем составляется план разработки, из которого будет собран чеклист, которому могут следовать ИИ-агенты, а также который будет загружен в ИИ-агента, который пишет код (github copilot workspace, cursor etc)
Затем, собственно, запускается ИИ-агент. Автор рассматривает разные варианты запуска (где-то он сам переносит вывод ИИ в IDE, где-то агент сам пишет код и запускает тесты).
Выглядит круто. Рекомендую посмотреть самостоятельно т.к. часть вещей я опустил.
https://harper.blog/2025/02/16/my-llm-codegen-workflow-atm/
#development #ai #llm
Крутая статья, где автор рассказывает, как он используем LLM для разработки небольших приложений и для правок в существующих приложениях
Если коротко, то весь процесс разработки фичи проходит с помощью LLM: генерация спеки, плана, кода, тестов, доки. Автор также использует инструменты, которые сильно облегчают работу с LLM
Если подробнее
Сначала необходимо побрейнштормить вместе с LLM идею
Ask me one question at a time so we can develop a thorough, step-by-step spec for this idea. Each question should build on my previous answers, and our end goal is to have a detailed specification I can hand off to a developer. Let’s do this iteratively and dig into every relevant detail. Remember, only one question at a time.
Here’s the idea: <IDEA>
Когда брейншторм окончен, необходимо сгруппировать это все в требования
Now that we’ve wrapped up the brainstorming process, can you compile our findings into a comprehensive, developer-ready specification? Include all relevant requirements, architecture choices, data handling details, error handling strategies, and a testing plan so a developer can immediately begin implementation.
Вывод сохраняется в файл spec.md
Затем составляется план разработки, из которого будет собран чеклист, которому могут следовать ИИ-агенты, а также который будет загружен в ИИ-агента, который пишет код (github copilot workspace, cursor etc)
Draft a detailed, step-by-step blueprint for building this project. Then, once you have a solid plan, break it down into small, iterative chunks that build on each other. Look at these chunks and then go another round to break it into small steps. review the results and make sure that the steps are small enough to be implemented safely, but big enough to move the project forward. Iterate until you feel that the steps are right sized for this project. From here you should have the foundation to provide a series of prompts for a code-generation LLM that will implement each step. Prioritize best practices, and incremental progress, ensuring no big jumps in complexity at any stage. Make sure that each prompt builds on the previous prompts, and ends with wiring things together. There should be no hanging or orphaned code that isn't integrated into a previous step. Make sure and separate each prompt section. Use markdown. Each prompt should be tagged as text using code tags. The goal is to output prompts, but context, etc is important as well.
<SPEC>
Затем, собственно, запускается ИИ-агент. Автор рассматривает разные варианты запуска (где-то он сам переносит вывод ИИ в IDE, где-то агент сам пишет код и запускает тесты).
Выглядит круто. Рекомендую посмотреть самостоятельно т.к. часть вещей я опустил.
https://harper.blog/2025/02/16/my-llm-codegen-workflow-atm/
#development #ai #llm
harper.blog
My LLM codegen workflow atm
A detailed walkthrough of my current workflow for using LLms to build software, from brainstorming through planning and execution.
👍18😁1
Lynx: Unlock Native for More
Lynx - набор инструментов для создания нативных приложений на основе идей веб-технологий. Это что-то близкое к React Native, но не React Native (я, честно сказать, не уверен что до конца вообще понял разницу между Lynx и RN)
Этот инструментарий, в частности, используется в TikTok.
Идея инструмента, в целом, обычная: берем лучшие части веба (например jsx, css), делаем ядро инструмента, которое обеспечит быстрый запуск и плавную работу (например, в Lynx, отдельный тред для UI, а вся логика в бекграунде), делаем свой тулинг сборки (в частности здесь тулинг поверх rspack), делаем кросс-платформенность (можно скомпилировать в web).
Выглядит интересно. Использование инструмента в TikTok дает некоторое доверие.
https://lynxjs.org/blog/lynx-unlock-native-for-more
#development #javascript #react #native #tiktok
Lynx - набор инструментов для создания нативных приложений на основе идей веб-технологий. Это что-то близкое к React Native, но не React Native (я, честно сказать, не уверен что до конца вообще понял разницу между Lynx и RN)
Этот инструментарий, в частности, используется в TikTok.
Идея инструмента, в целом, обычная: берем лучшие части веба (например jsx, css), делаем ядро инструмента, которое обеспечит быстрый запуск и плавную работу (например, в Lynx, отдельный тред для UI, а вся логика в бекграунде), делаем свой тулинг сборки (в частности здесь тулинг поверх rspack), делаем кросс-платформенность (можно скомпилировать в web).
Выглядит интересно. Использование инструмента в TikTok дает некоторое доверие.
https://lynxjs.org/blog/lynx-unlock-native-for-more
#development #javascript #react #native #tiktok
lynxjs.org
Empower the web community and invite more to build cross-platform apps
👍4
Javascript Game Tutorials
Занятный сайт, на котором собраны гайды, как делать игры на JS (пока 2 гайда на 1 игру). Сами гайды выглядят просто топово - все объясняет по шагам с интерактивом. Есть текст, есть codepen, есть youtube
Если вам не интересна сама тема создания игр - посмотрите на сами гайды - хороший пример того, как может быть устроено обучение
https://javascriptgametutorials.com/
#development #javascript #game #tutorial
Занятный сайт, на котором собраны гайды, как делать игры на JS (пока 2 гайда на 1 игру). Сами гайды выглядят просто топово - все объясняет по шагам с интерактивом. Есть текст, есть codepen, есть youtube
Если вам не интересна сама тема создания игр - посмотрите на сами гайды - хороший пример того, как может быть устроено обучение
https://javascriptgametutorials.com/
#development #javascript #game #tutorial
JavaScript Game Tutorials
Learn how to build games with JavaScript
🔥19🤩3❤1
End of Life
У многих продуктов есть End of life - конец поддержки мейнтейнером. Когда у продукта закончилась поддержка - нет никаких гарантий, что там будут чинить баги или фиксить дыры безопасности. Именно поэтому важно всегда обновлять те части проекта, проблемы в которых могут нести риски
Сайт собирает end of life кучи продуктов - начиная от опереционных систем и заканчивая библиотеками (jquery, react).
Рекомендую сохранить в закладки
https://endoflife.date/
#development #endOfLife
У многих продуктов есть End of life - конец поддержки мейнтейнером. Когда у продукта закончилась поддержка - нет никаких гарантий, что там будут чинить баги или фиксить дыры безопасности. Именно поэтому важно всегда обновлять те части проекта, проблемы в которых могут нести риски
Сайт собирает end of life кучи продуктов - начиная от опереционных систем и заканчивая библиотеками (jquery, react).
Рекомендую сохранить в закладки
https://endoflife.date/
#development #endOfLife
endoflife.date
Home
Check end-of-life, support schedule, and release timelines for more than 380+ products at one place.
❤8👍5
Дайджест за 2025-03-31 - 2025-04-04
A 10x Faster TypeScript
Команда TypeScript решила переписать компилятор на go. Кажется уже обсудили везде где только можно, поэтому я ничего особо нового не добавлю. Если коротко: компилятор typescript не очень быстрый и команде приходится заниматься хитрыми оптимизациями чтобы ускорить его. Логичный шаг - переписать компилятор на другой язык. Сделали прототип на go и он оказался в 10 раз быстрее на крупных проектах (типа vscode)
Уже вышли различные посты и интервью, где объясняется, почему был выбран именно Go (если коротко: на нем легко писать компилятор для языка типа TypeScript, а еще он быстрый и кросс-платформенный). Подробнее расписал artalar на хабре
My LLM codegen workflow atm
Крутая статья, где автор рассказывает, как он используем LLM для разработки небольших приложений и для правок в существующих приложениях
Если коротко, то весь процесс разработки фичи проходит с помощью LLM: генерация спеки, плана, кода, тестов, доки. Автор также использует инструменты, которые сильно облегчают работу с LLM
Lynx: Unlock Native for More
Lynx - набор инструментов для создания нативных приложений на основе идей веб-технологий. Это что-то близкое к React Native, но не React Native (я, честно сказать, не уверен что до конца вообще понял разницу между Lynx и RN)
Этот инструментарий, в частности, используется в TikTok.
Javascript Game Tutorials
Занятный сайт, на котором собраны гайды, как делать игры на JS (пока 2 гайда на 1 игру). Сами гайды выглядят просто топово - все объясняет по шагам с интерактивом. Есть текст, есть codepen, есть youtube
Если вам не интересна сама тема создания игр - посмотрите на сами гайды - хороший пример того, как может быть устроено обучение
End of Life
У многих продуктов есть End of life - конец поддержки мейнтейнером. Когда у продукта закончилась поддержка - нет никаких гарантий, что там будут чинить баги или фиксить дыры безопасности. Именно поэтому важно всегда обновлять те части проекта, проблемы в которых могут нести риски
Сайт собирает end of life кучи продуктов - начиная от опереционных систем и заканчивая библиотеками (jquery, react).
——————————————
Спасибо что читаете, ставите реакции и отмечаетесь в комментариях. Если вы хотите помочь каналу - расскажите о нем своим коллегам или друзьям. Также оставляйте фидбек по формату, материалу и чему-угодно еще 🙂
A 10x Faster TypeScript
Команда TypeScript решила переписать компилятор на go. Кажется уже обсудили везде где только можно, поэтому я ничего особо нового не добавлю. Если коротко: компилятор typescript не очень быстрый и команде приходится заниматься хитрыми оптимизациями чтобы ускорить его. Логичный шаг - переписать компилятор на другой язык. Сделали прототип на go и он оказался в 10 раз быстрее на крупных проектах (типа vscode)
Уже вышли различные посты и интервью, где объясняется, почему был выбран именно Go (если коротко: на нем легко писать компилятор для языка типа TypeScript, а еще он быстрый и кросс-платформенный). Подробнее расписал artalar на хабре
My LLM codegen workflow atm
Крутая статья, где автор рассказывает, как он используем LLM для разработки небольших приложений и для правок в существующих приложениях
Если коротко, то весь процесс разработки фичи проходит с помощью LLM: генерация спеки, плана, кода, тестов, доки. Автор также использует инструменты, которые сильно облегчают работу с LLM
Lynx: Unlock Native for More
Lynx - набор инструментов для создания нативных приложений на основе идей веб-технологий. Это что-то близкое к React Native, но не React Native (я, честно сказать, не уверен что до конца вообще понял разницу между Lynx и RN)
Этот инструментарий, в частности, используется в TikTok.
Javascript Game Tutorials
Занятный сайт, на котором собраны гайды, как делать игры на JS (пока 2 гайда на 1 игру). Сами гайды выглядят просто топово - все объясняет по шагам с интерактивом. Есть текст, есть codepen, есть youtube
Если вам не интересна сама тема создания игр - посмотрите на сами гайды - хороший пример того, как может быть устроено обучение
End of Life
У многих продуктов есть End of life - конец поддержки мейнтейнером. Когда у продукта закончилась поддержка - нет никаких гарантий, что там будут чинить баги или фиксить дыры безопасности. Именно поэтому важно всегда обновлять те части проекта, проблемы в которых могут нести риски
Сайт собирает end of life кучи продуктов - начиная от опереционных систем и заканчивая библиотеками (jquery, react).
——————————————
Спасибо что читаете, ставите реакции и отмечаетесь в комментариях. Если вы хотите помочь каналу - расскажите о нем своим коллегам или друзьям. Также оставляйте фидбек по формату, материалу и чему-угодно еще 🙂
❤14
Node Modules Inspector
Node Modules Inspector - инструмент, позволяющий провести анализ пакета - от чего зависит, какие уязвимости, сколько весит и все такое. Главные отличительные особенности этого проекта: очень приятный UI и запуск прямо в браузере в Web Container (песочница, в которой можно запускать что-то близкое к nodejs)
Выглядит нереально круто: выбираешь пакет, запускается WebContainer, внутри него запускается pnpm и устанавливает пакет и выводит всю стату для анализа
https://node-modules.dev/
#development #javascript #pnpm #performance #webcontainer
Node Modules Inspector - инструмент, позволяющий провести анализ пакета - от чего зависит, какие уязвимости, сколько весит и все такое. Главные отличительные особенности этого проекта: очень приятный UI и запуск прямо в браузере в Web Container (песочница, в которой можно запускать что-то близкое к nodejs)
Выглядит нереально круто: выбираешь пакет, запускается WebContainer, внутри него запускается pnpm и устанавливает пакет и выводит всю стату для анализа
https://node-modules.dev/
#development #javascript #pnpm #performance #webcontainer
node-modules.dev
Node Modules Inspector
Visualize your node_modules, inspect dependencies, and more.
👍18🔥4❤1
Omlet - Uncover React component usage across your dev teams
Еще один инструмент для анализа кода, но на этот раз для дизайн-систем и UI-китов. Омлет собирает аналитику по использованию компонентов в коде: какие компоненты как используются, как быстро отказываются от deprecated компонентов, какие компоненты не из дизайн-системы разработчики часто используют (кандидаты на вынос в дизайн-систему)
Выглядит как инструмент с очень узким юзкейсом - для выделенных команд UI-кита в больших компаниях.
https://omlet.dev/
#development #uikit #react
Еще один инструмент для анализа кода, но на этот раз для дизайн-систем и UI-китов. Омлет собирает аналитику по использованию компонентов в коде: какие компоненты как используются, как быстро отказываются от deprecated компонентов, какие компоненты не из дизайн-системы разработчики часто используют (кандидаты на вынос в дизайн-систему)
Выглядит как инструмент с очень узким юзкейсом - для выделенных команд UI-кита в больших компаниях.
https://omlet.dev/
#development #uikit #react
Omlet
Component analytics and insights for React.
🔥7👍2
Reproducibility vs. Provenance: Trusting the JavaScript Supply Chain
reproduce - инструмент, который проверяет, что пакет, скачиваемый из npm, действительно собран из исходников на github. Т.е. инструмент проверяет пакеты на reproducibility.
Зачем это надо? Это необходимо для гарантии того, что никто никак не патчит код пере публикацией. Это может быть как проблема безопасности (хакеры встроились в пайплайн публикации и воруют крипто-кошельки), так и проблема доверия (авторы пакета обещают что никак не используют ваши данные, а сами отправляют телеметрию).
Provenance - это когда кто-то заявляет, что пакет и правда собран из исходников (например Github). reproducibility - это когда каждый может убедиться в том, что пакет собран из тех же исходников, что есть на github.
Теперь для проверки reproducibility есть reproduce.
https://blog.vlt.sh/blog/reproducibility
#development #npm #security
reproduce - инструмент, который проверяет, что пакет, скачиваемый из npm, действительно собран из исходников на github. Т.е. инструмент проверяет пакеты на reproducibility.
Зачем это надо? Это необходимо для гарантии того, что никто никак не патчит код пере публикацией. Это может быть как проблема безопасности (хакеры встроились в пайплайн публикации и воруют крипто-кошельки), так и проблема доверия (авторы пакета обещают что никак не используют ваши данные, а сами отправляют телеметрию).
Provenance - это когда кто-то заявляет, что пакет и правда собран из исходников (например Github). reproducibility - это когда каждый может убедиться в том, что пакет собран из тех же исходников, что есть на github.
Теперь для проверки reproducibility есть reproduce.
https://blog.vlt.sh/blog/reproducibility
#development #npm #security
vlt /vōlt/ - blog
Reproducibility vs. Provenance: Trusting the JavaScript Supply Chain
We launched a new tool to detect package integrity issues in the JavaScript ecosystem. Learn how `reproduce` is changing the game.
🔥11👍7
Playwright: игра в скриншотные тесты
Отличная статья от Okko про реализацию скриншот-тестов в связке playwright + storybook. Она одновременно верхнеуровневая (т.е. автор не погружается прям в самые детали) и одновременно содержит весь самый сок, необходимый для настройки скриншот-тестов в проекте.
Okko требуется поддерживать интерфейсы для веба и смарт-тв, на которых могут быть разные ОС, поэтому вопрос поддержки UI стоит достаточно остро. Поэтому они и вложились в скриншот-тесты.
В статье рассказывается про:
- Как отключить анимации в дополнение к API playwright
- Как получить список всех историй и пройти по ним в цикле для запуска всех скриншот-тестов
- Как работать с загрузкой изображений, шрифтов и других ресурсов
- Как и зачем запускаться в docker
- Как работать с эталонами
- Как настраивать Playwright
В общем, мастхев ссылка если вы занимаетесь скриншот-тестированием или хотите поставить этот процесс
https://habr.com/ru/companies/okko/articles/890438/
#development #javascript #storybook #testing #screenshotTesting #habr #okko
Отличная статья от Okko про реализацию скриншот-тестов в связке playwright + storybook. Она одновременно верхнеуровневая (т.е. автор не погружается прям в самые детали) и одновременно содержит весь самый сок, необходимый для настройки скриншот-тестов в проекте.
Okko требуется поддерживать интерфейсы для веба и смарт-тв, на которых могут быть разные ОС, поэтому вопрос поддержки UI стоит достаточно остро. Поэтому они и вложились в скриншот-тесты.
В статье рассказывается про:
- Как отключить анимации в дополнение к API playwright
- Как получить список всех историй и пройти по ним в цикле для запуска всех скриншот-тестов
- Как работать с загрузкой изображений, шрифтов и других ресурсов
- Как и зачем запускаться в docker
- Как работать с эталонами
- Как настраивать Playwright
В общем, мастхев ссылка если вы занимаетесь скриншот-тестированием или хотите поставить этот процесс
https://habr.com/ru/companies/okko/articles/890438/
#development #javascript #storybook #testing #screenshotTesting #habr #okko
Хабр
Playwright: игра в скриншотные тесты
Работа с Playwright всегда доставляет мне удовольствие. « Наиграв » уже десятки, если не сотни часов в библиотеке, решая проблемы, копаясь в исходниках или на просторах сети, я практически всегда...
🔥18
Серия бесплатных воркшопов про менеджмент от Стратоплан
Всем привет, с 14 по 18 апреля c 17:00 по 19:00 по МСК будут проходить бесплатные 2х-часовые занятия от Стратоплан по менеджменту. Среди спикеров есть как минимум 2 чувака, которых я рекомендую читать и слушать всем - Виталий Шароватов (слежу за ним уже лет 7) и Дмитрий Болдырев, который недавно выпускал крутую серию постов про образование команд из рабочих групп
Будет 5 занятий, на которых рассмотрят:
– первые шаги: ожидания и задачи после назначения
– найм и как это делать правильно
– как создать команду
– как ставить и контролировать задачи
– лидерство
Если вы - тимлид или хотите расти в этом направлении - рекомендую записаться. Это бесплатновое, плюс спикеры реально хороши.
Бесплатная регистрация здесь
#managment #stratoplan #note
Всем привет, с 14 по 18 апреля c 17:00 по 19:00 по МСК будут проходить бесплатные 2х-часовые занятия от Стратоплан по менеджменту. Среди спикеров есть как минимум 2 чувака, которых я рекомендую читать и слушать всем - Виталий Шароватов (слежу за ним уже лет 7) и Дмитрий Болдырев, который недавно выпускал крутую серию постов про образование команд из рабочих групп
Будет 5 занятий, на которых рассмотрят:
– первые шаги: ожидания и задачи после назначения
– найм и как это делать правильно
– как создать команду
– как ставить и контролировать задачи
– лидерство
Если вы - тимлид или хотите расти в этом направлении - рекомендую записаться. Это бесплатновое, плюс спикеры реально хороши.
Бесплатная регистрация здесь
#managment #stratoplan #note
Школа менеджмента STRATOPLAN
Основы управления
Бесплатный курс от Школы менеджмента «Стратоплан»
👍11🔥9❤4
Дайджест за 2025-04-07 - 2025-04-11
Node Modules Inspector
Node Modules Inspector - инструмент, позволяющий провести анализ пакета - от чего зависит, какие уязвимости, сколько весит и все такое. Главные отличительные особенности этого проекта: очень приятный UI и запуск прямо в браузере в Web Container (песочница, в которой можно запускать что-то близкое к nodejs)
Выглядит нереально круто: выбираешь пакет, запускается WebContainer, внутри него запускается pnpm и устанавливает пакет и выводит всю стату для анализа
Omlet - Uncover React component usage across your dev teams
Еще один инструмент для анализа кода, но на этот раз для дизайн-систем и UI-китов. Омлет собирает аналитику по использованию компонентов в коде: какие компоненты как используются, как быстро отказываются от deprecated компонентов, какие компоненты не из дизайн-системы разработчики часто используют (кандидаты на вынос в дизайн-систему)
Выглядит как инструмент с очень узким юзкейсом - для выделенных команд UI-кита в больших компаниях.
Reproducibility vs. Provenance: Trusting the JavaScript Supply Chain
reproduce - инструмент, который проверяет, что пакет, скачиваемый из npm, действительно собран из исходников на github. Т.е. инструмент проверяет пакеты на reproducibility.
Зачем это надо? Это необходимо для гарантии того, что никто никак не патчит код пере публикацией. Это может быть как проблема безопасности (хакеры встроились в пайплайн публикации и воруют крипто-кошельки), так и проблема доверия (авторы пакета обещают что никак не используют ваши данные, а сами отправляют телеметрию).
Playwright: игра в скриншотные тесты
Отличная статья от Okko про реализацию скриншот-тестов в связке playwright + storybook. Она одновременно верхнеуровневая (т.е. автор не погружается прям в самые детали) и одновременно содержит весь самый сок, необходимый для настройки скриншот-тестов в проекте.
Okko требуется поддерживать интерфейсы для веба и смарт-тв, на которых могут быть разные ОС, поэтому вопрос поддержки UI стоит достаточно остро. Поэтому они и вложились в скриншот-тесты.
Серия бесплатных воркшопов про менеджмент от Стратоплан
Всем привет, с 14 по 18 апреля c 17:00 по 19:00 по МСК будут проходить бесплатные 2х-часовые занятия от Стратоплан по менеджменту. Среди спикеров есть как минимум 2 чувака, которых я рекомендую читать и слушать всем - Виталий Шароватов (слежу за ним уже лет 7) и Дмитрий Болдырев, который недавно выпускал крутую серию постов про образование команд из рабочих групп
——————————————
Спасибо что читаете, ставите реакции и отмечаетесь в комментариях. Если вы хотите помочь каналу - расскажите о нем своим коллегам или друзьям. Также оставляйте фидбек по формату, материалу и чему-угодно еще 🙂
Node Modules Inspector
Node Modules Inspector - инструмент, позволяющий провести анализ пакета - от чего зависит, какие уязвимости, сколько весит и все такое. Главные отличительные особенности этого проекта: очень приятный UI и запуск прямо в браузере в Web Container (песочница, в которой можно запускать что-то близкое к nodejs)
Выглядит нереально круто: выбираешь пакет, запускается WebContainer, внутри него запускается pnpm и устанавливает пакет и выводит всю стату для анализа
Omlet - Uncover React component usage across your dev teams
Еще один инструмент для анализа кода, но на этот раз для дизайн-систем и UI-китов. Омлет собирает аналитику по использованию компонентов в коде: какие компоненты как используются, как быстро отказываются от deprecated компонентов, какие компоненты не из дизайн-системы разработчики часто используют (кандидаты на вынос в дизайн-систему)
Выглядит как инструмент с очень узким юзкейсом - для выделенных команд UI-кита в больших компаниях.
Reproducibility vs. Provenance: Trusting the JavaScript Supply Chain
reproduce - инструмент, который проверяет, что пакет, скачиваемый из npm, действительно собран из исходников на github. Т.е. инструмент проверяет пакеты на reproducibility.
Зачем это надо? Это необходимо для гарантии того, что никто никак не патчит код пере публикацией. Это может быть как проблема безопасности (хакеры встроились в пайплайн публикации и воруют крипто-кошельки), так и проблема доверия (авторы пакета обещают что никак не используют ваши данные, а сами отправляют телеметрию).
Playwright: игра в скриншотные тесты
Отличная статья от Okko про реализацию скриншот-тестов в связке playwright + storybook. Она одновременно верхнеуровневая (т.е. автор не погружается прям в самые детали) и одновременно содержит весь самый сок, необходимый для настройки скриншот-тестов в проекте.
Okko требуется поддерживать интерфейсы для веба и смарт-тв, на которых могут быть разные ОС, поэтому вопрос поддержки UI стоит достаточно остро. Поэтому они и вложились в скриншот-тесты.
Серия бесплатных воркшопов про менеджмент от Стратоплан
Всем привет, с 14 по 18 апреля c 17:00 по 19:00 по МСК будут проходить бесплатные 2х-часовые занятия от Стратоплан по менеджменту. Среди спикеров есть как минимум 2 чувака, которых я рекомендую читать и слушать всем - Виталий Шароватов (слежу за ним уже лет 7) и Дмитрий Болдырев, который недавно выпускал крутую серию постов про образование команд из рабочих групп
——————————————
Спасибо что читаете, ставите реакции и отмечаетесь в комментариях. Если вы хотите помочь каналу - расскажите о нем своим коллегам или друзьям. Также оставляйте фидбек по формату, материалу и чему-угодно еще 🙂
👍8🔥4
How to get deep traces in your Node.js backend with OTel and Deno
Deno в одном из недавних релизов добавили нативную поддержку Open Telemetry - инструментария, которая добавляет возможности для observability вашей системы. Буквально можно смотреть на что конкретно было затрачено время, пока сервер отвечал пользователю.
Данная статья в целом не погружается в глубоко работу Open Telemetry, но подсвечивают, что OT в nodejs сделан через костыли, а для подключения надо написать 2 экрана кода (в свое время сам ужаснулся этой SDK), а в Deno достаточно указать ключ запуска deno
https://deno.com/blog/otel-tracing-in-node-and-deno
#development #javascript #opentelemetry #deno
Deno в одном из недавних релизов добавили нативную поддержку Open Telemetry - инструментария, которая добавляет возможности для observability вашей системы. Буквально можно смотреть на что конкретно было затрачено время, пока сервер отвечал пользователю.
Данная статья в целом не погружается в глубоко работу Open Telemetry, но подсвечивают, что OT в nodejs сделан через костыли, а для подключения надо написать 2 экрана кода (в свое время сам ужаснулся этой SDK), а в Deno достаточно указать ключ запуска deno
https://deno.com/blog/otel-tracing-in-node-and-deno
#development #javascript #opentelemetry #deno
Deno
How to get deep traces in your Node.js backend with OTel and Deno | Deno
Adding meaningful tracing to a Node backend requires additional instrumentation and configuration. Here’s another approach that requires zero additional code.
👍10
Конспект книги Team Topologies, часть №1 - team-first mindset
Основные концепции:
Team-first mindset
Команда - самый эффективный способ организации людей для решения проблем. Поэтому важно перестроить сознание на team-first и уметь работать с командами:
- Когда команда - неделимый юнит для реализации любой работы
- Похвала и порицание всегда идут на команду, а не на отдельных людей
- Цели команды важнее собственных
Модель Такмана говорит о том, как рабочая группа превращается в команду:
- Формирование - создается рабочая группа и начинает работать сообща
- Шторминг - возникают конфликты между людьми. На этом этапе часть людей может покинуть группу или группа может распасться полностью.
- Нормализация - выработка единых подходов
- Перформинг - команда выходит на плато высокой продуктивности
Числа Данбара
Антрополог Данбар проанализировал различные сообщества людей и заметил, что есть 4 "круга" социальных связей:
- Очень близкие отношения с 5-7 людьми
- Приятели, хорошие друзья - 15 человек
- Семья, коллеги - 50 человек
- Стая - 150-200 человек
Это не какая-то математическая модель - это результат наблюдений.
Как это перекладывается на IT и организации:
- Идеальный размер команды - 5-7 человек. Но в крайнем случае - до 15, но тогда высок риск что люди внутри сами поделятся на 2 группы
- 50 человек - уровень подразделения
- 200 человек - уровень отдела
В книге приводится кейс компании, которая обходит фазу шторминга в модели Такмана:
- Рекомендованы команды по 7 человек
- Но команды могут расти вместе с ростом задач или продукта, это нормально
- Когда команда достигает 15 человек - её делят на 2 команды
Т.к. команда из 15 человек - уже сработавшаяся, то когда их поделят на 2 команды, они могут пропустить фазу шторминга.
Когнитивная нагрузка на команду должна быть ограничена
Виды когнитивной нагрузки:
- Внутренняя - относится напрямую к реализации задачи напрямую
- Внешняя - относится к окружению, в котором задачу нужно сделать
- Общая - относится к аспектам задачи, которым можно уделить внимание для получения новых данных
Надо минимизировать первые 2 типа нагрузки (через обучение и автоматизацию) и сфокусироваться на 3 типе когнитивной нагрузки, решение которой позволяет делать более крутые фичи
Когнитивная нагрузка применима и к системам. Главное правило: не давать на команду больше когнитивной нагрузки, чем она может переварить. Иначе команда начинает работать как группа индивидуалистов т.к. утопают в сложности своих задач и у них нет времени на командную работу
Главная концепция - Закон Конвея
> Дизайн IT-систем повторяет дизайн коммуникации организации
Популярный пример: если вы решите сделать компилятор языка программирования и его будут делать 4 команды - он будет 4-х ступенчатым.
Коммуникация команд всегда побеждает архитектуру. Именно поэтому нельзя создавать архитектуру системы, не думая о дизайне команд и их коммуникаций. Есть 2 пути - либо отталкиваться от команд и создавать архитектуру на основе командного деления. Либо применять обратный маневр Конвея - сначала придумать архитектуру, а потом под эту архитектуру собрать команды.
Очень важная мысль: архитектура и топология команд очень связаны друг с другом. Задача архитектора - дизайнить и то и другое одновременно.
Как следствие - все бест-практисы архитектуры валидны и для организации работы команд:
- Низкое зацепление и большая связность - команды должны слабо зависеть друг от друга и должны больше коммуницировать внутри себя
- Команды не должны быть большими
- Команды должны иметь четкие интерфейсы, описывающие, как с ними взаимодействовать
Я прошелся совсем по верхам, но это минимум, который необходимо знать для организации команд. На основе этих идей создана концепция Team Topologies об основных типах команд и их взаимодействии, которую я раскрою в следующих постах.
#note #TeamTopology #book #конспект #managment
Основные концепции:
Team-first mindset
Команда - самый эффективный способ организации людей для решения проблем. Поэтому важно перестроить сознание на team-first и уметь работать с командами:
- Когда команда - неделимый юнит для реализации любой работы
- Похвала и порицание всегда идут на команду, а не на отдельных людей
- Цели команды важнее собственных
Модель Такмана говорит о том, как рабочая группа превращается в команду:
- Формирование - создается рабочая группа и начинает работать сообща
- Шторминг - возникают конфликты между людьми. На этом этапе часть людей может покинуть группу или группа может распасться полностью.
- Нормализация - выработка единых подходов
- Перформинг - команда выходит на плато высокой продуктивности
Числа Данбара
Антрополог Данбар проанализировал различные сообщества людей и заметил, что есть 4 "круга" социальных связей:
- Очень близкие отношения с 5-7 людьми
- Приятели, хорошие друзья - 15 человек
- Семья, коллеги - 50 человек
- Стая - 150-200 человек
Это не какая-то математическая модель - это результат наблюдений.
Как это перекладывается на IT и организации:
- Идеальный размер команды - 5-7 человек. Но в крайнем случае - до 15, но тогда высок риск что люди внутри сами поделятся на 2 группы
- 50 человек - уровень подразделения
- 200 человек - уровень отдела
В книге приводится кейс компании, которая обходит фазу шторминга в модели Такмана:
- Рекомендованы команды по 7 человек
- Но команды могут расти вместе с ростом задач или продукта, это нормально
- Когда команда достигает 15 человек - её делят на 2 команды
Т.к. команда из 15 человек - уже сработавшаяся, то когда их поделят на 2 команды, они могут пропустить фазу шторминга.
Когнитивная нагрузка на команду должна быть ограничена
Виды когнитивной нагрузки:
- Внутренняя - относится напрямую к реализации задачи напрямую
- Внешняя - относится к окружению, в котором задачу нужно сделать
- Общая - относится к аспектам задачи, которым можно уделить внимание для получения новых данных
Надо минимизировать первые 2 типа нагрузки (через обучение и автоматизацию) и сфокусироваться на 3 типе когнитивной нагрузки, решение которой позволяет делать более крутые фичи
Когнитивная нагрузка применима и к системам. Главное правило: не давать на команду больше когнитивной нагрузки, чем она может переварить. Иначе команда начинает работать как группа индивидуалистов т.к. утопают в сложности своих задач и у них нет времени на командную работу
Главная концепция - Закон Конвея
> Дизайн IT-систем повторяет дизайн коммуникации организации
Популярный пример: если вы решите сделать компилятор языка программирования и его будут делать 4 команды - он будет 4-х ступенчатым.
Коммуникация команд всегда побеждает архитектуру. Именно поэтому нельзя создавать архитектуру системы, не думая о дизайне команд и их коммуникаций. Есть 2 пути - либо отталкиваться от команд и создавать архитектуру на основе командного деления. Либо применять обратный маневр Конвея - сначала придумать архитектуру, а потом под эту архитектуру собрать команды.
Очень важная мысль: архитектура и топология команд очень связаны друг с другом. Задача архитектора - дизайнить и то и другое одновременно.
Как следствие - все бест-практисы архитектуры валидны и для организации работы команд:
- Низкое зацепление и большая связность - команды должны слабо зависеть друг от друга и должны больше коммуницировать внутри себя
- Команды не должны быть большими
- Команды должны иметь четкие интерфейсы, описывающие, как с ними взаимодействовать
Я прошелся совсем по верхам, но это минимум, который необходимо знать для организации команд. На основе этих идей создана концепция Team Topologies об основных типах команд и их взаимодействии, которую я раскрою в следующих постах.
#note #TeamTopology #book #конспект #managment
👍24❤4
Конспект книги Team Topologies, часть №2 - типы команд и взаимодействия
Во всех компаниях разная культура, разные процессы и разные команды. Но фундаментально все команды и взаимодействия между ними можно свести к 4 базовым видам команд и 3 базовым видам взаимодействия
4 базовых вида команд:
- Продуктовые команды (Stream aligned teams, уточню что перевод не совсем корректный, но он наиболее понятный)
- Команды сложной подсистемы (complex-subsystem team)
- Платформенные команды (platform team)
- Поддерживающие команды (enabling team)
Продуктовые команды:
- Основной вид команды в организации (90+% команд)
- Сфокусированы на доставке ценности
- Имеют все необходимые компетенции для решения задач своего потока
- Экспериментируют и учаться
- Все остальные типы команд нужны для того, чтобы продуктовые команды быстрее доставляли ценность
Команды сложной подсистемы:
- Отвечает за развитие и поддержку сложной под-системы. Сложной настолько, что всем членам команды необходимо быть экспертами в области этой системы (наприммер, команда создающая видео-кодек)
- Команда инкапсулирует в себе когнитивную сложность какой-то предметной области. Позволяя продуктовым командам быстрее разрабатывать фичи.
Платформенные команды:
- Цель команды - обеспечить продуктовым командам возможность доставлять фичи с высокой степенью автономности
- Платформенная команда взаимодействует с продуктовыми командами для понимания того, что им нужно и совместного прототипирования
- Платформенная команда развивает платформу как продукт
- Крупные платформы также внутри могут делиться на команду и иметь внутри все 4 типа команд
Поддерживающие команды:
- Состоит из специалистов в определенной технической или продуктовой области
- Команда ищет новые возможности и развивает инструментарий для других команд
- Не являются центром уникальной экспертизы, а помогают другим командам получить компетенции и возможности
То есть, если совсем коротко:
- Есть команды, которые делают продуктовые фичи
- Если есть что-то реально сложное, под эту сложность выделяют отдельные команды, которые делают это "сложное" - легким и удобным для других команд
- Т.к. продуктовые команды постоянно заняты продуктовыми фичами, то им помогают платформенные команды и поддерживающие команды
- Платформенные команды предоставляют платформы, которые легки и удобны в использовании и помогают продуктовым командам доставлять фичи
- Поддерживающие команды создают инструментарий для продуктовых команд и развивают их компетенции
Как команды могут друг с другом взаимодействием:
- Совместая работа
- X-as-a-Service
- Фасилитация
Совместная работа
- Описание говорящее - 2 команды совместно что-то делают
- Не рекомендуется часто заниматься совместной работой т.к. это затратное мероприятие. К этому нужно подходить осознанно
- 1 команда должна совместной работать только с 1 другой командой в 1 момент времени
- Взаимодействие эффективно для поиска новых решений и инноваций
X-as-a-Service:
- Потребление или предоставление чего-либо с минимальным взаимодействием
- Этот тип взаимодействия можно использовать со множеством команд одновременно
- Эффективно на поздних этапах развития чего-либо, когда важна стабильность поставки, а не поиск новых решений
Фасилитация:
- Помощь или получение помощи от другой команды для устранения препятствий
- Режим взаимодействия рекомендуется использовать с небольшим количеством команд одновременно
Проще это объяснять на примерах:
- Поддерживающая команда в режиме фасилитации помогает продуктовой команде научитья использовать инструментарий для UI-автотестов
- Платформенная команда предоставляет инструментарий для деплоя в прод как X-as-a-Service
- ML-команда (Команда сложной под-системы) в режиме совместной работы с продуктовой командой ищут оптимальные способы использования ML для автоматизации проверки контента пользователей (отзывов например)
Конечно, все несколько сложнее, но в рамках обзора приходится ужиматься по контенту
#note #TeamTopology #book #конспект #managment
Во всех компаниях разная культура, разные процессы и разные команды. Но фундаментально все команды и взаимодействия между ними можно свести к 4 базовым видам команд и 3 базовым видам взаимодействия
4 базовых вида команд:
- Продуктовые команды (Stream aligned teams, уточню что перевод не совсем корректный, но он наиболее понятный)
- Команды сложной подсистемы (complex-subsystem team)
- Платформенные команды (platform team)
- Поддерживающие команды (enabling team)
Продуктовые команды:
- Основной вид команды в организации (90+% команд)
- Сфокусированы на доставке ценности
- Имеют все необходимые компетенции для решения задач своего потока
- Экспериментируют и учаться
- Все остальные типы команд нужны для того, чтобы продуктовые команды быстрее доставляли ценность
Команды сложной подсистемы:
- Отвечает за развитие и поддержку сложной под-системы. Сложной настолько, что всем членам команды необходимо быть экспертами в области этой системы (наприммер, команда создающая видео-кодек)
- Команда инкапсулирует в себе когнитивную сложность какой-то предметной области. Позволяя продуктовым командам быстрее разрабатывать фичи.
Платформенные команды:
- Цель команды - обеспечить продуктовым командам возможность доставлять фичи с высокой степенью автономности
- Платформенная команда взаимодействует с продуктовыми командами для понимания того, что им нужно и совместного прототипирования
- Платформенная команда развивает платформу как продукт
- Крупные платформы также внутри могут делиться на команду и иметь внутри все 4 типа команд
Поддерживающие команды:
- Состоит из специалистов в определенной технической или продуктовой области
- Команда ищет новые возможности и развивает инструментарий для других команд
- Не являются центром уникальной экспертизы, а помогают другим командам получить компетенции и возможности
То есть, если совсем коротко:
- Есть команды, которые делают продуктовые фичи
- Если есть что-то реально сложное, под эту сложность выделяют отдельные команды, которые делают это "сложное" - легким и удобным для других команд
- Т.к. продуктовые команды постоянно заняты продуктовыми фичами, то им помогают платформенные команды и поддерживающие команды
- Платформенные команды предоставляют платформы, которые легки и удобны в использовании и помогают продуктовым командам доставлять фичи
- Поддерживающие команды создают инструментарий для продуктовых команд и развивают их компетенции
Как команды могут друг с другом взаимодействием:
- Совместая работа
- X-as-a-Service
- Фасилитация
Совместная работа
- Описание говорящее - 2 команды совместно что-то делают
- Не рекомендуется часто заниматься совместной работой т.к. это затратное мероприятие. К этому нужно подходить осознанно
- 1 команда должна совместной работать только с 1 другой командой в 1 момент времени
- Взаимодействие эффективно для поиска новых решений и инноваций
X-as-a-Service:
- Потребление или предоставление чего-либо с минимальным взаимодействием
- Этот тип взаимодействия можно использовать со множеством команд одновременно
- Эффективно на поздних этапах развития чего-либо, когда важна стабильность поставки, а не поиск новых решений
Фасилитация:
- Помощь или получение помощи от другой команды для устранения препятствий
- Режим взаимодействия рекомендуется использовать с небольшим количеством команд одновременно
Проще это объяснять на примерах:
- Поддерживающая команда в режиме фасилитации помогает продуктовой команде научитья использовать инструментарий для UI-автотестов
- Платформенная команда предоставляет инструментарий для деплоя в прод как X-as-a-Service
- ML-команда (Команда сложной под-системы) в режиме совместной работы с продуктовой командой ищут оптимальные способы использования ML для автоматизации проверки контента пользователей (отзывов например)
Конечно, все несколько сложнее, но в рамках обзора приходится ужиматься по контенту
#note #TeamTopology #book #конспект #managment
🔥9👍1
Конспект книги Team Topologies, часть №3 - итоги
В этом посте не будет какой-то прям новой инфы из книги. Тут я резюмирую про что книга и для кого
В рамках предыдущих постов я срезал очень много углов т.к. уместить 200-300 страниц в 8000 символов и не потерять смысл - сложно.
Книга оказалась намного лучше, чем я ожидал. Обычно такие книги на определенный % состоят из всякой воды и лозунгов. Но эта книга более системная. Авторы взяли свой опыт и опыт всей индустрии в рамках организации команд и сложили его в удобную форму книги.
В книге очень много ссылок на другие книги, исследования, кейсы крупных компаний. Это натурально кладезь полезных ссылок на всякое.
Авторы не говорят, что их рецепт - единственный верный. Они прямо говорят, что подход, описанный в Team Topologies - базовый, фундаментальный. Но в определенных контекстах и в крупных организациях топология команд может отличаться т.к. там в узких кейсах будут эффективны более специфичные бест-практисы
Тем не менее, очень хорошо подана база:
- Команды должны быть маленькими
- И их ответственность должна быть маленькой (помещаться в команду)
- Разработка - это не сервера и бинари, это социо-техническая система, т.е. важна как техника так и люди и взаимодействия между ними
- Архитектура - это команды+системы
- Многие бест-практисы архитектуры актуальны и для организации команд
- Закон Конвея - организация побеждает архитектуру
- Команды должны быть самостоятельными
- Как следствие - все "вспомогательные" команды должны работать так, чтобы повышать самостоятельность других команд, а не снижать их. Пример: хорошо, когда команда, разратывающая инструментарий для автоматизации, предоставляет удобную библиотеку, гайдлайны по интеграции, коучит продуктовые команды для повышения экспертизы в автоматизации. Плохо, когда эта же команда сама заходит в команды и пишет там тесты
- Нужны четкие границы ответственности команд
- Команды разные нужны, команды разные важны
- То же самое и про взаимодействия - нужны разные в разный момент времени
Очень много в книге уделено разработке внутренних платформ и как внутренние платформы могут превратится в большие продукты, где внутри также есть разные типы команд
Для меня книга открыла глаза на некоторые аспекты взаимодействия команд, стало реально проще понимать, почему текущие наши попытки взаимодействия с какими-то командами работали плохо, а какие-то работали хорошо
Для кого эта книга:
- Архитекторы
- Менеджмент над тимлидами
- Тимлиды, которые уже больше про управление командой, чем про альфа-волчистость в команде (условно, если вы альфа-веб разработчик в команде веб-разработчиков и, поэтому, тимлид - то возможно книга будет не для вас)
Книгу строго рекомендую к прочтению, если она матчится с вашей текущей ролью.
#note #TeamTopology #book #конспект #managment
В этом посте не будет какой-то прям новой инфы из книги. Тут я резюмирую про что книга и для кого
В рамках предыдущих постов я срезал очень много углов т.к. уместить 200-300 страниц в 8000 символов и не потерять смысл - сложно.
Книга оказалась намного лучше, чем я ожидал. Обычно такие книги на определенный % состоят из всякой воды и лозунгов. Но эта книга более системная. Авторы взяли свой опыт и опыт всей индустрии в рамках организации команд и сложили его в удобную форму книги.
В книге очень много ссылок на другие книги, исследования, кейсы крупных компаний. Это натурально кладезь полезных ссылок на всякое.
Авторы не говорят, что их рецепт - единственный верный. Они прямо говорят, что подход, описанный в Team Topologies - базовый, фундаментальный. Но в определенных контекстах и в крупных организациях топология команд может отличаться т.к. там в узких кейсах будут эффективны более специфичные бест-практисы
Тем не менее, очень хорошо подана база:
- Команды должны быть маленькими
- И их ответственность должна быть маленькой (помещаться в команду)
- Разработка - это не сервера и бинари, это социо-техническая система, т.е. важна как техника так и люди и взаимодействия между ними
- Архитектура - это команды+системы
- Многие бест-практисы архитектуры актуальны и для организации команд
- Закон Конвея - организация побеждает архитектуру
- Команды должны быть самостоятельными
- Как следствие - все "вспомогательные" команды должны работать так, чтобы повышать самостоятельность других команд, а не снижать их. Пример: хорошо, когда команда, разратывающая инструментарий для автоматизации, предоставляет удобную библиотеку, гайдлайны по интеграции, коучит продуктовые команды для повышения экспертизы в автоматизации. Плохо, когда эта же команда сама заходит в команды и пишет там тесты
- Нужны четкие границы ответственности команд
- Команды разные нужны, команды разные важны
- То же самое и про взаимодействия - нужны разные в разный момент времени
Очень много в книге уделено разработке внутренних платформ и как внутренние платформы могут превратится в большие продукты, где внутри также есть разные типы команд
Для меня книга открыла глаза на некоторые аспекты взаимодействия команд, стало реально проще понимать, почему текущие наши попытки взаимодействия с какими-то командами работали плохо, а какие-то работали хорошо
Для кого эта книга:
- Архитекторы
- Менеджмент над тимлидами
- Тимлиды, которые уже больше про управление командой, чем про альфа-волчистость в команде (условно, если вы альфа-веб разработчик в команде веб-разработчиков и, поэтому, тимлид - то возможно книга будет не для вас)
Книгу строго рекомендую к прочтению, если она матчится с вашей текущей ролью.
#note #TeamTopology #book #конспект #managment
👍9🔥4🤩1