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

My LLM codegen workflow atm

Крутая статья, где автор рассказывает, как он используем 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

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

Javascript Game Tutorials

Занятный сайт, на котором собраны гайды, как делать игры на JS (пока 2 гайда на 1 игру). Сами гайды выглядят просто топово - все объясняет по шагам с интерактивом. Есть текст, есть codepen, есть youtube

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


https://javascriptgametutorials.com/

#development #javascript #game #tutorial

End of Life

У многих продуктов есть End of life - конец поддержки мейнтейнером. Когда у продукта закончилась поддержка - нет никаких гарантий, что там будут чинить баги или фиксить дыры безопасности. Именно поэтому важно всегда обновлять те части проекта, проблемы в которых могут нести риски

Сайт собирает end of life кучи продуктов - начиная от опереционных систем и заканчивая библиотеками (jquery, react).

Рекомендую сохранить в закладки


https://endoflife.date/

#development #endOfLife

Дайджест за 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).

——————————————

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

Node Modules Inspector

Node Modules Inspector - инструмент, позволяющий провести анализ пакета - от чего зависит, какие уязвимости, сколько весит и все такое. Главные отличительные особенности этого проекта: очень приятный UI и запуск прямо в браузере в Web Container (песочница, в которой можно запускать что-то близкое к nodejs)

Выглядит нереально круто: выбираешь пакет, запускается WebContainer, внутри него запускается pnpm и устанавливает пакет и выводит всю стату для анализа

https://node-modules.dev/

#development #javascript #pnpm #performance #webcontainer

Omlet - Uncover React component usage across your dev teams

Еще один инструмент для анализа кода, но на этот раз для дизайн-систем и UI-китов. Омлет собирает аналитику по использованию компонентов в коде: какие компоненты как используются, как быстро отказываются от deprecated компонентов, какие компоненты не из дизайн-системы разработчики часто используют (кандидаты на вынос в дизайн-систему)

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

https://omlet.dev/

#development #uikit #react

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

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

Серия бесплатных воркшопов про менеджмент от Стратоплан

Всем привет, с 14 по 18 апреля c 17:00 по 19:00 по МСК будут проходить бесплатные 2х-часовые занятия от Стратоплан по менеджменту. Среди спикеров есть как минимум 2 чувака, которых я рекомендую читать и слушать всем - Виталий Шароватов (слежу за ним уже лет 7) и Дмитрий Болдырев, который недавно выпускал крутую серию постов про образование команд из рабочих групп

Будет 5 занятий, на которых рассмотрят:
– первые шаги: ожидания и задачи после назначения
– найм и как это делать правильно
– как создать команду
– как ставить и контролировать задачи
– лидерство

Если вы - тимлид или хотите расти в этом направлении - рекомендую записаться. Это бесплатновое, плюс спикеры реально хороши.

Бесплатная регистрация здесь

#managment #stratoplan #note

Дайджест за 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) и Дмитрий Болдырев, который недавно выпускал крутую серию постов про образование команд из рабочих групп

——————————————

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

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

Конспект книги 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 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

Конспект книги Team Topologies, часть №3 - итоги

В этом посте не будет какой-то прям новой инфы из книги. Тут я резюмирую про что книга и для кого

В рамках предыдущих постов я срезал очень много углов т.к. уместить 200-300 страниц в 8000 символов и не потерять смысл - сложно.

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

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

Авторы не говорят, что их рецепт - единственный верный. Они прямо говорят, что подход, описанный в Team Topologies - базовый, фундаментальный. Но в определенных контекстах и в крупных организациях топология команд может отличаться т.к. там в узких кейсах будут эффективны более специфичные бест-практисы

Тем не менее, очень хорошо подана база:
- Команды должны быть маленькими
- И их ответственность должна быть маленькой (помещаться в команду)
- Разработка - это не сервера и бинари, это социо-техническая система, т.е. важна как техника так и люди и взаимодействия между ними
- Архитектура - это команды+системы
- Многие бест-практисы архитектуры актуальны и для организации команд
- Закон Конвея - организация побеждает архитектуру
- Команды должны быть самостоятельными
- Как следствие - все "вспомогательные" команды должны работать так, чтобы повышать самостоятельность других команд, а не снижать их. Пример: хорошо, когда команда, разратывающая инструментарий для автоматизации, предоставляет удобную библиотеку, гайдлайны по интеграции, коучит продуктовые команды для повышения экспертизы в автоматизации. Плохо, когда эта же команда сама заходит в команды и пишет там тесты
- Нужны четкие границы ответственности команд
- Команды разные нужны, команды разные важны
- То же самое и про взаимодействия - нужны разные в разный момент времени

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


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

Для кого эта книга:
- Архитекторы
- Менеджмент над тимлидами
- Тимлиды, которые уже больше про управление командой, чем про альфа-волчистость в команде (условно, если вы альфа-веб разработчик в команде веб-разработчиков и, поэтому, тимлид - то возможно книга будет не для вас)


Книгу строго рекомендую к прочтению, если она матчится с вашей текущей ролью.



#note #TeamTopology #book #конспект #managment

Обучение в стратоплане: обзор на модуль про принятие решений

Очередной обзор на обучение в стратоплане. В этом модуль обсуждали, как принимать решения. Модуль более сфокусированный, чем предыдущий. В предыдущем поверхностно прошли по куче концепций. В этом же модуле обсуждали 2 крупные концепции: алгоритм принятия решений и алгоритм решения конфликтов

Алгоритм принятия решений

Алгоритм состоит из 5 шагов:
1. Является ли это решение своевременным и актуальным для вас?
2. Имеется ли вся информация для принятия решения?
3. Есть ли подробный план реализации?
4. Заинтересованы ли в этом решении компания, руководитель, ЛПР?
5. Чувствую ли я себя хорошо при принятии решения?

Алгоритм одновременно и простой и сложный. Простой - потому что, когда смотришь на него, думаешь "не ну это и так очевидно". Сложный - потому что спотыкаешься, когда пробуешь применить.

Например, возьмем 2 шаг - "Имеется ли вся информация для принятия решения?". Как это понять?
Чтобы решить этот шаг необходимо собрать всю информацию. Как это сделать? Здесь может помочь метод "4 ячейки". Суть метод в том, что мы делим квадрат на 4 части
1. Что я знаю
2. Что я не знаю, но я понимаю, что я этого не знаю
3. Что я знаю, но я не понимаю, что это относится к теме
4. Что я не знаю, но не понимаю, что я этого не знаю

Эти 4 пункта позволяют найти поинты, которые необходимо дополнительно исследовать и поинты, которые необходимо проресерчить. Четвертый пункт - самый интересный. С одной стороны кажется, что он не имеет смысла. Ведь как я могу написать то, чего не представляю. Но на практике, описывая этот квадрат, мозг может найти что-то на подкорке сознания и перенести это в пункт 2 - не знаю, но теперь понял что это надо узнать.

После того как вся информация собрана, её надо проанализировать, ведь не вся информация одинаково полезна. Надо понять:
- К чему обращается информация - это логика, эмоции, правила
- Про интерпретировать. Какая основная мысль?
- Проанализировать. Действительно ли информация верна?

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

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

Когда вы приняли решение, вы должны понимать, что принимаете его исходя из чьих то целей:
- Компании
- Команды
- Членов команды
- Конечного продукта

Если вы приходите и говорите "я так решил", то это плохой путь.

Теперь интересное про конфликты

Формула конфликта: Конфликт (открытое противостояние) = Конфликтная ситуация (набор условий, из которых конфликт может появиться) + Конфликтоген (слова и действия, запускающие конфликт)

Формула конструктива:
- Конструктив = Конфликтная ситуация - Конфликтоген
- Конструктив = Конфликт - Конфликтная ситуация - (Конфликтоген)

Т.е. вам либо надо находить конфликтоген и убирать его, либо убирать конфликтную ситуацию.

Что интересно, в любом конфликте (если в нем не участвуют социопаты) у обоих конфликтующих сторон есть позитивное намерение. Обе стороны считают, что делают что-то хорошее, а их оппонент - что-то плохое. Позитивное намерение зачастую неочевидно для оппонента. Чтобы решить конфликт - необходимо обозначить позитивные намерения обеих сторон, тогда появляется шанс перейти в конструктив и поиск вин-вин ситуации.

Как решать конфликты:
- Наладить контакт - обозначить проблему, предложить спокойно обсудить
- Выяснить как конфликтующие стороны видят ситуацию, их позитивные намерения и желаемые изменения в поведении оппонента
- Договор - обсудить на какие уступки могут пойти стороны конфликта и заключить договор (устный, MN-ка)





#note #stratoplan #managment

Дайджест за 2025-04-14 - 2025-04-18

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

Конспект книги Team Topologies, часть №1 - team-first mindset
Основные концепции:
Team-first mindset
Команда - самый эффективный способ организации людей для решения проблем. Поэтому важно перестроить сознание на team-first и уметь работать с командами:

Конспект книги Team Topologies, часть №2 - типы команд и взаимодействия
Во всех компаниях разная культура, разные процессы и разные команды. Но фундаментально все команды и взаимодействия между ними можно свести к 4 базовым видам команд и 3 базовым видам взаимодействия



Конспект книги Team Topologies, часть №3 - итоги
В этом посте не будет какой-то прям новой инфы из книги. Тут я резюмирую про что книга и для кого

В рамках предыдущих постов я срезал очень много углов т.к. уместить 200-300 страниц в 8000 символов и не потерять смысл - сложно.

Обучение в стратоплане: обзор на модуль про принятие решений
Очередной обзор на обучение в стратоплане. В этом модуль обсуждали, как принимать решения. Модуль более сфокусированный, чем предыдущий. В предыдущем поверхностно прошли по куче концепций. В этом же модуле обсуждали 2 крупные концепции: алгоритм принятия решений и алгоритм решения конфликтов



——————————————

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

Introducing Zod 4 beta

Спустя несколько лет с выхода Zod v3 выпустили бетку Zod v4. Zod - библиотека для валидации объектов на мэтч с переданной схемой.

В 4-м релизе увеличили скорость работы валидации и работы TS по валидации типов, уменьшили размер бандла, добавили новые удобные API. Если вы используете Zod - рекомендую запланировать обновление.

Что интересного уже есть в бетке

Ускорение
- В 2.6 раз быстрее парсинг строк
- в 3 раза быстрее парсинг массивов
- в 8 раз быстрее парсинг объектов
- в 20 раз ускорение инициализации typescript на типах Zod
- в 2 раза уменьшили бандл сайз
- Если вам этого мало - сделали @zod/mini, который содержит основной функционал и весит в 6.6 раз меньше

Улучшили работу со схемами:

Сделали отдельную систему для описания метаданных к схемам

import * as z from "zod";
 
const myRegistry = z.registry<{ title: string; description: string }>();

const emailSchema = z.string().email();
 
myRegistry.add(emailSchema, { title: "Email address", description: "..." });
myRegistry.get(emailSchema);
// => { title: "Email address", ... }

Сделали вывод JSON-схемы

import * as z from "zod";
 
const mySchema = z.object({name: z.string(), points: z.number()});
 
z.toJSONSchema(mySchema);
// => {
//   type: "object",
//   properties: {
//     name: {type: "string"},
//     points: {type: "number"},
//   },
//   required: ["name", "points"],
// }

Сделали новое API для корректного получения типа объекта. В посте упоминают кейс, когда у одной схемы поле - опциональное (можно не указать), а другой - обязательное, но значение может быть undefined. Т.е. грубо говоря

type Obj1 = {
   prop?: string;
}

type Obj2 = {
   prop: string | undefined;
}

Разница небольшая, но она есть. В Zod3 нельзя получить корректный тип для этих объектов.

z.object({ name: z.string().optional() }); 
// { name?: string | undefined }
 
z.object({ name: z.union([z.string(), z.undefined()]) }); 
// { name?: string | undefined }

В Zod4 добавили новый метод, который это умеет, но опциональность ключа там указывается в имени ключа (что, конечно, странно. В друг у нас действительно поле со знаком в конце, что тогда делать?)

const ValueOptional = z.interface({ name: z.string().optional()}); 
// { name: string | undefined }
 
const KeyOptional = z.interface({ "name?": z.string() }); 
// { name?: string }

Кроме того, z.interface позволяет описывать цикличные типы проще, чем это было в Zod3

import * as z from "zod"; // zod@4
 
const Category = z.interface({
  name: z.string(),
  get subcategories() {
    return z.array(Category)
  }
});

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

import * as z from "zod";
 
// configure English locale (default)
z.config(z.locales.en());

Во вторых, улучшили форматирование ошибок

✖ Unrecognized key: "extraField"
✖ Invalid input: expected string, received number
  → at username
✖ Invalid input: expected number, received string
  → at favoriteNumbers[1]

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

https://v4.zod.dev/v4

#development #javascript #library #zod #release

The new Cookie Store API

Внезапно узнал, что уже 4 года как существует новое API для работы с куками, которое давно доступно в Chrome, недавно стало доступно в Safari и все еще недоступно в Firefox - Cookie Store API

Новое API намного удобнее. Хотя любое API, по сравнению со старым, будет удобнее.

Первое, что бросается в глаза - это человеческий интерфейс для установки. Если вам нужно просто установить значение - cookieStore.set("cookie1", "cookie1-value");. Если вам нужна полная настройка:

cookieStore.set({
  name: 'theme',
  value: 'dark',
  path: '/',
  partitioned: false,
  sameSite: 'strict',
});

Второе, что бросается в глаза - это то, что все взаимодействие стало асинхронным

  try {
    await cookieStore.set("cookie1", "cookie1-value");
  } catch (error) {
    console.log(`Error setting cookie1: ${error}`);
  }

Тут я не совсем понял смысла от асинхронщины, но методы будут бросать ошибки - что тоже хорошо.

Еще 1 фича не бросается в глаза, но она очень крутая - можно наконец-то подписаться на изменения кук и увидеть измененные и удаленные куки

cookieStore.addEventListener('change', (event) => {
  console.log(event);
});

Пример использования из статьи: синхронизируем состояние стора с состоянием куки

cookieStore.addEventListener('change', (event) => {
 const deleted = ev.deleted.find((c) => c.name === THEME_COOKIE_NAME);

 if (deleted) {
  setStoredTheme(undefined);
  return;
 }

 const changed = ev.changed.find((c) => c.name === THEME_COOKIE_NAME);

 if (changed) {
  setStoredTheme(changed.value);
  return;
 }
})

В общем, выглядит многообещающе. Ждем открытия без флага в Firefox и можно юзать. Но если хочется уже использовать, то должны быть рабочие полифилы.

https://fotis.xyz/posts/the-new-cookie-store-api/

#development #javascript #cookie