Масштабная конференция получилась:) С моего второго этажа отлично видны все остальные стенды - я решил отдохнуть немного, так как чуток осип полтора часа рассказыаать про исследование. А мне еще через полтора часа вести инженерную дискуссию про влияние AI на разработку:)
1🔥36❤9⚡5👍3😨1
The history of C# and TypeScript with Anders Hejlsberg | GitHub (Рубрика #Software)
Интересное интервью Андерса Хейлсберга, создателя C#, Delphi, Turbo Pascal и ведущего архитектора TypeScript, которое он дал GitHub. Андреас разбирает, как создавались C# и TypeScript и какие компромиссы стояли за решениями и какие принципы помогают языкам и командам "жить долго".
Из получасовго интервью можно почерпнуть много интересного
1️⃣ Быстрый фидбек важнее почти всего
Короткий цикл «написал → сразу понял/проверил» определяет скорость и качество. Поэтому ценность TypeScript - не только в типах, но и в инструментах: подсказки, проверка, рефакторинг, быстрый компилятор.
2️⃣Масштаб требует жертвовать личным идеалом
Когда пользователей и сценариев много, побеждает прагматика: язык успешен, если вписывается в реальную работу команд, а не только в учебник.
3️⃣ Эволюция сильнее революции
TypeScript вырос как надстройка над JavaScript: улучшает поддерживаемость больших проектов, не заставляя «сжигать мосты» и менять экосистему.
4️⃣ Прозрачность ускоряет open source
Публичные PR/issue и обсуждения переводят приоритеты от "внутренних" к реальным потребностям, а решения становятся объяснимыми и проверяемыми.
5️⃣ Иногда нужен рывок в основании без ломки внешнего контракта
Переписывание критического компонента ради производительности имеет смысл, если пользователь не платит ценой совместимости.
6️⃣ Эпоха AI смещает роль инженера
Всё больше кода генерируется, а ценность инструментов - в точности: типы, проверки, тесты и рефакторинг как ограждения от правдоподобных ошибок.
7️⃣ "Память проекта" - это актив
История обсуждений и решений (почему сделали так, а не иначе) снижает повторение ошибок и облегчает онбординг.
Если эти lessons learned превратить в какие-то выводы, то они могу быть такими
Для инженеров
- Инвестируйте в быстрый цикл: локальные проверки, быстрые тесты, линтеры/типы, удобные IDE-инструменты.
- Пишите для "коллективного владения": читаемость, предсказуемость, простые правила важнее личной элегантности.
- Учитесь по контексту решений: обсуждения в issue/PR часто дают больше, чем абстрактные «best practices».
- При работе с AI-кодом усиливайте страховку: типизация + статанализ + тесты, иначе вы просто быстрее генерируете долг.
Для технических руководителей
- Ставьте скорость обратной связи в KPI инженерной системы: CI, тесты, статанализ, быстрые сборки. Медленный фидбек рождает процессы-«костыли».
- Держите баланс интересов: стандарты и совместимость важнее вкуса отдельных сильных инженеров.
- Внедряйте изменения через миграции и совместимость: постепенное улучшение обычно дешевле и надёжнее тотальной замены.
- Стройте институциональную память: ADR/решения, ссылки на обсуждения, понятные причины компромиссов - это снижает риски при росте и текучести.
В общем, долгоживущие технологии и команды выигрывают, когда обеспечивают быстрый фидбек, принимают прагматичные компромиссы, эволюционируют с обратной совместимостью, а также ведут прозрачную историю решений.
#AI #Engineering #Software #Management #Leadership #Startup #LLM #ML #Architecture #RnD
Интересное интервью Андерса Хейлсберга, создателя C#, Delphi, Turbo Pascal и ведущего архитектора TypeScript, которое он дал GitHub. Андреас разбирает, как создавались C# и TypeScript и какие компромиссы стояли за решениями и какие принципы помогают языкам и командам "жить долго".
Из получасовго интервью можно почерпнуть много интересного
1️⃣ Быстрый фидбек важнее почти всего
Короткий цикл «написал → сразу понял/проверил» определяет скорость и качество. Поэтому ценность TypeScript - не только в типах, но и в инструментах: подсказки, проверка, рефакторинг, быстрый компилятор.
2️⃣Масштаб требует жертвовать личным идеалом
Когда пользователей и сценариев много, побеждает прагматика: язык успешен, если вписывается в реальную работу команд, а не только в учебник.
3️⃣ Эволюция сильнее революции
TypeScript вырос как надстройка над JavaScript: улучшает поддерживаемость больших проектов, не заставляя «сжигать мосты» и менять экосистему.
4️⃣ Прозрачность ускоряет open source
Публичные PR/issue и обсуждения переводят приоритеты от "внутренних" к реальным потребностям, а решения становятся объяснимыми и проверяемыми.
5️⃣ Иногда нужен рывок в основании без ломки внешнего контракта
Переписывание критического компонента ради производительности имеет смысл, если пользователь не платит ценой совместимости.
6️⃣ Эпоха AI смещает роль инженера
Всё больше кода генерируется, а ценность инструментов - в точности: типы, проверки, тесты и рефакторинг как ограждения от правдоподобных ошибок.
7️⃣ "Память проекта" - это актив
История обсуждений и решений (почему сделали так, а не иначе) снижает повторение ошибок и облегчает онбординг.
Если эти lessons learned превратить в какие-то выводы, то они могу быть такими
Для инженеров
- Инвестируйте в быстрый цикл: локальные проверки, быстрые тесты, линтеры/типы, удобные IDE-инструменты.
- Пишите для "коллективного владения": читаемость, предсказуемость, простые правила важнее личной элегантности.
- Учитесь по контексту решений: обсуждения в issue/PR часто дают больше, чем абстрактные «best practices».
- При работе с AI-кодом усиливайте страховку: типизация + статанализ + тесты, иначе вы просто быстрее генерируете долг.
Для технических руководителей
- Ставьте скорость обратной связи в KPI инженерной системы: CI, тесты, статанализ, быстрые сборки. Медленный фидбек рождает процессы-«костыли».
- Держите баланс интересов: стандарты и совместимость важнее вкуса отдельных сильных инженеров.
- Внедряйте изменения через миграции и совместимость: постепенное улучшение обычно дешевле и надёжнее тотальной замены.
- Стройте институциональную память: ADR/решения, ссылки на обсуждения, понятные причины компромиссов - это снижает риски при росте и текучести.
В общем, долгоживущие технологии и команды выигрывают, когда обеспечивают быстрый фидбек, принимают прагматичные компромиссы, эволюционируют с обратной совместимостью, а также ведут прозрачную историю решений.
#AI #Engineering #Software #Management #Leadership #Startup #LLM #ML #Architecture #RnD
YouTube
The history of C# and TypeScript with Anders Hejlsberg | GitHub
Anders Hejlsberg is one of the most influential language designers of our time, having created Turbo Pascal, Delphi, C#, and TypeScript. In this interview, he discusses his 40-year career, the early days of open source at Microsoft, and the decision to move…
❤9🔥7⚡1
[1/2] 2026 Agentic Coding Trends Report - How coding agents are reshaping software development (Рубрика #AI)
Anthropic опубликовала любопытный отчёт о ключевых трендах "агентного кодинга" на 2026 год. Этот документ рисует картину того, что разработка всё больше опирается на AI-агентов, которые пишут код, пока люди задают им цели и контролируют результат. Они приводят статистику, что разработчики Anthropic используют AI в 60% задач, хотя полностью доверяют ему лишь 0–20% работы (это из их декабрьской статьи "How AI is transforming work at Anthropic", о которой я уже рассказывал). В новом документе они приводят кейсы и других компаний, который смогли добиться значимых результатов, но все-таки фокус на 8 тенденциях, что сгруппированы в три категории: foundation trends, capability trends, impact trends. Ну и ниже я расскажу про каждый из трендов, а также поделюсь мыслями, а что делать с ними инженерам и руководителям
1️⃣ Foundation trends: The tectonic shift
Trend 1: The software development lifecycle changes dramatically
SDLC остаётся, но цикл сжимается: агент пишет/дебажит/документирует, тесты и мониторинг быстрее замыкают фидбек (недели → часы).
- Инженерам стоит начать прокачивать «оркестрацию» (декомпозиция, постановка задач агенту, критерии приёмки, быстрый ревью).
• CTO стоит пересобрать процесс и метрики (меньше “время на задачу”, больше “качество+output”), и реально использовать “онбординг за часы” для динамического перераспределения людей по продуктам/проектам
2️⃣ Capability trends: What agents can do
Trend 2: Single agents evolve into coordinated teams
Один агент → команда агентов с ролями + оркестратор. Это про параллельную работу и синхронизацию в VCS. Пример из отчёта: multi-agent оркестрация дала Fountain 50% быстрее screening и сократила срок укомплектования нового центра до <72 часов.
- Инженерам надо научиться резать задачи так, чтобы их можно было делать параллельно (и собирать через PR/чеки).
- CTO стоит внедрять паттерны multi-agent (роли, протоколы, правила мержа/ревью для “агентских” изменений).
Trend 3: Long-running agents build complete systems
Агенты работают «долго»: часы → дни/недели. Могут тащить фичу/подсистему целиком, закрывать техдолг, делать “невыгодные руками” улучшения. Пример: Rakuten прогнали Claude Code по задаче в vLLM (12,5 млн строк) - 7 часов автономной работы и 99,9% точности.
- Инженерам пора начать мыслить чекпоинтами (контракты, тесты, инварианты) и строить ограждения, чтобы агент не «уехал».
- CTO стоит подготовить среду для длинных прогонов (sandbox, CI, лимиты, наблюдаемость) и выделить задачи “под агента” (миграции, рефакторинги, чистка бэклога).
Trend 4: Human oversight scales through intelligent collaboration
Ключ в том, чтобы масштабировать контроль. Агенты учатся звать человека, а не молча “дожимать”; AI проверяет AI (security/архитектура/качество), человек смотрит только «что важно».
- Инженерам надо собирать пайплайн “генерация → автопроверки → человек”.
- CTO стоит формализовать уровни риска и эскалации (что агент может сам, что только через человека), инвестировать в автоматизированный ревью/тестирование.
Trend 5: Agentic coding expands to new surfaces and users
Агентный кодинг выходит за IDE: больше языков (включая legacy типа COBOL/Fortran), больше ролей (ops, security, design, DS), больше интерфейсов для не-разработчиков.
- Инженерам пора готовиться к "коду от доменных экспертов" - нужны шаблоны, guardrails, API/платформа, чтобы это было безопасно. Тут можно вспомнить про условный Lovable и приложения, что продакты сгенерировали через него
- CTO надо сознательно открывать агентные инструменты другим отделам, но через песочницы, права доступа и наблюдаемость.
В продолжении я расскажу про последние три тренда из этого интересного отчета.
#AI #Engineering #Software #Management #Leadership #Startup #LLM #ML #Architecture
Anthropic опубликовала любопытный отчёт о ключевых трендах "агентного кодинга" на 2026 год. Этот документ рисует картину того, что разработка всё больше опирается на AI-агентов, которые пишут код, пока люди задают им цели и контролируют результат. Они приводят статистику, что разработчики Anthropic используют AI в 60% задач, хотя полностью доверяют ему лишь 0–20% работы (это из их декабрьской статьи "How AI is transforming work at Anthropic", о которой я уже рассказывал). В новом документе они приводят кейсы и других компаний, который смогли добиться значимых результатов, но все-таки фокус на 8 тенденциях, что сгруппированы в три категории: foundation trends, capability trends, impact trends. Ну и ниже я расскажу про каждый из трендов, а также поделюсь мыслями, а что делать с ними инженерам и руководителям
1️⃣ Foundation trends: The tectonic shift
Trend 1: The software development lifecycle changes dramatically
SDLC остаётся, но цикл сжимается: агент пишет/дебажит/документирует, тесты и мониторинг быстрее замыкают фидбек (недели → часы).
- Инженерам стоит начать прокачивать «оркестрацию» (декомпозиция, постановка задач агенту, критерии приёмки, быстрый ревью).
• CTO стоит пересобрать процесс и метрики (меньше “время на задачу”, больше “качество+output”), и реально использовать “онбординг за часы” для динамического перераспределения людей по продуктам/проектам
2️⃣ Capability trends: What agents can do
Trend 2: Single agents evolve into coordinated teams
Один агент → команда агентов с ролями + оркестратор. Это про параллельную работу и синхронизацию в VCS. Пример из отчёта: multi-agent оркестрация дала Fountain 50% быстрее screening и сократила срок укомплектования нового центра до <72 часов.
- Инженерам надо научиться резать задачи так, чтобы их можно было делать параллельно (и собирать через PR/чеки).
- CTO стоит внедрять паттерны multi-agent (роли, протоколы, правила мержа/ревью для “агентских” изменений).
Trend 3: Long-running agents build complete systems
Агенты работают «долго»: часы → дни/недели. Могут тащить фичу/подсистему целиком, закрывать техдолг, делать “невыгодные руками” улучшения. Пример: Rakuten прогнали Claude Code по задаче в vLLM (12,5 млн строк) - 7 часов автономной работы и 99,9% точности.
- Инженерам пора начать мыслить чекпоинтами (контракты, тесты, инварианты) и строить ограждения, чтобы агент не «уехал».
- CTO стоит подготовить среду для длинных прогонов (sandbox, CI, лимиты, наблюдаемость) и выделить задачи “под агента” (миграции, рефакторинги, чистка бэклога).
Trend 4: Human oversight scales through intelligent collaboration
Ключ в том, чтобы масштабировать контроль. Агенты учатся звать человека, а не молча “дожимать”; AI проверяет AI (security/архитектура/качество), человек смотрит только «что важно».
- Инженерам надо собирать пайплайн “генерация → автопроверки → человек”.
- CTO стоит формализовать уровни риска и эскалации (что агент может сам, что только через человека), инвестировать в автоматизированный ревью/тестирование.
Trend 5: Agentic coding expands to new surfaces and users
Агентный кодинг выходит за IDE: больше языков (включая legacy типа COBOL/Fortran), больше ролей (ops, security, design, DS), больше интерфейсов для не-разработчиков.
- Инженерам пора готовиться к "коду от доменных экспертов" - нужны шаблоны, guardrails, API/платформа, чтобы это было безопасно. Тут можно вспомнить про условный Lovable и приложения, что продакты сгенерировали через него
- CTO надо сознательно открывать агентные инструменты другим отделам, но через песочницы, права доступа и наблюдаемость.
В продолжении я расскажу про последние три тренда из этого интересного отчета.
#AI #Engineering #Software #Management #Leadership #Startup #LLM #ML #Architecture
1👍14❤9🔥5
[2/2] 2026 Agentic Coding Trends Report - How coding agents are reshaping software development (Рубрика #AI)
В этом посте мы закончим разбирать короткий trend-report Anthropic, который задает фокус того, что стоит делать в 2026 году нам как инженерам и руководителям, чтобы не отстать от стремительно меняющейся индустрии разработки софта.
3️⃣ Impact trends: What agents may change in 2026
Trend 6: Productivity gains reshape software development economics
Эффект - не только "быстрее", но "больше": растёт объём shipped-результата, появляется работа, которую раньше бы не делали (в отчёте ~27% AI-задач - “не сделали бы иначе”). TELUS, например, сделали 13k внутренних AI-решений и ускорили shipping кода на 30%, сэкономив 500k+ часов.
- Инженерам надо пересмотреть приоритеты - закрывать техдолг и “papercuts” становится выгодно.
• CTO стоит ожидать “взрыва output” и заранее ставить рамки качества, иначе скорость съест поддерживаемость.
Trend 7: Non-technical use cases expand across organizations
Неинженерные команды начинают автоматизировать процессы сами: меньше тикетов в разработку, больше локальных “мини-продуктов”. Zapier в отчёте - 89% adoption и 800+ внутренних агентов; у Anthropic юристы сократили маркетинг-ревью до 24 часов, причём self-service инструменты собрал юрист без опыта кодинга.
- Инженерам надо помогать через внутренние библиотеки/коннекторы/примеры, а не “делать за всех”.
- CTO пора строить governance для citizen devevelopers (что можно автоматизировать, где хранятся секреты, кто отвечает за поддержку).
Trend 8: Dual-use risk requires security-first architecture
Агентный кодинг усиливает и защиту, и атаки. Любой инженер может делать security-review с агентом - и любой атакующий тоже масштабирует свои попытки.
- Инженерам надо двигать практики безопасности: “least privilege” для инструментов агента, изоляция, журналирование, защита от инъекций/подмены контекста.
- CTO надо идти в security by design агентных систем (права, контуры, аудит, red teaming) до того, как агенты получат доступ к продовым данным/деплою.
Если свести отчёт к одному тезису: выиграют команды, которые научатся
- Ууправлять несколькими агентами
- Масштабировать контроль качества
- Безопасно расширить агентные инструменты за пределы инженерии
#AI #Engineering #Software #Management #Leadership #Startup #LLM #ML #Architecture
В этом посте мы закончим разбирать короткий trend-report Anthropic, который задает фокус того, что стоит делать в 2026 году нам как инженерам и руководителям, чтобы не отстать от стремительно меняющейся индустрии разработки софта.
3️⃣ Impact trends: What agents may change in 2026
Trend 6: Productivity gains reshape software development economics
Эффект - не только "быстрее", но "больше": растёт объём shipped-результата, появляется работа, которую раньше бы не делали (в отчёте ~27% AI-задач - “не сделали бы иначе”). TELUS, например, сделали 13k внутренних AI-решений и ускорили shipping кода на 30%, сэкономив 500k+ часов.
- Инженерам надо пересмотреть приоритеты - закрывать техдолг и “papercuts” становится выгодно.
• CTO стоит ожидать “взрыва output” и заранее ставить рамки качества, иначе скорость съест поддерживаемость.
Trend 7: Non-technical use cases expand across organizations
Неинженерные команды начинают автоматизировать процессы сами: меньше тикетов в разработку, больше локальных “мини-продуктов”. Zapier в отчёте - 89% adoption и 800+ внутренних агентов; у Anthropic юристы сократили маркетинг-ревью до 24 часов, причём self-service инструменты собрал юрист без опыта кодинга.
- Инженерам надо помогать через внутренние библиотеки/коннекторы/примеры, а не “делать за всех”.
- CTO пора строить governance для citizen devevelopers (что можно автоматизировать, где хранятся секреты, кто отвечает за поддержку).
Trend 8: Dual-use risk requires security-first architecture
Агентный кодинг усиливает и защиту, и атаки. Любой инженер может делать security-review с агентом - и любой атакующий тоже масштабирует свои попытки.
- Инженерам надо двигать практики безопасности: “least privilege” для инструментов агента, изоляция, журналирование, защита от инъекций/подмены контекста.
- CTO надо идти в security by design агентных систем (права, контуры, аудит, red teaming) до того, как агенты получат доступ к продовым данным/деплою.
Если свести отчёт к одному тезису: выиграют команды, которые научатся
- Ууправлять несколькими агентами
- Масштабировать контроль качества
- Безопасно расширить агентные инструменты за пределы инженерии
#AI #Engineering #Software #Management #Leadership #Startup #LLM #ML #Architecture
Telegram
Книжный куб
[1/2] 2026 Agentic Coding Trends Report - How coding agents are reshaping software development (Рубрика #AI)
Anthropic опубликовала любопытный отчёт о ключевых трендах "агентного кодинга" на 2026 год. Этот документ рисует картину того, что разработка всё…
Anthropic опубликовала любопытный отчёт о ключевых трендах "агентного кодинга" на 2026 год. Этот документ рисует картину того, что разработка всё…
👍11❤4👎1🔥1
Путешествие в Лондон (Рубрика #Travel)
Через пару недель мы с женой сгоняем на недельку в Лондон, где мы побываем впервые:) Когда я начинал учить английский в школе в Северодвинске и проговаривал "London is the capital of Great Britain" я и представить не мог, что когда-то поеду в этот самый London. Правда, сейчас путешествия уже стали рутиной, но я попросил жену добавить в нашу поездку посещение Блетчли-парка, где в период Второй мировой войны в Блетчли-парке располагалось главное шифровальное подразделение Великобритании, а сейчас там расположен Национальный музей компьютеров. Все остальные достопримечательности подбирала моя жена, которой я верю больше чем себе в вопросе планирования досуга:) А ближе к концу апреля мы поедем в Лондон уже с детишками, благо UK - это не Португалия, а значит дает нормальные визы (на полгода).
В общем, я уже предвкушаю интересную поездку:)
P.S.
Если кто 28 февраля будет в Лондоне и захочет пообщаться, то пишите в личку - мы выделили это воскресенье под встречи со своими знакомыми, кого сложно встретить в Москве:)
#Travel #Software #Engineering #History
Через пару недель мы с женой сгоняем на недельку в Лондон, где мы побываем впервые:) Когда я начинал учить английский в школе в Северодвинске и проговаривал "London is the capital of Great Britain" я и представить не мог, что когда-то поеду в этот самый London. Правда, сейчас путешествия уже стали рутиной, но я попросил жену добавить в нашу поездку посещение Блетчли-парка, где в период Второй мировой войны в Блетчли-парке располагалось главное шифровальное подразделение Великобритании, а сейчас там расположен Национальный музей компьютеров. Все остальные достопримечательности подбирала моя жена, которой я верю больше чем себе в вопросе планирования досуга:) А ближе к концу апреля мы поедем в Лондон уже с детишками, благо UK - это не Португалия, а значит дает нормальные визы (на полгода).
В общем, я уже предвкушаю интересную поездку:)
P.S.
Если кто 28 февраля будет в Лондоне и захочет пообщаться, то пишите в личку - мы выделили это воскресенье под встречи со своими знакомыми, кого сложно встретить в Москве:)
#Travel #Software #Engineering #History
1🔥29❤10👍3👎1🌚1
Interview with ‘Just use a VPS’ bro (OpenClaw version) (Рубрика #AI)
Я давно так не смеялся, как с этого видео:) С учетом того, что я сам люблю возиться с Linux, то юмор попал в точку - раньше приходилось читать мануалы, а сейчас мне с этими настройками помогают всякие perplexity. В этом видео высмеивается стереотипный "сисадмина-параноик" и культура селфхостинга (self-hosting). Юмор строится на контрасте между простым желанием пользователя ("Я просто хочу запустить AI-агента") и безумно сложным, перегруженным инструктажем от "VPS-бро", для которого "просто" означает полноценную настройку Linux-сервера с нуля. В конце, когда пользователь отчаивается и просит сменить агента, что ему помогает, появляется новый "консультант", который начинает затирать про AWS EC2, Security Groups и Kubernetes. Шутка в том, что убегая от сложности Linux пользователь проваливается еще глубже в кроличью нору (прямо как Алиса).
В общем, автор этого канала просто топ, рекомендую его всем знакомым айтишникам:)
#Humor #Engineering #Software #AI #DevOps #DevEx
Я давно так не смеялся, как с этого видео:) С учетом того, что я сам люблю возиться с Linux, то юмор попал в точку - раньше приходилось читать мануалы, а сейчас мне с этими настройками помогают всякие perplexity. В этом видео высмеивается стереотипный "сисадмина-параноик" и культура селфхостинга (self-hosting). Юмор строится на контрасте между простым желанием пользователя ("Я просто хочу запустить AI-агента") и безумно сложным, перегруженным инструктажем от "VPS-бро", для которого "просто" означает полноценную настройку Linux-сервера с нуля. В конце, когда пользователь отчаивается и просит сменить агента, что ему помогает, появляется новый "консультант", который начинает затирать про AWS EC2, Security Groups и Kubernetes. Шутка в том, что убегая от сложности Linux пользователь проваливается еще глубже в кроличью нору (прямо как Алиса).
В общем, автор этого канала просто топ, рекомендую его всем знакомым айтишникам:)
#Humor #Engineering #Software #AI #DevOps #DevEx
YouTube
Interview with ‘Just use a VPS’ bro (OpenClaw version).
Just use a VPS bro…
Interview with a VPS bro with Jack Borrough - aired on © The VPS.
Music: Paramore - Emergency
Openclaw installation guide
Linux server installation guide
OpenClaw VPS setup
Next-gen ai
Anthropic Claude
Linux server setup
Programming…
Interview with a VPS bro with Jack Borrough - aired on © The VPS.
Music: Paramore - Emergency
Openclaw installation guide
Linux server installation guide
OpenClaw VPS setup
Next-gen ai
Anthropic Claude
Linux server setup
Programming…
😁18❤2🔥1🤯1
Liam Wong: TO:KY:00 (Рубрика #Culture)
Прекрасная книга с фотографиями Лиама Вонга, который был арт-директором в Ubisoft, ездил по миру и в какой-то момент увлекся фотографией и стал профессионалом в ней. В этой книге представлена его серия робот о Токио, что предстает перед нами в антураже киберпанка Ридли Скота, что мы увидели в "Бегущем по лезвию". А сам бегущий был экранизацией книги "Мечтают ли андроиды об электроовцах" Филиппа Киндреда Дика, одного из моих любимых фантастов. В общем, я листал эту книгу Лиама с большим удовольствием, чего и вам рекомендую!
Прекрасная книга с фотографиями Лиама Вонга, который был арт-директором в Ubisoft, ездил по миру и в какой-то момент увлекся фотографией и стал профессионалом в ней. В этой книге представлена его серия робот о Токио, что предстает перед нами в антураже киберпанка Ридли Скота, что мы увидели в "Бегущем по лезвию". А сам бегущий был экранизацией книги "Мечтают ли андроиды об электроовцах" Филиппа Киндреда Дика, одного из моих любимых фантастов. В общем, я листал эту книгу Лиама с большим удовольствием, чего и вам рекомендую!
1🔥19❤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❤6⚡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🔥58❤11⚡3