System-Design.Space (Update) (Рубрика #SystemDEsing)
В последние недели я не останавливался с доработками своего сайта system-design.space. И сегодня я решил поделиться тремя ключевыми изменениями
1) Я поменял дизайн главной страницы, чтобы прямо на ней был блок с онбордингом и описанием всех возможностей доступных на сайте:
- Выбор трека изучения
- Изучения графа знаний
- Доступ на страницу со всеми материалами с поиском и фильтрацией по ним
Надеюсь, что теперь сайт станет понятнее и удобнее для пользователей, а то я посмотрел ряд сессий из Яндекс Метрики, где пользователи попадали на сайт и как будто не могли понять а что на нем есть и дальше просто уходили
2) Теперь в каждой главе в начале есть блок, в котором рассказывается о чем глава, почему это полезно для проектирования систем, а также как эти знания можно использовать на интервью - это моя попытка объяснить почему главу стоит прочитать. Если вы по описанию видите, что глава вам не особо полезна или интересна, то сразу можно пролистнуть на следующую
3) Я сам устал от артефактов в мобильной верстке, поэтому мы с OpenAI Codex написали скрипты для e2e тестов layouts в десктопном и мобильном режиме и поправили 90+ проблемных глав. Теперь на мобилке должно быть гораздо приятнее изучать этот сайт.
Было еще какое-то количество небольших изменений, но эти показались мне достойными упоминания.
#SystemDesign #Architecture #Software #DistributedSystems #UX #Interview
В последние недели я не останавливался с доработками своего сайта system-design.space. И сегодня я решил поделиться тремя ключевыми изменениями
1) Я поменял дизайн главной страницы, чтобы прямо на ней был блок с онбордингом и описанием всех возможностей доступных на сайте:
- Выбор трека изучения
- Изучения графа знаний
- Доступ на страницу со всеми материалами с поиском и фильтрацией по ним
Надеюсь, что теперь сайт станет понятнее и удобнее для пользователей, а то я посмотрел ряд сессий из Яндекс Метрики, где пользователи попадали на сайт и как будто не могли понять а что на нем есть и дальше просто уходили
2) Теперь в каждой главе в начале есть блок, в котором рассказывается о чем глава, почему это полезно для проектирования систем, а также как эти знания можно использовать на интервью - это моя попытка объяснить почему главу стоит прочитать. Если вы по описанию видите, что глава вам не особо полезна или интересна, то сразу можно пролистнуть на следующую
3) Я сам устал от артефактов в мобильной верстке, поэтому мы с OpenAI Codex написали скрипты для e2e тестов layouts в десктопном и мобильном режиме и поправили 90+ проблемных глав. Теперь на мобилке должно быть гораздо приятнее изучать этот сайт.
Было еще какое-то количество небольших изменений, но эти показались мне достойными упоминания.
#SystemDesign #Architecture #Software #DistributedSystems #UX #Interview
2🔥52❤11⚡3
GitHub будем учить свои модели на поведенческих данных пользователей (Рубрика #AI)
GitHub обновил правила для Copilot: с 24 апреля 2026 данные взаимодействия пользователей Free / Pro / Pro+ можно использовать для обучения AI-моделей по умолчанию, если это не отключить вручную. Причем речь идет не просто про prompts, ни и про остальную информацию: ответы Copilot, куски кода, комментарии и другой контекст, который пользователь отправляет в Copilot во время сессии. Причем содержимое приватного репозитория само по себе GitHub обещает не брать в обучение, но фрагменты приветного кода, которые вы сами отправили в Copilot, - уже другой случай. Старые настройки по отключению шаринга такой информации GitHub обещает сохранить.
Для небольших команд и отдельных рзаработчиков это неприятный сдвиг в дефолтных настройках приватности. Особенность в том, что если разработчик использует личный Copilot-аккаунт в рабочем репозитории, часть рабочего контекста потенциально становится тренировочными данными. А значит личная подписка Copilot больше не выглядит нейтральным вариантом для работы с чувствительным кодом, внутренними API, названиями сервисов, инцидентами, архитектурными заметками и т.д.
Для крупных корпораций сейчас ниже: GitHub отдельно выводит такие аккаунты и использование внутри организаций из обучения моделей в корпоративном контуре.
Но проблема никуда не исчезает - она смещается в теневое использование:
- сотрудники с личными Pro-аккаунтами,
- подрядчики вне корпоративного контура,
- сценарии личный аккаунт + рабочий репозиторий,
- отсутствие явной политики, что можно и нельзя отправлять в AI-ассистенты.
В общем, для больших компаний это проблема управления и повод пересмотреть границы разрешенного инструментария.
Список мер может быть примерно таким:
1. Проверить, кто и на каких планах использует Copilot
2. Для рабочей разработки по возможности переводить команды на Business / Enterprise
3. Явно запретить личные AI-аккаунты в продовых и чувствительных репозиториях
4. Обновить vendor/privacy ревью: что считается данными взаимодействия, где opt-out из программы отгрузки телеметрии, что покрывает DPA (data processing agreement)
5. Зашить это в IDP/SSO/policy уровень: согласованные инструменты, обучение для инженеров
В итоге, видно, что AI рынок сильнее сдвигается в сторону разделения
Скорее да. Рынок AI все сильнее делится на две модели:
- consumer/self-serve продукты учатся на пользовательских взаимодействиях,
- enterprise продукты продают privacy и no-training как часть контракта.
#AI #Engineering #Software #Productivity #DevEx
GitHub обновил правила для Copilot: с 24 апреля 2026 данные взаимодействия пользователей Free / Pro / Pro+ можно использовать для обучения AI-моделей по умолчанию, если это не отключить вручную. Причем речь идет не просто про prompts, ни и про остальную информацию: ответы Copilot, куски кода, комментарии и другой контекст, который пользователь отправляет в Copilot во время сессии. Причем содержимое приватного репозитория само по себе GitHub обещает не брать в обучение, но фрагменты приветного кода, которые вы сами отправили в Copilot, - уже другой случай. Старые настройки по отключению шаринга такой информации GitHub обещает сохранить.
Для небольших команд и отдельных рзаработчиков это неприятный сдвиг в дефолтных настройках приватности. Особенность в том, что если разработчик использует личный Copilot-аккаунт в рабочем репозитории, часть рабочего контекста потенциально становится тренировочными данными. А значит личная подписка Copilot больше не выглядит нейтральным вариантом для работы с чувствительным кодом, внутренними API, названиями сервисов, инцидентами, архитектурными заметками и т.д.
Для крупных корпораций сейчас ниже: GitHub отдельно выводит такие аккаунты и использование внутри организаций из обучения моделей в корпоративном контуре.
Но проблема никуда не исчезает - она смещается в теневое использование:
- сотрудники с личными Pro-аккаунтами,
- подрядчики вне корпоративного контура,
- сценарии личный аккаунт + рабочий репозиторий,
- отсутствие явной политики, что можно и нельзя отправлять в AI-ассистенты.
В общем, для больших компаний это проблема управления и повод пересмотреть границы разрешенного инструментария.
Список мер может быть примерно таким:
1. Проверить, кто и на каких планах использует Copilot
2. Для рабочей разработки по возможности переводить команды на Business / Enterprise
3. Явно запретить личные AI-аккаунты в продовых и чувствительных репозиториях
4. Обновить vendor/privacy ревью: что считается данными взаимодействия, где opt-out из программы отгрузки телеметрии, что покрывает DPA (data processing agreement)
5. Зашить это в IDP/SSO/policy уровень: согласованные инструменты, обучение для инженеров
В итоге, видно, что AI рынок сильнее сдвигается в сторону разделения
Скорее да. Рынок AI все сильнее делится на две модели:
- consumer/self-serve продукты учатся на пользовательских взаимодействиях,
- enterprise продукты продают privacy и no-training как часть контракта.
#AI #Engineering #Software #Productivity #DevEx
The GitHub Blog
Updates to our Privacy Statement and Terms of Service: How we use your data - GitHub Changelog
Hey GitHub Community, We’ve made some important updates to our Privacy Statement and Terms of Service to keep you informed about how we handle your data. Notably, from April 24…
❤6👍2🗿2🔥1
Как бигтехи планируют внедрять AI-native разработку у себя в 2026 году (Рубрика #Management)
В предыдущих текстах этой серии я писал, что индустрия движется от классического PDLC к AI-native разработке, а затем — к AI-native организации. В этой статье я планировал рассмотреть подходы бигтехов к организации этого перехода и постановке целей внутри организации, а также измерения результатов.
По публичным сигналам Microsoft, GitHub, Google, Amazon, Meta, Uber, Stripe и Netflix видно, что AI становится полноценным слоем инженерной операционной модели. Он встраивается в PR (pull requests), ревью кода, тестирование, миграции, триаж багов, CI/CD пайпланы и все чаще — в агентские workflow, где система не только подсказывает, но и выполняет bounded task под контролем человека.
Мерить этот переход они тоже начинают по-новому: не одной метрикой usage, которая была популярна в прошлом, а целой цепочкой adoption → throughput → quality/risk → economics. Именно эта связка постепенно становится новым языком для технических топ-менеджеров и платформенных команд. Эта четверка выглядит примерно так
1) Adoption. Насколько AI вообще вошел в повседневный контур работы, сколько активных пользователей, каков adoption агентов, как распределено использование по командам, IDE, CLI и workflow.
2) Throughput. Сократились ли cycle time на PR и ревью, что произошло с time to merge, ускорился ли путь от первого коммита до открытого PR, выросла ли инженерная velocity.
3) Quality/risk. Что происходит с полезными комментариями, обратной связью, предотвращением дефектов, обработкой дубликатов ошибок, эффективностью тестирования и частотой инцидентов (это контр-балансирующие метрики относительно скорости и througput)
4 )Economics. Сколько сэкономили часов на конкретных джобах, человеко-лет спасено при миграциях, какое значение у CTS-SW (cost to serve software от AWS), какое ROI и какова стоимость масштабирования всего этого слоя AI.
Именно такая связка всё чаще просматривается в официальных материалах GitHub, Google, AWS, Uber и Amazon..
#AI #Management #Future #Software #Engineering #Productivity #Agents #Processes
В предыдущих текстах этой серии я писал, что индустрия движется от классического PDLC к AI-native разработке, а затем — к AI-native организации. В этой статье я планировал рассмотреть подходы бигтехов к организации этого перехода и постановке целей внутри организации, а также измерения результатов.
По публичным сигналам Microsoft, GitHub, Google, Amazon, Meta, Uber, Stripe и Netflix видно, что AI становится полноценным слоем инженерной операционной модели. Он встраивается в PR (pull requests), ревью кода, тестирование, миграции, триаж багов, CI/CD пайпланы и все чаще — в агентские workflow, где система не только подсказывает, но и выполняет bounded task под контролем человека.
Мерить этот переход они тоже начинают по-новому: не одной метрикой usage, которая была популярна в прошлом, а целой цепочкой adoption → throughput → quality/risk → economics. Именно эта связка постепенно становится новым языком для технических топ-менеджеров и платформенных команд. Эта четверка выглядит примерно так
1) Adoption. Насколько AI вообще вошел в повседневный контур работы, сколько активных пользователей, каков adoption агентов, как распределено использование по командам, IDE, CLI и workflow.
2) Throughput. Сократились ли cycle time на PR и ревью, что произошло с time to merge, ускорился ли путь от первого коммита до открытого PR, выросла ли инженерная velocity.
3) Quality/risk. Что происходит с полезными комментариями, обратной связью, предотвращением дефектов, обработкой дубликатов ошибок, эффективностью тестирования и частотой инцидентов (это контр-балансирующие метрики относительно скорости и througput)
4 )Economics. Сколько сэкономили часов на конкретных джобах, человеко-лет спасено при миграциях, какое значение у CTS-SW (cost to serve software от AWS), какое ROI и какова стоимость масштабирования всего этого слоя AI.
Именно такая связка всё чаще просматривается в официальных материалах GitHub, Google, AWS, Uber и Amazon..
#AI #Management #Future #Software #Engineering #Productivity #Agents #Processes
Medium
Как бигтехи планируют внедрять AI-native разработку у себя в 2026 году
В предыдущих текстах этой серии я писал, что индустрия движется от классического PDLC к AI-native разработке, а затем — к AI-native…
👍8🔥6❤4👎1
The programming language after Kotlin – with the creator of Kotlin (Рубрика #Engineering)
Очередной интересный выпуск "The Pragmatic Engineer" на этот раз с Андреем Бреславом, создателем Kotlin и основателем CodeSpeak, в котором Гергели Орош обсуждает с Андреем как появляются и приходят к успеху инженерные платформы и языки - через правильное время для появления, компромиссы, важность инструментария, совместимость с экосистемой и ясное понимание, что должен делать человек, а что - машина.
Если кратко описать содержимое, то ключевые вопросы и ответы звучат так
1. Почему Kotlin вообще появился
2. Как принимаются языковые компромиссы
3. Почему Java interoperability стала не просто технической деталью, а стратегией успеха Kotlin
4. Как Android неожиданно стал важным ускорителем для Kotlin
5. Что сейчас происходит в рзаработке во время LLM эры
Основные инсайты:
1. Лучшие инженерные решения побеждают не из-за "красоты", а потому что попадают в реальную боль рынка. Kotlin выстрелил не в вакууме: он появился в момент, когда Java тормозила, а разработчикам нужен был более удобный язык без разрыва с существующей экосистемой.
2. Tooling важнее, чем многие думают. Первая версия Kotlin была не компилятором, а IDE-плагином. Сначала язык сделали демонстрируемым и удобным в среде разработчика, а уже потом дотягивали execution path. Это хороший урок для любых platform teams и внутренних developer tools.
3. Дизайн платформы - это управление необратимостью. В Kotlin есть красивые решения вроде smart casts, за которыми скрывается сложная логика компилятора, а есть и сожаления вроде отказа от ternary operator, который позже уже нельзя было аккуратно вернуть. Для техлидов это напоминание: ранние API- и platform-решения цементируются быстрее, чем кажется.
4. Совместимость - это не компромисс второго сорта, а стратегия дистрибуции. Ставка на двустороннюю совместимость с Java и готовность работать в существующих ограничениях экосистемы оказались важнее, чем попытка сделать идеальный "язык с нуля". Android-поворот только усилил этот эффект
5. В эпоху LLM ценность инженера смещается выше по стеку абстракций: от написания каждой строки к описанию intent, ограничений, тестов и гейтов качества. CodeSpeak строится вокруг идеи "поддерживать спецификации, а не код", а сам Бреслав отдельно подчеркивает, что работа с AI coding tools - это навык, которому можно учиться. Он также ожидает новый виток специализированных, agent-first IDE.
В общем, это был интересный подкаст, который только краем задевал тему AI, что теперь редкость в моем плейлисте:)
#SystemDesign #Engineering #Leadership #Architecture #AI #Software #DevEx
Очередной интересный выпуск "The Pragmatic Engineer" на этот раз с Андреем Бреславом, создателем Kotlin и основателем CodeSpeak, в котором Гергели Орош обсуждает с Андреем как появляются и приходят к успеху инженерные платформы и языки - через правильное время для появления, компромиссы, важность инструментария, совместимость с экосистемой и ясное понимание, что должен делать человек, а что - машина.
Если кратко описать содержимое, то ключевые вопросы и ответы звучат так
1. Почему Kotlin вообще появился
2. Как принимаются языковые компромиссы
3. Почему Java interoperability стала не просто технической деталью, а стратегией успеха Kotlin
4. Как Android неожиданно стал важным ускорителем для Kotlin
5. Что сейчас происходит в рзаработке во время LLM эры
Основные инсайты:
1. Лучшие инженерные решения побеждают не из-за "красоты", а потому что попадают в реальную боль рынка. Kotlin выстрелил не в вакууме: он появился в момент, когда Java тормозила, а разработчикам нужен был более удобный язык без разрыва с существующей экосистемой.
2. Tooling важнее, чем многие думают. Первая версия Kotlin была не компилятором, а IDE-плагином. Сначала язык сделали демонстрируемым и удобным в среде разработчика, а уже потом дотягивали execution path. Это хороший урок для любых platform teams и внутренних developer tools.
3. Дизайн платформы - это управление необратимостью. В Kotlin есть красивые решения вроде smart casts, за которыми скрывается сложная логика компилятора, а есть и сожаления вроде отказа от ternary operator, который позже уже нельзя было аккуратно вернуть. Для техлидов это напоминание: ранние API- и platform-решения цементируются быстрее, чем кажется.
4. Совместимость - это не компромисс второго сорта, а стратегия дистрибуции. Ставка на двустороннюю совместимость с Java и готовность работать в существующих ограничениях экосистемы оказались важнее, чем попытка сделать идеальный "язык с нуля". Android-поворот только усилил этот эффект
5. В эпоху LLM ценность инженера смещается выше по стеку абстракций: от написания каждой строки к описанию intent, ограничений, тестов и гейтов качества. CodeSpeak строится вокруг идеи "поддерживать спецификации, а не код", а сам Бреслав отдельно подчеркивает, что работа с AI coding tools - это навык, которому можно учиться. Он также ожидает новый виток специализированных, agent-first IDE.
В общем, это был интересный подкаст, который только краем задевал тему AI, что теперь редкость в моем плейлисте:)
#SystemDesign #Engineering #Leadership #Architecture #AI #Software #DevEx
YouTube
The programming language after Kotlin – with the creator of Kotlin
Andrey Breslav is the creator of Kotlin and the founder of CodeSpeak, a new programming language that aims to reduce boilerplate by replacing trivial code with concise, plain-English descriptions. He led Kotlin’s design at JetBrains through its early releases…
❤8🔥4👍2👌1
Какие темы вам больше отзываются на этом канале
Anonymous Poll
59%
AI в разработке
70%
System Design и проектирование
48%
Engineering Management
32%
Управление продуктом (теперь я и этим занимаюсь)
38%
Книги и наупоп
Я решил устроить небольшой опрос ^ , чтобы понять какие материалы вам больше нравятся на канале. Я постараюсь учесть ваше мнение и подкорректировать плотность постов в нужную сторону. И спасибо вам, что подписаны и читаете канал.
❤24👍8🔥7
State of AI4SDLC на DevOpsConf 2026 (Рубрика #DevOps)
Завтра я открываю конференцию DevOpsConf первым докладом в главном зале и расскажу про наше исследование AI4SDLC, а также что это значит для нас как инженеров, занимающихся разработкой и поставкой софта в продакшен. Я расскажу про то, как выглядят новые процессы разработки, а также про то, как их внедряют в зарубежных бигтехах, а также как действуем мы в Т-Банке.
Вообще мое выступление будет состоять из следующих частей
1️⃣ Как себя чувствует индустрия
Здесь я расскажу про наше исследование AI4SDLC, которое мы проводили в конце прошлого года и которое состояло из мета-исследования и опроса в котором поучаствовала примерно тысяча респондентов со всей России. Мы хотели ответить на вопросы
- В каких задачах разработки AI используется чаще всего, а где остаётся редким?
- Как соотносятся изменения продуктивности и качества (опросы, телеметрия, эксперименты)?
- Как доверие к AI-коду связано с практиками проверки (ревью, тесты, quality gates)?
- Какие элементы процесса превращают индивидуальный эффект в командный?
Сами результаты доступны здесь
2️⃣ От классического PDLC к AI-native-разработке
Здесь я расскажу про сдвиг индустрии от классических процессов к AI-native, как это выглядит и почему происходит. Здесь я поделюсь сигналами от западных бигтех компаний, а также расскажу как мы идем примерно в эту же сторону. На эту тему у меня есть подробная статья на моем сайте tellmeabout.tech.
3️⃣ От AI-native-разработки к AI-native-организации
Здесь я расскажу о том, как вслед за процессами разработки начинает меняться и огрдизайн компаний. Тут опять будут сигналы от западных бигтех компаний + размышления о том, почему так происходит, какие преимущества дает и какие вопросы при этом требуется решить. На эту тему у меня есть подробная статья на моем сайте tellmeabout.tech.
4️⃣ От классического task management к AI-native: как меняется сама единица работы. Тут я расскажу про подходы Atlassian и Linear, которые практикуют разные подходы к управлению задачами и являются лидерами рынка для корпораций и стартапов соответственно. На эту тему у меня есть подробная статья на моем сайте tellmeabout.tech.
5️⃣ Как бигтехи планируют внедрять AI-native разработку у себя в 2026 году. Тут я расскажу про то, как бигтехи подходят к организации этого перехода и постановке целей внутри организации, а также как они планируют измерять результат. На эту тему у меня есть подробная статья на моем сайте tellmeabout.tech.
P.S.
У нас есть отдельный сайт ai4sdlc.tbank.ru про наши AI решения для разработки. И мы их не только используем внутри, но и продаем крупным компаниям.
P.P.S.
Если будете очно на кофне, то можете поймать меня и пообщаться.
#AI #Management #Future #Software #Engineering #Productivity #Agents #Processes
Завтра я открываю конференцию DevOpsConf первым докладом в главном зале и расскажу про наше исследование AI4SDLC, а также что это значит для нас как инженеров, занимающихся разработкой и поставкой софта в продакшен. Я расскажу про то, как выглядят новые процессы разработки, а также про то, как их внедряют в зарубежных бигтехах, а также как действуем мы в Т-Банке.
Вообще мое выступление будет состоять из следующих частей
1️⃣ Как себя чувствует индустрия
Здесь я расскажу про наше исследование AI4SDLC, которое мы проводили в конце прошлого года и которое состояло из мета-исследования и опроса в котором поучаствовала примерно тысяча респондентов со всей России. Мы хотели ответить на вопросы
- В каких задачах разработки AI используется чаще всего, а где остаётся редким?
- Как соотносятся изменения продуктивности и качества (опросы, телеметрия, эксперименты)?
- Как доверие к AI-коду связано с практиками проверки (ревью, тесты, quality gates)?
- Какие элементы процесса превращают индивидуальный эффект в командный?
Сами результаты доступны здесь
2️⃣ От классического PDLC к AI-native-разработке
Здесь я расскажу про сдвиг индустрии от классических процессов к AI-native, как это выглядит и почему происходит. Здесь я поделюсь сигналами от западных бигтех компаний, а также расскажу как мы идем примерно в эту же сторону. На эту тему у меня есть подробная статья на моем сайте tellmeabout.tech.
3️⃣ От AI-native-разработки к AI-native-организации
Здесь я расскажу о том, как вслед за процессами разработки начинает меняться и огрдизайн компаний. Тут опять будут сигналы от западных бигтех компаний + размышления о том, почему так происходит, какие преимущества дает и какие вопросы при этом требуется решить. На эту тему у меня есть подробная статья на моем сайте tellmeabout.tech.
4️⃣ От классического task management к AI-native: как меняется сама единица работы. Тут я расскажу про подходы Atlassian и Linear, которые практикуют разные подходы к управлению задачами и являются лидерами рынка для корпораций и стартапов соответственно. На эту тему у меня есть подробная статья на моем сайте tellmeabout.tech.
5️⃣ Как бигтехи планируют внедрять AI-native разработку у себя в 2026 году. Тут я расскажу про то, как бигтехи подходят к организации этого перехода и постановке целей внутри организации, а также как они планируют измерять результат. На эту тему у меня есть подробная статья на моем сайте tellmeabout.tech.
P.S.
У нас есть отдельный сайт ai4sdlc.tbank.ru про наши AI решения для разработки. И мы их не только используем внутри, но и продаем крупным компаниям.
P.P.S.
Если будете очно на кофне, то можете поймать меня и пообщаться.
#AI #Management #Future #Software #Engineering #Productivity #Agents #Processes
1🔥13👏3❤2
Как AI меняет инженерную культуру / Александр Поломодов (Рубрика #Engineering)
Появилась запись моего выступления на конференции Dream Teamlead, что устраивал Yandex в прошлую субботу. Я уже рассказывал про него, но кратко в нем было 4 темы
1) Как себя чувствует индустрия разработки софта в эру AI - тут анализ основан на нашем исследовании AI4SDLC 2025
2) Как мы движемся от классического PDLC к AI-native-разработке (у меня есть статья на эту тему)
3) Как AI-native-разработка приводит к AI-native-организации (у меня есть статья на эту тему)
4) Как меняется роль тимлида в такой организации (так как выступал на конференции для тимлидов, то надо было поговорить о том, а что эти изменения значат для них)
#AI #Management #Future #Software #Engineering #Productivity #Agents #Processes
Появилась запись моего выступления на конференции Dream Teamlead, что устраивал Yandex в прошлую субботу. Я уже рассказывал про него, но кратко в нем было 4 темы
1) Как себя чувствует индустрия разработки софта в эру AI - тут анализ основан на нашем исследовании AI4SDLC 2025
2) Как мы движемся от классического PDLC к AI-native-разработке (у меня есть статья на эту тему)
3) Как AI-native-разработка приводит к AI-native-организации (у меня есть статья на эту тему)
4) Как меняется роль тимлида в такой организации (так как выступал на конференции для тимлидов, то надо было поговорить о том, а что эти изменения значат для них)
#AI #Management #Future #Software #Engineering #Productivity #Agents #Processes
YouTube
Как AI меняет инженерную культуру / Александр Поломодов
В своём докладе на Dream → Teamlead Александр Поломодов, Technical Director & Fellow, отвечающий за AI in SDLC, Architecture, Engineering RnD в Т-Банке, разобрал исследования и актуальные тренды влияния AI на разработку. Среди новых инструментов: умные suggests…
🔥19👍7❤3👎1
"Экономическое равновесие. Теория объемной геометрии в экономике" (Рубрика #Economics)
Прочитал эту тонкую книгу Ильи Кунцевича, которая вышла в 2015 году. Я выбрал эту книгу, так как был привлечен центральной мыслью о том, что экономику следует рассматривать как закрытую систему, моделируемую с помощью геометрии, а не привычной линейной математики. Илья говорит о том, что линейные модели не справляются с описанием реальной экономики и именно это стало одной из причин кризиса 2008 года. В итоге, книга рассматриваются базовые понятия и инструменты экономики, анализ состояния мировой экономики, критерии экономического роста и распределения материальных ценностей, а также понятие фракталов, которое автор считает важным для понимания теории экономического равновесия. Забавно, что одна из ключевых идей автора про то, что идеальная схема экономики - это окружность, где люди вкладывают и получают взамен то, что действительно заработали. Ну и по все книге присутствуют треугольники и перевернутые треугольники, которые нарисованы одинаково, хотя автор рассказывает про углы наклона и нестабильность. Это и есть вся глубокая геометрическая теория, которая оказалась разочаровывающей:)
В итоге, книга показалась мне местами интересной по рассуждением, но практически без теоретической основы, без особой глубины геометрической концепции и без достойных иллюстраций идей. Рекомендовать ее читать не буду, но мне понравилось заочно дискутировать с автором в своей голове:)
#Economics #PopScience #History
Прочитал эту тонкую книгу Ильи Кунцевича, которая вышла в 2015 году. Я выбрал эту книгу, так как был привлечен центральной мыслью о том, что экономику следует рассматривать как закрытую систему, моделируемую с помощью геометрии, а не привычной линейной математики. Илья говорит о том, что линейные модели не справляются с описанием реальной экономики и именно это стало одной из причин кризиса 2008 года. В итоге, книга рассматриваются базовые понятия и инструменты экономики, анализ состояния мировой экономики, критерии экономического роста и распределения материальных ценностей, а также понятие фракталов, которое автор считает важным для понимания теории экономического равновесия. Забавно, что одна из ключевых идей автора про то, что идеальная схема экономики - это окружность, где люди вкладывают и получают взамен то, что действительно заработали. Ну и по все книге присутствуют треугольники и перевернутые треугольники, которые нарисованы одинаково, хотя автор рассказывает про углы наклона и нестабильность. Это и есть вся глубокая геометрическая теория, которая оказалась разочаровывающей:)
В итоге, книга показалась мне местами интересной по рассуждением, но практически без теоретической основы, без особой глубины геометрической концепции и без достойных иллюстраций идей. Рекомендовать ее читать не буду, но мне понравилось заочно дискутировать с автором в своей голове:)
#Economics #PopScience #History
👍9🤣8❤7
Внедрение AI в организации в стиле Григория Остера (Рубрика #AI)
Недавно было первое апреля, а сегодня еще и суббота, поэтому я решил сегодня рассказать в канале про свою статью о внедрении AI в организациях по заветам Григория Остера и его книг из серии "Вредные советы". Эти книги предназначалась для непослушных детей и их родителей и в ней давались абсурдные советы, что приводили к катастрофам. Именно так в детстве я учился “от противного” как поступать правильно. Эта статья примерно в таком стиле рассказывает про внедрение AI в организацию, которое очень напоминает подход к “цифровым трансформациям” бизнеса, которые были популярны 10–15 лет назад у бизнесов, построенных не вокруг IT (условно не digital native).
P.S.
Если после прочтения статьи вы захотите испробовать альтернативный подход, то можете почитать мои статьи о том, как это стоит делать, правда в домене разработки софта (или как мы это называем AI4SDLC). Я про это много писал уже, например, можно посмотреть статьи
1️⃣ От классического PDLC к AI-native-разработке
Здесь про сдвиг индустрии от классических процессов к AI-native, как это выглядит и почему происходит. Подробная статья на моем сайте tellmeabout.tech.
2️⃣ От AI-native-разработки к AI-native-организации
Здесь про то, как вслед за процессами разработки начинает меняться и огрдизайн компаний. Подробная статья на моем сайте tellmeabout.tech.
3️⃣ От классического task management к AI-native: как меняется сама единица работы.
Здесь про Atlassian и Linear, которые практикуют разные подходы к управлению задачами и являются лидерами рынка для корпораций и стартапов соответственно. Подробная статья на моем сайте tellmeabout.tech.
4️⃣ Как бигтехи планируют внедрять AI-native разработку у себя в 2026 году.
Здесь о том, как бигтехи подходят к организации этого перехода и постановке целей внутри организации, а также как они планируют измерять результат. Подробная статья на моем сайте tellmeabout.tech.
Серия этих статей описывают концептуальный подход, который положен в основу нашей стратегии и тактики на этот год в направлении внедрения AI в разработке внутри компании.
#AI #Management #Future #Software #Engineering #Productivity #Agents #Processes
Недавно было первое апреля, а сегодня еще и суббота, поэтому я решил сегодня рассказать в канале про свою статью о внедрении AI в организациях по заветам Григория Остера и его книг из серии "Вредные советы". Эти книги предназначалась для непослушных детей и их родителей и в ней давались абсурдные советы, что приводили к катастрофам. Именно так в детстве я учился “от противного” как поступать правильно. Эта статья примерно в таком стиле рассказывает про внедрение AI в организацию, которое очень напоминает подход к “цифровым трансформациям” бизнеса, которые были популярны 10–15 лет назад у бизнесов, построенных не вокруг IT (условно не digital native).
P.S.
Если после прочтения статьи вы захотите испробовать альтернативный подход, то можете почитать мои статьи о том, как это стоит делать, правда в домене разработки софта (или как мы это называем AI4SDLC). Я про это много писал уже, например, можно посмотреть статьи
1️⃣ От классического PDLC к AI-native-разработке
Здесь про сдвиг индустрии от классических процессов к AI-native, как это выглядит и почему происходит. Подробная статья на моем сайте tellmeabout.tech.
2️⃣ От AI-native-разработки к AI-native-организации
Здесь про то, как вслед за процессами разработки начинает меняться и огрдизайн компаний. Подробная статья на моем сайте tellmeabout.tech.
3️⃣ От классического task management к AI-native: как меняется сама единица работы.
Здесь про Atlassian и Linear, которые практикуют разные подходы к управлению задачами и являются лидерами рынка для корпораций и стартапов соответственно. Подробная статья на моем сайте tellmeabout.tech.
4️⃣ Как бигтехи планируют внедрять AI-native разработку у себя в 2026 году.
Здесь о том, как бигтехи подходят к организации этого перехода и постановке целей внутри организации, а также как они планируют измерять результат. Подробная статья на моем сайте tellmeabout.tech.
Серия этих статей описывают концептуальный подход, который положен в основу нашей стратегии и тактики на этот год в направлении внедрения AI в разработке внутри компании.
#AI #Management #Future #Software #Engineering #Productivity #Agents #Processes
Medium
Внедрение AI в организации в стиле Григория Остера
В детстве я любил читать книги Григория Остера из серии “Вредные советы”. Одна из книг предназначалась для непослушных детей и их родителей…
👏5🔥4❤3😁3🤣2👍1🤝1
Answer Engine Optimization (Рубрика #Search)
Наткнулся на еще не законченную книгу Rodrigo Stockebrand для O’Reilly про то, как интернет переходит от поиска к ответам. Книга позиционируется не как новый подход к SEO в мире AI, а скорее как попытка описать новую реальность веба после смерти десяти синих ссылок (из выдачи поисковиков). Автор ставит себе целью рассказать практические советы о том, как сделать контент более обнаружимым и цитируемым для gen AI систем. Интересно, что по этой теме я уже разбирал интересный эпизод подкаста Ленни "Why ChatGPT will be the next big growth channel".
Но если возвращаться к книге, то ее автором является практик с почти 20-летним опытом в SEO/AEO, который работал с Amazon, Pfizer, NASA, преподавал в University of Miami и выступал в Harvard Business School. Но сама книга пока написана на малую толику и доступно всего три главы
1) The Death of Ten Blue Links - эта глава задает правильный фрейм: сначала признать, что интерфейс поиска уже меняется, а потом обсуждать тактику
2) How Answer Engines Work - здесь автор пытается объяснить механику выбора источников, а не просто сказать "оптимизируйтесь под AI"
3) RAG Fundamentals - это база про работу retrieval augmented generation, но скорее для маркетологов, чем для инженеров:) Наличие этой главы дает надежду, что автор не остановится на советах SEO-оптимизаторам, а расскажет про управление знаниями поглубже:)
В общем, книга может быть интересной и я ее себе добавил в список work in progress книг, которые я отсматриваю по мере появления новых глав.
#SEO #AI #Markerting #Search
Наткнулся на еще не законченную книгу Rodrigo Stockebrand для O’Reilly про то, как интернет переходит от поиска к ответам. Книга позиционируется не как новый подход к SEO в мире AI, а скорее как попытка описать новую реальность веба после смерти десяти синих ссылок (из выдачи поисковиков). Автор ставит себе целью рассказать практические советы о том, как сделать контент более обнаружимым и цитируемым для gen AI систем. Интересно, что по этой теме я уже разбирал интересный эпизод подкаста Ленни "Why ChatGPT will be the next big growth channel".
Но если возвращаться к книге, то ее автором является практик с почти 20-летним опытом в SEO/AEO, который работал с Amazon, Pfizer, NASA, преподавал в University of Miami и выступал в Harvard Business School. Но сама книга пока написана на малую толику и доступно всего три главы
1) The Death of Ten Blue Links - эта глава задает правильный фрейм: сначала признать, что интерфейс поиска уже меняется, а потом обсуждать тактику
2) How Answer Engines Work - здесь автор пытается объяснить механику выбора источников, а не просто сказать "оптимизируйтесь под AI"
3) RAG Fundamentals - это база про работу retrieval augmented generation, но скорее для маркетологов, чем для инженеров:) Наличие этой главы дает надежду, что автор не остановится на советах SEO-оптимизаторам, а расскажет про управление знаниями поглубже:)
В общем, книга может быть интересной и я ее себе добавил в список work in progress книг, которые я отсматриваю по мере появления новых глав.
#SEO #AI #Markerting #Search
O’Reilly Online Learning
Answer Engine Optimization
Answer engines like ChatGPT are changing how people search for information. Instead of returning lists of web pages, these systems provide direct answers, sourced from content they... - Selection from Answer Engine Optimization [Book]
❤7👍3🔥3
Не усложняй! Управление проектами по методу P3.express (рубрика #Management)
Прочитал книгу Дмитрия и Валерии Ильенковых про управление проектами и она мне понравилась. Саму книгу мне дал почитать Дима, с которым мы знакомы со времен Teamlead Conf 2020, где оба выступали. По моему ощущению "Не усложняй" - это "Пиши, сокращай" для управления проектами, но в хорошем смысле этого слова (сама "Пиши, сокращай" вышла противоречивой для меня ). В "Не усложняй" много примеров, простые слова, ясная структура и подача без ощущения, что тебя сейчас завалят терминологией ради терминологии. При этом книга не "про поговорить", а про вполне прикладной каркас: метод P3.express разбит на 33 шага и 7 стадий, чтобы сделать проект более прозрачным и предсказуемым без тяжелой трансформации процессов. Мне понравилась эта простота - так как я слишком испорчен теорией IPMA, PMI, многослойным PMBoK и всем тем прекрасным бюрократическим великолепием, которое часто идет в комплекте с project management:)
Если говорить про плюсы книги, то они такие
1. Она очень приземленная. Советы почти всегда подкрепляются историями и кейсами - от Boeing и SpaceX до Сиднейской оперы, Денверского аэропорта и собственных факапов авторов. Из-за этого рекомендации не висят в воздухе.
2. Ее можно спокойно давать новичкам, которым надо просто и доступно понять, как начинать работать с проектами. И ее же можно дать опытным людям, которые устали от бюрократии и хотят упростить процессы, не разваливая управление совсем. Авторы прямо пишут, что книга полезна не только проджектам, но и тимлидам, владельцам IT-компаний, аналитикам и другим людям, которые регулярно делают проекты.
3. Для технических руководителей и инженеров книгу точно стоит читать. Не потому, что всем срочно надо стать PM, а потому, что она хорошо объясняет базовые опоры: кто такой спонсор проекта, зачем нужно краткое резюме проекта, как декомпозировать результаты, почему полезны регулярные Go/No-Go и как не тащить мертвые инициативы только потому, что в них уже вбухали силы и деньги.
Отдельно понравился кусок про sunk cost fallacy через "Конкорд". Авторы напоминают, что эффект Конкорда - это когда проект уже очевидно не летит, но его продолжают тащить просто потому, что слишком много вложили. В P3.express для этого есть повторяющийся момент проверки Go/No-Go: не "как бы дожать", а честно спросить, проект все еще нужен или мы страдаем по инерции. Очень здравая мысль для корпораций и больших внутренних инициатив.
Если совсем коротко, шесть принципов подхода p3.express такие:
- Выбирать результат и факты, а не привычки и привязанности
- Беречь энергию команды и экономить ресурсы
- Действовать проактивно
- Искать слабое звено системы
- Ничего не делать без ясной цели
- Опираться на переиспользуемые элементы: шаблоны, чек-листы, повторяемые шаги
Жизненный цикл проекта в P3.express тоже собран минималистично и понятно:
- Старт проекта
- Планирование цикла
- Еженедельный контур управления
- Ежедневный контур управления
- Закрытие цикла
- Завершение проекта
- Этап после проекта, где оценивают полученные выгоды и новые идеи
В общем, если вам нужен не еще один "великий свод знаний" аля PMBoK, а вменяемая книга, которую можно рекомендовать людям рядом - продактам, тимлидам, инженерам, молодым менеджерам и уставшим руководителям, - "Не усложняй" выглядит очень удачным кандидатом. Не как замена PMBoK, а хороший антидот к нему (а я PMBoK читал в трех разных изданиях)
P.S.
С Димой мы договорились записать эпизод подкаста и обсудить управление проектами в общем, а также эту книгу в частности. В общем, stay tuned ...
#Management #Leadership #ProjectManagement #Processes #Engineering
Прочитал книгу Дмитрия и Валерии Ильенковых про управление проектами и она мне понравилась. Саму книгу мне дал почитать Дима, с которым мы знакомы со времен Teamlead Conf 2020, где оба выступали. По моему ощущению "Не усложняй" - это "Пиши, сокращай" для управления проектами, но в хорошем смысле этого слова (
Если говорить про плюсы книги, то они такие
1. Она очень приземленная. Советы почти всегда подкрепляются историями и кейсами - от Boeing и SpaceX до Сиднейской оперы, Денверского аэропорта и собственных факапов авторов. Из-за этого рекомендации не висят в воздухе.
2. Ее можно спокойно давать новичкам, которым надо просто и доступно понять, как начинать работать с проектами. И ее же можно дать опытным людям, которые устали от бюрократии и хотят упростить процессы, не разваливая управление совсем. Авторы прямо пишут, что книга полезна не только проджектам, но и тимлидам, владельцам IT-компаний, аналитикам и другим людям, которые регулярно делают проекты.
3. Для технических руководителей и инженеров книгу точно стоит читать. Не потому, что всем срочно надо стать PM, а потому, что она хорошо объясняет базовые опоры: кто такой спонсор проекта, зачем нужно краткое резюме проекта, как декомпозировать результаты, почему полезны регулярные Go/No-Go и как не тащить мертвые инициативы только потому, что в них уже вбухали силы и деньги.
Отдельно понравился кусок про sunk cost fallacy через "Конкорд". Авторы напоминают, что эффект Конкорда - это когда проект уже очевидно не летит, но его продолжают тащить просто потому, что слишком много вложили. В P3.express для этого есть повторяющийся момент проверки Go/No-Go: не "как бы дожать", а честно спросить, проект все еще нужен или мы страдаем по инерции. Очень здравая мысль для корпораций и больших внутренних инициатив.
Если совсем коротко, шесть принципов подхода p3.express такие:
- Выбирать результат и факты, а не привычки и привязанности
- Беречь энергию команды и экономить ресурсы
- Действовать проактивно
- Искать слабое звено системы
- Ничего не делать без ясной цели
- Опираться на переиспользуемые элементы: шаблоны, чек-листы, повторяемые шаги
Жизненный цикл проекта в P3.express тоже собран минималистично и понятно:
- Старт проекта
- Планирование цикла
- Еженедельный контур управления
- Ежедневный контур управления
- Закрытие цикла
- Завершение проекта
- Этап после проекта, где оценивают полученные выгоды и новые идеи
В общем, если вам нужен не еще один "великий свод знаний" аля PMBoK, а вменяемая книга, которую можно рекомендовать людям рядом - продактам, тимлидам, инженерам, молодым менеджерам и уставшим руководителям, - "Не усложняй" выглядит очень удачным кандидатом. Не как замена PMBoK, а хороший антидот к нему (а я PMBoK читал в трех разных изданиях)
P.S.
С Димой мы договорились записать эпизод подкаста и обсудить управление проектами в общем, а также эту книгу в частности. В общем, stay tuned ...
#Management #Leadership #ProjectManagement #Processes #Engineering
p3express.ru
Книга «Не усложняй! Управление проектами по методу P3․express»
Если вы уже перепробовали все методы, но дедлайны все равно горят, а команды выгорают — поздравляем. Вы нашли решение, которое навсегда закроет эту проблему.
👍24❤11🔥6
A Day in the Life of a Senior Leader (Рубрика #Management)
За свою жизнь я прочитал немало книг про управление, но с Майклом Лоппом интересная история - он пишет не просто книги про менджмент, его книги напоминают байки у костра:) Это третья книга, которую я у него прочел и все они выглядят как коллекция эссе, что объединены одной темой. В этот раз Майкл пытается снять с senior leadership ореол супергероики и показать, из чего этот день реально сделан: время, люди, приоритеты, встречи, пожары и поиск смысла.
Предыдущие две книги это
- "Managing Humans" - книга про управление разработкой, где автор приводил набор управленческих “стрел”, говорил процессы и описывал человеческие типажи
- "The Art of Leadership" - книга, которая выстраивала leadership как последовательность практик на трех уровнях: менеджер, директор и топ-менеджер
А в новой книге Майкл рассказывает не только про красивые истории из жизни топов, а скорее про реальность, где надо принимать сложные решения, выстраивать коммуникации, ходить на встречи, двигать вперед продукт и не умереть от нехватки времени. Книга пока пишется и я прочитал только 8 глав, где есть следующие интересные моменты
1) Мантра Майкла в одной из первых глав звучит примерно так "ask questions, repeat the hard parts, and listen" - это про то, как хороший лидер не отбирает решение у команды, а вопросами, повторением сложных мест и внимательным слушанием доводит людей до собственного решения.
2) Глава про "contagion" рассказывает о том, как по компании расползаются ложные нарративы и почему в условиях стресса люди охотнее верят в удобное объяснение, чем в точное
3) Главы "The Seven Circles of Meeting Hell" и "Late Again" рассказывают про дисфункции лидерства: плохие совещания, хроническую занятость и опоздания как не "забавную особенность", а вполне стратегический дефект управления (а вы замечали такие системные опоздания у коллег? )
4) Глава "Managing Up" рассказывает почти про сюжет из Бравого Солдата Швейка, где честная передачу важной информации подменяется удобным сюжетом маскирующим сложные моменты реальной жизни
5) Глава "Prestige Writing" мне нравится тем, что Майкл описывает это как центральный навык: чем выше роль, тем больше ты управляешь не руками, а через тексты, фрейминг и нарративы. Я давно заметил, что многие недооценивают этот навык
6) Глава "The Product Engineer" про то, что люди, которые реально строят продукт, должны иметь равный голос в продуктовых решениях и это про инженеров и условных продакт менеджеров или дизайнеров
Интересно, что эти главы основаны на свежих эссе - они актуальны, интересны и остры. Планирую дочитать и остальные главы, которые появятся в течение квартала (на странице книги указано, что она выйдет в июне 2026 года).
#Management #Leadership #Software #Engineering #Product #Writing #Processes
За свою жизнь я прочитал немало книг про управление, но с Майклом Лоппом интересная история - он пишет не просто книги про менджмент, его книги напоминают байки у костра:) Это третья книга, которую я у него прочел и все они выглядят как коллекция эссе, что объединены одной темой. В этот раз Майкл пытается снять с senior leadership ореол супергероики и показать, из чего этот день реально сделан: время, люди, приоритеты, встречи, пожары и поиск смысла.
Предыдущие две книги это
- "Managing Humans" - книга про управление разработкой, где автор приводил набор управленческих “стрел”, говорил процессы и описывал человеческие типажи
- "The Art of Leadership" - книга, которая выстраивала leadership как последовательность практик на трех уровнях: менеджер, директор и топ-менеджер
А в новой книге Майкл рассказывает не только про красивые истории из жизни топов, а скорее про реальность, где надо принимать сложные решения, выстраивать коммуникации, ходить на встречи, двигать вперед продукт и не умереть от нехватки времени. Книга пока пишется и я прочитал только 8 глав, где есть следующие интересные моменты
1) Мантра Майкла в одной из первых глав звучит примерно так "ask questions, repeat the hard parts, and listen" - это про то, как хороший лидер не отбирает решение у команды, а вопросами, повторением сложных мест и внимательным слушанием доводит людей до собственного решения.
2) Глава про "contagion" рассказывает о том, как по компании расползаются ложные нарративы и почему в условиях стресса люди охотнее верят в удобное объяснение, чем в точное
3) Главы "The Seven Circles of Meeting Hell" и "Late Again" рассказывают про дисфункции лидерства: плохие совещания, хроническую занятость и опоздания как не "забавную особенность", а вполне стратегический дефект управления (
4) Глава "Managing Up" рассказывает почти про сюжет из Бравого Солдата Швейка, где честная передачу важной информации подменяется удобным сюжетом маскирующим сложные моменты реальной жизни
5) Глава "Prestige Writing" мне нравится тем, что Майкл описывает это как центральный навык: чем выше роль, тем больше ты управляешь не руками, а через тексты, фрейминг и нарративы. Я давно заметил, что многие недооценивают этот навык
6) Глава "The Product Engineer" про то, что люди, которые реально строят продукт, должны иметь равный голос в продуктовых решениях и это про инженеров и условных продакт менеджеров или дизайнеров
Интересно, что эти главы основаны на свежих эссе - они актуальны, интересны и остры. Планирую дочитать и остальные главы, которые появятся в течение квартала (на странице книги указано, что она выйдет в июне 2026 года).
#Management #Leadership #Software #Engineering #Product #Writing #Processes
O’Reilly Online Learning
A Day in the Life of a Senior Leader
Everyone knows that senior leaders have extraordinary demands on their time. Their stamina, decisiveness, and high-wire balancing of resources, people, and priorities can seem... - Selection from A Day in the Life of a Senior Leader [Book]
🔥9❤4👍3
Кото-математика (Math Cats: Scratching the Surface of Mathematical Concepts) (Рубрика #PopScience)
На выходных прочитал забавную книгу 2025 году профессора математики Daniel M. Look, где через кошачьи позы, прыжки, коробки и мемы объясняются вполне настоящие математические сюжеты - от теоремы Пифагора и типов углов до египетских дробей, чисел Фибоначчи, топологии, систем счисления, дифференциальных уравнений и хаоса. Книга очень доступная и компактная - в ней чуть больше 100 страниц, 22 мини-главы, а сами завязки историй затягивают - мой пятилетний сын с интересом послушал рассказ про кота-почтальона Феликса, который хочет обойти всех адресатов писем, пройдя по мостам аналога Кенигсберга по одному разу. Сомневаюсь, что мой рассказ про Эйлеровы графы так же качественно зацепил моего маленького любителя математики (серьезно он сам иногда сидит и решает математические задачки в Duolingo).
В общем, если вы ждете от книги не глубины уровня большого серьезного матнаучпопа, а остроумных заходов, то это она. У автора получилась книга, которая дает почувствовать вкус к математике и увидеть, как ее можно объяснять без пафоса и страданий. Судя по интервью и университетским материалам, именно такого эффекта автор и добивался.
Отдельно отмечу, что книга не целится напрямую в детей - автор рассказывает не только базу, но касается и топологии, дифференциальных уравнений, детерменированного хаоса и теории игр. Если вы все это знаете и хотите детям на пальцах объяснить концепции, а потом ответить на их вопросы, то эта книга самое оно. Но отдать ее ребенку и ожидать, что он поймет как работает эквивалентность счетных бесконечностей ("алеф-ноль") будет черезмерно оптимистично:)
Лично я получил большое эстетическое удовольствие от чтения книги и запомнил интересные подводки автора - это позволит мне проще объяснять базу своим детям:)
#Math #PopScience #ForKids #ForParents
На выходных прочитал забавную книгу 2025 году профессора математики Daniel M. Look, где через кошачьи позы, прыжки, коробки и мемы объясняются вполне настоящие математические сюжеты - от теоремы Пифагора и типов углов до египетских дробей, чисел Фибоначчи, топологии, систем счисления, дифференциальных уравнений и хаоса. Книга очень доступная и компактная - в ней чуть больше 100 страниц, 22 мини-главы, а сами завязки историй затягивают - мой пятилетний сын с интересом послушал рассказ про кота-почтальона Феликса, который хочет обойти всех адресатов писем, пройдя по мостам аналога Кенигсберга по одному разу. Сомневаюсь, что мой рассказ про Эйлеровы графы так же качественно зацепил моего маленького любителя математики (серьезно он сам иногда сидит и решает математические задачки в Duolingo).
В общем, если вы ждете от книги не глубины уровня большого серьезного матнаучпопа, а остроумных заходов, то это она. У автора получилась книга, которая дает почувствовать вкус к математике и увидеть, как ее можно объяснять без пафоса и страданий. Судя по интервью и университетским материалам, именно такого эффекта автор и добивался.
Отдельно отмечу, что книга не целится напрямую в детей - автор рассказывает не только базу, но касается и топологии, дифференциальных уравнений, детерменированного хаоса и теории игр. Если вы все это знаете и хотите детям на пальцах объяснить концепции, а потом ответить на их вопросы, то эта книга самое оно. Но отдать ее ребенку и ожидать, что он поймет как работает эквивалентность счетных бесконечностей ("алеф-ноль") будет черезмерно оптимистично:)
Лично я получил большое эстетическое удовольствие от чтения книги и запомнил интересные подводки автора - это позволит мне проще объяснять базу своим детям:)
#Math #PopScience #ForKids #ForParents
❤26👍13🔥4✍1👏1🤝1
State of FinOps 2026: почему FinOps становится экономическим control plane для AI-native engineering (Рубрика #Survey)
Изучил свежий State of FinOps 2026. Главный тезис: FinOps окончательно перестал быть практикой про объяснение вчерашнего счета за облачное потребление и стал слоем управления стоимостью технологий, включая AI, SaaS решения, лицензии, приватные облака, датацентры и даже ФОТ (фонд оплаты труда). Не случайно FinOps Foundation в 2026 году официально сменила формулировку миссии с "value of cloud" на "value of technology", а в самом Framework добавила отдельную capability "Executive Strategy Alignment".
В своем опросе авторы снимали срез по всей операционной модели FinOps: текущие и будущие приоритеты практики, оргструктуру и место команды в компании, требуемые навыки, расширение охвата на новые технологические категории, работу с AI тратами и AI в самом FinOps, взаимодействие с соседними дисциплинами, пробелы в инструментах и движение к единому формату cost/usage data через FOCUS (FinOps Open Cost & Usage Specification). Итого, видно, что это отчет не просто про оптимизацию потребления облачных ресурсов, а обзор того, как меняется экономический контур инженерной организации.
С точки зрения методологии это ежегодный опрос-срез сообщества FinOps Foundation: шестой по счету с 2020 года, 1,192 респондента, суммарно представляющие компании с $83+ млрд ежегодных трат на AI. Состав был такой: 47% крупные корпорации, 33% корпорации и 20% малый и средний бизнес. География была такая: 35% EMEA, 34% North America, 16% APAC и 15% South/Central America. Сами выводы исследования достаточно интересны
1️⃣ AI стал главным объектом FinOps
- 98% респондентов уже управляют AI расходами и FinOps для AI - это главный приоритет на следующие 12 месяцев (а также самые большой пробел в скиллах).
- Одновременно растет использование AI внутри самой FinOps-практики для детекции аномалий, правильного сайзинга, аллокации затрат и автоматизации всего этого. При этом основные боли пока очень базовые: visibility, аллокация по бизнес-юнитам и попытка вообще понять value/ROI AI-инвестиций
2️⃣ FinOps окончательно вышел за пределы public cloud
- 90% уже управляют SaaS или планируют делать это в ближайший год, 64% - лицензиями, 57% - приватными облаками, 48% - датацентрами; еще 28% добрались до ФОТов.
- Здесь особенно важна не сама ширина охвата, а сдвиг логики - зрелый FinOps переходит от поиска потерь к управлению инвестиционными компромиссами между технологиями
3️⃣ FinOps сместился в организации вверх
- 78% команд теперь сидят под CTO/CIO, а не под CFO; 60% работают как централизованные команды для enablement
- Даже у компаний с $100M+ затратами команды остаются очень небольшими - в среднем 8–10 сотрудников и 3–10 контракторов
- Это очень похоже на платформенные команды: они масштабируются не headcount’ом, а стандартами, автоматизацией и федерализацией
- Параллельно растет влияние FinOps на технологический выбор
4️⃣ Shift-left в FinOps стал реальностью, но измерения пока не догнали практику
- Среди самых желанных возможностей инструментов - гранулярный мониторинг костов на AI, оценка костов перед реализацией и деплоем архитектурных изменений и единый дащборд по разным типам технологических затрат
- Интересно, что комьюнити уже движется от реактивных дашбордов к проактивным и автоматизации в реальном времени, но до сих пор плохо понимает, как измерять избегание затрат (cost avoidance) от предотвращенных проблем
5️⃣ FOCUS становится источником данных для этого нового FinOps
- По мере расширения практики на AI, SaaS и датацентры организациям нужен единый язык billing/cost данных
- Именно поэтому FOCUS в отчете идет как инфраструктурная тема, а не как "еще один стандарт"
В общем, это интересный опрос от сообщества и хороший ресурс по экономическим вопросам управления технологиями (раньше я с ним знаком не был)
#Economics #Management #Engineering #Leadership #Software #AI #Metrics
Изучил свежий State of FinOps 2026. Главный тезис: FinOps окончательно перестал быть практикой про объяснение вчерашнего счета за облачное потребление и стал слоем управления стоимостью технологий, включая AI, SaaS решения, лицензии, приватные облака, датацентры и даже ФОТ (фонд оплаты труда). Не случайно FinOps Foundation в 2026 году официально сменила формулировку миссии с "value of cloud" на "value of technology", а в самом Framework добавила отдельную capability "Executive Strategy Alignment".
В своем опросе авторы снимали срез по всей операционной модели FinOps: текущие и будущие приоритеты практики, оргструктуру и место команды в компании, требуемые навыки, расширение охвата на новые технологические категории, работу с AI тратами и AI в самом FinOps, взаимодействие с соседними дисциплинами, пробелы в инструментах и движение к единому формату cost/usage data через FOCUS (FinOps Open Cost & Usage Specification). Итого, видно, что это отчет не просто про оптимизацию потребления облачных ресурсов, а обзор того, как меняется экономический контур инженерной организации.
С точки зрения методологии это ежегодный опрос-срез сообщества FinOps Foundation: шестой по счету с 2020 года, 1,192 респондента, суммарно представляющие компании с $83+ млрд ежегодных трат на AI. Состав был такой: 47% крупные корпорации, 33% корпорации и 20% малый и средний бизнес. География была такая: 35% EMEA, 34% North America, 16% APAC и 15% South/Central America. Сами выводы исследования достаточно интересны
1️⃣ AI стал главным объектом FinOps
- 98% респондентов уже управляют AI расходами и FinOps для AI - это главный приоритет на следующие 12 месяцев (а также самые большой пробел в скиллах).
- Одновременно растет использование AI внутри самой FinOps-практики для детекции аномалий, правильного сайзинга, аллокации затрат и автоматизации всего этого. При этом основные боли пока очень базовые: visibility, аллокация по бизнес-юнитам и попытка вообще понять value/ROI AI-инвестиций
2️⃣ FinOps окончательно вышел за пределы public cloud
- 90% уже управляют SaaS или планируют делать это в ближайший год, 64% - лицензиями, 57% - приватными облаками, 48% - датацентрами; еще 28% добрались до ФОТов.
- Здесь особенно важна не сама ширина охвата, а сдвиг логики - зрелый FinOps переходит от поиска потерь к управлению инвестиционными компромиссами между технологиями
3️⃣ FinOps сместился в организации вверх
- 78% команд теперь сидят под CTO/CIO, а не под CFO; 60% работают как централизованные команды для enablement
- Даже у компаний с $100M+ затратами команды остаются очень небольшими - в среднем 8–10 сотрудников и 3–10 контракторов
- Это очень похоже на платформенные команды: они масштабируются не headcount’ом, а стандартами, автоматизацией и федерализацией
- Параллельно растет влияние FinOps на технологический выбор
4️⃣ Shift-left в FinOps стал реальностью, но измерения пока не догнали практику
- Среди самых желанных возможностей инструментов - гранулярный мониторинг костов на AI, оценка костов перед реализацией и деплоем архитектурных изменений и единый дащборд по разным типам технологических затрат
- Интересно, что комьюнити уже движется от реактивных дашбордов к проактивным и автоматизации в реальном времени, но до сих пор плохо понимает, как измерять избегание затрат (cost avoidance) от предотвращенных проблем
5️⃣ FOCUS становится источником данных для этого нового FinOps
- По мере расширения практики на AI, SaaS и датацентры организациям нужен единый язык billing/cost данных
- Именно поэтому FOCUS в отчете идет как инфраструктурная тема, а не как "еще один стандарт"
В общем, это интересный опрос от сообщества и хороший ресурс по экономическим вопросам управления технологиями (раньше я с ним знаком не был)
#Economics #Management #Engineering #Leadership #Software #AI #Metrics
data.finops.org
State of FinOps 2026 Report
Read the latest State of FinOps Report to discover the latest findings and trends within the FinOps discipline.
❤7🔥4👍3🤨1
Engineering Leadership: The Hard Parts (Рубрика #Management)
Я люблю читать книги про менеджмент, которые не пытаются продать "лидерство" как набор красивых поз или фраз. И новая книга O’Reilly "Engineering Leadership: The Hard Parts", вышедшая в начале 2026 года, выглядит интересной ровно из-за этого. Авторы решили в ней рассказать про ту часть работы, где приоритеты съезжают, ресурсов не хватает, процессы скрипят, а работу все равно надо сделать. Ее написали Хуан Пабло Буритика и Джеймс Тернбулл. Первый - CTO Convergint с опытом Stripe и Splice, а второ - старший вице‑президент по разработке там же, который до этого успел поруководить в Kickstarter, Docker, Venmo и ряде других компаний, а также он успел до этой книги написать несколько других технических книг.
По оглавлению видно, что книга идет от неопределенности и роли руководителя к темам работы с командой, задания направления, поставки результата, работы с бюджетом, определения технических принципов, а также совместных решений и метрик. То есть разговор здесь не только про личные встречи с сотрудниками и оценку работы, а про весь фулхауз сразу: люди, продукт, процесс, деньги и технологии.
Особенно хорошо, что
1️⃣ Авторы начинают с диагностики хаоса. Не с мечты про идеальную команду, а с признаков того, что система уже едет: нет владельцев, слабая коммуникация, культура поиска виноватых, режим постоянного пожара, отсутствие внятных измерений. Это хороший заход, потому что многие книги по управлению начинают там, где у читателя уже "все хорошо". Я тоже люблю говорить менти, что упоминают про сложности новой работы, о том, что если бы все было хорошо, то вас бы не позвали руководить этим направлением:)
2️⃣ Роль технического руководителя они раскладывают через несколько опор: люди, смысл работы, план, процесс и результат. Сильная мысль тут простая: руководитель - это не "бывший лучший разработчик", а многорукий шива или как описывают авторы "generalist with range", который связывает команду, направление и способ работы в одну систему.
3️⃣ Есть сильный блок про работу в хаосе. Авторы не выдают "универсальный шаблон", а скорее дают набор ментальных моделей: сначала понять контекст, потом выбирать действие; смотреть на результат, а не на суету; проговаривать компромиссы вслух; строить не героизм, а систему, в которой людям проще двигать работу.
4️⃣ Книга не застревает только на вопросе людей. Там есть приоритизация, очередь задач, баланс между новыми функциями и техническим долгом, прозрачность приоритетов. А потом - бюджеты, расходы, подрядчики, спор "делать самим или покупать", а следом технические принципы и стратегия. Такой диапазон тем в одной книге встречается нечасто
5️⃣ Завершается все инженерными практиками и метриками. И это может быть одна из самых ценных частей. Многие организации либо вообще не умеют мерить инженерную работу, либо превращают метрики в дубинку. Здесь же по оглавлению видно более здоровый подход: метрики надо проектировать под вопрос и не фетишизировать скорость разработки (velocity)
Если ставить книгу рядом с книгами Will Larson, то сравнение у меня такое
- An Elegant Puzzle - это сильная системная книга про инженерный менеджмент: размер команд, технический долг, планирование преемственности, организационные решения (см. мой пост)
- Engineering Leadership: The Hard Parts - это более приземленная книга про повседневную работу руководителя внутри уже шумящей системы
В общем, их можно отлично совмещать.
#Engineering #Management #Leadership #Processes #Strategy #Metrics
Я люблю читать книги про менеджмент, которые не пытаются продать "лидерство" как набор красивых поз или фраз. И новая книга O’Reilly "Engineering Leadership: The Hard Parts", вышедшая в начале 2026 года, выглядит интересной ровно из-за этого. Авторы решили в ней рассказать про ту часть работы, где приоритеты съезжают, ресурсов не хватает, процессы скрипят, а работу все равно надо сделать. Ее написали Хуан Пабло Буритика и Джеймс Тернбулл. Первый - CTO Convergint с опытом Stripe и Splice, а второ - старший вице‑президент по разработке там же, который до этого успел поруководить в Kickstarter, Docker, Venmo и ряде других компаний, а также он успел до этой книги написать несколько других технических книг.
По оглавлению видно, что книга идет от неопределенности и роли руководителя к темам работы с командой, задания направления, поставки результата, работы с бюджетом, определения технических принципов, а также совместных решений и метрик. То есть разговор здесь не только про личные встречи с сотрудниками и оценку работы, а про весь фулхауз сразу: люди, продукт, процесс, деньги и технологии.
Особенно хорошо, что
1️⃣ Авторы начинают с диагностики хаоса. Не с мечты про идеальную команду, а с признаков того, что система уже едет: нет владельцев, слабая коммуникация, культура поиска виноватых, режим постоянного пожара, отсутствие внятных измерений. Это хороший заход, потому что многие книги по управлению начинают там, где у читателя уже "все хорошо". Я тоже люблю говорить менти, что упоминают про сложности новой работы, о том, что если бы все было хорошо, то вас бы не позвали руководить этим направлением:)
2️⃣ Роль технического руководителя они раскладывают через несколько опор: люди, смысл работы, план, процесс и результат. Сильная мысль тут простая: руководитель - это не "бывший лучший разработчик", а многорукий шива или как описывают авторы "generalist with range", который связывает команду, направление и способ работы в одну систему.
3️⃣ Есть сильный блок про работу в хаосе. Авторы не выдают "универсальный шаблон", а скорее дают набор ментальных моделей: сначала понять контекст, потом выбирать действие; смотреть на результат, а не на суету; проговаривать компромиссы вслух; строить не героизм, а систему, в которой людям проще двигать работу.
4️⃣ Книга не застревает только на вопросе людей. Там есть приоритизация, очередь задач, баланс между новыми функциями и техническим долгом, прозрачность приоритетов. А потом - бюджеты, расходы, подрядчики, спор "делать самим или покупать", а следом технические принципы и стратегия. Такой диапазон тем в одной книге встречается нечасто
5️⃣ Завершается все инженерными практиками и метриками. И это может быть одна из самых ценных частей. Многие организации либо вообще не умеют мерить инженерную работу, либо превращают метрики в дубинку. Здесь же по оглавлению видно более здоровый подход: метрики надо проектировать под вопрос и не фетишизировать скорость разработки (velocity)
Если ставить книгу рядом с книгами Will Larson, то сравнение у меня такое
- An Elegant Puzzle - это сильная системная книга про инженерный менеджмент: размер команд, технический долг, планирование преемственности, организационные решения (см. мой пост)
- Engineering Leadership: The Hard Parts - это более приземленная книга про повседневную работу руководителя внутри уже шумящей системы
В общем, их можно отлично совмещать.
#Engineering #Management #Leadership #Processes #Strategy #Metrics
O’Reilly Online Learning
Engineering Leadership: The Hard Parts
Whether they're building a startup or scaling an established org, engineering leaders know the real job is keeping chaos under control. In a world of shifting priorities, scarce... - Selection from Engineering Leadership: The Hard Parts [Book]
👍30❤7🔥4
Как Hyundai сделал то, что не смогли Google и DARPA? (Рубрика #Robotics)
С интересом посмотрел историю про версию робота Atlas от Boston Dynamics и Hyundai, из которой видно, что Atlas перестает быть просто research-легендой и начинает превращаться в промышленный продукт. История этого робота вообще выросла из потребности в роботе-гуманоиде для аварий навроде аварии на Фукусима, а теперь Hyundai готовит его к реальной работе на своих заводах.
Основная мысль истории в том, что в робототехнике побеждает не тот, у кого самый вирусный деморолирк, а тот, кто умеет собрать полный контур. У нового робота Atlas этот контур выглядит так
- Boston Dynamics приносит механику, контроль и годы R&D
- Google DeepMind - новый слой embodied AI
- Hyundai - заводскую дисциплину, цепочку поставок, внутреннего первого заказчика и путь к масштабу
Без этого последнего звена даже очень красивый гуманоид легко остается просто дорогой лабораторной демонстрацией
Если говорить про основную техническую историю, то это актуаторы (исполнительные механизмы). Hyundai Mobis прямо пишет, что они шаренные ключевые компоненты с автомобильными управляющими системами, а сами актуаторы съедают больше 60% стоимости гуманоидов Atlas. И это показывает как Hyundai обеспечил прорыв в подготовке робота к проду: не через "изобрести все с нуля", а через умное переиспользование уже отлаженной индустриальной базы из соседней отрасли.
Если говорить про продуктовую часть, то Boston Dynamics сама признает, что предыдущая версия Atlas была слишком дорогой и сложной в ремонте, а прод-версию специально делали проще и удобнее в обслуживании (работали над сокращением TCO, total cost of ownership). Важно еще, что новый Atlas не просто "копирует человека", а умеет работать в мире, уже спроектированном под человека. Boston Dynamics пишет, что он рассчитан на те же workstations и то же оборудование, что и у людей - а это позволяет использовать его на текущих автоматизированных заводах по производству машин как drop-in замену человеческого труда на тех стадиях рабочего процесса, что раньше не были автоматизированы.
Возможности робота и железо под капотом выглядят серьезно, в итоге у роботоа есть: 56 степеней свободы, почти непрерывная кинематика, тактильные руки (tactile hands), 360° обзор, автономная замена батареи, работа в режимах autonomous / VR / tablet, интеграция с MES и WMS через Orbit. Но самое важное даже не в цифрах, а в том, что Atlas уже учат реальным производственным операциям и думают о раскатке новых навыков на весь флот роботов. Это уже больше похоже не на "одного умного робота", а на новую software-defined физическую платформу.
Но Boston Dynamics не разгоняет хайп, а говорит, что начинает с простых задач и только потом будет двигаться к более сложной сборке и плотной работе рядом с людьми. То есть революция в робототехнике, скорее всего, придет не одним большим скачком, а серией скучных, очень инженерных итераций (как обычно и бывает)
#Robotics #RnD #Engineering #AI #Engineering #Software #Hardware #Architecture
С интересом посмотрел историю про версию робота Atlas от Boston Dynamics и Hyundai, из которой видно, что Atlas перестает быть просто research-легендой и начинает превращаться в промышленный продукт. История этого робота вообще выросла из потребности в роботе-гуманоиде для аварий навроде аварии на Фукусима, а теперь Hyundai готовит его к реальной работе на своих заводах.
Основная мысль истории в том, что в робототехнике побеждает не тот, у кого самый вирусный деморолирк, а тот, кто умеет собрать полный контур. У нового робота Atlas этот контур выглядит так
- Boston Dynamics приносит механику, контроль и годы R&D
- Google DeepMind - новый слой embodied AI
- Hyundai - заводскую дисциплину, цепочку поставок, внутреннего первого заказчика и путь к масштабу
Без этого последнего звена даже очень красивый гуманоид легко остается просто дорогой лабораторной демонстрацией
Если говорить про основную техническую историю, то это актуаторы (исполнительные механизмы). Hyundai Mobis прямо пишет, что они шаренные ключевые компоненты с автомобильными управляющими системами, а сами актуаторы съедают больше 60% стоимости гуманоидов Atlas. И это показывает как Hyundai обеспечил прорыв в подготовке робота к проду: не через "изобрести все с нуля", а через умное переиспользование уже отлаженной индустриальной базы из соседней отрасли.
Если говорить про продуктовую часть, то Boston Dynamics сама признает, что предыдущая версия Atlas была слишком дорогой и сложной в ремонте, а прод-версию специально делали проще и удобнее в обслуживании (работали над сокращением TCO, total cost of ownership). Важно еще, что новый Atlas не просто "копирует человека", а умеет работать в мире, уже спроектированном под человека. Boston Dynamics пишет, что он рассчитан на те же workstations и то же оборудование, что и у людей - а это позволяет использовать его на текущих автоматизированных заводах по производству машин как drop-in замену человеческого труда на тех стадиях рабочего процесса, что раньше не были автоматизированы.
Возможности робота и железо под капотом выглядят серьезно, в итоге у роботоа есть: 56 степеней свободы, почти непрерывная кинематика, тактильные руки (tactile hands), 360° обзор, автономная замена батареи, работа в режимах autonomous / VR / tablet, интеграция с MES и WMS через Orbit. Но самое важное даже не в цифрах, а в том, что Atlas уже учат реальным производственным операциям и думают о раскатке новых навыков на весь флот роботов. Это уже больше похоже не на "одного умного робота", а на новую software-defined физическую платформу.
Но Boston Dynamics не разгоняет хайп, а говорит, что начинает с простых задач и только потом будет двигаться к более сложной сборке и плотной работе рядом с людьми. То есть революция в робототехнике, скорее всего, придет не одним большим скачком, а серией скучных, очень инженерных итераций (как обычно и бывает)
#Robotics #RnD #Engineering #AI #Engineering #Software #Hardware #Architecture
YouTube
Как Hyundai сделал то, что не смогли Google и DARPA?
📌 Бесплатная регистрация на курс по ссылке 👉🏼 https://easyworkers.ru/prorobotov2603?utm_source=YouTube&utm_campaign=pro2602
Не упусти шанс погрузиться в захватывающий мир нейросетей! Начните зарабатывать на нейросетях и выйдите на доход от 100 000 руб.…
Не упусти шанс погрузиться в захватывающий мир нейросетей! Начните зарабатывать на нейросетях и выйдите на доход от 100 000 руб.…
🔥13👍7❤5
Я часто рассказываю про то, что надо знать базу для того, чтобы развиваться в software engineering. Но обычно сложно описать, а что же входит в это определение "база" и является джентельменским набором хорошего инженера. Но тут мой коллега, Женя Козлов, крутой инженер, написал серию статей про процессоры, модели памяти, многозадачность и конкурентность. В этой серии разбираются моменты, которые полезны инженерам, что делают высоконагруженные системы, которые плотно работают с данными. Собственно, сам Женя у нас лидит команду, что занимается Statist - это наша система продуктовой аналитики, которая давно заменила нам Amplitude и по всем характеристикам тянет на data intensive application. В общем, я очень рекомендую вам эту серию статей от Жени, если вам интересно понять как компьютер обрабатывает под капотом те программы, что вы пишите на своем любимом языке программирования.
Отдельно отмечу, что мы с Женей записывали эпизод подкаста Code of Leadership, из которого можно узнать про интересный путь Жени к его текущей роли внутри Т-Банка, а также что он делает у нас в компании.
Отдельно отмечу, что мы с Женей записывали эпизод подкаста Code of Leadership, из которого можно узнать про интересный путь Жени к его текущей роли внутри Т-Банка, а также что он делает у нас в компании.
Telegram
Книжный куб
Code of Leadership #35 - Interview with Eugene Kozlov about SDLC (Рубрика #Engineering)
В очередном выпуске подкаста ко мне пришел интересный гость, Евгений Козлов, с которым мы вместе работаем в Т-Технология. Женя является Staff Software Engineer и руководит…
В очередном выпуске подкаста ко мне пришел интересный гость, Евгений Козлов, с которым мы вместе работаем в Т-Технология. Женя является Staff Software Engineer и руководит…
🔥13❤4👍4
Forwarded from Евгений Козлов пишет про IT (Eugene Kozlov)
Concurrency, Synchronization and Consistency.
🔹Основы. Железо
- Архитектура Фон-Неймана
- Узкое место архитектуры Фон-Неймана
- Когерентность кеша. Основы
- Контроллеры когерентности
- Протокол когерентности MSI
- Блокировки, атомарные операции
- Выводы по аппаратной части
🔹Модель памяти / Барьеры памяти
- Что такое модель памяти? Sequential Consistency.
- Барьеры памяти
- Модель памяти X86
- Модель памяти ARM
- Выводы по моделям памяти + материалы
🔹Прикладной уровень. Операционная система
- Spinlocks с примерами на stdatomic.h + pthread.h
- Race Condition + Mutex
- Mutex Internals. Fast Userspace Mutex
- Semaphores. Основы. Сферы применения.
- Read-Write Mutexes
- Масштабируемость RW Mutex
- Mutex vs RWMutex
- Bonus: Проблема False Sharing
- Приоритеты потоков на примере Linux
- Ключевое слово volatile в C
- Реентерабелные функции в C
🔹Вызовы конкурентного программирования
- Проблема обедающих философов. Взаимная блокировка (Deadlock)
- Priority Inversion или баг случившийся на Марсе
- Синхронизация не бесплатна. Иерархия накладных расходов
Golang
- Пишем собственный Mutex
- sync.Mutex Internals
🔹Основы. Железо
- Архитектура Фон-Неймана
- Узкое место архитектуры Фон-Неймана
- Когерентность кеша. Основы
- Контроллеры когерентности
- Протокол когерентности MSI
- Блокировки, атомарные операции
- Выводы по аппаратной части
🔹Модель памяти / Барьеры памяти
- Что такое модель памяти? Sequential Consistency.
- Барьеры памяти
- Модель памяти X86
- Модель памяти ARM
- Выводы по моделям памяти + материалы
🔹Прикладной уровень. Операционная система
- Spinlocks с примерами на stdatomic.h + pthread.h
- Race Condition + Mutex
- Mutex Internals. Fast Userspace Mutex
- Semaphores. Основы. Сферы применения.
- Read-Write Mutexes
- Масштабируемость RW Mutex
- Mutex vs RWMutex
- Bonus: Проблема False Sharing
- Приоритеты потоков на примере Linux
- Ключевое слово volatile в C
- Реентерабелные функции в C
🔹Вызовы конкурентного программирования
- Проблема обедающих философов. Взаимная блокировка (Deadlock)
- Priority Inversion или баг случившийся на Марсе
- Синхронизация не бесплатна. Иерархия накладных расходов
Golang
- Пишем собственный Mutex
- sync.Mutex Internals
Telegram
Евгений Козлов пишет про IT
Concurrency, Synchronization and Consistency. Пост №1. Архитектура Фон Неймана.
Прошел без малого год с момента когда я начал серию постов о Concurrency, потоках, процессах и аппаратной части. Много обратной связи получил, в основном положительной. При этом…
Прошел без малого год с момента когда я начал серию постов о Concurrency, потоках, процессах и аппаратной части. Много обратной связи получил, в основном положительной. При этом…
🔥32👍7❤5
Code of Leadership 2. Эпизод #1 - Оценка эффективности внедрения AI с Авениром Вороновым(Рубрика #AI)
Вышел первый выпуск второго сезона моего подкаста Code of Leadership. В этот раз в гостях был Авенир Воронов, директор по внедрению из компании veai.ru, что делает AI решения для корпоративной разработки. А говорили мы о теме, которая кажется мне одной из самых практичных в AI-native разработке: как не просто выдать инженерам AI-инструмент, а понять, что его внедрение действительно дало команде и бизнесу.
Если коротко, разговор получился вокруг одного ключевого вопроса: какой язык измерения вообще нужен для AI-внедрения. Мы обсудили, почему пилоты часто запускают энтузиасты без baseline и критериев успеха, как из телеметрии IDE и диалогов с copilot-инструментом можно собирать сценарии работы и оценивать время и деньги, зачем смотреть не только на adoption, но и на контрметрики качества, а также почему эмоциональный фон инженеров и типы их взаимодействия с AI тоже дают важные сигналы.
Отдельно получилось интересно поговорить про то, как меняется сама модель разработки. AI сдвигает работу выше по стеку абстракций: от написания строк к формулированию intent, ограничений, правил и тестов. А значит, меняются не только инструменты, но и роли, процессы и само понимание того, что считать успешным внедрением. Мне особенно отозвалась мысль, что успешное внедрение AI почти никогда не измеряется одной цифрой. Для одного заказчика важен ROI, для другого - спокойствие команды и качество работы, для третьего - скорость пути от идеи до релиза. Поэтому реальное использование и растущий adoption оказываются не менее важны, чем красивые цифры на дашборде.
В общем, это выпуск не про магический рост productivity, а про более взрослый разговор: как измерять AI-внедрение без маркетингового шума и не терять связь с реальной болью инженерной организации.
Выпуск доступен на разных площадках: Youtube, VK, Podster, Ya Music.
#AI #Engineering #Management #DevEx #Productivity #Leadership #Software
Вышел первый выпуск второго сезона моего подкаста Code of Leadership. В этот раз в гостях был Авенир Воронов, директор по внедрению из компании veai.ru, что делает AI решения для корпоративной разработки. А говорили мы о теме, которая кажется мне одной из самых практичных в AI-native разработке: как не просто выдать инженерам AI-инструмент, а понять, что его внедрение действительно дало команде и бизнесу.
Если коротко, разговор получился вокруг одного ключевого вопроса: какой язык измерения вообще нужен для AI-внедрения. Мы обсудили, почему пилоты часто запускают энтузиасты без baseline и критериев успеха, как из телеметрии IDE и диалогов с copilot-инструментом можно собирать сценарии работы и оценивать время и деньги, зачем смотреть не только на adoption, но и на контрметрики качества, а также почему эмоциональный фон инженеров и типы их взаимодействия с AI тоже дают важные сигналы.
Отдельно получилось интересно поговорить про то, как меняется сама модель разработки. AI сдвигает работу выше по стеку абстракций: от написания строк к формулированию intent, ограничений, правил и тестов. А значит, меняются не только инструменты, но и роли, процессы и само понимание того, что считать успешным внедрением. Мне особенно отозвалась мысль, что успешное внедрение AI почти никогда не измеряется одной цифрой. Для одного заказчика важен ROI, для другого - спокойствие команды и качество работы, для третьего - скорость пути от идеи до релиза. Поэтому реальное использование и растущий adoption оказываются не менее важны, чем красивые цифры на дашборде.
В общем, это выпуск не про магический рост productivity, а про более взрослый разговор: как измерять AI-внедрение без маркетингового шума и не терять связь с реальной болью инженерной организации.
Выпуск доступен на разных площадках: Youtube, VK, Podster, Ya Music.
#AI #Engineering #Management #DevEx #Productivity #Leadership #Software
YouTube
Code of Leadership - S2 - E1 - Оценка эффективности внедрения AI с Авениром Вороновым
Вышел первый выпуск второго сезона моего подкаста Code of Leadership. В этот раз в гостях был Авенир Воронов, директор по внедрению из компании veai.ru, что делает AI решения для корпоративной разработки. А говорили мы о теме, которая кажется мне одной из…
1🔥12❤4👍2✍1