Liam Wong: TO:KY:00 (Рубрика #Culture)
Прекрасная книга с фотографиями Лиама Вонга, который был арт-директором в Ubisoft, ездил по миру и в какой-то момент увлекся фотографией и стал профессионалом в ней. В этой книге представлена его серия робот о Токио, что предстает перед нами в антураже киберпанка Ридли Скота, что мы увидели в "Бегущем по лезвию". А сам бегущий был экранизацией книги "Мечтают ли андроиды об электроовцах" Филиппа Киндреда Дика, одного из моих любимых фантастов. В общем, я листал эту книгу Лиама с большим удовольствием, чего и вам рекомендую!
Прекрасная книга с фотографиями Лиама Вонга, который был арт-директором в Ubisoft, ездил по миру и в какой-то момент увлекся фотографией и стал профессионалом в ней. В этой книге представлена его серия робот о Токио, что предстает перед нами в антураже киберпанка Ридли Скота, что мы увидели в "Бегущем по лезвию". А сам бегущий был экранизацией книги "Мечтают ли андроиды об электроовцах" Филиппа Киндреда Дика, одного из моих любимых фантастов. В общем, я листал эту книгу Лиама с большим удовольствием, чего и вам рекомендую!
1🔥16❤9👍3
The Untold Story of Log4j and Log4Shell | Christian Grobmeier | GitHub (Рубрика #Security)
С большим интересом посмотрел историю про один из самых крупных факапов в истории безопасности, которую рассказывал непосредственный участник событий - Кристиан Гробмайер, мейнтейнер Apache Log4j, участник Apache Software Foundation. Человек, который в декабре 2021 внезапно оказался ответственным за "половину интернета".
Интересно, что я помню масштаб той истории и ее стремительное развитие - это было эпично. Но что же произошло?
В 2021 в библиотеке Log4j нашли уязвимость максимального уровня 10 из 10 Log4Shell (CVE-2021-44228) - возможность удалённого выполнения кода через обычную строку логирования (${jndi:…}). Эксплуатация была элементарной, а Log4j был буквально везде: enterprise-системы, облака, гос-сервисы, игры. Например, в процессе работы над инцидентом Кристиана позвал его сын и показал, что даже его Minecraft сервер пал жертвой этой уязвимости ...
А дальше был кризис
- Несколько волонтёров, что поддерживали библиотеку на энтузиазме
- Ноль сна и куча давления в стиле "чините быстрее"
- Давление со стороны компаний и СМИ,
- При этом мало поддержки и ноль вопросов о том, а как ребята себя чувствуют и нужна ли помощь
В общем, этот инцидент показал не баг в одной библиотеке, а системную проблему всей open-source-экосистемы. Если говорить про инсайты в общем, то они примерно такие и актуальны до сих пор
1️⃣ Open source ≠ безопасно по умолчанию
Открытый код не означает автоматически защищённый код. Безопасность - это люди, процессы и поддержка, а не лицензия.
2️⃣ Масштаб библиотеки = масштаб риска
Маленькая зависимость → тысячи продуктов → глобальный инцидент. Большинство компаний даже не знали, что у них есть Log4j, пока не стало поздно. Отсюда резкий интерес к SBOM (Software Bill of Materials) и прозрачности цепочки поставок.
3️⃣ Самая опасная уязвимость - незнание
Мейнтейнеры часто не security-эксперты. Без обучения secure coding разработчики часто становятся точками отказа
4️⃣ Один-два мейнтейнера - это single point of failure (если докапываться, то два - это уже не single )
Критичные библиотеки не могут держаться на энтузиазме пары людей. Деньги важны, но ещё важнее - участие компаний-потребителей.
5️⃣ Культура важнее технологий
Агрессия, давление и обвинения делают экосистему слабее. Поддержка и сотрудничество - наоборот.
🌝 Что это значит для инженеров
- Минимизируйте зависимости. Каждая библиотека - потенциальная атака.
- Автоматизируйте обновления и CVE-алерты (Dependabot, SCA).
- Не доверяйте входным данным никогда, даже "внутренним".
- Отключайте опасные фичи по умолчанию (типа jdni)
- Используйте defense-in-depth.
- Генерируйте SBOM - знайте, из чего вы собрали продукт.
- Нашли проблему в OSS - помогите, а не просто «репортните и забудьте».
🔥 Что это значит для тимлидов и CTO
- Безопасность зависимостей = бизнес-риск, а не "техническая деталь"
- У вас должен быть ответственный за OSS-цепочку и реакцию на CVE
- SBOM - must-have, а не nice-to-have
- Закладывайте время инженеров на вклад в критичные open-source-проекты.
- Инвестируйте в обучение secure development
- Планируйте регулярные апдейты зависимостей как часть roadmap
- Готовьтесь к 0-day заранее, а не в Slack-панике
Итого, Log4Shell показал простую вещь - наш софт настолько безопасен, насколько безопасны его самые маленькие зависимости. А для того, чтобы они были лучше стоит не только использовать эти библиотеки, но и поддерживать их самим.
#Security #Engineering #Software #Management #OpenSource
С большим интересом посмотрел историю про один из самых крупных факапов в истории безопасности, которую рассказывал непосредственный участник событий - Кристиан Гробмайер, мейнтейнер Apache Log4j, участник Apache Software Foundation. Человек, который в декабре 2021 внезапно оказался ответственным за "половину интернета".
Интересно, что я помню масштаб той истории и ее стремительное развитие - это было эпично. Но что же произошло?
В 2021 в библиотеке Log4j нашли уязвимость максимального уровня 10 из 10 Log4Shell (CVE-2021-44228) - возможность удалённого выполнения кода через обычную строку логирования (${jndi:…}). Эксплуатация была элементарной, а Log4j был буквально везде: enterprise-системы, облака, гос-сервисы, игры. Например, в процессе работы над инцидентом Кристиана позвал его сын и показал, что даже его Minecraft сервер пал жертвой этой уязвимости ...
А дальше был кризис
- Несколько волонтёров, что поддерживали библиотеку на энтузиазме
- Ноль сна и куча давления в стиле "чините быстрее"
- Давление со стороны компаний и СМИ,
- При этом мало поддержки и ноль вопросов о том, а как ребята себя чувствуют и нужна ли помощь
В общем, этот инцидент показал не баг в одной библиотеке, а системную проблему всей open-source-экосистемы. Если говорить про инсайты в общем, то они примерно такие и актуальны до сих пор
1️⃣ Open source ≠ безопасно по умолчанию
Открытый код не означает автоматически защищённый код. Безопасность - это люди, процессы и поддержка, а не лицензия.
2️⃣ Масштаб библиотеки = масштаб риска
Маленькая зависимость → тысячи продуктов → глобальный инцидент. Большинство компаний даже не знали, что у них есть Log4j, пока не стало поздно. Отсюда резкий интерес к SBOM (Software Bill of Materials) и прозрачности цепочки поставок.
3️⃣ Самая опасная уязвимость - незнание
Мейнтейнеры часто не security-эксперты. Без обучения secure coding разработчики часто становятся точками отказа
4️⃣ Один-два мейнтейнера - это single point of failure (
Критичные библиотеки не могут держаться на энтузиазме пары людей. Деньги важны, но ещё важнее - участие компаний-потребителей.
5️⃣ Культура важнее технологий
Агрессия, давление и обвинения делают экосистему слабее. Поддержка и сотрудничество - наоборот.
- Минимизируйте зависимости. Каждая библиотека - потенциальная атака.
- Автоматизируйте обновления и CVE-алерты (Dependabot, SCA).
- Не доверяйте входным данным никогда, даже "внутренним".
- Отключайте опасные фичи по умолчанию (типа jdni)
- Используйте defense-in-depth.
- Генерируйте SBOM - знайте, из чего вы собрали продукт.
- Нашли проблему в OSS - помогите, а не просто «репортните и забудьте».
- Безопасность зависимостей = бизнес-риск, а не "техническая деталь"
- У вас должен быть ответственный за OSS-цепочку и реакцию на CVE
- SBOM - must-have, а не nice-to-have
- Закладывайте время инженеров на вклад в критичные open-source-проекты.
- Инвестируйте в обучение secure development
- Планируйте регулярные апдейты зависимостей как часть roadmap
- Готовьтесь к 0-day заранее, а не в Slack-панике
Итого, Log4Shell показал простую вещь - наш софт настолько безопасен, насколько безопасны его самые маленькие зависимости. А для того, чтобы они были лучше стоит не только использовать эти библиотеки, но и поддерживать их самим.
#Security #Engineering #Software #Management #OpenSource
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
The Untold Story of Log4j and Log4Shell | Christian Grobmeier | GitHub
In late 2021, the Log4Shell vulnerability sent shockwaves through the global tech community. For the first time, we're sharing the untold, inside story from the perspective of Christian Grobmeier, a maintainer of the Log4j project. Hear about the immense…
🔥12❤4⚡3👍2
Update: SDS (System-Design.Space)
С прошлого апдейта я не останавливал работу над проектом и добавил на сайт кучу нового:
- Добавил уровень сложности для глав и разметил их
- Добавил фильтрацию по типу материала и сложности
- Добавил возможность отслеживать прогресс прохождения, отмечая пройденные главы, а таже возможность откладывать главы в закладки (это завязано на local storage, поэтому пока не переносится по устройствам)
- Добавил много интерактивных архитектурных диаграмм в часть с задачами/кейсами
- Добавил в базовые практики проектирования главы про балансировку трафика, кеши, асинхронность
- Добавил части про безопасность и фронтовую архитектуру
- Добавил кучу глав в разные части программы.
В общем, мне очень нравится дорабатывать и расширять сайт. Если у вас есть идеи улучшений или репорты о багах, то пишите в комменты и я их учту в планах разработки
#SystemDesign #Interview #Career #Architecture #DistributedSystems #Databases #Engineering #Software
С прошлого апдейта я не останавливал работу над проектом и добавил на сайт кучу нового:
- Добавил уровень сложности для глав и разметил их
- Добавил фильтрацию по типу материала и сложности
- Добавил возможность отслеживать прогресс прохождения, отмечая пройденные главы, а таже возможность откладывать главы в закладки (это завязано на local storage, поэтому пока не переносится по устройствам)
- Добавил много интерактивных архитектурных диаграмм в часть с задачами/кейсами
- Добавил в базовые практики проектирования главы про балансировку трафика, кеши, асинхронность
- Добавил части про безопасность и фронтовую архитектуру
- Добавил кучу глав в разные части программы.
В общем, мне очень нравится дорабатывать и расширять сайт. Если у вас есть идеи улучшений или репорты о багах, то пишите в комменты и я их учту в планах разработки
#SystemDesign #Interview #Career #Architecture #DistributedSystems #Databases #Engineering #Software
System Design Space
System Design Space — Проектируй лучшие системы и проходи интервью
Изучай System Design для создания надёжных масштабируемых систем и успешного прохождения технических собеседований.
1🔥54❤9⚡3
Бывший CEO GitHub стартанул новую компанию для создания новой платформы для разработчиков (Рубрика #Engineering)
Интересная новость от Томаса, который недавно ушел из Microsoft (а точнее из GitHub), чтобы заняться своим стартапом. Он вышел из неизвестности с анонсом компании "EntireHQ", которая подняла $60 млн в сид раунде с оценкой в $300 млн на создание новой платформы с примерно таким видением
- Git‑совместимая база данных, объединяющая код, намерение, ограничения и рассуждения в единую систему с контролем версий.
- Универсальный семантический слой рассуждений, позволяющий координацию нескольких агентов через граф контекста.
- AI‑native интерфейс, который заново изобретает жизненный цикл разработки ПО для сотрудничества "агент–человек"
Это видение обусловлено тем, что за последние три месяца фундаментальная роль разработчика ПО была фактически "пересобрана". Невероятные улучшения в последних моделях от Anthropic, Google и OpenAI сделали кодинговых агентов настолько хорошими, что во многих ситуациях теперь проще написать промпт, чем вручную писать код. Терминал снова стал центром притяжения на наших компьютерах. Лучшие инженеры могут одновременно запускать десяток агентов.
Ну и компания не просто анонсировала сид-раунд и видение - ребята уже выкатили продукт Checkpoints, который автоматически сохраняет контекст агента. С этим новым кубиком мы получаем автоматическое сохранение контекста агента как данных первого класса, с версионированием в Git. Когда вы коммитите код, сгенерированный агентом, Checkpoints сохраняет полную сессию вместе с коммитом: транскрипт, промпты, затронутые файлы, расход токенов, вызовы инструментов и многое другое. Ребята уже опубликовали этот продукт в виде open‑source CLI на GitHub.
Будет очень интересно следить за начинаниями ребят - тем более Томас обещал, что они будут разрабатывать свой продукт в формате Open Source.
#AI #Software #Engineering #Architecture #Agents #Software #ML #Leadership #Startup
Интересная новость от Томаса, который недавно ушел из Microsoft (а точнее из GitHub), чтобы заняться своим стартапом. Он вышел из неизвестности с анонсом компании "EntireHQ", которая подняла $60 млн в сид раунде с оценкой в $300 млн на создание новой платформы с примерно таким видением
- Git‑совместимая база данных, объединяющая код, намерение, ограничения и рассуждения в единую систему с контролем версий.
- Универсальный семантический слой рассуждений, позволяющий координацию нескольких агентов через граф контекста.
- AI‑native интерфейс, который заново изобретает жизненный цикл разработки ПО для сотрудничества "агент–человек"
Это видение обусловлено тем, что за последние три месяца фундаментальная роль разработчика ПО была фактически "пересобрана". Невероятные улучшения в последних моделях от Anthropic, Google и OpenAI сделали кодинговых агентов настолько хорошими, что во многих ситуациях теперь проще написать промпт, чем вручную писать код. Терминал снова стал центром притяжения на наших компьютерах. Лучшие инженеры могут одновременно запускать десяток агентов.
Ну и компания не просто анонсировала сид-раунд и видение - ребята уже выкатили продукт Checkpoints, который автоматически сохраняет контекст агента. С этим новым кубиком мы получаем автоматическое сохранение контекста агента как данных первого класса, с версионированием в Git. Когда вы коммитите код, сгенерированный агентом, Checkpoints сохраняет полную сессию вместе с коммитом: транскрипт, промпты, затронутые файлы, расход токенов, вызовы инструментов и многое другое. Ребята уже опубликовали этот продукт в виде open‑source CLI на GitHub.
Будет очень интересно следить за начинаниями ребят - тем более Томас обещал, что они будут разрабатывать свой продукт в формате Open Source.
#AI #Software #Engineering #Architecture #Agents #Software #ML #Leadership #Startup
X (formerly Twitter)
Thomas Dohmke (@ashtom) on X
tl;dr Today, we’re announcing our new company @EntireHQ to build the next developer platform for agent–human collaboration. Open, scalable, independent, and backed by a $60M seed round. Plus, we are shipping Checkpoints to automatically capture agent context.…
🔥24❤10⚡1
The rise of the professional vibe coder (Рубрика #Engineering)
На днях у Ленни вышло интервью про вайб кодинг с Лазаром Йовановичем из Lovable (его должность буквально “Professional Vibe Coder”). И там отлично сформулировано то, что как использовать Lovable и не только для вайб инжиниринга и быстрой поставки фичей в свое приложение. Из интеррвью можно получить много инсайтов, среди которых следующие
Что такое vibe engineering (по‑честному)
- Это переход от "микроменеджмента синтаксиса" к управлению намерениями
- Раньше: пишешь классы/циклы, гуглишь ошибки, дебажишь полдня
- Теперь: описываешь что должно быть (UX, бизнес-логика, ограничения, edge cases) → AI строит решение → ты валидируешь как продакт и инженер одновременно
Я прямо на system-design.space это все проходил и это действительно так и работает - за вечер и часть ночи я пересобрал сборку проекта, оптимизировав производительность + SEO, переехал на другой хостинг (как раз съехал с Lovable), добавил поиск по сайту. В общем, это очень вдохновляющий опыт - цикл обратной связи коротки и от идеи до результата проходят часы.
Лазар формулирует работу в своем видео как формулировку "желания джинну"
- Что за продукт/фича
- Кто пользователь
- Что считается “готовым” или критерии DoD (definition of done)
- Ограничения (данные, доступы, SLA, безопасность)
И у него в Lovable за 20–40 минут получается скелет: UI, API, модели, базовую логику. Это момент, когда из головы появляется "что-то кликабельное", и команда перестаёт спорить абстракциями.
И я примерно так стартую проекты - с условного визуала. Но потом я иду в Codex и докручиваю то, что отличает демку от продакшена: проверки, обработка ошибок, миграции, тесты, логирование, права доступа, рефакторинг. Наверное, можно это делать и в Lovable, но мне удобнее делать это по другому. В итоге, получаются короткие итерации: собрал → кликнул → сломал → уточнил промпт → повторил. Время цикла - часы, не спринты.
Главный инсайт из интервью относится к не-технарям
Они могу быть реально быстрее инженеров, потому что их не засасывает в "а давай выберем библиотеку/идеальную архитектуру". Они держат в голове только одно: ценность для пользователя.
Но я как технарь и руководитель добавлю: качество и ответственность никуда не делись - просто точка приложения усилий сместилась. И дальше все равно
Если оцеивать, а что такой подход меняет для рынка и команд, то на ум приходит следующее
- Умение писать бойлерплейт обесценилось. Ценится то, что раньше было "поверх кода": декомпозиция, архитектура, продуктовый вкус, ответственность за риск.
- Роли продакт-менеджеров и инженеров размываются. Появляется гибрид: product engineer, который может придумать и сразу собрать продукт
- Для MVP и внутренних тулов это вообще чит‑код: закрывать бэклог можно силами 1–2 людей, если у них сильный product sense + дисциплина.
Но есть и тёмная сторона “вайба”:
Если просто «навайбить» без рамок - получишь красивый интерфейс с дырявой безопасностью и техдолгом, который взорвётся через квартал. Поэтому мой rule of thumb:
✅ Вайб - для скорости и формы,
✅ Инженерия - для границ (security, доступы, тесты, наблюдаемость, данные),
✅ Ответственность - всегда на людях, не на модели.
Короче: делать продукт стало проще, но делать его хорошо - всё ещё требует профессиональных навыков. Просто теперь эти навыки - это не набор синтаксических трюков, а способность быстро и точно "заказывать" систему и доводить её до надёжного состояния.
#AI #VibeEngineering #Product #Software #Architecture #Lovable #Codex #Productivity #Management #Leadership
На днях у Ленни вышло интервью про вайб кодинг с Лазаром Йовановичем из Lovable (его должность буквально “Professional Vibe Coder”). И там отлично сформулировано то, что как использовать Lovable и не только для вайб инжиниринга и быстрой поставки фичей в свое приложение. Из интеррвью можно получить много инсайтов, среди которых следующие
Что такое vibe engineering (по‑честному)
- Это переход от "микроменеджмента синтаксиса" к управлению намерениями
- Раньше: пишешь классы/циклы, гуглишь ошибки, дебажишь полдня
- Теперь: описываешь что должно быть (UX, бизнес-логика, ограничения, edge cases) → AI строит решение → ты валидируешь как продакт и инженер одновременно
Я прямо на system-design.space это все проходил и это действительно так и работает - за вечер и часть ночи я пересобрал сборку проекта, оптимизировав производительность + SEO, переехал на другой хостинг (как раз съехал с Lovable), добавил поиск по сайту. В общем, это очень вдохновляющий опыт - цикл обратной связи коротки и от идеи до результата проходят часы.
Лазар формулирует работу в своем видео как формулировку "желания джинну"
- Что за продукт/фича
- Кто пользователь
- Что считается “готовым” или критерии DoD (definition of done)
- Ограничения (данные, доступы, SLA, безопасность)
И у него в Lovable за 20–40 минут получается скелет: UI, API, модели, базовую логику. Это момент, когда из головы появляется "что-то кликабельное", и команда перестаёт спорить абстракциями.
И я примерно так стартую проекты - с условного визуала. Но потом я иду в Codex и докручиваю то, что отличает демку от продакшена: проверки, обработка ошибок, миграции, тесты, логирование, права доступа, рефакторинг. Наверное, можно это делать и в Lovable, но мне удобнее делать это по другому. В итоге, получаются короткие итерации: собрал → кликнул → сломал → уточнил промпт → повторил. Время цикла - часы, не спринты.
Главный инсайт из интервью относится к не-технарям
Они могу быть реально быстрее инженеров, потому что их не засасывает в "а давай выберем библиотеку/идеальную архитектуру". Они держат в голове только одно: ценность для пользователя.
Но я как технарь и руководитель добавлю: качество и ответственность никуда не делись - просто точка приложения усилий сместилась. И дальше все равно
Если оцеивать, а что такой подход меняет для рынка и команд, то на ум приходит следующее
- Умение писать бойлерплейт обесценилось. Ценится то, что раньше было "поверх кода": декомпозиция, архитектура, продуктовый вкус, ответственность за риск.
- Роли продакт-менеджеров и инженеров размываются. Появляется гибрид: product engineer, который может придумать и сразу собрать продукт
- Для MVP и внутренних тулов это вообще чит‑код: закрывать бэклог можно силами 1–2 людей, если у них сильный product sense + дисциплина.
Но есть и тёмная сторона “вайба”:
Если просто «навайбить» без рамок - получишь красивый интерфейс с дырявой безопасностью и техдолгом, который взорвётся через квартал. Поэтому мой rule of thumb:
✅ Вайб - для скорости и формы,
✅ Инженерия - для границ (security, доступы, тесты, наблюдаемость, данные),
✅ Ответственность - всегда на людях, не на модели.
Короче: делать продукт стало проще, но делать его хорошо - всё ещё требует профессиональных навыков. Просто теперь эти навыки - это не набор синтаксических трюков, а способность быстро и точно "заказывать" систему и доводить её до надёжного состояния.
#AI #VibeEngineering #Product #Software #Architecture #Lovable #Codex #Productivity #Management #Leadership
YouTube
The rise of the professional vibe coder (a new AI-era job)
Lazar Jovanovic is a full-time professional vibe coder at Lovable. His job is to build both internal tools and customer-facing products purely using AI, while not having a coding background. In this conversation, he breaks down the tactics, workflows, and…
👍14🔥5👎3❤2
TypeScript Origins: The Documentary (Рубрика #Software)
На днях я посмотрел документальный фильм TypeScript Origins от OfferZen. В нём выступают создатель TypeScript Андерс Хейлсберг и другие ключевые участники сообщества: от инженеров Microsoft до разработчиков JetBrains, Bloomberg, Deno и др. Фильм рассказывает, как и зачем в Microsoft создали TypeScript и как язык и его экосистема развивались с момента первого релиза. Ниже я расскажу про свои основные инсайты из этого фильма, а также поделюсь мыслями о том, что это значит для нас как инженеров и технических лидеров.
1️⃣ TypeScript родился из необходимости на больших проектах
В начале 2010-х команда во главе с Андерсом Хейлсбергом увидела, что JavaScript плохо масштабируется в больших кодовых базах - не хватает типизации и инструментов для поддержки крупных приложений. В Microsoft запустили внутренний проект (кодовое имя Strata), чтобы "навести порядок" в мире JS, не ломая его основы. Один из героев фильма метко заметил: "Вопрос не в том, сломан ли JavaScript, а в том, достаточно ли он сломан". TypeScript стал ответом - надстройкой над JS, которая решает реальные боли разработчиков.
2️⃣ Ставка на совместимость и постепенное внедрение
Создатели TypeScript с самого начала решили: любой код на JavaScript должен оставаться валидным кодом на TypeScript. Статическая типизация - опциональна. Такой подход позволил командам внедрять язык постепенно, без переписывания всего с нуля. Фильм подчёркивает, с каким пониманием авторы отнеслись к сообществу JavaScript - они максимально сохранили его привычки и свободу. Благодаря этому TypeScript легко "встраивался" в существующие проекты.
3️⃣ Открытость и сообщество сыграли решающую роль
TypeScript был открыт миру (open source) с первого релиза в 2012 году, и это во многом предопределило его успех. В фильме показано, как вокруг языка сформировалось активное сообщество и экосистема: поддержку выразили разработчики инструментов (JetBrains, VS Code), крупные пользователи (например, инженеры Bloomberg) и даже создатели новых платформ вроде Deno. Изначально скепсиса хватало - даже Дэниел Розенвассер (менеджер команды TypeScript) признаётся, что поначалу боялся, "как бы Microsoft всё не загубила". Однако открытая разработка и вовлечение сообщества помогли этого избежать: внешние контрибьюторы улучшали язык, а компании охотно внедряли его у себя.
4️⃣ Внутренние препятствия и поддержка руководства
Документальный фильм приоткрывает и закулисье создания языка внутри Microsoft. Продвижение новой технологии в корпорации оказалось непростым делом: команде TypeScript пришлось доказывать ценность своего подхода и конкурировать за ресурсы. Лишь благодаря поддержке дальновидных лидеров и энтузиазму самих разработчиков проект выжил и вырос. Для успеха понадобилось сочетание технического визионерства и умения "продать" идею внутри компании.
🧐 Что это означает для разработчиков и технических руководителей?
- Решайте реальные проблемы. История TypeScript подчёркивает: инструмент выстреливает, когда снимает настоящую боль.
- Внедряйте эволюционно, а не революционно. Нововведения лучше приживаются, если не требуют ломать всё сразу.
- Сила open source и сообщества. Открытость к сообществу ускоряет развитие технологии. Если вы разрабатываете библиотеку или внутренний инструмент, подумайте об открытом коде и обратной связи от внешних разработчиков.
- Поддерживайте культуру новаторства. Для технических руководителей урок в том, чтобы прислушиваться к инициативам снизу. TypeScript вырос из маленькой команды энтузиастов - дайте своим инженерам пространство экспериментировать и предлагать улучшения.
P.S.
Если интересно больше деталей и живых историй, то я рекомендую посмотреть TypeScript Origins целиком - там много интересных моментов и тонких моментов, которые не поместились в это саммари.
#AI #Engineering #Software #Management #Leadership #Startup #LLM #ML #Architecture #RnD
На днях я посмотрел документальный фильм TypeScript Origins от OfferZen. В нём выступают создатель TypeScript Андерс Хейлсберг и другие ключевые участники сообщества: от инженеров Microsoft до разработчиков JetBrains, Bloomberg, Deno и др. Фильм рассказывает, как и зачем в Microsoft создали TypeScript и как язык и его экосистема развивались с момента первого релиза. Ниже я расскажу про свои основные инсайты из этого фильма, а также поделюсь мыслями о том, что это значит для нас как инженеров и технических лидеров.
1️⃣ TypeScript родился из необходимости на больших проектах
В начале 2010-х команда во главе с Андерсом Хейлсбергом увидела, что JavaScript плохо масштабируется в больших кодовых базах - не хватает типизации и инструментов для поддержки крупных приложений. В Microsoft запустили внутренний проект (кодовое имя Strata), чтобы "навести порядок" в мире JS, не ломая его основы. Один из героев фильма метко заметил: "Вопрос не в том, сломан ли JavaScript, а в том, достаточно ли он сломан". TypeScript стал ответом - надстройкой над JS, которая решает реальные боли разработчиков.
2️⃣ Ставка на совместимость и постепенное внедрение
Создатели TypeScript с самого начала решили: любой код на JavaScript должен оставаться валидным кодом на TypeScript. Статическая типизация - опциональна. Такой подход позволил командам внедрять язык постепенно, без переписывания всего с нуля. Фильм подчёркивает, с каким пониманием авторы отнеслись к сообществу JavaScript - они максимально сохранили его привычки и свободу. Благодаря этому TypeScript легко "встраивался" в существующие проекты.
3️⃣ Открытость и сообщество сыграли решающую роль
TypeScript был открыт миру (open source) с первого релиза в 2012 году, и это во многом предопределило его успех. В фильме показано, как вокруг языка сформировалось активное сообщество и экосистема: поддержку выразили разработчики инструментов (JetBrains, VS Code), крупные пользователи (например, инженеры Bloomberg) и даже создатели новых платформ вроде Deno. Изначально скепсиса хватало - даже Дэниел Розенвассер (менеджер команды TypeScript) признаётся, что поначалу боялся, "как бы Microsoft всё не загубила". Однако открытая разработка и вовлечение сообщества помогли этого избежать: внешние контрибьюторы улучшали язык, а компании охотно внедряли его у себя.
4️⃣ Внутренние препятствия и поддержка руководства
Документальный фильм приоткрывает и закулисье создания языка внутри Microsoft. Продвижение новой технологии в корпорации оказалось непростым делом: команде TypeScript пришлось доказывать ценность своего подхода и конкурировать за ресурсы. Лишь благодаря поддержке дальновидных лидеров и энтузиазму самих разработчиков проект выжил и вырос. Для успеха понадобилось сочетание технического визионерства и умения "продать" идею внутри компании.
- Решайте реальные проблемы. История TypeScript подчёркивает: инструмент выстреливает, когда снимает настоящую боль.
- Внедряйте эволюционно, а не революционно. Нововведения лучше приживаются, если не требуют ломать всё сразу.
- Сила open source и сообщества. Открытость к сообществу ускоряет развитие технологии. Если вы разрабатываете библиотеку или внутренний инструмент, подумайте об открытом коде и обратной связи от внешних разработчиков.
- Поддерживайте культуру новаторства. Для технических руководителей урок в том, чтобы прислушиваться к инициативам снизу. TypeScript вырос из маленькой команды энтузиастов - дайте своим инженерам пространство экспериментировать и предлагать улучшения.
P.S.
Если интересно больше деталей и живых историй, то я рекомендую посмотреть TypeScript Origins целиком - там много интересных моментов и тонких моментов, которые не поместились в это саммари.
#AI #Engineering #Software #Management #Leadership #Startup #LLM #ML #Architecture #RnD
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
TypeScript Origins: The Documentary
TypeScript Origins: The Documentary is brought to you by OfferZen - the community-first developer jobs platform. The documentary features core contributors and community members like Anders Hejlsberg, Steve Lucco, Luke Hoban, Daniel Rosenwasser, Ryan Cavanaugh…
❤11🔥4⚡1
T-Sync конференция - фото (Рубрика #Engineering)
Сегодня рассматривал фотографии с конференции и понял, что она получилась масштабной. Плюс новый формат принес глоток свежего воздуха
- Обычные конференции сконцентрированы на broadcast подходе к трансляции знаний - от спикера к остальным. И хоть они говорят про нетворк, но он сконцентрирован на сборе бесплатного стаффа со стендов
- Наша конфа была сконцентрирована на вопросах и ответах - для получения знаний посетителям надо было ходить и задавать вопросы реальным инженерам, что делали представленные системы. Да, у нас были инженерные дискуссии и там сложность была в том, чтобы добыть наушники, которых всем не хватало. Плюс у нас еще был t-hack и другие интерактивные активности, что требовали вовлечения
В итоге, формат нам понравился и мы будем его повторять в будущем.
P.S.
И немного фоток самого события для красочности
Сегодня рассматривал фотографии с конференции и понял, что она получилась масштабной. Плюс новый формат принес глоток свежего воздуха
- Обычные конференции сконцентрированы на broadcast подходе к трансляции знаний - от спикера к остальным. И хоть они говорят про нетворк, но он сконцентрирован на сборе бесплатного стаффа со стендов
- Наша конфа была сконцентрирована на вопросах и ответах - для получения знаний посетителям надо было ходить и задавать вопросы реальным инженерам, что делали представленные системы. Да, у нас были инженерные дискуссии и там сложность была в том, чтобы добыть наушники, которых всем не хватало. Плюс у нас еще был t-hack и другие интерактивные активности, что требовали вовлечения
В итоге, формат нам понравился и мы будем его повторять в будущем.
P.S.
И немного фоток самого события для красочности
1👍14🔥7❤5💔1
Профессор Илья Стребулаев о том, как заработать на своих идеях и ценить свои неудачи (Рубрика #Startup)
Посмотрел крутое интервью Ильи Стребулаева, профессора из Стэнфорда и эксперта в области корпоративных финансов и венчурного капитала. Илья дал его Алексею Пивоварову, иноагенту и ведущему проекта "Редакция". Они поговорили про перенос логики венчурных инвесторов (как они думают о ставках, риске и качестве решений) на более широкий круг задач - от управления проектами до развития карьеры, что хорошо переносится на тему технического управления. Ниже мои инсайты
1️⃣ Консенсус - не всегда "здоровье команды", иногда это симптом риска
- Если группа слишком быстро приходит к согласию, это может означать конформизм и отсутствие альтернатив.
- Как применять: в архитектурных ревью и дизайн‑доках вводить явную норму: "минимум 2 альтернативы" и "1 назначенный оппонент". Это превращает «несогласие» из личного конфликта в часть процесса.
2️⃣ Очередность высказываний критична: "первым говорит авторитетный" → искажение распределения мнений.
- Внешний конспект прямо указывает: когда первым выступает самый авторитетный участник, мнение остальных сдвигается.
- Как применять: в обсуждениях инцидентов/пост‑мортемов и больших технических решений сначала собирать индивидуальные оценки (письменно), а уже потом обсуждать.
3️⃣ Слепое голосование/сбор мнений до обсуждения повышает честность сигнала
- Предложение "использовать слепое голосование" дано как практический приём.
- Как применять: для RFC/ADR: до синка просим всех выбрать вариант A/B/C и написать по 2 аргумента "за/против" в форме. На созвоне обсуждаем расхождения, а не "базовую позицию лидера".
4️⃣ Полезно начинать обсуждение с “джунов” (или “самых тихих”)
- "Начинать с джунов" - это способ получить более разнообразную картину.
- Как применять: в ревью требований: первым коротко выступает тот, у кого меньше иерархической власти.
5️⃣ Венчурные методы оценки проектов применимы не только инвесторам, но и тем, кто управляет командами/запускает проекты
- Это ключевая рамка пересказа: подходы VC полезны для управленцев и инициаторов.
- Как применять: относиться к крупным инициативам как к портфелю ставок: ограничивать размер ставки (time/budget), заранее определять критерии успеха/провала и "точки выхода" (kill criteria).
6️⃣ Неудачи - актив, если их превращать в данные, а не в стигму
- Эта идея зафиксирована уже в названии ролика ("ценить свои неудачи").
- Как применять: стандартизировать пост‑мортемы: что предполагали, что наблюдали, что изменим. Полезный паттерн - хранить «реестр гипотез» и отмечать, какие из них были опровергнуты и почему (это снижает повторяемость ошибок).
7️⃣ Монетизация идей как инженерная задача
- Тема "как заработать на своих идеях" заявлена в названии; её полезно читать как призыв думать про value‑delivery, а не только про "технологическую красоту".
- Как применять: для каждой крупной фичи фиксировать: "кому больно", "какая метрика улучшится", "какая минимальная поставка (MVP) подтвердит ценность", "какая цена ошибки". Это дисциплинирует backlog и снимает иллюзию прогресса.
Стратегические выводы и практики
1️⃣ Перестроить управление инициативами на "bets + checkpoints". Для каждой крупной инициативы заранее задавать:
(а) ожидаемый выигрыш,
(б) стоимость ошибки,
(в) точки проверки,
(г) критерии остановки.
Это делает "ценность неудач" управляемой: проигрыш должен быть ограничен.
2️⃣ Метрики качества решений (а не только delivery): доля решений с зафиксированными альтернативами; среднее время до пересмотра плохого решения; количество повторяемых инцидент‑классов после пост‑мортемов. Эти метрики напрямую связаны с тезисами про групповую динамику и извлечение уроков.
3️⃣ Оргизменения:
- Ввести норму "письменная позиция до созвона" (для решений выше порога);
- Защищать несогласие (не как "оппозицию лидеру", а как "обязательный элемент качества");
- Обучить фасилитации: кто говорит первым, как фиксируем аргументы, как закрываем решение.
#Engineering #Management #VC #Startup #Software #Leadership
Посмотрел крутое интервью Ильи Стребулаева, профессора из Стэнфорда и эксперта в области корпоративных финансов и венчурного капитала. Илья дал его Алексею Пивоварову, иноагенту и ведущему проекта "Редакция". Они поговорили про перенос логики венчурных инвесторов (как они думают о ставках, риске и качестве решений) на более широкий круг задач - от управления проектами до развития карьеры, что хорошо переносится на тему технического управления. Ниже мои инсайты
1️⃣ Консенсус - не всегда "здоровье команды", иногда это симптом риска
- Если группа слишком быстро приходит к согласию, это может означать конформизм и отсутствие альтернатив.
- Как применять: в архитектурных ревью и дизайн‑доках вводить явную норму: "минимум 2 альтернативы" и "1 назначенный оппонент". Это превращает «несогласие» из личного конфликта в часть процесса.
2️⃣ Очередность высказываний критична: "первым говорит авторитетный" → искажение распределения мнений.
- Внешний конспект прямо указывает: когда первым выступает самый авторитетный участник, мнение остальных сдвигается.
- Как применять: в обсуждениях инцидентов/пост‑мортемов и больших технических решений сначала собирать индивидуальные оценки (письменно), а уже потом обсуждать.
3️⃣ Слепое голосование/сбор мнений до обсуждения повышает честность сигнала
- Предложение "использовать слепое голосование" дано как практический приём.
- Как применять: для RFC/ADR: до синка просим всех выбрать вариант A/B/C и написать по 2 аргумента "за/против" в форме. На созвоне обсуждаем расхождения, а не "базовую позицию лидера".
4️⃣ Полезно начинать обсуждение с “джунов” (или “самых тихих”)
- "Начинать с джунов" - это способ получить более разнообразную картину.
- Как применять: в ревью требований: первым коротко выступает тот, у кого меньше иерархической власти.
5️⃣ Венчурные методы оценки проектов применимы не только инвесторам, но и тем, кто управляет командами/запускает проекты
- Это ключевая рамка пересказа: подходы VC полезны для управленцев и инициаторов.
- Как применять: относиться к крупным инициативам как к портфелю ставок: ограничивать размер ставки (time/budget), заранее определять критерии успеха/провала и "точки выхода" (kill criteria).
6️⃣ Неудачи - актив, если их превращать в данные, а не в стигму
- Эта идея зафиксирована уже в названии ролика ("ценить свои неудачи").
- Как применять: стандартизировать пост‑мортемы: что предполагали, что наблюдали, что изменим. Полезный паттерн - хранить «реестр гипотез» и отмечать, какие из них были опровергнуты и почему (это снижает повторяемость ошибок).
7️⃣ Монетизация идей как инженерная задача
- Тема "как заработать на своих идеях" заявлена в названии; её полезно читать как призыв думать про value‑delivery, а не только про "технологическую красоту".
- Как применять: для каждой крупной фичи фиксировать: "кому больно", "какая метрика улучшится", "какая минимальная поставка (MVP) подтвердит ценность", "какая цена ошибки". Это дисциплинирует backlog и снимает иллюзию прогресса.
Стратегические выводы и практики
1️⃣ Перестроить управление инициативами на "bets + checkpoints". Для каждой крупной инициативы заранее задавать:
(а) ожидаемый выигрыш,
(б) стоимость ошибки,
(в) точки проверки,
(г) критерии остановки.
Это делает "ценность неудач" управляемой: проигрыш должен быть ограничен.
2️⃣ Метрики качества решений (а не только delivery): доля решений с зафиксированными альтернативами; среднее время до пересмотра плохого решения; количество повторяемых инцидент‑классов после пост‑мортемов. Эти метрики напрямую связаны с тезисами про групповую динамику и извлечение уроков.
3️⃣ Оргизменения:
- Ввести норму "письменная позиция до созвона" (для решений выше порога);
- Защищать несогласие (не как "оппозицию лидеру", а как "обязательный элемент качества");
- Обучить фасилитации: кто говорит первым, как фиксируем аргументы, как закрываем решение.
#Engineering #Management #VC #Startup #Software #Leadership
YouTube
Профессор Илья Стребулаев о том, как заработать на своих идеях и ценить свои неудачи
Наверно, у каждого такое бывало: приходит в голову какая-то идея, и думаешь: блин, если это осуществить, можно заработать миллионы!
18+ НАСТОЯЩИЙ МАТЕРИАЛ (ИНФОРМАЦИЯ) ПРОИЗВЕДЕН, РАСПРОСТРАНЕН И (ИЛИ) НАПРАВЛЕН ИНОСТРАННЫМ АГЕНТОМ ПИВОВАРОВЫМ АЛЕКСЕЕМ…
18+ НАСТОЯЩИЙ МАТЕРИАЛ (ИНФОРМАЦИЯ) ПРОИЗВЕДЕН, РАСПРОСТРАНЕН И (ИЛИ) НАПРАВЛЕН ИНОСТРАННЫМ АГЕНТОМ ПИВОВАРОВЫМ АЛЕКСЕЕМ…
2❤20🔥9⚡5
Марко Спада в Большом Театре (Рубрика #Humor)
Уже сложилась традиция, что каждый год я хожу с женой в Большой Театр зимой. Обычно это подарки на Новый год или мой День Рождения. Таким темпом я постепенно начинаю разбираться в балете, но у меня все равно остается вопрос - почему у девушек в балете платья, а у мужчин "термобелье":)
#Culture
Уже сложилась традиция, что каждый год я хожу с женой в Большой Театр зимой. Обычно это подарки на Новый год или мой День Рождения. Таким темпом я постепенно начинаю разбираться в балете, но у меня все равно остается вопрос - почему у девушек в балете платья, а у мужчин "термобелье":)
#Culture
❤20😁10🔥2