Книжный куб @book_cube Channel on Telegram

Книжный куб

@book_cube

Рекомендации интересных книг, статей и выступлений от Александра Поломодова (@apolomodov), технического директора в T Tech

Книжный куб (Russian)

Добро пожаловать в Telegram канал 'Книжный куб'! Здесь вы найдете рекомендации интересных книг, статей и выступлений от Александра Поломодова, технического директора в TInkoff, который отвечает за клиентские интерфейсы, маркетинг и вовлечение. Если вы увлечены миром литературы и хотите быть в курсе последних разработок, то этот канал - для вас! Александр делится своими личными рекомендациями и отзывами о книгах, которые помогут вам расширить свой кругозор и найти вдохновение. Присоединяйтесь к 'Книжный куб' и погрузитесь в увлекательный мир книг и знаний!

Книжный куб

14 Feb, 06:09

10 Developer Productivity Boosts from Generative AI (Рубрика #DevEx)

Глянул очередное интересное и короткое видео от Martin Keen, IBM Fellow, который за много лет в IBM проявил себя как изобретатель (больше 400 патентов), технический руководитель, исследователь в AI, а также создатель контента на канале IBM Technology. В этом видео Мартин рассказывает про то, как Gen AI может помочь повысить продуктивность разработчиков, а я про эту тему рассказывал много и подробно раньше, например, в последнем докладе про то, как и зачем мерить developer productivity. Но давайте вернемся к мыслям Мартина

1) Elemenating repetitive tasks. Генеративный ИИ может помочь исключить повторяющиеся задачи, ускоряя рутинную работу.
2) Natural language interface. Интерфейс на естественном языке позволяет запрашивать генерацию кода и контроль версий.
3) Code suggestions. Подсказки помогают начать работу с незнакомыми библиотеками и пакетами.
4) Code improvements. Это улучшения для устранения избыточных и неэффективных частей кода, почти как при pair programming, но где пару составляет AI ассистент
5) Code translation. Трансляции кода с одного языка на другой, которая может быть полезна для масшабной миграции, например, со Scala на Java/Kotlin
6) Code testing. ИИ может создавать тестовые сценарии и оценивать результаты.
7) Bug detection. Автоматическая идентификация и даже исправление багов
😍 Personalized dev environment. Как я понял это история про тюнинг IDE и других инструментов под стиль разработчика
9) Generation documentation. Генерация документации на основе кода

В конце автор говорит о том, что сейчас Gen AI скорее не замена разработчика, а помощь для расширения его возможностей. Это хорошо перекликается с мыслями из статьи "What Do Developers Want From AI?", про которую я рассказывал раньше.

P.S.
Автор не забыл про десятый пункт - он предложил зрителем самим написать в комментах:)

P.P.S.
У Мартина есть интересное видео про тренды AI в 2025 году, про которое я уже писал в канале.

#Management #Leadership #Software #SoftwareDevelopment #Metrics #Devops #Processes #AI #ML #DevEx
1,199
Книжный куб

14 Feb, 05:08

Как я чувствую себя, когда иду на работу ... А вообще это обычный поход моего младшего сына в сад.
1,218
Книжный куб

13 Feb, 11:14

Research Insights Made Simple #8 "Measuring developer goals" (Рубрика #DevEx)

В этом выпуске подкаста про инсайты ко мне в гости пришел Александр Кусургашев для того, чтобы поговорить про гугловую статью "Measuring developer goals":) Александр работает в Т-Банке в подразделении Core Tech и занимается развитием нашей внутренней платформы разработки. Он верит в законы физики, платформизацию и пользу от переиспользования. Для него важно, чтобы IT системы Т-Банка работали эффективно - от уровня физической инфраструктуры до конечных сервисов для потребителей. Большую часть своей IT карьеры Саша провел разрабатывая платформенные решения для low latency и ultra low latency electronic trading.

За время подкаста мы обсудили темы:
- Опыт работы Саши и его зона ответственности в Т-Банке
- Обсуждение critical user journeys для определения измеримых и объективных целей инженеров
- Гранулярность и декомпозиция целей
- Комплексный подход к оптимизации
- Важность систематического процесса выделения целей
- Эволюция обратной связи в опросах Engineering Satisfaction Survey
- Переход от инструментов к целям
- Измерение метрик и мониторинг процессов
- Вариативность инструментов и сложность стандартизации
- Научный подход к улучшению процессов

Выпуск доступен на Youtube, VK, Podster.fm, Ya Music

P.S.
Я уже разбирал этот whitepaper полгода назад.

#Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes
1,514
Книжный куб

13 Feb, 06:18

Обложка книги "Digital Nudge" и немного примеров применения концепции
1,575
Книжный куб

13 Feb, 06:09

Digital Nudge (Рубрика #Management)

Полгода назад мне подарили эту книгу, но прочитал я ее на днях. В ней Fabio Pereira рассказывает про базовые принципы поведенческой экономики, которые могут быть применены в цифровом миру для тонкого влияния на решения и поведение пользователей. Автор вводит концепцию digital nudging или цифрового подталкивания, которая представляет собой использование тонких элементов дизайна, информации и взаимодействия в цифровой среде для управления поведением пользователей без ограничения их свободы выбора. По-факту, это адаптация nudge theory Ричарда Талера и Касса Састейна из книги "Nudge". Правда, digital nudge адаптирован к цифровому контексту, например, веб-сайтам, приложениям или онлайн-платформам, и используют элементы интерфейса, такие как настройки по умолчанию, визуальные подсказки, персонализированные рекомендации и своевременные уведомления для влияния на принятие решений.

Оснонвые идеи книги
1) Choice architecture (архитектура выбора): То, как представлены варианты выбора в цифровой среде, может существенно влиять на поведение пользователей. Например, настройки по умолчанию (например, автоматическое продление подписок) часто направляют пользователей к определенным действиям.
2) Behavioral triggers (психологические триггеры): Цифровые "подталкивания" опираются на психологические принципы, такие как социальное доказательство (например, отзывы пользователей), дефицит (например, "Осталось всего 3 товара") и избегание потерь для стимулирования желаемого поведения.
3) Personalization (персонализация): "Подталкивания" могут быть адаптированы на основе данных о пользователях, таких как предпочтения или действия в реальном времени, для повышения их эффективности.
4) Low-cost interventions (дешевые интервенции): Цифровые "подталкивания" недороги и минимально навязчивы, что делает их масштабируемым решением для влияния на поведение в разных областях

Автор приводит большой список примеров использования digital nudges
- Электронная коммерция: Выделение ограниченных по времени предложений или персонализированных рекомендаций для увеличения продаж.
- Здоровье и фитнес: Стимулирование более здорового образа жизни или регулярных тренировок через напоминания и элементы геймификации.
- Продуктивность на работе: Подталкивание сотрудников к выполнению задач или освоению новых инструментов с помощью целевых уведомлений.
- Образование: Повышение вовлеченности студентов с помощью интерактивных учебных материалов и функций отслеживания прогресса.

Эта книга связана с другими
- "Nudge: Improving Decisions About Health, Wealth, and Happiness" Ричарда Талера и Касса Санстейна — основополагающая работа о теории "подталкивания".
- "Hooked: How to Build Habit-Forming Products" ("На крючке") - эта книга Нира Эяля о том, как создавать продукты, которые захватывают пользователей и становятся неотъемлемой частью их повседневной жизни. Я про нее уже рассказывал
- "Thinking, Fast and Slow" ("Думай медленно... решай быстро") Даниэля Канемана — исследует психологические системы принятия решений. Я про нее уже рассказывал
- "Predictably Irrational" ("Предсказуемая иррациональность") Дэна Ариели — объясняет, почему люди принимают иррациональные решения и как на них можно влиять.Я про нее уже рассказывал
- "Inside the Nudge Unit" Дэвида Хэлперна — о практическом применении теории "подталкивания" в государственной политике.
- "Misbehaving: The Making of Behavioral Economics" Ричарда Талера — рассказывает о развитии поведенческой экономики как научной дисциплины.
Эти книги предоставляют более глубокое понимание поведенческой экономики и науки о принятии решений, дополняя темы из Digital Nudge.
А вообще, сама книга "Digital nudge" очень простая и легкая, а поэтому хорошо подходит для того, чтобы познакомиться с этой темой.

P.S.
Я уже рассказывал про пару выступлений Фабио конференциях, из которых можно сложить отличное представление о самой концепции digital nudge
- The Psychology of UX
- Infobesity - How to Cope with the Overload of Information

#Thinking #PopularScience #SelfDevelopment #Brain #Economics #Psychology
1,391
Книжный куб

12 Feb, 09:12

[2/2] Behavioral Interview Discussion with Ex-Meta Hiring Committee Member (Рубрика #Management)

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

9) Кандидатам важно уметь правильно презентовать свой опыт, а для этого важно понимать свои достижения и проекты, а также соотнести свои проекты с ценностями компании
10) Важно правильно выбирать проекты для рассказа. Например, автор рекомендует делить проекты по личному участию, влиянию на бизнес и масштабу. Важно, чтобы о выбранных проектах можно было интересно рассказать (рассказ об унылом проекте вгоняет интервьюера в депрессию)
11) На интервью часто задают вопросы об совершенных ошибках. Не стоит отвечать, что их не было - все люди ошибаются, но хорошие кандидаты признают ошибки и учаться на них (а лучшие учатся еще и на чужих ошибка)
12) Помимо ошибок интервьюер может спросить про слабости кандидата. Не стоит отвечать на них, что их нет или "Я - трудоголик", важно признавать свои слабости, а если еще рассказать про извлеченные из них уроки, то будет еще лучше. Но для интервьера важна честность и искренность, наигранные рассказы не принесут вистов
13) При подготовке к интервью важно подумать о том, а как показать, что вы подходите команде и решаете похожие задачи и сможете принести пользу новой компании. Лучше всего показать это через то, чтобы показать как вы добились реальных результатов на прошлом месте и принесли пользу бизнесу
14) При подготовке к интервью будьте готовы рассказать о себе, любимом проекте, а также конфликтной ситуации. В принципе, можно подготовить еще набор историй, привязанных к ценностям компании, а также отсортированных по масштабу, личному участию и импакту. Это поможет вам на интервью проще подбирать примеры из своего опыта под вопросы интервьюера
15) В конце интервью часто есть время на то, чтобы задать вопросы интервьюеру - это важный момент для того, чтобы продемонстировать интересе к компании и команде (если вас смотрят в конкретную команду), например можно задать вопросы про
- О развитии отдела и технологий
- О стиле управления нанимающего менеджера и динамике команды

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

P.S.
Я как-то рассказывл про то, как мы нанимаем
- Технических руководителей
- Staff+ инженеров
В принципе, многие советы Остина полезны и для подготовки к нашим интервью.

#Management #Software #Processes #Project #ProductManagement #Engineering #Processes #Leadership #Staff #Architecture #Career
1,536
Книжный куб

12 Feb, 05:08

[1/2] Behavioral Interview Discussion with Ex-Meta Hiring Committee Member (Рубрика #Management)

Интересное обсуждение поведенческих интервью в бигтех компаниях. Оно само выполнено в виде интервью, которое берет Stefan Mai у Austen McDonald, бывшего senior engineering manager в Meta, а также члена комитета по найму там же. Собственно, в этом интервью Остин делится своим опытом и рассказывает свои мысли относительно поведенческих интервью. Мне эта запись понравилась, так как я часто сам провожу интервью инженеров и руководителей и знаю о чем речь не понаслышке.
Вот что я вынес для себя из этого интервью
1) Остин считает, что поведенческие интервью требуют тщательной подготовки, причем подготовка дает возможность стать лучшим инженером в будущем из-за глубокой рефлексии об опыте и достижениях в прошлых проектах. Мне кажется, что навыки рефлексии - это ключ к ежедневному росту над собой, но это обычно не слишком приятно, поэтому люди избегают таких размышлений, а подготовка к интервью помогает им найти силы для этого дела
2) Поведенческие интервью важных для высоких грейдов, как инженерных, так и менеджерских. Компании оценивают прошлые успехи и поведение и используют это как экстраполяцию будущих результатов кандидата
3) Поведенческие интервью варьируются в зависимости от грейда, в приведенном видео Остин приводит примеры таких различий
4) У компаний есть критерии для оценки кандидатов, например, инициативность, настойчивость, ...
5) Крупные компании стремятся уйти от субъективных решений, поэтому формализуют критерии оценки
6) Как и всегда первое впечатление очень важно, поэтому важно правильно начать интервью и не обосраться. Автор рекомендует подготовить ответы на вопросы, которые с большой вероятностью будут заданы в начале интервью: "Расскажи о себе", "Расскажи о своем любимом проекте". Ответы на эти вопросы позволят задать првильный тон всей встрече.
7) Часто для проведения интервью используют стандартные схемы, например, STAR (Situation - Tasks - Actions - Results) или CARL (Context - Actions - Results - Learning), причем Остину нравится CARL больше STAR за счет последнего пункта про извлеченные уроки, а также он рекомендует меньше тратить времени на рассказ о контексте и больше на само действие и результаты
8 ) Стандартизированный подход (STAR / CARL / ваш любимый) может мешать непринужденной беседе и выглядеть неестественно, это решается тренировкой интервьюеров

Продолжение рассказа во втором посте.

#Management #Software #Processes #Project #ProductManagement #Engineering #Processes #Leadership #Staff #Architecture #Career
1,538
Книжный куб

11 Feb, 12:18

Я люблю читать канал "Малоизвестное интересное", так как там периодически, бывают очень интересные мысли. Они позволяют мне самому чуть шире взглянуть на происходящее на переднем краю технологических возможностей, а иногда этот взгляд не шире, но как будто под другим углом:) Конкретно в этом посте мне понравилась интересная визуализация и вообще график качество/стоимость для LLMs, а также фронтир возможностей OpenAI, DeepSeek и Gemini моделей.
1,616
Книжный куб

11 Feb, 12:18

Кто получит «Мандат Неба»?
Динамика «гонки вооружений» LLM одним слайдом.
«Гонка вооружений» на рынке больших языковых моделей (LLM) определяется просто: все стараются получить максимально высокую точность при минимальной цене. А а «фронтир» отражает лучшие на данный момент варианты по сочетанию этих двух параметров.
Диаграмма показывает [1], как разные версии языковых моделей (от OpenAI, Deepseek, Google «Gemini», Anthropic и др.) соотносятся по:
• стоимости (ось X): цена за миллион токенов - чем правее точка, тем дешевле использование модели (ниже стоимость за миллион токенов).
• качеству (ось Y): рейтинг LMSys Elo - чем выше точка, тем сильнее модель (лучшее качество ответов/результатов).

На диаграмме видны две основные "границы эффективности" (pareto frontier): 
•  Синяя линия от OpenAI, показывающая их модели
•  Оранжевая линия от Gemini 2, которая, судя по надписи, предлагает "лучше, дешевле, круче"
•  Более дорогие и мощные модели в верхней левой части (например, различные версии GPT-4) 
•  Средний сегмент в центре (Claude 3.5, Gemini 1.5) 
•  Более доступные модели в правой части (Amazon Nova Lite, Gemini 1.5 Flash)


Ключевые выводы (по состоянию на февраль 2025)
• Чемпион в соотношении цена-производительность - Gemini 2.0 Flash Thinking (лучше, чем DeepSeek r1 (по ELO) и дешевле
• Стоимость возможностей GPT-4 упала в 1000 раз за 18 месяцев
• Скорость роста возможностей моделей просто немыслимая – так не бывает, … но так есть!

PS Спецы из Google DeepMind полагают, что они близки к получению «Мандата Неба» ("Mandate of Heaven" (天命, Тяньмин)) [2]. Когда говорят, что компания имеет "Mandate of Heaven" в сфере ИИ, это означает, что она занимает лидирующую позицию не просто благодаря рыночной доле, но и благодаря признанию её технологического превосходства и инновационного лидерства.

Но вряд ли конкуренты согласятся 😊

#ИИгонка
1,677
Книжный куб

11 Feb, 07:11

[2/2] Squad Health Check и сравнение его с DORA Metrics, SPACE, DevEx (Рубрика #Management)

Продолжая сравнение разных подходов к оценке эффективности команд, расскажу про оставшиеся параметры по которым их можно сравнивать.

3) Ограниченная масштабируемость и анализ трендов
- SHC затрудняет агрегацию результатов по нескольким командам - частота опросов, список ответов и многое другое команды могут кастомизировать под себя. Это приводит к проблемам при отслеживании тенденций
- DORA Metrics хорошо масштабируется между командами и предоставляет четкий анализ трендов для оценки производительности с течением времени.
- SPACE разработан для анализа продуктивности как на уровне отдельных сотрудников, так и на уровне всей организации, что делает его масштабируемым и эффективным для анализа трендов.
- DevEx предлагает структурированный подход к измерению опыта разработчиков в разных командах, что позволяет последовательно отслеживать улучшения в таких областях, как состояние потока и обратная связь.
4) Применимость полученных данных
- SHC иногда приводит к выводам, что бывают слишком общими или расплывчатыми для того, чтобы их можно было напрямую преобразовать в конкретные действия. Обсуждения могут сосредотачиваться больше на симптомах, чем на их причинах.
- DORA Metrics: Определяет конкретные област, например, MTTR (mean time to recover), которые можно улучшить с помощью целевых вмешательств, таких как оптимизация CI/CD.
- SPACE предоставляет данные, связывая метрики с конкретными аспектами продуктивности (например, проблемы в коммуникации). Это позволяет легко понять как их использовать для оптимизации
- DevEx сосредоточен на изменениях в инструментах и процессах разработчиков, которые напрямую повышают продуктивность и удовлетворенность.
5) Чрезмерный акцент на моральном духе
- SHC сильно акцентирует внимание на моральном духе команды, удовольствии от работы и сотрудничестве, но может упускать из виду важные бизнес-результаты или техническую эффективность.
- DORA Metrics отдает приоритет метрикам производительности разработки, которые влияют на эффективность разработки, а через нее на бизнес-результаты.
- SPACE уравновешивает моральный дух с другими аспектами (например, эффективностью и потоком), обеспечивая учет как благополучия команды, так и бизнес-целей.
- DevEx фокусируется на улучшении опыта разработчиков в целом при согласовании с организационными целями (например, ускорение вывода продукта на рынок).
6) Ресурсоемкость
- SHC требует подготовки фасилитаторов для эффективного проведения обсуждений. Регулярное проведение оценки может быть трудоемким для команд под давлением сроков.
- DORA Metrics позволяет автоматизировать сбор данных с CI/CD систем, что делает менее ресурсоемким использование системы после внедрения.
- SPACE достаточно сложен из-за многомерной природы данных, которые надо подтянуть из внутренних систем компании, но после первоначального внедрения может работать без супер-больших вложений
- DevEx cосредоточен на автоматизации рабочих процессов и улучшении инструментов разработки, находится где-то посередине между DORA и SPACE.

В заключение можно сказать, что хотя Squad Health Check отлично подходит для обсуждения проблем внутри команды и улучшения межличностных отношений, он уступает DORA Metrics, SPACE Framework или DevEx Framework в объективности измерений, техническом фокусе, масштабируемости и применимости данных. Организации должны выбирать фреймворк исходя из своих целей — будь то улучшение морального духа команды или повышение технической эффективности.

#Management #Devops #Management #Leadership #Processes #SRE #Software #Metrics #Productivity
1,664
Книжный куб

11 Feb, 05:08

[1/2] Squad Health Check и сравнение его с DORA Metrics, SPACE, DevEx (Рубрика #Management)

Буквально на днях наткнулся на древний инструмент опросов от Spotify. Этот концепт был опубликован в далеком 2014 году, через пару лет после публикации знаменитой модели Spotify со всякими гильдиями, сквадами и другими забавными названиями. Эту модель придумал Henrik Kniberg и популяризировал красивыми мультиками и комиксами, что стали виральными. Несмотря на попытки прикрутить модель в лоб, это мало у кого получалось, а потом и создатели сказали, что сами отошли от нее и адаптировали свои процессы под новую реальность. Собствено, Squad Health Check появился больше 10 лет назад, но он до сих пор используется в Spotify. Если упрощать, то squad health check - это инструмент самооценки, разработанный для agile команд,. Он используется для оценки и улучшения динамики команды, производительности и общей эффективности путем отслеживания различных измерений здоровья команды с течением времени. Основными фичами этой системы являются

1) Traffic light system (светофорная система): члены команды оценивают различные измерения с помощью простых цветных индикаторов, что позволяет легко визуализировать общее состояние команды.
2) Dimensions evaluated (jцениваемые измерения): общие измерения включают доставку ценности, простоту выпуска, веселье, здоровье кодовой базы, моральный дух команды и сотрудничество. Их можно настраивать в соответствии с конкретными потребностями команды.
3) Open discussions (открытые обсуждения): результаты используются для содействия обсуждениям проблем и успехов, помогая командам определять области для улучшения и создавать выполнимые планы.
4) Historical tracking (историческое отслеживание): со временем команды могут отслеживать свой прогресс и определять тенденции или повторяющиеся проблемы.

В общем, этот подход был хорош для 2014 года, но с тех пор успели появиться DORA (DevOps Research and Assesment) metrics (подробности в посте про книгу Accelerate), SPACE framework (подробности в посте) и DevEx (подробности в посте), которые шагнули сильно дальше. Если сравнить их между собой то получим примерно следующее (метод Squad health check я буду для краткости называть SHC)

1) Субъективность vs. Объективность.
- SHC сильно зависит от субъективных самооценок участников команды. Это может привести к предвзятым или непоследовательным результатам, так как разные люди могут по-разному интерпретировать вопросы или не быть полностью честными.
- DORA Metrics предоставляет объективные, количественные данные о параметрах разработки (например, deployment frequence или lead time).
- SPACE: Сочетает субъективные и объективные данные, но благодаря своей структуре минимизирует предвзятость, объединяя такие метрики, как удовлетворенность, с измеримыми показателями производительности, которые можно получить через логи/метрики из систем (activity часть SPACE)
- DevEx: Похожим на SPACE образом пытается сбалансировать субъективность и объективность.
2) Отсутствие фокуса на технических метриках
- SHC делает акцент на моральном духе команды, сотрудничестве и процессах, но не уделяет внимания техническим метрикам, таким как частота развертываний или качество кода.
- DORA Metrics сосредоточены на технических параметрах разработки, что делает его очень полезным для оптимизации DevOps/SRE практик
- SPACE охватывает технические аспекты (например, эффективность и поток) наряду с благополучием команды, предоставляя более целостное представление о продуктивности.
- DevEx прямо рассматривает технические препятствия (например, неэффективность инструментов), которые влияют на производительность и удовлетворенность разработчиков.

Продолжение сравнения этих разных подходов в следующем посте.

#Management #Devops #Management #Leadership #Processes #SRE #Software #Metrics #Productivity
1,639
Книжный куб

10 Feb, 07:12

[4/4] Software Engineering at Google (Делай как в Google. Разработка программного обеспечения) (Рубрика #Engineering)

Продолжая рассказ про эту крутую книгу, поднятый в постах 1 и 2 и 3, здесь я расскажу про четвертую и пятую часть книги под названием "Инструменты" и "Заключение".

IV. Tools (инструменты)
16. Version control and branch management (Управление версиями и управление ветками)
В этой главе авторы описывают, как Google использует управление версиями, а точнее свой монорепозиторий, для управления огромными объемами кода. Авторы объясняют стратегию управления ветками, которые обеспечивают непрерывную интеграцию и совместную разработку. По-факту, это версия TBD (trunk based development)
17. Code search (поиск кода)
Глава сосредоточена на инструментарии, который делает навигацию по огромному кодовому базису эффективной. Она объясняет, как мощные возможности поиска имеют решающее значение для понимания и поддержки крупных систем
18. Build systems and build philosophy (Системы сборки и философия сборки)
Авторы рассказывают про инфраструктуру сборки и практики, включая инкрементальные сборки и автоматизацию. Этот раздел детализирует, как системы сборки Google спроектированы для скорости и масштаба
19. Critique: Google’s code review tool (критика: инструмент обзора кода Google)
Интересная глава про внутренний инструмент, используемый для облегчения обзора кода. Обсуждение охватывает его сильные и слабые стороны, а также влияние на рабочий процесс и эффективность разработчиков.
20. Static analysis (статический анализ)
В этой глава объясняется, как автоматизированные инструменты анализируют исходный код для обнаружения ошибок или отклонений от стандартов до запуска кода. Этот активный подход является ключевым для поддержания качества кода в масштабе.
21. Dependency management (управление зависимостями)
Эта глава рассказывает про методы обработки зависимостей в огромной кодовой базе. Предоставляет стратегии для минимизации конфликтов и поддержания целостности системы по мере эволюции кода. Подробнее про концепт можно почитать на сайте build системы Bazel
22. Large-scale changes (крупномасштабные изменения)
В этой главе авторы обсуждают методы и инструменты для безопасного применения широкомасштабных изменений по тысячам файлов. Глава сосредоточена на планировании, автоматизации и минимизации рисков при обработке крупномасштабных изменений кода. Ясно, что такие возможности во многом основаны на использовании монорепы.
23. Continuous integration (непрерывная интеграция)
Эта глава детализирует практики и инфраструктуру, которые позволяют интегрировать изменения в коде часто и надежно. Непрерывная интеграция показана как необходимая для раннего обнаружения проблем в процессе разработки. Если хочется описания попроще, то рекомендую книгу "Grokking Continuous Delivery" ("Грокаем continuous delivery") тоже от ребят из Google, про которую я уже рассказывал
24. Continuous delivery (непрерывная доставка)
Здесь речь идет про конвейеры и автоматизацию, которые обеспечивают быструю и надежную развертывание изменений. Эта глава подчеркивает, как оптимизированные процессы доставки поддерживают постоянные инновации, сохраняя при этом стабильность. Книга "Grokking Continuous Delivery" тут тоже отлично подходит
25. Compute as a service (вычисления как сервис)
Описывает, как Google использует масштабируемые вычислительные ресурсы для поддержки разработки, тестирования и развертывания. Объясняет, как эта «инфраструктура как сервис» лежит в основе многих инженерных практик Google.

V. Заключение
Здесь авторы подводят итоги и отмечают, что инженерия программного обеспечения — это непрерывный процесс, который сочетает культуру, хорошо определенные процессы и передовые инструменты. Также авторы размышляют о выученных уроках, подчеркивая, что хотя не все практики будут применимы к каждой организации, принципы адаптивности и устойчивого развития являются универсальными.

#Engineering #Management #Software #Development #Processes #Leadership #SRE #DevOps
1,614
Книжный куб

09 Feb, 11:55

Драйв (Drive: The Surprising Truth About What Motivates Us) (Рубрика #Management)

Недавно я прочитал эту классическую книгу Даниэля Пинка (обложки в отдельном посте), которая была написана в конце 2000-х годов. В то время она звучала свежо и бросала вызов традиционным представлениям о мотивации, особенно подходу «кнут и пряник», основанному на вознаграждениях и наказаниях. Дэниель смешал фокус на внутренней мотивации, а не внешних стимулах. Автор хорошо вплетал в свое повествование результаты исследований ученых, таких как Дэниеля Канемана и его книгу "Thniking, Fast and Slow" (подробности в моем посте) или Дэна Ариели и его книгу "Predictably Irrational" (подробности в моем посте).

По-факту, Дэниэль Пинк предлагает модель мотивации 3.0, которая основывается на трех столпах
1) Автономия: Желание контролировать свою работу и принимать собственные решения. Пинк подчеркивает, что автономия способствует вовлеченности и креативности, позволяя людям самостоятельно направлять свои усилия.
2) Мастерство: Стремление улучшать свои навыки и достигать совершенства в значимых задачах. Это требует постоянного обучения и упорства.
3) Цель: Необходимость вносить вклад во что-то большее, чем собственные интересы. Связь работы с более высокой миссией усиливает мотивацию и удовлетворение.

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

В итоге, по Пинку есть 3 модели мотивации
1) Мотивация 1.0 — выживание
2) Мотивация 2.0 — вознаграждения/наказания
3) Мотивация 3.0 - внутренняя мотивация на основе автономии, мастерства и цели
Собственно, надо стремиться с мотивации 3.0, но для этого компании должны «платить достаточно, чтобы убрать деньги с повестки дня», чтобы сотрудники могли сосредоточиться на более значимых стимулах. Чем-то эти уровни мотивации напоминают пирамиду Маслоу

Пинк выделяет два типа поведения у людей
1) Тип X - внешне мотивированные
2) Тип I - внутренне мотивированные.
Поведение типа I более устойчиво, так как опирается на возобновляемые внутренние ресурсы, такие как страсть и любопытство.

Книга Пинка написана очень просто и достаточно популярна, но к ней и ряд замечаний
1) Автор по кругу повторяет мысли про автономию, мастерство и цели без особых изменений и развития темы
2) Автор упоминает исследования, что поддерживают его мысли, но почти не упоминает исследования, которые могли бы опровергнуть его выводы, создавая впечатление предвзятости.
3) Некоторые рецензенты считают описание мотивации на рабочем месте слишком упрощенным. Например, Пинк предполагает, что развитие внутренней мотивации автоматически улучшит производительность, игнорируя такие факторы как обучение сотрудников или различия в индивидуальных целях.
4) Центральный аргумент о переходе к внутренней мотивации кажется некоторым критикам преувеличенным. Они отмечают важность внешних стимулов во многих рутинных или некреативных профессиях, которые Пинк практически не рассматривает.
5) Многие рецензенты указывают на то, что *Drive* лишь популяризирует уже существующие психологические теории (особенно теорию самодетерминации), не добавляя существенных новых идей.
6) Книга критикуется за недостаток конкретных шагов по внедрению идей в реальной практике.
7) Акцент на автономии как ключевом факторе мотивации может быть неактуален для всех культур. Критики отмечают ограниченную применимость модели Пинка в странах с более строгими рабочими структурами или другими культурными нормами. Рекомендую почитать на тему разнообразия культур книгу "The culture map" (подробнее в моем посте)

Итого, книга отлично популяризировала тему внутренней мотивации, но она достаточно поверхностна - с нее можно начать но для серьезного погружения в тему стоит почитать более фундаментальную литературу.

#Psychology #Economics #Brain #SelfDevelopment
1,656
Книжный куб

09 Feb, 11:55

Обложки книг "Drive: The Surprising Truth About What Motivates Us" и "Драйв"
1,850
Книжный куб

08 Feb, 10:13

Иллюстрации из статьи "Cross-layer Enterprise Architecture Evaluation"
1,931
Книжный куб

08 Feb, 05:08

The Engineering Unlocks Behind DeepSeek | YC Decoded (Рубрика #AI)

Интересный 13 минутный разбор DeepSeek R1 от ребят из Y Combinator, который фокусируется не на хайпе, а на инженерных вещах. Основные моменты разбора такие

1) Deepseek анонсировала логическую модель R1, которая обеспечивает сопоставимую производительность с OpenAIo1 при меньших затратах.
2) Это вызвало панику в социальных сетях и снижение рыночной капитализации Nvidia на 600 миллиардов долларов.
3) Но DeepSeek - это не новый игрок на рынке. Они публикуют результаты своих исследований и модели весов, в отличие от других крупных лабораторий, таких как OpenAI и Google DeepMind. И многие результаты уже были опубликованы ранее, например, они оптимизировали обучение в fp8 и исправление накопления ошибки
4) Важно различать модели DeepSeek-R1 и DeepSeek-V3
- DeepSeek V3 обеспечивает производительность, сопоставимую с GPT-4 и другими базовыми моделями.
• R1 является reasoning моделью, построенной на основе V3, и достигает производительности, сравнимой с OpenAI o1 и Google Gemini Flash 20.
5) В V3 они использовали архитектуру, что активирует только 37 миллиардов параметров для каждого предсказания, что экономит массу вычислений, а также использовали технологии multi-head latent attention (mla) для уменьшения объема памяти и увеличения пропускной способности.
6 ) Для R1 они придумали интересную схему обучения с подкреплением (reinforcement learning)
7) Часть хайпа вокруг R1 была свзяана с доступностью модели через веб-сайт и приложение Deepseek. Сама модель предлагала сравнимую производительность за небольшую часть стоимости других моделей.
8 ) Большая часть шумихи связана с ошибочными представлениями о стоимости обучения, сумма была указана для финального обучения модели без
9) Методы DeepSeek можно воспроизвести для создания своих моделей, например, Лаборатория Калифорнийского университета в Беркли применила эти методы для создания небольших reasoning моделей всего за 30 долларов.
10) Так как это видео от Y Combinator, то они заканчивают идеей о том, что на переднем краю развития AI есть место для новых игроков, которые могут подвинуть старожилов за счет оптимизации рабочих нагрузок GPU, улучшения софта и так далее. А все это приводит к уменьшению стоимости внедрения AI в конечные продукты, что делает текущий момен подходящим временем для создания стартапа.

#AI #Engineering #Software #ML #Architecture
1,853
Книжный куб

06 Feb, 05:08

AI Trends for 2025 (Рубрика #AI)

Недавно глянул это семиминутное видео от Martin Keen, IBM Fellow, который за много лет в IBM проявил себя как изобретатель (больше 400 патентов), технический руководитель, исследователь в AI, а также создатель контента на канале IBM Technology. В этом коротком видео он рассказывает о своем видении трендов в AI на 2025 год. Ксатати, в прошлом году он тоже делал такое видео на 2024 год, поэтому можно пойти и сравнить насколько его прогнозы попали в точку. Но давайте вернемся к прогнозам на этот год.

1) Agentic AI - это важный тренд на создание многошаговых планов и их исполнения с использованием доступных инструментов. Правда, пока современные модели испытывают трудности с логическим мышлением и выполнением сложных планов
2) Inference time compute - модели уже используют больше времени во врем inference, улучшая логический вывод. Это позволяет настраивать и улучшать систему без необходимости обучать/тюнить базовую модель.
3) Very large models - в этом году мы предположительно пробьем 1 трлн параметров в foundational models
4) Very small models - будут активно развиваться модели меньшего размера, которые могут работать на ноутбуках и телефонах.
5) More advanced use cases - ИИ улучшит качество обслуживания клиентов, IT operations и автоматизацию.
6) Near infinite memory - Современные модели ИИ имеют контекстные окна в миллионы токенов. Дальше будет больше и, например, условные чат-боты смогут сохранять и использовать всю доступную информацию по пользователю.
7) Human in the loop augmentation - Чат-боты могут превосходить врачей в диагностике, но в паре с экспертами они могут быть эффективнее. Для этого нужны более совершенные системы для интеграции ИИ в рабочие процессы. Мы, например, активно интегрируем свой Nestor во все процессы вокруг SDLC (software development lifecycle) для повышения продуктивности инженеров

#AI #ML #Trends #Software #Engineering
1,480
Книжный куб

05 Feb, 08:12

Data завтрак в Т-Банке в начале января 2025 года (Рубрика #Data)

Наконец-то я смог посмотреть доклады с data-завтрака, что был почти месяц назад. На нем выступл Дима Аношин, автор канала "Инжиниринг данных" (@rockyourdata), а также Валера Поляков, наш директор по данным. Я немного поучаствовал в организации мероприятия, но посетить не смог из-за того, что летел домой из Шри-Ланки. А темы были интересные:
- Дима рассказывал о том, как выглядят data проекты в западных компаниях и на каких технологиях они строятся, благо у Димы есть опыт работы в Amazon, Microsoft и целом ряде компаний поменьше
- Валера рассказывал про эволюцию подходов Т-Банка к работе с данными с начала времен и до текущего момента.

Ну давайте я кратенько расскажу про каждый из докладов

1) Современные облачные решения для аналитики и их значимость для бизнеса от Димы Аношина
- Начал Дима с рассказа о значении аналитики для увеличения прибыли и снижения затрат.
- Дальше он рассказал о концептуальных аналитических решениях, которые базово состоят из источников, систем хранения и обработки данных.
- Дима поделился 11 реальными проектами, в которых он участвовал за последние десять лет. По этим проектам было наглядно видны тренды - переход от on-prem в cloud, переход от all-in-one в separate storage и compute, восход облачных аналитических решений snowflake и databricks, оформление роли data engineer как людей, что делают инфру под dataops

2) История платформы данных в Т: от SAS до PaaS от Валеры Полякова
История развития инфраструктуры данных с 2007 года.
- Эпоха SAS (2007 - 2011): Работа с проприетарными инструментами SAS до перехода на Greenplum.
- Эпоха Greenplum (2012 - 2016): Переход на MPP базы данных, выбор Greenplum, масштабирование инфраструктуры. Тут еще был поворот не туда с SAP BO в 2014 году:)
- Эпоха роста сложности (2017 - 2021): Здесь компания активно росла и предел масштабирования для одного кластера Greenplum был достигнут. Дальше рост через был внедрение мультикластерности и собственных решений для репликации данных. Это привело к стремительному росту нагрузки и сложностей с управлением данными.
- Эпоха изменений (2022 - 2026): Эпоха изменений, что принесла современные подходы
-- Демократизация инженеринга данных и платформизация.
-- Переход к облачной нативности платформы данных с использованием мультитенантной архитектуры.
-- Внедрение концепции "данные как продукт" с акцентом на метрики качества.
- Изменения несут за собой новые вызовы, с которыми мы работаем прямо сейчас
-- Вопросы стандартизации данных между доменами.
-- Важность централизованных практик для методологии работы с данными.
-- Баланс между тактическими задачами и стратегическим развитием.

В общем и целом, data-завтрак по моему мнению получился отличным, доклады плотными - надеюсь, что это превратится в традицию и мои коллеги из платформы данных еще не раз будут радовать нас интересными и полезными мероприятиями.

P.S.
В конце прошлого года я рассказывал доклад про эволюцию архитектуры в Т, который очень похож по структуре и логике повествования на Валерин доклад. В итоге, я ловил моментами дежавю, когда слушал этот доклад про эволюцию платформы данных:)

#Engineering #Data #Architecture #Storytelling
1,661
Книжный куб

05 Feb, 05:08

The Rise of Vertical AI in Accounting (Рубрика AI)

Прочитал на выходных интересную статью про AI в бухгалтерском учете из рассылки a16z Fintech от фонда AnderssenHorowitz. Вообще, Andreessen Horowitz (чаще известный как a16z) - это ведущая венчурная компания из Кремниевой долины, основанная в 2009 году Марком Андриссеном и Беном Хоровицем. С объемом капитала в $45 миллиардов (по состоянию на начало 2025 года), фирма инвестирует на разных этапах и в различных отраслях, включая технологии, ИИ, здравоохранение, криптовалюты и финтех, делая ставку на смелых предпринимателей и прорывные инновации. Известная своей активной поддержкой портфельных компаний, a16z инвестировала в такие трансформационные проекты, как Airbnb, Lyft и Slack, а также стала пионером в таких новых секторах, как Web3 и искусственный интеллект. Кстати, у ребят есть интересная подборка больших идей на 2025 год, которую интересно почитать для расширения сознания.

Если же возвращаться к самой статье, то она посвящена растущей роли вертикального AI в бухгалтерском учете, особенно в решении задач, связанных с услугами клиентского консалтинга (Client Advisory Services, CAS). Суть вертикальности в том, что бухгалтерский учет отличается по областям (авторы приводят в пример строительство и медицину), а это приводит к тому, что универсальный подход (горизонтальный) может проигрывать вертикальному, когда есть фокус на конкретный домен. Вообще, на западе услуги клиентского консалтинга (CAS) являются драйвером роста для компаний благодаря следующим стратегическим преимуществам:
- CAS формируют устойчивые отношения с клиентами, открывая возможности для перекрестных продаж.
- Доходы CAS растут на 30% ежегодно по сравнению с 9% в среднем по отрасли.
- CAS обеспечивает предсказуемый и менее сезонный поток доходов по сравнению с традиционными налоговыми и аудиторскими услугами.
Но масштабирование CAS требует значительных трудозатрат на повторяющиеся задачи, такие как закрытие месяца, сверка транзакций и управление расходами. Эти задачи часто выполняются вручную младшими бухгалтерами или офшорными сотрудниками, но сейчас у многих есть желание автоматизировать это при помощи AI
- ИИ может значительно сократить время на выполнение рутинных задач с часов до минут за счет автоматизации сбора данных, их обработки и сверки.
- Однако для этого требуются высокоточные модели ИИ, способные работать с разнообразными источниками данных и учитывать особенности рабочих процессов в различных отраслях.
Дальше авторы сравнивают вертикальный и горизонтальный подход, одновременно нативно встраивая рекламу Adaptive, компанию из их портфеля, что вертикально AI-фицирует бухгалтерию для строительных фирм.

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

#AI #ML #Software #VC
1,687
Книжный куб

04 Feb, 11:14

[3/4] Software Engineering at Google (Делай как в Google. Разработка программного обеспечения) (Рубрика #Engineering)

Продолжая рассказ про эту крутую книгу, поднятый в постах 1 и 2, здесь я расскажу про третью часть книги под названием "Процессы".

III. Processes (Процессы)
8. Style guides and rules (руководства по стилю и правила)
Здесь авторы объясняют необходимость стандартизированных стилей кодирования и правил. Консистентность во всех кодовых базах снижает трение (friction), облегчает поддержку и позволяет автоматизированным инструментам помогать обеспечивать соблюдение этих стандартов. Забавно, что в части языках эти правила зафиксированы на уровне языка, например, в Go
9. Code review (обзор кода)
Здесь авторы излагают подход Google к code review как ключевому процессу для поддержания качества. Они описывают лучшие практики, преимущества (такие как обмен знаниями и раннее обнаружение ошибок) и то, как систематические обзоры поддерживают масштабируемую разработку.
10. Documentation (документация)
Эта глава сосредоточена на создании ясной, поддерживаемой и доступной документации. Авторы подчеркивают, как правильная документация помогает обеспечить долгосрочную жизнеспособность кода и облегчает процесс онбординга и сотрудничества.
11. Testing overview (обзор тестирования)
Авторы представляют общую философию тестирования в Google. Эта глава объясняет, как тесты являются важными для обнаружения проблем на ранней стадии, обеспечения надежности кода и возможности быстрых циклов разработки.
12. Unit testing (юнит-тестирование)
Авторы рассказывают про детали тестирования отдельных компонентов. Они подчеркивают важность хорошо написанных, быстрых юнит-тестов для проверки того, что небольшие части кода работают правильно. Забавно, что в некоторых компаниях инженеры не видят смысла в юнит тестах, так как они находят не все ошибки. Но unit tests - это не просто про поиск багов, это про написание кода, который является тестируемым. И уже эта цель приводит нас к хорошей декомпозиции кода на части, а также использованию композиционных подходов, которые позволяют заменить реализацию большинства компонентов во время тестирования.
13. Test doubles (тестовые дубликаты)
В этой главе обсуждаются стратегии применения дублей, таких как моки, стабы и фейки, которые используются для имитации частей системы в изоляции. Это гарантирует, что юнит-тесты остаются локальными и могут запускаться без зависимости от внешних компонентов.
14. Larger testing (более крупное тестирование)
В этой главе авторы выходят за пределы юнит тестов и рассказывают про интеграционные, системные и end2end тесты. Они объясняют, как эти более широкие тесты проверяют, что несколько компонентов работают правильно вместе.
15. Deprecation (устаревание)
Авторы предлагают рекомендации по выводу из эксплуатации старого или устаревшего кода. Они подчеркивают управление жизненным циклом функций и кодовых путей для поддержания стабильности, позволяя при этом эволюционировать и совершенствоваться.

Окончание будет в последнем посте из этой серии.

#Engineering #Management #Software #Development #Processes #Leadership #SRE #DevOps
1,675
Книжный куб

04 Feb, 05:08

Comic Agile - Aligning Teams (Рубрика #Humor)

Как-то из выступления Manuel Pais, автора Team Topologies, я узнал про этот ресурс. Мануэль показывал в своей презентации комикс про Team Topologies, а я вечером наткнулся на другой прикольный комикс про aligning teams, который тоже смешной и одновременно грустный.

#Management #Leadership #Software
1,645
Книжный куб

03 Feb, 11:14

[2/4] Software Engineering at Google (Делай как в Google. Разработка программного обеспечения) (Рубрика #Engineering)

Продолжая рассказ про эту крутую книгу, я хотел бы рассказать чуть подробнее о содержании книги, что состоит из 5 частей и 25 глав

I. Thesis (тезис)
1. What is software engineering? (Что такое инженерия программного обеспечения?)
В этой главе авторы рассказывают основную идею о том, что разработка софта не является одноразовой работой, а приводит к созданию развивающегося продукта. А это значит, что мы не пишем код аля write-once как раньше писали в Perl или сейчас генерирует условный LLM, а мы проектируем софт с учетом изменений, поддержки и долгосрочной жизнеспособности, а не быстрых ad-hoc задач. Хотя если вы пишите одноразовой скрипт, то логично использовать GPT:)
II. Culture (культура)
2. How to work well on teams (как хорошо работать в командах)
Эта глава фокусируется на навыках сотрудничества, коммуникации и практиках, которые позволяют разнообразным командам эффективно работать вместе, закладывая основу для крупномасштабных проектов. По-факту, только маленькие проект можно сделать в одиночку, а если планируешь что-то большее, то придется объединяться, а значит разработка софта - это командный вид спорта. И для достижения успеха в нем надо прокачивать soft skills:)
3. Knowledge sharing (обмен знаниями)
Эта глава подчеркивает важность документирования полученного опыта и insights. Здесь рассказывается про методы и процессы для обеспечения передачи ценных знаний. Забавно, что многие не любят сами писать документацию, но жалуются на ее отсутствие или неактуальность. Я как любитель письменного жанра рекомендую таким людям начать с себя и задать тренд по написанию документов, фиксирующих важные моменты, например, RFC/ADR, агенда встреч, PR/FAQ из подхода "Working backwards" от Amazon (подробнее в моем обзоре этой книги)
4. Engineering for Equity (инженерия для равенства)
Изучает, как справедливые процессы, равный доступ к инструментам и сбалансированное распределение рабочей нагрузки помогают поддерживать продуктивную и инклюзивную инженерную среду. Честно говоря, эта глава выбивается из общего списка, так как по всей видимости написана поборниками повестки и инклюзивности.
5. How to lead a team (как руководить командой)
Эта глава предоставляет практические рекомендации по руководству командой, подчеркивая четкую коммуникацию, согласование целей и построение доверия для того, чтобы команды могли работать наилучшим образом.
6. Leading at scale (руководство в масштабе)
Здесь обсуждаются проблемы, специфичные для управления очень большими командами. Авторы описывают масштабируемые практики управления и структуры, которые помогают поддерживать последовательную производительность и культуру по мере роста команд.
7. Measuring engineering productivity (Измерение производительности инженерии)
Эта глава посвящена неформальным и формальным метрикам для оценки эффективности инженерии. Авторы объясняют, как сбалансировать скорость с качеством, подчеркивая, что производительность заключается не только в результатах, но и в деятельности. Эта тема была мне настолько интересна, что я эту главу я давно уже разобрал в деталях в отдельном посте.

#Engineering #Management #Software #Development #Processes #Leadership #SRE #DevOps
1,706
Книжный куб

03 Feb, 09:12

"Дети Солнца" в театре-сцене "Мельников" (Рубрика #Culture)

На прошлой неделе я был на предпоказе этого спектакля в постаноке молодого режиссера Лизы Дороничевой на сцене Театра — Сцены "Мельников". Спектакль основан на пьессе Максима Горького, который написал ее 120 лет назад сразу после событий Кровавого воскресенья. Я не большой знаток театра, но могу сказать, что постановка мне понравилась, особенно первый акт, в котором мы знакомимся с бытом ученого Павла Протасова, представителя интеллегенции, который полностью погружен в свои исследования и обращает мало внимания на происходяшее вокруг. Мы видим идеализм и стремление к прогрессу Павла, но это имеет мало общего с реальной жизнью и проблемами окружающих, которых в пьессе достаточно много: безответная любовь, семейные конфликты и социальные противоречия, а также эпидемия холеры. Герои пьессы сталкиваются с одиночеством и невозможностью найти общий язык как между собой, так и с абстрактным народом. Второй акт разворачивает основные идеи пьесы, поэтому получается тяжелым и мы видим
- Разрыв между интеллигенцией и народом: мы видим пропасть между образованной элитой, мечтающей о светлом будущем, и простыми людьми, живущими в бедности и невежестве.
- Идеализм и реальность: герои стремятся к высоким идеалом, но оторванность от реальной жизни приводит к трагедии
- Социальное неравенство: мы видим разрыв между Павлом и его слугами, что усугубляет непонимание и приводит к социальным противоречиям
- Любовь и одиночество: Личные отношения героев отражают их внутренние конфликты и неспособность к взаимопониманию.
- Критика утопических идей: в конце пьессы мы видим как утопические идеалы разваливаются от контакта с реальным миром

Интересно, что название "Дети солнца" символизирует стремление героев к знаниям и прогрессу, но также указывает на их оторванность от реальности. Солнце становится метафорой иллюзорного света, который ослепляет героев, мешая им видеть окружающий мир. В самой постановке этот солнечный свет играет ключевую роль - он светит в красивое окно, иногда обжигающе ярко, иногда сквозь дождь, а в начале второго акта его просто нет с нами, что показывает, что настали тяжелые дни.

Отдельно отмечу, что постановка выполнена так, что мы оказываемся, фактически, вне времени и если не знать историю написания пьесы, то ни за что не поверишь, что ей 120 лет:)

P.S.
Кстати, художественным руководителем Театра на Бронной и Театра — Сцена «Мельников» является Константин Богомолов, который осенью прошлого года рассказывал о проектах нового сезона и где было упоминание о "Детях Солнца".

#Theater #Culture #SelfDevelopment
1,795
Книжный куб

03 Feb, 07:12

Обложки для книг "Software Engineering at Google" и "Делай как в Google. Разработка программного обеспечения"
1,729
Книжный куб

03 Feb, 05:08

[1/4] Software Engineering at Google (Делай как в Google. Разработка программного обеспечения) (Рубрика #Engineering)

Я читаю и перечитываю эту крутую книгу уже примерно пару лет, как раз с того момента, как она мне доехала с Amazon в 2022 году. Я никогда не читал ее в русском переводе от издательства "Питер", но перевод "Делай как в Google" по меньшей мере озадачивает меня, хотя я привык уже к играм разума российских издателей. Правда, я не читал перевод не из-за его качества, а потому что у меня была книга в оригинальном издании.

Если говорить про саму книгу, то она была написана Титусом Уинтерсом, Томом Маншреком и Хайрумом Райтом, а также большим количеством других уважаемых людей из Google. Каждая глава в этой книге написана отдельным коллективом авторов, причем часто изначально в виде whitepaper для конференций разработке софта. Я отметил две особенности, что помешали лично мне проглотить ее быстро
- Стиль изложения и динамика меняется от главы к главе - я не могу читать больше одной главы за один раз
- Главы написаны академическим языком, а значит достаточно формальным и сложным

Кстати: если вы хотите узнать про часть процессов разработки, связанных с continuous delivery, но изложенные простым языком, то рекомендую книгу "Grokking Continuous Delivery", которая тоже родилась в Google, но написана одним человеком и похожа по стилю на комикс. Кстати, я уже рассказывал про книгу "Grokking CD" раньше

Если же возвращаться к изначальной книге, то основная цель авторов книги - поделиться своим опытом и уроками, что инженеры Google получили из управления огромной кодовой базой и сложнейшей инфраструктурой. Ребятам было важно не просто нашмалять код по быстрому, но спроектировать его так, чтобы системы можно было поддерживать и развивать с течением времени. Вообще, ключевые идеи такие
- Programming over time (программирование с учетом эволюции): в книге подчеркивается, что хорошая программная инженерия — это не просто одноразовое программирование, а поддержка и развитие программного обеспечения в долгосрочной перспективе.
- Processes and scale (процессы и масштаб): авторы рассказывают и объясняют смысл процессов и практик, используемых в Google, например, про code review, стратегии тестирования и управление гигантским монорепозиторием. Эти процессы адаптированы к тем нефукнциональным требования и огромным масштабам, которые характерны для Google.
- Tools and infrastructure (инструменты и инфраструктура): авторы обсуждают, как специализированные внутренние инструменты и инфраструктура не только поддерживают, но и улучшают сотрудничество и эффективность среди инженеров (примерно про это идет речь в whitepaper "The issue of monorepo and polyrepo in large enterprises", про который я говорил раньше)
- Culture and collaboration(культура и сотрудничество): хотя некоторые разделы очень специфичны для Google, книга также подчеркивает важность формирования культуры, которая поощряет эффективное межкомандное сотрудничество и обмен передовым опытом. Частично про это можно почитать в проекте "Google's Project Aristotle", где ребята изучали, а что делает команды продуктивными (я рассказывал про этот проект раньше)
- Practical lessons (практические уроки): хотя многие практики уникальны для размера и ресурсов Google, книга содержит ценные сведения о проблемах создания и поддержки крупномасштабного софта

В целом, книга рассказывает о принципах создания софта, которые работают на крупном масштабе, но многие из которых уже давно стали стандартом де-факто и которые можно и нужно применять в технологических компаниях независимо от их размера. Условно, когда я рассказываю о лучших инженерных практиках из этой книги и слышу в ответ фразу "Мы же не Google", то у меня возникает вопрос, а точно ли надо быть сотрудником Google, чтобы чистить зубы перед сном или мыть руки перед едой.

В следующих постах я кратко расскажу о содержании книги по главам: часть про культуру

#Engineering #Management #Software #Development #Processes #Leadership #SRE #DevOps
1,883
Книжный куб

02 Feb, 09:12

Giilker Intelligent Four Square Chess (Рубрика #Kids)

Жена подарила мне эту игру на новый год. Мы немного поиграли в нее на новогодние праздники, а потом отложили. Но в последнюю неделю я каждый вечер играю со своим старшим сыном в эту игру и она нам очень нравится - у нее простые правила и она динамичная. По картинке видно, что игра представляет из себя поле 5x5, игроки ходят по очереди и должны выставить свои фишки четыре в ряд, побеждает тот, кто сделает это первым. Звучит все достаточно просто, но на самом деле поле состоит из 125 клеток (5*5*5), так как оно трехмерно и фишки можно ставить друг на друга. Поэтому победит тот, кто выставит четыре фишки в любом направлении: вертикальном, горизонтальном или диагональном. Сама игра позволяет играть вдвоем или соревноваться с компьютером - это очень удобно, так как можно потренироваться пока сына нет дома.

P.S.
Мне так понравилась игрушка, что я купил себе такую же на работу и она приедет ко мне через пару недель:)

#ForKids #ForParents #SelfDevelopment #Brain
2,377
Книжный куб

01 Feb, 10:13

Вопросы, для оценки реалистичности стратегии визионера (Рубрика #Strategy)

В прошлом посте я рассказывал про Theranos и подход к стратегии от Элизабет ХЗолмс. Там я указал список разных точек зрения, под которыми стоит посмотреть, чтобы попробовать отличить настоящую стратегию от фейковой, а в этом посте я чуть подробнее их раскрою

1) Четкое и реалистичное видение
Настоящая стратегия: Представляет ясное, вдохновляющее и достижимое видение, которое соответствует миссии и ценностям организации. Цели конкретны, измеримы и выполнимы.
Признаки мошенничества: Слишком расплывчатые или грандиозные заявления без реалистичного плана или осуществимости. Обещания невероятных результатов с минимальными усилиями — тревожный знак.
2) Детальный план реализации
- Настоящая стратегия: Включает конкретные шаги, распределение ресурсов, контрольные точки и планы на случай непредвиденных обстоятельств для достижения целей.
- Признаки мошенничества: Отсутствие конкретных деталей о том, как будут достигнуты цели, или чрезмерное использование модных слов и абстрактных концепций без четкого плана действий.
3) Участие заинтересованных сторон
- Настоящая стратегия: Активно привлекает членов команды и заинтересованных лиц к процессу планирования и принятия решений, способствуя сотрудничеству и прозрачности.
- Признаки мошенничества: Действует в изоляции или в условиях секретности, препятствуя участию других. Мошенники часто используют срочность, чтобы избежать проверки.
4) Эмоциональная привлекательность vs. Манипуляция
- Настоящая стратегия: Вдохновляет через искреннее общение, эмоциональный интеллект и соответствие общим ценностям.
- Признаки мошенничества: Использует тактику давления, страх или чрезмерное возбуждение, чтобы побудить к импульсивным действиям без должной оценки.
5) Соответствие долгосрочным целям
- Настоящая стратегия: Учитывает текущие приоритеты в сочетании с долгосрочными целями и демонстрирует адаптивность к изменяющимся обстоятельствам.
- Признаки мошенничества: Сосредотачивается на краткосрочных выгодах или нереалистичных обещаниях без учета долгосрочной устойчивости.
6) Прозрачность и доверие
- Настоящая стратегия: Вызывает доверие через открытое общение, проверяемые утверждения и надежное руководство.
- Признаки мошенничества: Использует чрезмерно сложные структуры для сокрытия намерений или избегает предоставления проверяемой информации об организации или руководстве.
7) Реалистичность обещанных результатов
- Настоящая стратегия: Устанавливает достижимые цели, подкрепленные данными, анализом рынка и реалистичными прогнозами.
- Признаки мошенничества: Делает преувеличенные заявления о гарантированном успехе или доходах, которые звучат слишком хорошо, чтобы быть правдой.

Чем больше красных флажков выскакивает при анализе визионерской стратегии, тем менее вероятно, что это реальная возможность, а не скам:)

#Management #Leadership #Strategy
2,048
Книжный куб

01 Feb, 07:40

Клубная встреча "Стратегия визионеров" от SouthHub (Рубрика #Management)

В один из вечеров на этой неделе я был на клубной встрече SouthHub, где мы обсуждали вопросы миссии, видения, стратегии и того, как эти высокие материии влияют на компанию. Правда, у нас был и практический интерес - как распознать, что тебе про эту миссию, видение и стратегию рассказывает визионер, наподобие, Стива Джобса, Илона Маска, Билла Гейтса или мошенник, наподобие, Элизабет Холмс, Сэма Бэнкман-Фрида или Адама Ноймана. Для подготовки к обсуждению нас попросили перед встречей глянуть документальный фильм "The Inventor: Out for Blood in Silicon Valley" ("Изобретатель. Жажда крови в Силиконовой долине"), который рассказывает историю единорога Элизабет Холмс под названием "Theranos", который обещал изменить сферу медицинских анализов. Сам фильм отлично рассказывает историю в динамике, приводя кусочки публичных интервью с Элизабет, а также остальными ключевыми участниками событий, поэтому рекомендую его посмотреть, если еще не видели - больно история интересная вышла.

Если же возвращаться к вопросу про отличия визионера от мошенника, то мы в ходе обсуждений пришли к выводу, что
1) Все высокие материи в виде миссии, видения, стратегии можно свести к высокоуровневым вопросам
- Зачем мы что-то делаем? - Миссия
- что конкретно мы делаем? - Видение
- Как мы это делаем? - Стратегия
2) Визионеры из списка выше (Джобс, Маск, Гейтс) отличаются от мошенников из списка ниже (Холмс, Бэнкман-Фрид, Ноймана) только результатами. Если бы у последних трех все сошлось, то мы бы продолжали говорить о них, как о звездах мира бизнеса. По-факту, многие визионеры топят со своей стратегией до талого и у кого-то получается довести "fake it until make it" до состояния made, а у кто-то остается у разбитого корыта
3) Но результаты визионера - это слишком lagging indicator, то есть мы хотим понять раньше выйдет ли что-то из задумки очередного визионера. Для этого можно задать ряд вопросов к его стратегии и проверить насколько консистентно выглядят ответы. Например, можно посмотреть под разными углами, например, так
- Четкое и реалистичное видение
- Детальный план реализации
- Участие заинтересованных сторон
- Эмоциональная привлекательность vs. Манипуляция
- Соответствие долгосрочным целям
- Прозрачность и доверие
- Реалистичность обещанных результатов

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

#Management #Leadership #Strategy
2,015
Книжный куб

31 Jan, 10:13

Стипендия Т-Образования (Рубрика #Edu)

Уже в четвертый раз открылась ежегодная стипендиальная программа для талантливых студентов. Она доступна для студентов российских вузов очной формы обучения и любого курса, кроме выпускного. Для попадания в программу нужно будет пройти отбор (экзамен, портфоли и интервью), причем пройти экзамен и подготовить портфолио надо до 7 апреля включительно. В программе есть 2 трека: аналитика и разработка.
Для тех, кто получит стипендию будут доступны плюшки в виде
- 25к рублей в месяц в течение учебного года
- Ментор в виде сотрудника Т-Банка
- Доступ к образовательным материалам компании, куда входят курсы, лекции и т.д., а также приглашения на закрытые отраслевые мероприятия
- Упрощенный отбор в штат на работу в Т-Банке после окончания стипендии

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

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

#Edu #SelfDevelopment
2,339
Книжный куб

31 Jan, 06:09

Иллюстрации для статьи "Adaptive Enterprise Architecture: Towards a model". Качество изображений оригинальное (в pdf они были настолько же плохими с точки зрения разрешения)
2,308
Книжный куб

31 Jan, 05:08

Adaptive Enterprise Architecture: Towards a model (Рубрика #Architecture)

Недавно я решил почитать whitepapers по enterprise architecture и наткнулся на статью ученых из Морокко, где они пытаются скрестить ежа с ужом, а точнее корпоративную архитектуру со скрамом:) В начале статьи авторы отмечают, что текущие подходы к корпоративной архитектуре (TOGAF, Zachman) не обладают необходимой гибкостью для обработки быстрых, разноуровневых изменений, что характерны для модных ныне цифровых трансформаций. Они сосредоточены на реактивных процессах, ориентированных на заполнение кучи документов и с их помощью сложно управлять непредвиденными изменениями. Дальше авторы решают сформулировать набор критериев для адаптивной корпоративной архитектуры, куда входят такие вещи как
1) Support multi-level dynamics (поддержка многоуровневой динамики) - изменения бывают на разных уровнях и идут с разной скоростью, а значит архитектурный процесс должен уметь работать с каждым типом изменений. Авторы отмечают, что стандартный подход с архитектурой as-is и to-be уже не является статичным, а подвергается различным изменениям, что надо учитывать в архитектурных процессах
2) Sensing of change (ощущение изменений) - процесс должен поддерживать ощущение идущих вокруг изменений и позволять планировать свои инициативы для адаптации к изменениям
3) Process of adaptation (процесс адаптации под новые потребности) - это ключевая часть подхода авторов, что называется adaptive enterprise architecture
4) Complexity of change management (комплексность управления изменениями) - TOGAF и Zachman проваливают этот критерий, ребята хотят подход, который будет сильно проще с точки зрения управления изменениями
5) Handling of unforseen changes (обработка непредвиденных изменений) - это нужно для современных корпораций, что сталкиваются с высокими темпами непредвиденных изменений в своем бизнес окружении.
6) Explicit management of adaptability trade-offs - авторы отмечают важность явного управления компромиссами по адаптивности к изменениям. Сейчас это зачастую просто одно из нефункциональных требований или атрибутов качества решений, а в новом подходе им надо управлять явно
7) Evaluation of adaptation (эволюция адаптации) - для управления адаптацией ее надо уметь измерять, а занчит нам нужны метрики внутри процесса корпоративной архитектуры

Дальше авторы сравнивают по этим критериям разные подходы к корпоративной архитектуре и оказывается, что все они не удовлетворяют критериям. Они объединяют подходы в группы
1) Approaches based on guidelines (Zachman, TOGAF, Koffi A.D, LEAP, DYA)
2) Integration oriented approaches (Shmidt R & al, Zimmerman A & al)
3) Co-evolution oriented approaches (DEEVA, ACEM, ...)

И дальше авторы решают предложить свой подход, который удовлетворяет критериям и полагается на проверенные временем agile подходы, а точнее на Скрам. Дальше они рассказывают о том, какой Скрам замечательный, а потом натягивают его на архитектуру
1) У нас появляется роли architecture owner, business/IT owners. Первый отвечает за стратегический alignment, а вторые за оптимизацию бизнес-процессов и технического решения
2) Работа идет в циклах по 2-4 недели и используются скрам ритуалы: weekly cross-owner syncs, architecture reviews для обеспечения фидбека
3) Появляется архитектурный беклог, в котором приоритизируются изменения корп архитектуры, а также есть KPI и отслеживание движения As-Is / To-Be на графиках
Все остальные ритуалы agile про связь бизнеса и IT остаются на месте, просто EA беклог и ритуалы адаптивной корпоративной архитектуры живут рядом.

Для меня это whitepaper показался натягиванием совы на глобус без особых объяснений как это будет работать на практике, а не на бумаге:)

#Architecture #Software #Management #Governance #Engineering
1,534
Книжный куб

30 Jan, 09:12

Обложки книг "Hooked: How to Build Habit-Forming Products" и "На крючке" и несколько иллюстраций самой модели.
1,715
Книжный куб

30 Jan, 08:11

Hooked: How to Build Habit-Forming Products (На крючке) (Рубрика #Management)

Эта уже классическая книга Нира Эяля рассказывает о том, как создавать продукты, которые захватывают пользователей и становятся неотъемлемой частью их повседневной жизни. В книге представлена модель крючка в виде процесса из четырех зацикленных шагов, что позволяют формировать привычки пользователей. В самой модели следующие четыре части
1) Trigger (триггер): запускает поведение пользователя через внешние сигналы (например, уведомления) или внутренние мотивации (эмоции или мысли).
2) Action (действие): поведение, выполняемое в ожидании вознаграждения, которое должно быть максимально простым для пользователя.
3) Variable reward (переменное вознаграждение): результат действия, который удерживает пользователей благодаря своей непредсказуемой природе.
4) Investment (инвестиция): вклад пользователя в виде времени, данных, усилий или денег, что повышает вероятность возвращения к продукту.

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

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

1) Duolingo создал формирующий привычку опыт изучения языков:
- Триггер: отправляет ежедневные уведомления о целях изучения языка.
- Действие: предлагает геймифицированные, легко выполнимые уроки.
- Переменное вознаграждение: предоставляет очки опыта и достижения за серии успехов.
- Инвестиция: отслеживает прогресс и адаптирует пути обучения на основе результатов пользователя.
Я сам пользуюсь duolingo и у меня нерпрерывный streak сейчас в 2 года

2) TikTok стал крайне привлекательным, используя модель hooked:
- Триггер: внешние триггеры включают видео, которыми делятся друзья, в то время как внутренние триггеры обращаются к желанию развлечься.
- Действие: предлагает простой процесс создания аккаунта и легкий просмотр видео.
- Переменное вознаграждение: представляет постоянный поток разнообразных, персонализированных коротких видео.
- Инвестиция: позволяет пользователям создавать и делиться своими собственными видео, увеличивая привязанность к платформе.

3) Slack стал популярной платформой для коммуникации на рабочем месте и она тоже применяет модель hooked:
- Триггер: использует как внешние, так и внутренние триггеры для привлечения внимания пользователей.
- Действие: предлагает удобный интерфейс для легкого обмена сообщениями и участия в каналах.
- Переменное вознаграждение: доставляет вознаграждения в виде положительной обратной связи и уведомлений о выполнении задач.
- Инвестиция: поощряет вклад пользователей через обсуждения и участие в проектах.
Мы использовали Slack до того, как перешли на наш мессенджер Time.

Но есть у модели и стандартные проблемы, которые могут уменьшать ее эффективность
1) Несоответствие потребностям пользователей - неспособность понять реальные проблемы пользователей или создание решений для несуществующих проблем.
2) Чрезмерное усложнение модели - слишком сложный UX или слишком много фичей могут оттолкнуть пользователей
3) Неэффективные системы вознаграждений - если вознаграждения слишком предсказуемы, то это плохо. Одновременно плохо, если они неконсистентны между собой и не поддерживают интерес и мотивацию пользователей.
4) Пренебрежение фазой инвестиций - слишком слабое или слишком сильное поощрение вклада пользователей в приложение приведет к тому, что они сорвутся с крючка
5) Этические проблемы - привычки должны приносить пользу клиентам иначе легко провалиться на темную сторону силы

#Management #ProductManagement #Econimics #PopularScience
1,578
Книжный куб

29 Jan, 06:09

Влюбленные в математику (Рубрика #Math)

Вчера я был на премьере этого документального фильма Ольги Ажнакиной в Центральном доме кинематографистов в Москве. Фильм рассказывает истории трех молодых ученых-математиков: Александра Безносикова, Дарины Двинских и Александра Гасникова. Интересно, что их истории рассказываются закадровым голосом главных героев, но параллельно мы видим как они работают в ведущих научных центрах, включая МФТИ, Сколтех, ВШЭ, Иннополис и Сириус. Когда, я смотрел фильм, то сам вспомнил как мне нравилась математика, как я учился в ЗФТШ, а потом на Физтехе и как думал, что стану ученым, но ушел в индустрию и последние 20 лет работаю в IT:) Ученым я не стал, но получиив специальность по прикладной математике и физике с переменным успехом прикладываю ее к решению рабочих задач. Если же возвращаться к фильму, то вчера после самого просмотра был открытый микрофон и вопросы из зала, на которые отвечали режиссер и главные герои фильма и вот что там обсуждалось
1) Почему фильм именно про математиков?
Режиссер ответила, что изначально у нее было "стереотипное видение ученых-математиков" как скучных и несовременных людей. Фильм стремится разрушить этот стереотип, показывая математиков как "свободных, творческих, креативных молодых ребят"
2) А где трудности и препятствия, что преодолевают ученые? Кажется в фильме у ребят все получается?
Тут ответ был в том, что получается далеко не все. Например, часть где Александр Гасников решает стать не просто ученым, а научным функционером, заняв пост ректора Иннополиса - тут есть и нерв и преодоление себя. Кстати, тут мне сразу вспоминается дуальность А-Януса и У-Януса из "Понедельник начинается в субботу" Стругацких
3) Почему фильм такой короткий?
В нем действительно всего полчаса, но смотрится он на одном дыхании
4) Почему фильм заканчивается танго главной героини?
Ответ про красоту математики, которую можно сравнить с красивым танцом.

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

P.S.
Во время просмотра фильма я вспоминал книгу знаменитого математика Эдуарда Френкеля "Love and Math: The Heart of Hidden Reality" ("Любовь и математика"), которая показалась мне похожей по настроению и которая раскрывает красоту и элегантность математики, сравнивая ее с произведением искусств.

#PopularScience #Mathematics #Math
2,140
Книжный куб

28 Jan, 06:09

Deductive Software Architecture Recovery via Chain-of-thought Prompting - Part I (Рубрика #Architecture)

Вчера перед сном прочитал интересный whitepaper про процесс SAR (Software Architecture Recovery) при помощи LLMs. Мне идея показалась интересной, чтобы кратко рассказать про нее.

1) Стандартный подход к Software Architecture Recovery обычно работал снизу-вверх (bottom-up). Условно, некоторый анализатор кода запускался строил архитектурные метрики, которые как-то характеризовали архитектуру проекта (что-то в духе кейсов из книги "Software Architecture Metrics: Case Studies to Improve the Quality of Your Architecture", про которую я уже рассказывал)
2) В этом paper исследователи решили пойти сверху-вниз (top-down) и начать с задания референсной архитектуры, а дальше уже классифицировать части кода как относящиеся к той или иной части этой референсной архитектуры. Это позволяет не просто собрать текущее состояние архитектуры как было в стандартном подходе, а оценить расхождение между референсной архитектурой проекта и тем, что у нас есть на самом деле:)
3) Авторы говорят о том, что этот подход больше похож на то, как работают software engineers, так как обычно инженеры знают какая базовая архитектура в проекте, поэтому могут использовать эти знания при изучении кода

Дальнейшее описание процесса в следующем посте, а в приложении к этому основные иллюстрации с описанием процесса, описанием индикаторов компонентов архитектуры, а также промптом для LLM, который используется в классификации.

#Architecture #Software #Metrics #LLM #AI #ML #Engineering #RnD
1,420
Книжный куб

27 Jan, 09:12

Обложки для книг "The Golden Passport: Global Mobility for Millionaires" и "Золотой паспорт: Глобальная мобильность для миллионеров"
1,714
Книжный куб

27 Jan, 06:09

The Golden Passport: Global Mobility for Millionaires (Золотой паспорт: Глобальная мобильность для миллионеров) (Рубрика #Economics)

Прочитал за последнюю неделю интересную книгу с подробным исследованием программ гражданства через инвестиции, которые часто называют еще "золотыми паспортами". Книгу написала Кристин Сурак, доцент политической социологии Лондонской школы экономики и политических наук. Для этого она много лет исследовала эти программы, посещала конференции, общалась с посредниками, представителями правительств карликовых государств, а также с самими покупателями. По итогу, у нее получилась глубокая и интересная книга, которая раскрывает как историю вопроса, так и текущее состояние дел в этой области, где состоятельные люди могут фактически купить гражданство в различных странах.

Основные моменты книги включают:
- Исследование трансформации продажи паспортов от сомнительной практики до процветающей индустрии, в которую вовлечено более десятка стран. Интересно, что формально и в России есть программа гражданства через инвестиции, а глобальным лидером сейчас является Турция, которая перехватила лидерство у Кипра. В Карибском бассейне еще есть старожилы рынка инвестиционных паспортов в виде Сент-Китса, Гренады, Доминики, Сент-Люсии, Антигуа и так далее
- Анализ сложных причин этого явления, включая желание повысить глобальную мобильность, получить налоговые льготы и обеспечить страховку от политической нестабильности.
- Масштаб рынка - порядка 50к человек, что ежегодно приобретают гражданство через эти программы, стоимость зависит от программы, но начинается все с нескольких сотен тысяч долларов и может доходить до миллионов
- Исследование последствий этой практики для концепций гражданства, глобального неравенства и взаимосвязи между богатством и национальной принадлежностью.

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

P.S.
Это книга издательства Fortis Press, которая публикует переводы недавних интересных книг на актуальные темы. О парочке книг этого издательства я уже рассказывал раньше
- Woke, Inc. За фасадом корпоративной риторики о социальной справедливости (Woke, Inc.: Inside Corporate America's Social Justice Scam)
- Taming Silicon Valley: How We Can Ensure That AI Works for Us

#Economics #History
1,865
Книжный куб

26 Jan, 16:57

Книга-квест "Ам Ням. Жми" (Рубрика #ForKids)

Вчера прочитал перед сном сыну эту книгу, в которой 20 небольших глав, а сегодня мы прошли все мини игры в дополненной реальности. Если кратко, то описание книги обещает раскрыть истинную историю появления Ам Няма, а потом Ам Ням спасет мир от супер-злодея из комптьютерной игры. Мне показалось, что это неплохая книга для дошкольников - весело и интересно, а родителям забавно читать про взаимоотношение Ам Няма и его "дамочки" сердца, Ам Няши, которую он спасает на протяжении всей книге.

P.S.
Книги от DEVAR нравятся нашим детям и у нас дома собрался из них полный комплект, а о некоторых я уже рассказывал: например, о "Живой раскраске Смешарики".

#ForKids #ForParents #Tales
1,951
Книжный куб

26 Jan, 05:08

Недавно выступал на конфе имени Андрея Смирнова из X5, где рассказывал про soft skills и важности баланса между ними и hard skills. На записи есть проблемы с качеством звука, поэтому краткое саммари того, что я рассказывал такое
1) Эволюция разработки и роль софтов
- Разработка за последние 20 лет стала сложнее.
- В современных компаниях разработчики должны проектировать системы, писать код и тесты.
- Важность коммуникации и взаимодействия между различными ролями в разработке.
2) Pipeline Driven Organization и абстракции
- Pipeline Organization: интеграция различных ролей в начале процесса.
- Нам нужно использовать абстракции для упрощения работы, но все равно остается необходимость взаимодействия с деталями.
- Важность понимания под капотом систем и взаимодействия с разработчиками.
3) Сложность современного мира и коммуникация
- Мир меняется быстро, что требует постоянной адаптации.
- Коммуникация становится ключевым фактором в сложных и хаотичных условиях.
- Конечно можно работать на одном уровне, но часто люди хотят активного роста.
4) Рост в инженерии и лидерство
- Возможность роста в инженерии через индивидуальные проекты и менеджмент.
- Важность лидерских качеств и умения вести за собой команду.
- Инициатива о повышении исходит от самих сотрудников.
5) Личный опыт и планирование роста
- Личный опыт становления руководителем и важность планирования времени.
- Умение брать ответственность и доводить дела до конца.
- Важность коммуникационных навыков и навыков переговоров.
6) Мотивация и планирование
- Важно понимать, зачем ты делаешь то, что делаешь.
- Поддерживай мотивацию окружающих, особенно если ты лидер.
- Планирование помогает структурировать задачи и достигать целей.
7) Матрица Эйзенхауэра
- Важные и срочные задачи решаются сразу.
- Важные, но не срочные задачи откладываются на потом.
- Срочные, но не важные задачи можно делегировать.
- Цели должны быть амбициозными и достижимыми.
😍 Подход от желаемого результата (working backwards)
- Начинайте с желаемого результата, а не с текущего состояния.
- Стройте шаги от цели к текущему состоянию, а не наоборот.
• Это помогает избежать ментальных блокировок и достигать амбициозных целей.
9) Проектный менеджмент
- Проектный менеджмент полезен для больших задач с большими затратами на координацию
- Важно уметь использовать проектный менеджмент для достижения целей.
10) Принятие ответственности
- Признайте и примите ответственность за свои действия.
- Четко определите свои обязанности и цели.
- Фокусируйтесь на том, что можете контролировать
11) Решение проблем и рефлексия
- Решайте проблемы, а не откладывайте их.
- Учитесь на своих и чужих ошибках.
- Будьте устойчивы к проблемам и показывайте пример.
12) Развитие навыков коммуникации
- Активное слушание помогает лучше понимать собеседника.
- Адаптируйте стиль коммуникации под аудиторию.
- Важно понимать, что хочет услышать аудитория, и адаптировать свои выступления.
13) Проблемы с ясностью и публичными выступлениями
- Обсуждение важности ясности в речи и публичных выступлениях.
- Личный опыт выступлений на конференциях и трудности с эмоциями.
- Важность фидбека и рефлексии для развития коммуникационных навыков.
14) Планирование и чекпоинты
- Идея планирования с чекпоинтами для достижения больших целей.
- Личный опыт написания постов и создания книг.
- Важность фиксации результатов и планирования для достижения успеха.
15) Теоретический и практический подходы
- Различие между теоретическим и практическим подходом к решению проблем.
- Личный опыт работы с теоретическими и практическими методами.
- Важность фиксации и повторения результатов для роста и развития.
16) Лидерство и софт скилы
- Софт скилы важны как для инженеров, так и для лидеров.
- От высокогрейдового инженера сейчас ожидается лидерская проактивная позиция
- Для достижения амбициозных результатов необходимы лидерские качества и эффективные коммуникации.
- Без этих навыков сложно достичь масштабных результатов.

#Management #Leadership #Software #Processes #SelfDevelopment
2,054
Книжный куб

25 Jan, 09:12

Teaching Software Architecture Design - Building Intuition - Part II (Рубрика #Architecture)

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

Анализ гипотез по отношению к требованиям в итоге должен вести к
- Развитию инженерного подхода к принятию дизайн решений
- Повышению уверенности инжнеров, что предложенный ими диазайн удовлетворяет требованиям
- Способствует дискуссии о компромиссах, которые принимаются при выборе того или иного варианта дизайна

Для этого авторы предлагают использовать подход с опровержимой аргументацией (defeasible argumentation), в которой аргументы принимаются на текущий момент, если они звучат разумно и приняты на основе доказательств, что есть на текущий момент. Но эти аргументы могут быть пересмотрены при появлении новых данных. Этот подход очень напоминает то, как работают люди, что проектируют софт
- Они опираются на текущие данные и принимают решения в этом контексте
- При появлении новой информации они могут увидеть, что это противоречит предпосылкам, на которых был основан дизайн раньше
- А это потребует принятия нового решения, что изменит старое
Обычно такой процесс реализуется с использованием подходов RFC и ADR, где
- RFC - это request for comments или подход коммитетов к принятию решения
- ADR - это architecture decision record, что добавляется в список принятых архитектурных решений.

В рамках SADM студенты учатся задавать критические вопросы по отношению к дизайн гипотезам, практикуясь в формулировании аргументации, а также в ее опровержении. Причем здесь есть 2 формата аргументов

1) Аргументы для анализа use cases
Если предложенная гипотеза о декомпозиции помогает реализовать необходимое поведение для конкретного сценария, то студенты могут попробовать задать критические вопросы вида
- Какие исключения из шагов в сценарии делают его вклад в вариант использования недействительным?
- Есть ли какие-либо побочные эффекты предлагаемой архитектуры, которые отрицательно влияют на шаги или мешают им выполняться?
- Вносит ли предлагаемая архитектура отрицательный вклад в другие требования системы (варианты использования или требования к атрибутам качества)?
- Нарушаются ли какие-либо ограничения во время выполнения сценария или его исключений?

2) Аргументы для анализа атрибутов качества
Эта часть посложнее, так как требует много лет опыта, чтобы приводить неотразимые аргументы. А у начинающих часто аргументы звучат в формате "так работает google/aws/netflix", а значит это масштабируется, что является очень слабым аргументом. Здесь авторы предлагают студентам делать отсылки к референсной архитектуре, а также общепринятым архитектурным паттернам. Например, во второй части книги "Software Architecture in Practice" есть примеры паттернов, что приведены в свзяи с теми атрибутами качества, которые они поддерживают. Для использования паттернов можно использовать следующий подход
- Показать, как предлагаемая архитектура является примером задокументированного шаблона или эталонной архитектуры.
- Показать, что шаблон или эталонная архитектура, как известно, удовлетворяют указанному атрибуту качества.
Критические вопросы, которые студенты могут задавать по этим аргументам звучат примерно так
- Включает ли предлагаемая архитектура другие паттерны, которые отрицательно влияют на атрибут качества?
- Мешает ли предлагаемый шаблон/эталонная архитектура другому требованию к системе?

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

P.S.
Мне кажется, что здесь описан логичный и легкий процесс того, как можно подтянуть свои умения в дизайне сложных систем:)

#Architecture #Software #Engineering #SelfDevelopment
1,986
Книжный куб

25 Jan, 05:08

Tidy First? A Daily Exercise in Empirical Design • Kent Beck • GOTO 2024 (Рубрика #Architecture)

Интересное выступление Кента Бека, который когда-то не просто участвовал в подписании Agile Manifesto, а был первым подписантом среди уважаемых джентельментов ... так как шел первым по алфавиту. В этом выступлении Кент, создатель методологии XP (eXtreme Programming) рассказывает о своих экстремальных подходах к дизайну и кратко про книгу "Tidy First?", про которую я уже рассказывал раньше. Если кратко обобщить его рассказ в этом выступлении, то получится следующее

1) Начинается все с мотивации к деятельности - у нас есть порядка 3 млрд секунд (~ 95 лет). Если думать об истекающем времени, то есть мотивация не тратить его впустую
2) А в разработке софта есть много таких бесполезных вещей, например, автор так троллит тему с документацией:)
3) Когда-то давно автор участвовал в панельной дискуссии на конфе с корифеями Edward Yourdon, Larry L. Constantine, что написали книгу "Structured Design". Кент к той панельке прочел эту книгу и решил написать обновленную версию
4) Так появилась "Tidy First?", где Кент говорит про то, как наводить порядок в коде. Это позволит разработчику улучшить свое рабочее место и упростить работу.
5) Есть идея на вторую книгу "Tidy together?", в которой Кент планирует рассказать про совместную работу инженеров в командах, а в третьей книге будет рассказ про связь технологий с бизнесом
6) Основная идея автора - важность дизайна для изменения поведения системы. Софт состоит из фунукций и структуры. Про фукнции думает бизнес, а структура является backbone для этих функций
7) Если мы только клепаем фичи, то структура оказывается недоинвестированной - мы создаем технический долг, что усложняет внедрение новых фичей в дальнейшем
8 ) Цель правильного подхода в том, чтобы сбалансировать инвестиции в функции и структуру (автор приводит пример с выпиливанием дублирующего функционала)
9) Кент много говорит про социальные эффекты в разработке, про доверие и отвественность, а также разные стимулы и интересы у разных участников процесса. Обычно это называют социотехнической системой.
10) Кент много говорит про ограничения документации вида того, что она устаревает быстрее, чем ее обновляют и т.д. но не ясно какую альтернативу он предлагает
11) Кент говорит, что в разработке софта совокупная стоимость владения складывается по большей части из стоимости поддержки и модификации написанного, а не из первоначальных инвестиций в написание кода. Кстати, про этот тезис часто сейчас забывают, когда оценивают эффекты написания кода LLM ассистентами, считая только легкость начальной генерации кода:)
12) Но не все изменения стоят одинаково - обычно небольшие изменения стоят недорого, но много небольших изменений могут накапливаться и превращаться в большее, которое может стоить как значительная часть системы. В терминальном случае это большое изменение приводит к запрету версии 1.0 и создании нового пректа с нуля
13) Для снижения стоимости изменений, которые точно будут, надо понимать структуру затрат - это поможет подготовить софт к эволюции по мере изменений требований бизнеса
14) Кент говорит про coupling и про то, что изначально coupling между компонентами означал что изменения в одном элементе могут потребовать изменений в других. А потом определение Edward Yourdon, Larry L. Constantine начало мутировать и потеряло изначальный смысл
15) При разработке ПО нужно учитывать стоимость связей и стоимость их отсутствия. Важно находить компромиссы между стоимостью изменений и их последствиями. Пространство компромиссов помогает оценить целесообразность изменений.
16) Оценивать эти компромиссы лучше понимая экономические факторы вида NPV и стоимости денег во времени, оценки рисков и так далее. Например, инвестиции в структуру создают возможности для будущих изменений, что дает нам опцион на реализацию дешевых изменений в будущем
17) Отдельно автор отмечает, что наличие ограничений дает инженерам пространство и стимул для хороших решений:)

#Architecture #Software #SystemDesign #Management #Leadership #SoftwareArchitecture
1,985
Книжный куб

24 Jan, 13:18

Teaching Software Architecture Design - Building Intuition - Part I (Рубрика #Architecture)

Прочитал недавно интересный whitepaper про обучение архитектуре от Gaurav Agerwala, Len Bass. Заинтересовался я этой статьей из-за ее автора - Len Bass, который является соавтором классической книги "Software Architecture in Practice" и преподает в Carnegie Mellon University. И могу отметить, что я не был разочарован - подход авторов к обучению чем-то напоминает тот процесс system design interview, что мы практикуем у себя в компании:) Кстати, описание подхода есть на Github

Ну а теперь давайте перейдем к самой статье.

Исследователи в статье рассказывают о своем методе и структуре курса, который ставит себе целью демистифицировать процесс проектирования софта и помочь студентам думать аналитически, одновременно развивая интуицию, о компромиссных решениях, принимаемых на этапе проектирования. Но начинается все с введения, где авторы вспоминают про разные процессы проектирования
- ACDM (Architecure Centric Design Method) - итеративный подход из середины двухтысячных к проектированию софта, который ставит проектирование в центр процессов разработки. Подробнее можно почитать здесь
- ADD (Attribute Driven Design) - системная методология из начала двухтысячных для проектирования софта, которая фокусируется на внедрении и приоритизации атрибутов качества (quality attributes) одновременно с функциональными требованиями. Цель в том, чтобы создать эффективную архитектуру, которая будет удовлетворять как функциональные, так и нефункциональные требования.

К обоим подходам имел отношение Len Bass, но для студентов он решил сделать процесс SADM (Software Architecture Design Method), который доступен на GitHub и который фокусируется на ключевых активностях по идентификации и анализу верхнеуровнего дизайна на основе требований. В этом он похож на ADD, но он менее формален и фокусируется на том, чтобы помочь студентам наработать интуицию. Здесь фокус скорее не на отдельных шагах сложного процесса, а на практике в дизайне сложных систем, где много неизвестных. Сама суть метода SADM в том, чтобы дать дизайнером инструмент для работы с этими неизвестными. SADM - это метод для декомпозиции системы или компонета, который выглядит так
- У нас на входе есть требования
- Мы строим контекстную диаграмму
- Дальше выбираем scope для декомпозиции
- Предлагаем гипотезу того, как можно сделать декомпозицию
- Проверяем, что при этом мы удовлетворяем функциональные требования (сценарии)
- Проверяем, что при этом удовлетворяем атрибуты качества (кстати, в Github репозитории есть презентации про такие атрибуты как availability, performance, observability, security, modifiability, integrability)
- Если у нас есть неизвестные моменты, то мы заносим их в таблицу с process steps, чтобы разобраться с ними позже
Такая декомпозиция идет пока мы не декомпозировали систему на части так, чтобы закрыть все требования.

А теперь немного про process steps, куда мы переместили моменты, по которым требовалась дополнительная работа. Собственно, там могут быть 3 активности
- Отложенные решения - это решения, что мы отложили до появления новой информации. Например, использовать DBaaS решение или разворачивать самому кастомную технологию. Это решение может принимать после некоторого количества итерацаций SADM процесса
- Исследовательские активности - возможно требуется дополнительный сбор информации и поиск по внешним источникам, например, варианты подключаемых устройств к умному дому при дизайне IoT системы
- Активности по тестированию - некоторые решения стоит принимать после построения прототипа и проверки гипотез на нем.

Продолжение разбора статьи в следующем посте.

#Architecture #Software #Engineering #SelfDevelopment
1,903
Книжный куб

24 Jan, 05:08

Как я начал публично выступать (Рубрика #LifeStory)

Вчера я был на ИТ-квартирнике от наших devrel, который они проводили для людей, кто много делает для технического бренда компании. Мероприятие было теплым и ламповым - я пообщался со старыми знакомыми и похлопал коллегам, что победили в разных номинациях и поехал домой. Но пока ехал, я решил свпомнить о том, как я поборол страх выступлений и впервые вышел на сцену большой конференции, которой оказалась Teamlead Conf.

К этому привели события весны 2018 года, когда я решил в марте с друзьями съездить в Сорочаны покататься на сноуборде. Вроде это должна была быть рядовая поездка, ведь катать я начал лет за девять до этого, пару раз ездил в Альпы, достаточно много катал в Подмосковье. Но тут все пошло не по плану - за мной утром, как мы и договаривались заехали друзья и мы поехали на каталку. В ту ночь я поспал пару часов, но считал, что этого достаточно. Незадолго до этого я купил жесткую и быструю доску и очень хотел ее обкатать ...

Дальше я помню, как я очнулся на пассажирском сидении автомобиля, у меня болела голова, грудь, нога ...
Я повернулся к своему другу, что вел машину и задал вопрос "А где мы и что происходит?". Он посмотрел на меня и, как бы нехотя, начал рассказывать, что мы поехали на склон, приехали и начали кататься, прошел где-то часик, а потом один из них увидел как кого-то похожего на меня увозят на снегокате в сторону медпункта. Дальше они пришли туда и увидели, как мне оказывают помощь. В какой-то момент я очнулся и дальше начал задавать вопросы в стиле "А где мы и что происходит?", мне на них отвечали, но через 30 секунд происходил reboot и дальше я задавал их по новой. Мои друзья решают отвезти меня в Москву, чтобы вызвать для меня скорую и положить в московскую больницу. Медперсонал дает совет по дороге общаться со мной и отвечать на повторяющиеся вопросы, ожидая, что через N итераций ребуты перестанут происходить и память схватится.

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

Из этого происшествия я вынес несколько важных уроков
1) Не стоит в плохой форме заниматься экстремальными видами спорта
2) Даже если ты профи в чем-то, то техника безопасности наше все (теперь шлем всегда со мной)
3) Очень тяжело чувствовать себя как главный герой из романа "Цветы для Элджернона" ("Flowers for Algernon")
4) Через месяц, когда из основных пост-эффектов остались только очки, я решил, что надо начать больше делится своим опытом с окружающими - чтобы были материальные подтверждения для потенциальных внуков, что их дедушка до того, как впал в маразм, был достаточно прошаренным :)

Осенью 2018 года я уже выступил на питерском Teamlead Conf, где рассказывал про то, как мы выстраивали процессы разработки в наших фронтовых командах. Если найти запись этого выступления, то видно, что я сильно волнуюсь и мне сложно дается выступление на публике. Но с тех пор много воды утекло, поэтому сейчас публичные выступления на русском для меня это просто. В конце 2019 года я планировал в 2020 году податься на западные конференции и съездить выступить ... но не сложилось. Но из этих публичных выступлений вырос мой бложик TellMeAbout.Tech, а также этот tg канал.

P.S.
Как мне сказал однажды мой лучший друг: "В любых ситуациях надо попробовать увидеть лучшее, а не фокусироваться на проблемах". Кажется, что я внял совету и теперь вспоминаю про то падение, не как о причине серьезной травмы, а как триггер серии событий, что привели меня к знакомству с моей будущей женой. Мы с ней познакомились и начали общаться на первой конференции ArchDays, которую я открывал в главном зале, а она была ведущей второго зала:)

#Storytelling #PublicSpeaking #Leadership #SelfDevelopment
2,154
Книжный куб

23 Jan, 08:16

Think Like a CTO (Настоящий CTO: думай как технический директор) - Part II (Рубрика #Management)

В продолжении первого поста о книге "Think Like a CTO" здесь я расскажу про вторую часть книги.

7. Ежегодная оценка сотрудников - здесь автор рассказывает про performance review, промотирование и увольнение сотрудников. Я отдельно рассказывал про performance review, а также про наш процесс Т-Роста, который мы используем для роста сотрудников
8. Технологические решения - рассказ о том, как принимать сложные технологические решения, например, buy vs build, on-prem vs cloud, reliability vs cost или closed source vs open source, микросервисы или монолиты. Если кратко, то автор рассматривает плюсы и минусы каждого из подходов. Но вообще, общий паттерн рассмотрения вопроса долженн быть таков, что надо провести исследования, сравнить альтернативы, а потом принять решения. Я больше 5 лет назад рассказывал примерно об этом в докладе "Архитектура в масштабе или как мы в Tinkoff принимаем архитектурные решения"
9. Разработка - здесь автор рассказывает пару страниц о проектном управлении, потом криво рассказывает про waterfall и agile (очень криво), дальше про обеспечение качества. Честно говоря, это очень слабая глава, ооочень. По поводу проектов и продуктов рекомендую почитать мою статью, а про инженерные процессы рекомендую глянуть книгу "Grokking Continuous Delivery", про которую я рассказывал недавно
10. Работа с договорами - здесь гигиеническая база по договорной работе и важности привлечения юристов для изучения договоров:) А также важность лицензий на интеллектуальную собственность в общем, и код в частности.
11. Документация - здесь автор рассказывает базу про документацию. Правда, здесь видно, что автор привык работать в маленьких конторах и, например, предлагает документировать релизный процесс, а не нормально его автоматизировать. В общем, опять слабая глава.
12. Безопасность - очередная базовая глава про безопасность. Рекомендую вместо этого почитать книгу от Goolge "Building Secure and Reliable Systems", про которую я рассказывал. Также можно почитать старенькую книгу "Agile Application Security", про которую я рассказывал раньше
13. Поддержка и обслуживание - здесь автор рассказывает про operations часть, но делает это очень базово:) Рекомендую вместо этого почитать про это мой доклад о том, как проектировать надежные системы и поддерживать их надежность во время эксплуатации системы
14. Рост компании - глава про проведение due diligence, принятии и передаче должности технического директора. В принципе, норм, но очень базово.
15. Вы, Inc - глава о том, как идти в ногу со временем, поддеживать свой технический уровень, а также скиллы руководителя. А в конце автор дает совет, что не стоит задерживаться на работе, которая не соответствует вашим долговременным карьерным целям и не приносит удовлетворения.

P.S.
Про должности и ответственность CTO я уже как-то рассказывал в посте про инфляцию должности CTO

#Management #Leadership #Processes #Software #Architecture #Strategy #ChangeManagement
2,494
Книжный куб

23 Jan, 08:11

Обложки книг "Think Like a CTO" и "Настоящий CTO: думай как технический директор"
2,364
Книжный куб

23 Jan, 05:08

Think Like a CTO (Настоящий CTO: думай как технический директор) - Part I (Рубрика #Management)

Прочитал на неделе эту книгу Алана Уильямсона, что работает в частном инвестиционном фонде и часто выступает временным CTO для небольших компаний, что покупает этот фонд. Алан написал достаточно интересную книгу на тему бытия техническим директором. По оглавлению книга выглядит как надо - автор постарался обсудить большую часть важных тем. Правда, если заглядывать внутрь, то многие из этих тем прокопаны не слишком глубоко. Я связываю это с тем, что Алан работал в основном с небольшими и нетехнологическими компаниями, поэтому его советы годятся на инженерный масштаб до нескольких десятков людей. Оригинальная книга издана в Manning, а перевод вышел в издательстве "Питер" и он приемлемый.

А теперь давайте заглянем в содержание книги

1. Технический директор - размышления автора насчет содержимого роли технического директора в зависимости от размера компании, ее типа, стадии жизненного цикла. В далеком 2021 году я рассказывал доклад "Что такое CTO от стартапа до IPO" на Highload++". Смысл примерно такой же, но мне кажется, что у меня получилось поинтереснее:)
2. Взаимодействие с руководителями и коллегами - здесь автор рассказывает как находить общий язык с CEO и CFO. Звучат советы про то, чтобы понять потребности коллег и найти с ними общий язык. Вообще важно уметь в правильные коммуникации и разбираться во внутренней политике:) А также надо уметь правильно реализовывать изменения.
Отдельно автор упоминает про разные стили лидерства, приводя в пример оркестр - тут я рекомендую почитать книгу "Несведущий маэстро" ("The ignorant maestro") про стили лидерства на примере стилей знаменитых дирижеров, про которую я уже рассказывал. А также рекомендую изучить книгу "Seat at the Table", которая рассказывает что нужно уметь техническому директору, чтобы сидеть за одном столом с другими топ-менеджерами (я про нее тоже рассказывал).
3. Долгосрочное видение - здесь речь идет про видение, миссию, стратегию организации, а также необходимость сделать так, чтобы технологическая стратегия помогала с этим. Автор рассказывает про долгосрочное планирование, питчинг идей, бюджетирование, окупаемость проектов, а также работу с ожиданиями стейкхолдеров. Я на эту тему могу порекомендовать отличную книгу "Technology Strategy Patterns. Architecture as Strategy", которую я изучил больше пяти лет назад и которая дала мне многое в плане построения технологической стратегии (я рассказывал про нее здесь)
4. Создание команды - здесь автор рассматривает разные способы формирования команды: найм в штат, найм на подряд, аутстафф, аутсорс и так далее. По-факту, автор дает базовую сравнительную табличку с плюсами и минусами каждого из вариантов. Также он рассказывает про матрицу навыков, которую стоит заполнять по своим людям в команде, чтобы понимать какие области небходимых навыков закрыты хорошо, а по каким есть риски (условно, только Петя знает про инфру и если он уйдет, то хз что станет с серверами) - это позволяет искать кандидатов, что усилят команду. Дальше автор говорит про составление вакансии и поиск кандидатов через разные источники. В общем, все очень просто и базово.
5. Собеседования, выбор подходящего кандидата и его онбординг - здесь автор рассказывает про собеседования, но очень базово. Мне кажется, что я гораздо интереснее это раскрыл в своей серии статьей про найм: как нанимают в крупные компании, а потом отдельно про разработчиков, руководителей, SRE и даже аналитиков.
6. Управление командой - здесь автор говорит про типы команд, их цели, метрики, состав и так далее. Но мне кажется, что про эту тему лучше почитать книгу "Team topologies", в которой отлично разложено какие команды бывают, какие у них бывают цели и форматы взаимодействия, тем более я уже рассказывал про эту книгу раньше. Ну и у меня есть большой рассказ про то, как создавать команды под запросы бизнеса

Продолжение обзора книги в следующем посте.

#Management #Leadership #Processes #Software #Architecture #Strategy #ChangeManagement
2,317
Книжный куб

22 Jan, 05:08

Code of Leadership #28 - Interview with Vadim Goncharov about Design in Software Development (Рубрика #Management)

В этом выпуске подкаста ко мне пришел Вадим Гончаров поговорить про свой путь в ИТ и как на это повлияло увлечение дизайном. Вадим в веб-разработке больше 15 лет. В 2008 руководил собственной веб-студией. С 2013 работал в VK, а в 2017 присоединился к Т-Банку, где в качестве технического руководителя запускал "Тинькофф Журнал", самое крупное медиа про деньги в России. С 2020 Вадим начал руководить разработкой интерактивных спецпроектов и игр в мобильном приложении Т-Банка. Он проповедует lifelong learning: закончил МИЭМ, учился в Британке и Вышке, а сейчас учится в Сколково на программе МБА. Эпизод также доступен в Yandex Music и podster.fm

Мы обсудили следующие темы
- Ранние годы Вадима и учебу в школе и универе: Вадим всегда увлекался играми, учился в физмат лицее, а потом пошел в МИЭМ
- Влияние образования на карьеру: университет дал Вадиму базовые знания и умение учиться. Он подчеркивает важность понимания взаимосвязи различных идей и концепций.
- Создание агентства дизайна: после школы Вадим основал агентство дизайна в Подольске, которое занималось разработкой и дизайном сайтов
- Принципы работы и качество: В агентстве уделялось большое внимание качеству и эстетике. Вадим подчеркивает важность развития вкуса и поиска хороших специалистов.
- Влияние книг и обучения: Вадим рассказывает о влиянии различных книг, что повлияли на его подход к дизайну и разработке.
- Сертификация и фреймворки: обсуждается важность сертификации в программировании и изучения различных фреймворков.
- Визуализация данных: Вадим говорит о важности визуализации данных и упоминает работы Эдварда Тафта.
- Взаимодействие дизайнеров и разработчиков: Вадим подчеркивает важность синергии между дизайнерами и разработчиками для создания качественных продуктов.
- Опыт работы в Mail.ru: Вадим рассказывает о своем опыте работы в Mail.ru, где он развивался как фронтенд-разработчик и тесно сотрудничал с дизайнерами.
- Обучение в Британке: Вадим рассказывает о том, как обучение в Британской школе дизайна прокачало его скиллыы

Список рекомендаций для изучения
- Программист Прагматик. Эндрю Хант
- Совершенный код. Стив Макконнелл
- Чистый Код. Роберт Мартин
- Release It! Second Edition. Design and Deploy Production-Ready Software. Michael Nygard
- Дизайн привычных вещей. Дональд Норман
- Дизайн для реального мира. Виктор Папанек
- Дизайн-мышление в бизнесе. Тим Браун
- Beautiful Evidence. Edward Tufte
- Visual Explanations: Images and Quantities, Evidence and Narrative. Edward Tufte
- Envisioning Information. Edward Tufte
- The Visual Display of Quantitative Information. Edward Tufte
- Look Inside: Cutaway Illustrations and Visual Storytelling. Juan Velasco and Samuel Velasco

#Management #Leadership #Software #Processes #Retrospective #Design #Processes #SelfDevelopment
2,368
Книжный куб

21 Jan, 05:08

Applying Use Case Driven Object Modeling With Uml: An Annotated E-Commerce Example (Применение объектного моделирования с использованием UML и анализ прецедентов)

В очередной раз я достал с полки старую книжку про проектирование приложений из начала двухтысячных. В этот раз эта книга создателей процесса ICONIX, который предшествовал RUP и Agile. В книге базово описывается теоретическая часть процесса, а также даются практические примеры его применения для проектирования книжного онлайн магазина, а также списки типичных ошибок.
По-факту, подробно описываются четыре основных этапа из ICONIX

1) Анализ требований
- Создание функциональных требований
- Моделирование предметной области
- Определение поведенческих требований (прецеденты использования)
2) Предварительное проектирование
- Проведение анализа надежности (robustness analysis)
- Обновление модели предметной области
3) Детальное проектирование
- Создание диаграмм последовательности
- Доработка статической модели (диаграммы классов)
4) Реализация
- Написание кода и модульных тестов
- Интеграционное и сценарное тестирование

В итоге, весь процесс выглядит примерно так, как представлено на приложенных изображениях:) Для начала двухтысячных подход был достаточно интересен и книга была полезна, но сейчас она скарее находка для коллекционеров, чем актуальное руководство по уже отмершему процессу ICONIX.

P.S.
Раньше я уже рассказывал про ретро-книги из начала 2000-х про процессы разработки софта
- Введение в RUP (The Rational Unified Process. An Introduction)
- Гибкие технологии: Экстремальное программирование и унифицированный процесс разработки (Agile Modeling: Effective practices for XP)
- Разработка Web-приложений с использованием UML (Building Web Applications with UML)

А также разбирал видео с Гради Бучем про эволюцию software architecture, кстати, Гради - один из создателей UML

#SoftwareArchitecture #Architecture #Software #Management #Processes
2,368
Книжный куб

20 Jan, 06:09

Обложка книг "Design, Form, and Chaos" и "Дизайн, форма и хаос"
2,706
Книжный куб

20 Jan, 05:08

Design, Form, and Chaos (Дизайн, форма и хаос)

Эта классическая книга по дизайну от Пола Рэнда вышла в далеком 1993 году в "Yale University Press", а в России ее издает "Студия Артемия Лебедева". Книга очень короткая, но в ней есть определенная глубина - автор делится своими мыслями о сути графического дизайна и его роли в обществе. Автор может себе это позволить, так как у него десятилется опыта как успешного новатора в области графического дизайна. Свою книгу он выстроил вокруг следующих ключевых тем
- Связь между формой и содержанием - автор подчеркивает решающее взаимодействие между формой и содержанием, утверждая, что хороший дизайн не просто декоративен, но и служит для эффективной передачи идей
- Важность интуиции в дизайне - автор исследует роль интуиции в творческом процессе, подчеркивая, как дизайнеры должны сбалансировать инстинкт с рациональным мышлением для создания инновационных решений4
- Роль компьютеров в процессе проектирования - автор обсуждает влияние технологий на дизайн, предостерегая от чрезмерной зависимости от компьютеров в ущерб концептуальному мышлению.
По-факту, он отмечал уже в начале 90х годов засилие компьютеров и то, что молодые дизайнеры учатся зачастую не дизайну, а умению пользоваться компьютером (интересно что бы Пол Рэнд сказал на это сейчас)
- Принципы эффективного дизайна логотипов - опираясь на свой обширный опыт создания знаковых логотипов, Рэнд излагает принципы эффективного дизайна логотипа, подчеркивая простоту и запоминаемость. Мне действительно понравилась эта подборка, включающая IBM, IDEO и многие другие компании
- Искусство представления дизайнерских работ клиентам

Книга оказала глубокое влияние на сообщество дизайнеров.
1) Пол Рэнд укрепил свой статус лидера в графическом дизайне и поднял дизайн на уровень искусства и способа решения проблем клиентов
2) Акцент на форме и функции, а также призыв к критическому мышлению относительно своей работы, актуален для дизайнеров и сегодня
3) Стиль письма и крутые примеры Рэнда делают книгу популярной и доступной
4) Пол Рэнд не только делился своими мыслями и обучал коллег, но также смог поднять статус дизайна как профессии

В общем, книгу интересно прочитать даже если вы не профессиональный дизайнер, а просто мимо проходили:)

#Design #Culture #History
1,762
Книжный куб

19 Jan, 17:44

Баскетбол: ЦСКА - Локомотив (Рубрика #LifeStory)

В пятницу вечером мы с младшим сыном выписались из стационара долечиваться дома, а в воскресенье со средним сыном у нас был запланирован поход на баскетбольный матч. Максим еще ни разу не был на баскетболе, поэтому мы не просто смотрели матч, но и обсуждали правила игры, а также ее динамику. В этом плане матч не подвел - игра получилась равной, большую часть ЦСКА пытался догнать Локомотив, в четвертой четверти это сделать получилось ... Но потом Локомотив опять вышел вперед, а на последних секундах игроки ЦСКА попытались забить победную треху под сирену ... но мяч пролетел мимо. В общем, матч нам понравился, видимо, со средним сыном теперь иногда будем хотить и на баскетбол.

#ForKids #Sports
1,805
Книжный куб

18 Jan, 14:27

Обложка книги "Inner Drive: From Underdog to Global Company"
1,843
Книжный куб

13 Jan, 05:24

Новогодний отпуск

Мой отпуск уже заканчивается, завтра на  работу, а сегодня еще 9 часов лета. Если подводить итоги, то отпуск в новогодние каникулы обычно бывает хорош и позволяет успеть многое:
- Можно хорошо провести время с семьей и отдохнуть
- Посмотреть красивые места - в этот раз это была Шри Ланка
- Порефлексировать о  прошедшем годе и его итогах
- Подумать о будущем - раньше я бы сказал о планировании, но сейчас предпочитаю не строить планы, а думать о приоритетах
- Почитать интересные книги - я прочел тройку книг и несколько whitepapers

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

P.S.
И раз отпуск заканчивается, то дальше я смогу постить еще больше интересного в канале:)
1,584
Книжный куб

12 Jan, 07:10

What Do Developers Want From AI? (Рубрика #DevEx)

Летом 2024 года вышла интересная статья про то, что эволюция AI - это поворотный момент, но с технологическими революциями, что меняют формат работы людей, человечество сталкивается не в первый раз. Поэтому авторы статьи решают провести параллели с развитием автомобильной промышленности и сфокусироваться на потребностях и целях наших разработчиков. Это статья из серии "Hunam centric approach to developer productivity" от ребят из Google, про которую я рассказывал раньше. А теперь основные моменты статьи

1) Последние достижения в AI привели к появлению большого количества инструментов разработки для поддержки искусственного интелекта (например, DuetAI, CoPilot и ChatGPT для задач программирования). После этого было проведено много исследований влияния этих инструментов на продуктивность разработчиков, где задавались вопросы навроде
- Повышают ли улучшения ИИ скорость написания кода?
- Улучшают ли они качество написанного кода?
- Помогают ли они разработчикам находить более креативные решения?
2) Но вот обсуждений того, а как разработчики хотят взаимодействовать с AI в своих инструментах, было гораздо меньше. Авторы исследования со своим фокусом на человекоориентированный подход к пониманию продуктивности разработчиков решили это испраивать и провести исследование для ответа на вопрос, а где разработчики хотят видеть ИИ в своих рабочих процессах, и какими, по их мнению, будут его эффекты?
3) Здесь авторы начинают проводить параллели с автомобилями для понимания потребностей. Они говорят, что понимание того, что люди хотят и в чем нуждаются от технологий, является основой исследований пользовательского опыта. Однако этот подход иногда подвергается сомнению, особенно когда речь идет о крупных технических инновациях - в этих случаях вспоминают знаменитую фразу, приписываемуюГенри Форду: "Если бы я спросил людей, чего они хотят, они бы сказали 'более быстрых лошадей'".
4) Для исследования предпочтений разработчиков авторы провели многочисленные интервью и пользовательские сследования с разработчиками, имеющими различный опыт работы с инструментами разработки с поддержкой ИИ. Разработчики выражали свое желание, чтобы такие инструменты экономили их время и энергию, помогая им более эффективно выполнять свою работу, то есть они хотят, чтобы ИИ поддерживал более простые задачи и уменьшал рутину, позволяя им сосредоточиться на решении сложных проблем и творческих аспектах их работы.
5) Для того, чтобы понять какие области мешают разработчикам быть продуктивными в Google исследователи проводят опросы и анализируют логи. Это позволяет сфокусировать усилия на самых важных факторах, тройка которых в Google сейчас такая
- Технический долг
- Плохая или отсутствующая документация
- Сложности в изучении новых платформ и технологий
6) Авторы классифицировали эволюцию улучшений AI по трем типам (проведя параллели с автомобильной промышленностью)
- Улучшение существующих человеческих возможностей. Для машин это усилитель руля, антиблокировочная система для тормозов. Для AI в разработке это code completion.
- Расширение человеческих возможностей (добавление новых). Для машин это камера заднего вида, контроль слепых зон. Для AI в разработке это code review suggestions, chatbots
- Делегирование человеческих возможностей (фичи, что убирают human in the loop). Для машин это удержание полосы движения, автоматическое торможение, улучшенный круиз-контроль. Для AI в разработке это автоматический откат проблемных релизов, автоматическое удаление dead code, генерация тестов
7) Для успешного внедрения изменений с AI необходимо
- Понимание сопротивления и скептицизма разработчиков
- Создание правильной инфраструктуры для внедрения
- Обеспечение безопасного и справедливого доступа во всех отраслях
- Сохранение фокуса на целях разработчиков, а не только на технологических возможностях

#Management #Leadership #Software #SoftwareDevelopment #Metrics #Devops #Processes #AI #ML #DevEx
1,891
Книжный куб

11 Jan, 05:08

Обложки и немного иллюстраций к книгам "The Culture Map" и "Карта культурных различий"
1,850
Книжный куб

11 Jan, 04:07

The Culture Map (Карта культурных различий) (Рубрика #Management)

Прочитал на каникулах этот бестселлер десятилетней давности от Erin Meyer и он мне понравился. В нем Эрин, профессор INSEAD, интересно изложила свою гипотезу о карте различий разных культур, которую можно воспринимать через восемь отдельных непрерывных шкал, включающих в себя
1. Communication (коммуникация): low-context vs. high-context
2. Evaluation (оценивание): direct vs. indirect negative feedback
3. Persuading (убеждениe): principles-first vs. applications-first
4. Leading (лидерство): egalitarian vs. hierarchical
5. Decision-making (принятие решений): consensual vs. top-down
6. Trust (доверие): task-based vs. relationship-based
7. Disagreement (несогласие): confrontational vs. avoidance
8. Scheduling (планирование времени): structured vs. flexible24

Школа мысли Эрин в том, что у каждой из этих шкал есть два экстремальных значения, а дальше каждая из стран позиционируется на шкале так, чтобы отображать медиану приемлемого поведения. Но важна не сама точка, а скорее относительное положение стран между собой, так как все познается в сравнении. Для этого автор щедро приводит очень большое количество примеров, разбирая каждую ось
1. Communication (коммуникация)
- Низкоконтекстная - (США): Американский менеджер прямо скажет "Крайний срок проекта - следующая пятница, 17:00"
- Высококонтекстная (Япония): Японский менеджер может сказать "Нам стоит подумать о завершении в ближайшее время", ожидая, что команда поймет подразумеваемую срочность.
2. Evaluation (оценивание
- Прямая (Нидерланды): "Эта презентация полностью неверна и требует переделки".
- Непрямая (США): "Вы сделали несколько интересных замечаний, но, возможно, стоит рассмотреть альтернативные подходы".
3. Persuading (убеждениe)
- От принципов (Германия): Немецкий менеджер сначала объяснит теоретическую базу и методологию, прежде чем представить выводы.
- От практики (США): Американский презентующий начнет с вывода или рекомендации, затем при необходимости предоставит подтверждающие данные.
4. Leading (лидерство)
- Эгалитарное (Дания): Сотрудники свободно не соглашаются с начальником на встречах и могут пропускать иерархические уровни при общении.
- Иерархическое (Китай): Сотрудники должны следовать proper каналам и получать одобрение непосредственного руководителя перед обращением к высшему руководству.
5. Decision-making (принятие решений)
Консенсусное (Япония): Каждый отдел должен рассмотреть и одобрить предложение, прежде чем оно пойдет вверх по цепочке командования.
Сверху вниз (Бразилия): Босс принимает решения самостоятельно, а члены команды должны выполнять их без вопросов.
6. Trust (доверие)
На основе задач (США): Доверие строится через стабильное достижение результатов и соблюдение сроков.
На основе отношений (Китай): Доверие развивается через совместные обеды, личные разговоры и построение социальных связей вне работы.
7. Disagreement (несогласие):
Конфронтационное (Франция): Члены команды открыто дебатируют и оспаривают идеи друг друга во время встреч.
Избегающее (Япония): Проблемы обсуждаются приватно в малых группах для поддержания гармонии и избегания публичной конфронтации.
8. Scheduling (планирование времени)
Структурированное (Германия): Работа следует фиксированным графикам с четкими дедлайнами и точными временными рамками.
Гибкое (Индия): Графики адаптируемы, с подвижными дедлайнами и регулируемым рабочим временем в зависимости от обстоятельств.

В итоге, книга через модель и примеры помогает читателям взглянуть на другие культуры непредвзято и оценить какие недоразумения возникают из-за культурных различий, а не некомпетентности. Это позволяет преодолеть культурные границы и может помочь менеджеру мультикультурной команды
- Определить потенциальные области конфликтов между культурами
- Адаптировать стиль управления под конкретную культуру/культуры
- Улучшить коммуникацию в международных командах

P.S.
Есть хороший обзор книги от Руслана Фазлыева, CEO Ecwid.

#Management #Leadership #Culture #PopularScience
1,857
Книжный куб

09 Jan, 05:16

Обложка книги "Fundamentals of Enterprise Architecture" и немного иллюстраций. Забавно сравнить отличия финальной версии обложки и early preview.
2,229
Книжный куб

06 Jan, 04:38

Code of Leadership #27 - Интервью с Виктором Фирсовым про эволюцию развития веба Т-Банка за 12 лет (Рубрика #Management)

В этом выпуске подкаста ко мне пришел Виктор Фирсов для того, чтобы обсудить как эволюционировали веб-интерфейсы Т-Банка и как он всеми силами помогал этому. Сейчас Виктор является техническом руководителем 100+ инженеров, что отвечают за публичный веб и личные кабинеты физических лиц. А начинал Витя с позиции инженера и занимался формами для привлечения клиентов. Эпизод доступен в Youtube, Podster, Yandex Music.

На общение мы потратили чуть больше часа и успели обсудить следующие темы
- Где Витя родился, учился и как попал в IT
- Как он переехал из Нижнего Новгорода в Москву, приняв офер Т-Банка 12 лет назад
- Как прошла технологическая трансформация при переходе со старого решения на react
- Как команда росла и пришлось делать организационные изменения
- Как выглядели вызовы в 2022-2023 годах и как их удалось с успехом преодолеть
- Как выглядел проект ребрендинга в общем и что надо было сделать технической команде
- Как вообще подходить к позиции технического руководителя и чем она отличается от инженерной
- Какие советы можно дать вкатывающимся в IT, а также продолжающим свое профессиональное развитие

В общем, выпуск получился очень плотный по темам, поэтому думаю, что вам не придется скучать при просмотре:)

P.S.
Я с Витей работаю 8 лет, с самого своего первого дня работы в компании и могу сказать, что он прошел большой путь от хорошего инженера до крутого технического руководителя. До последнего года он был моим прямым reportee и я как мог помогал этому случиться. В последний год он мой skip level reportee, но это ему не мешает показывать классные результаты.

#Management #Leadership #Software #Processes #Retrospective #ChangeManagement
2,376
Книжный куб

05 Jan, 05:08

The elearning designer's handbook (E-learning. Пошаговое руководство по разработке электронного обучения) (Рубрика #Education)

Эта книга Тима Слейда попалась мне на глаза случайно и хотя она рассказывает про создание онлайн курсов, но мне это показалось отчасти близким к написанию книги:) По-итогу, я прочел книгу за пару часов в силу ее небольших размеров и общей очевидности идей. Если рассказывать про книгу кратко, то она состоит из предисловия, вступления, пяти основных шагов и финального напутствия о том, что надо продолжать двигаться дальше.
1) Предисловие - здесь автор рассказывает про свой путь к педагогическому дизайнеру электронного обучения (я даже не знал, что это так называется до того, как прочел книгу). Тим изначально был subject matter expert много лет, а потом его попросили сделать курс для обучения других и ... так его карьера сделала поворот к созданию курсов
2) Вступление - здесь автор на пальцах показывает, что создание курса похоже на строительство дома. Он объясняет, что нужно понимание кто такие бизнес-заказчики, кто такие subject matter experts и зачем нужен план (чтобы дом достроился и был сдан, а не остался брошенным недостроем)
3) Шаг первый - создание плана проекта. По-факту, если вы знаете про проектное управление и руководили проектами, то тут вы не узнаете почти ничего нового. Автор рассказывает про то, что надо определиться со scope проекта, участниками, их зоной ответственнсти (лучше по матрице RACI, но он про это не говорит). Важно построить график проекта и отметить ключевые точки и контролировать их прохождение и так далее
4) Шаг второй - составление раскадровки курса. В этой части автор говорит о том, что лучше не делать курс целиком, а пользоваться методом прогрессивного JPEG, когда содержимое курса сначала набрасывается в черновом верхнеуровневом варианте, а дальше показывается стейкхолдерам. Это позволяет на начальном этапе провалидировать концепцию курса и получить ценную обратную связь. Этот этап позволяет задать канву курса и зафиксировать примерно материалы, что войдут в него.
5) Шаг третий - разработка курса. На этом шаге надо пойти и сделать сами материалы. Когда есть понятная канва и структура, то это должно быть не таким сложным делом. Главное сломать страх чистового листа и начинать работать над деталями курса по частям.
6) Шаг четвертый - проверка и контроль качества курса. Здесь автор рассказывает про базовые вопросы тестирования самого продукта, потом выкатку на бета-тестеров, а также проверку удобства получившегося продукта с точки зрения user experience через интервью с бета-тестерами
7) Шаг пятый - запуск курса. Автор говорит о том, что иногда курсы могут публиковаться в LMS системах, а иногда это просто html странички в интернете. В любом случае автору курса надо понимать на какой платформе он публикует курс, как он сможет его дорабатывать, а также где сможет посмотреть аналитику по прохождению курса учениками.

В общем и целом, это очень базовая книга по созданию электронных курсов, у которой на английском вышло второе издание аж в 2020 году, а та версия, которую читал я, была издана на языке Шекспира в далеком 2018 году. Кажется, что с тех пор эта информация про создание курсов стала просто базой:)

P.S.
Кстати, у автора есть свой сайт TimSlade.com

#Education #Writing
2,497
Книжный куб

04 Jan, 09:12

Стажировки в Т-Банк - Тинькофф Старт (Рубрика #HR)

Открылась очередная зимняя программа стажировок в Т-Банк. Набор идет по куче направлений, в software engineering это направления вида java, scala, go, python, iOS, Android, .net, а также SRE, ML, frontend:) Стажировки у нас оплачиваются и во время них вы будете работать над реальными задачами, у вас будет ментор, который поможет вам адаптироваться, а по итогам лучшие стажеры будут приглашены в штат компании. Стажироваться можно в рамках гибкого графика - от 20 часов в неделю, удаленно или в офисе, в России или в соседних странах (Беларусь, Казахстан).

Для попадания на стажировку надо будет
- Подать заявку и зарегестрироваться в личном кабинете нашей edu платформы
- Заполнить анкету об опыте и мотивации, а также пройти экзамен
- Пройти интервью с командами
Если все пройдет успешно, то дальше останется только проявить себя во время стажировки, чтобы по ее окончании получить штатуную позицию.

#Career #Software #Engineering
3,342
Книжный куб

04 Jan, 06:09

Developer Productivity for Humans, Part 6: Measuring Flow, Focus, and Friction for Developers - Part II (Рубрика #Management)

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

1) Они решили опять начать отстраивать friction от восприятия инженеров, а не от данных из инструментов типа билдов, автотестов и иже с ним. В итоге, авторы построили метрику, используя
- Некоторое число компонентов, что включают ключевые активности инженеров
- Агрегировали эти компоненты по инженерам и вычислили среднее для каждого инженера
- Дальше для каждого из инженеров сравнили получившееся среднее с некоторым пороговым значением, рассчитанным в разрезе восприятия инженеров, а не просто условный 90 перцентиль
- Если пороговое значение было пробито, то считалось, что инженер испытывал friction в этот день
2) Раньше в Google уже были метрики friction, но они создавались для целей того, чтобы продемонстрировать помощь инфры или инструментов в деле снижения friction или для понимания того, а что мешает инженерам работать продуктивнее. Этим метрики отталкивались от количества или процента "плохих событий" относительно их большого количества, например, flaky tests в Google. Эти метрики имели смысл в сценариях инфра команд, но не очень матчились на опыт конкретных разработчиков.
3) Но оказалось, что если считать friction исходя из опыта разработчиков, то получаются все те же причины: test latency, flaky tests, issues with code changes being blocked due to CI failures. Это показывает, что старые метрики совпадали с новыми, но новый подход дал больше уверенности, что это отражает мнение самих разработчиков о том, что мешает им в работе.
4) Интересно, что разработчики отмечали, что до некоторой степени эти проблемы не являются причиной friction, а являются частью работы. Но при превышении некоторого порогового значения, например, flaky tests это становится проблемой и они классифицируют это как friction.
5) В итоге, метрикой friction стало
- Данные из логов о latencies для локальных билдов и тестов, latencies для change lists, проблемы с нестабильными тестами, проблемы с заблокированными submission attempts. Тут тоже пришлось поиграть с пороговыми значениями
- Данные из ежеквартальных опросов о том, испытывали ли они friction и насколько они удовлетворены со сложностью кода и скоростью разработки

В итоге, подход ребят позволяет создать базу для ответов на вопросы вида
- Можно ли улучшить focus и flow при уменьшении общекорпоративных встреч?
- Можно ли улучшить focus и flow делая дни или целые недели без встреч?
- Можно ли при помощи уменьшения длительности и слотов под сфокусированную работу добиться лучшего focus и flow?
- Как можно при помощи метрики friction определить какие процессы улучшать первыми?
- И так далее

Но сами исследователи пока в начале пути. Надеюсь, что они поделятся с нами результатами следующих шагов в очередных whitepapers.

#Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes
2,651
Книжный куб

03 Jan, 12:15

39 лет (Рубрика #Retrospective)

Сегодня мне исполнилось 39 лет:) Кажется, что это достаточно много, но мне до сих пор кажется, что я только начинаю знакомиться с окружающим миром:) И в этом мне помогает моя семья:
- Жена в прошедшем году изучала психоаналитическое бизнес-консультирование и местами мне казалось, что и я тоже. Она успешно закончила первый курс магистратуры и начала делать дипломную работу про профессиональную идентификацию продакт менеджеров:)
- Старший сын стал первокурсником, поступив на геймдизайн. Я начал читать больше книг по геймдизайну, чтобы быть способным поддерживать непринужденную беседу
- Средний сын заинтересовался футболом, хокеем и баскетболом. Теперь я хожу с ним на стадион и смотрю матчи футбольного и хоккейного ЦСКА, а на баскетбольный ЦСКА мы пойдем через 2 недели:)
- Младший сын научился считать и складывать в четыре года - он вообще быстро учится, поэтому я ему рассказываю научно-популярные истории о мире вокруг нас.
- Еще у нас в семье есть собака и кошка, причем кошка появилась относительно недавно. Теперь я понимаю фразу "живут как кошка с собакой" гораздо лучше:)

Если говорить про работу, то впечатления смешанные
- Моя команда радовала меня своими успехами - ребята действительно хорошо поработали и достигли крутых результатов, я писал об этом в посте про свой юбилей "0b1000 в Т-Банке"
- На уровне всей компании часть моих инициатив зашла не так хорошо, как хотелось бы мне. Мне кажется, что иногда мое особое мнение об идеальном результате мешает достигать just enough результатов:)

Если говорить про творческую часть, то за прошедший год я
- Прочитал порядка 100 книг
- Написал кучу постов на разные ITшные темы (здесь и на Medium)
- Снял порядка 60 часов видео с крутыми гостями
- Прошел курс МИФа для начинающих писателей
- Определился с четырьмя темами книг и нашел для каждой из них соавтора - осталось их только дописать:)

В общем, до 40 надо много успеть сделать, поэтому я не планирую снижать обороты.

#SelfDevelopment
2,658
Книжный куб

03 Jan, 05:08

Developer Productivity for Humans, Part 6: Measuring Flow, Focus, and Friction for Developers - Part I (Рубрика #Management)

Недавно я с большим интересом прочел статью от ребят из Google на тему состояния потока, фокусной работы и friction, что мешает работать эффективно. Эта статья из колонки про "Developer Productivity" в журнале IEEE. В этой статье авторы описываются свой подход примерно так:
1) Авторы хотели сфокусироваться на восприятии инженеров двух концепций: flow и friction
2) Для этого они собрали данные напрямую от разработчиков, включая проведение интервью, опросов, ведения разработчиками дневников
3) Дальше они взяли эти данные и попробовали связать восприятие инженеров с данными из логов - другие исследователи обычно сразу начинали с этого этапа
4) У исследователей получилось создать эвристики для трансформации сигналов из логов в метрики, что значимо связаны с flow, focus и friction
5) Дальше авторы отвалидировали эти метрики относительно само-отчетов инженеров и данных из логов - это позоволило верефицировать, что метрики все еще связаны с тем опытом инженеров, что был интересен исследователям.

Ну а теперь немного подробностей:
1) Обычные исследования flow предполагали, что context switches между инструментами рушит этот flow. Авторы же пошли от целей инженеров и показали, что flow сохраняется, если контекст задачи сохраняется. Подробнее про статью "Measuring Developer Goals" я рассказывал раньше
2) Из diary studies и follow-up interviews стало ясно, что flow многограннее, чем думали авторы
- Инженеры испытывают состояние потока, только если они позитивно настроены относительно работы, что они выполняют
- Это может быть не только код, но и другие активности (написание дизайн доков, изучение документации, написание писем/сообщений, ...)
- Когда состояние потока достигнуто, то инженеры могут оставаться в нем даже при небольших отвлекающих факторах
3) Дальше авторы рассказывают, что они не смогли выделить как определить из логов состояние потока, но можно выделить состояние сфокусированной работы. Для этого надо посмотреть занимаются ли инженеры связными задачами (фокус) или несвязными (расфокус).
4) Концептуальная модель выглядела примерно так: сфокусированная работа нужна для достижения flow, но ее не достаточно. Одновременно из логов можно вытащить focus time, когда инженеры работали над связными задачами, но не факт, что это точно отображается на сфокусированную работу. Для анализа связности задач ребята использовали word2vec по данным из логов
5) Дальше шла валидация того, что инженеры заполняли в опросах или в diary data с тем, что насчитали авторы насчет flow и focus из логов. В итоге, метрики авторов показали хорошую связь между восприятием и этими метриками

Рассказ про метрику friction в продолжении этого обзора.

#Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes
2,304
Книжный куб

02 Jan, 17:20

SolarBalls (Шаранутый космос) (Рубрика #ForKids)

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

1) Теория Большого взрыва
Вселенная началась с сингулярного состояния — бесконечно плотной и горячей точки, которая около 13,8 миллиарда лет назад начала расширяться. Это событие не было "взрывом" в привычном смысле, а представляло собой расширение пространства. В мультсериале этот процесс объясняется через разговоры между персонажами-планетами, которые обсуждают "появление всего". Например, они шутят о том, как всё началось с "маленького пузырька", который раздувался (аллюзия на инфляционную модель. Также упоминается реликтовое излучение — "эхо" Большого взрыва, которое подтверждает эту теорию. Оно представлено как "фоновая музыка", оставшаяся от ранней Вселенной. Интересно, что за его открытие когда-то даже дали Ноебелвскую премию.
2) Образование звёзд и планет
Звёзды формируются из облаков газа и пыли под действием гравитации. В мультсериале это показано как "танец" частиц, которые притягиваются друг к другу, пока не зажигается звезда. Планеты образуются из протопланетного диска вокруг молодых звёзд. В одной из серий персонажи обсуждают, как "космическая пыль и газ начали сплющиваться", создавая планеты. Это сопровождается шутками о том, что они "родились из космического беспорядка". Звёзды также играют ключевую роль в создании элементов. Например, лёгкие элементы (водород и гелий) появились после Большого взрыва, а более тяжёлые синтезировались в недрах звёзд или при их взрывах (сверхновых).
3) Появление жизни
Жизнь на Земле рассматривается как уникальное явление благодаря её местоположению в зоне обитаемости ("золотой середине"), где температура позволяет существовать жидкой воде. В одной из серий персонажи обсуждают возможность появления жизни на других планетах. Например, Венера мечтает о том, чтобы поддерживать жизнь, но другие планеты объясняют ей, что её экстремальные условия (высокая температура и давление) делают это невозможным. Также поднимается вопрос панспермии — гипотезы о том, что жизнь могла быть занесена на Землю с астероидов или комет.

Прикольно, что в мульике наука смешивается с юмором, например:
- Планеты спорят о своих орбитах и размерах, что иллюстрирует стабильность Солнечной системы.
- Звёзды шутят о своей яркости и важности для жизни.
- и так далее

В общем, я очень рекомендую этот сериал к просмотру:)

#PopularScience #Physics #ForKids #Humor
1,789
Книжный куб

02 Jan, 05:08

A Tool for Process Merging in Business-Driven Development (Рубрика #Architecture)

Пока искал материалы для книги по архитектуре наткнулся на артефакты из прошлого в виде подхода "Business-driven development", который 20 лет назад промотировал IBM:) Сейчас оригинальная статья на сайте IBM про business-driven development не доступна, но вот статья про инструменты все еще с нами. По-факту, BDD — это методология разработки IT-решений, которая напрямую связывает бизнес-потребности с IT-реализациями, в которой выделялись этапы вида
1) Моделирование: Определение целей бизнеса и построение моделей бизнес-процессов.
2) Разработка: Преобразование моделей в IT-реализации. В те времена реализация предполагала использование языка BPEL (Business Process Execution Language), который позволял устроить оркестрацию бизнес-процессов поверх сервисов из SOA (service-oriented architecture). Сейчас SOA ушла в прошлое и мы часто видим использование BPMN (Business Process Model and Notation) движков типа Camunda примерно для такой же окрестрации, но теперь микросервисов:)
3) Внедрение: Интеграция решений в инфраструктуру и мониторинг их эффективности.

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

Авторы предлагали делать 2 модели реальности:
- Аналитическую модель, что концентрируется на том, что делают процессы и используется бизнес-аналитиками
- Дизайн модель, что отвечает за IT-реализацию, включая потоки данных, логику решений и специфику имплементации

В общем, это была попытка от бизнес-процессов прыгнуть к реализации поверх сервисов через генерацию BPEL кода, но последняя версия BPEL вышла в 2007 году, то есть подход оказался нерабочим, так как остались незакрытыми вопросы, подсвеченные открытыми внутри самой статьи
- Поддержание согласованности между бизнес-моделями и кодом (round-tripping)
- Определение оптимальной детализации сервисов
- Обеспечение качества моделей (выявление ошибок проектирования)
- Улучшение визуализации больших моделей и поиск в их коллекциях

Хотя авторы предсказывали, что дальше модель станет кодом, где графические и текстовые элементы будут объединены в единую систему, а переходы между уровнями абстракции поддерживаются методами обеспечения качества.

Мне кажется, что вся эта тема умерла из-за своей тяжеловесности. В итоге, во многих технологических компаниях концепция создания карты бизнес-процессов и связки их с IT уступила место созданию технологического продукта для пользователей, а потом если надо фиксации процессов, которые он поддерживает:) Условно, подход от бизнес-процессов к ИТ-сервисам представлял собой поход сверху-вниз, а поход от создания ИТ-продуктов к бизнес-ландшафту скорее снизу-вверх. Последний подход оказался более приспособлен к жизни в меняющихся условиях - он быстрее давал результат и обеспечивал большую гибкость, что эволюционно привело к его победе:)

P.S.
Примерно в эти года я защищал магистерский диплом на тему реинжиниринга бизнес-процессов и автоматизации деятельности retail компании, поэтому отлично помню большое количество вариантов моделирования бизнес-процессов и их автоматизации:)

#Management #Architecture #ArchBook #Retrospective #History #Processes #Software
1,827
Книжный куб

01 Jan, 06:09

Обложки для книг "Taming Silicon Valley: How We Can Ensure That AI Works for Us" и "Большой обман больших языковых моделей"
1,980
Книжный куб

01 Jan, 05:08

Taming Silicon Valley: How We Can Ensure That AI Works for Us (Большой обман больших языковых моделей)

Прочитал на днях эту книгу Гэри Маркуса, изданную в MIT Press в сентябре 2024 года, то есть буквально на днях:) Книга представляет собой критическое исследование социальных и этических вызовов, связанных с искусственным интеллектом (ИИ), и его развитием под контролем крупных технологических компаний. Сам Гэри - это американский психолог, когнитивист, писатель и предприниматель, известный своими исследованиями на пересечении когнитивной психологии, нейронауки и искусственного интеллекта (ИИ). Он является профессором-эмеритом кафедры психологии и нейронауки Нью-Йоркского университета и основателем компании Geometric Intelligence, которая была приобретена Uber в 2016 году.

Ключевые идеи книги примерно такие
1) У AI есть две медали - с одной стороны он может привести к революции в естественных науках, технологиях, медицине и так далее. А с другой стороны он несет с собой значительные риски, например, распространение дезинформации, киберпреступности, подрыв демократии, а также экзистенциальная угроза всему человечеству
2) Критика крупных технологических компаний. В книге утверждается, что основные технологические компании ставят прибыль выше этических соображений, выпуская системы ИИ преждевременно в гонке за рыночным доминированием. Это приводит к созданию ненадежных технологий с внутренними недостатками, которые усугубляют общественные риски. Маркус критикует культуру Кремниевой долины, ориентированную на быструю прибыль, часто игнорирующую долгосрочные последствия ради краткосрочной выгоды. Интересно, что эта критика даже вынесена в название книги
3) Пробелы в регулировании. Маркус рассказывает о том, как крупные технологические компании эффективно «захватили» политиков через лоббизм, маркетинг и обещания саморегулирования, что привело к слабым или отсутствующим механизмам управления ИИ. Он подчеркивает необходимость создания надежного регулирования для решения таких вопросов, как конфиденциальность данных, дезинформация и вытеснение рабочих мест.
4) Гэри предлагает следующий план действий
- Установление сильных прав на данные.
- Введение многоуровневого надзора за системами ИИ.
- Проведение значимых налоговых реформ для крупных технологических компаний.
- Продвижение прозрачности и ответственности в разработке ИИ.
- Приведение ИИ в соответствие с правами человека и этическими принципами.
Также он выступает за общественное давление для стимулирования регуляторных действий, утверждая, что граждане должны требовать ответственности как от правительств, так и от корпораций.
5) Моральный упадок Кремниевой долины. Маркус исследует «моральное падение» Кремниевой долины, прослеживая её переход от целей инноваций к эксплуататорским практикам, направленным на извлечение ценности за счет общественного благополучия.
Укрепление позиций граждан:
6) Книга является призывом к действию для обычных граждан: лучше понимать технологии ИИ и выступать за их этичное использование.

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

#Management #Strategy #Leadership #Vision #Bigtech #AI #ML
1,924
Книжный куб

31 Dec, 10:13

Code of Leadership & Research Insights Made Simple (Рубрика #Management)

В этом году я стартанул два подкаста - один про engineering management с интервью и разбором книг, а второй с разбором whitepapers. За год получилось пообщаться с большим количеством интересных гостей, спасибо каждому из них. А также спасибо все зрителям, слушателям и читателям. В качестве новогоднего поздравления я выложил все видео в VK, чтобы их можно было смотреть без ограничений

Code of Leadership
- Видео: Youtube, Vk Video
- Аудио: Podster, Ya Music
Описание отдельных эпизодов
01) "Team topologies" со Станиславом Халупом
02) "Antifragility in IT" с Александром Бындю
03) "Herding Cats" с Женей Кузовлевым
04) "Turn the ship around" с Екатериной Шестимеровой
05) "Project Phoenix" с Иваном Михеевым
06) Интервью про Staff+ инженеры, архитектура и SDLC с Алексеем Тарасовым
07) "Your brain at Work" с Эрнесто Инаркиевым
08) Интервью с Андреем Цыбиным про Statist (система для продуктовой аналитики)
09) "An Elegant Puzzle - System of Engineering Management (часть 1)" с Eugene Sergueev
10) "An Elegant Puzzle - System of Engineering Management (часть 2)" с Eugene Sergueev
11) Интервью с Кириллом Крайневым про системных аналитиков в Тинькофф
12) Интервью с Димой Гаевским про платформу Spirit (Internal developer platform) в Тинькофф
13) "Accelerate" с Игорем Курочкиным
14) Interview with Artem Ivanov about Risk Tech
15) Interview with Roman Lebed about Information security
16) "The Five Dysfunctions of a Team" с Андреем Соколовым
17) Interview with Anton Kosterin about Architecture Governance
18) Interview with Pavel Akhmetchanov about Processes and Tools
19) Interview with Evgeny Sokolov about Modern Education
20) Interview with Alexey Grishin about Software Architecture
21) "A Philosophy of Software Design" с Гришей Скобелевым
22) Интервью с Дмитрием Аношиным про data engineering
23) Interview with Andrew Marchenko
24) Interview with Konstantin Evteev
25) Interview with Anastasia Kabishcheva about group dynamics and BART Model
26) Interview with Salikh Fakhrutdinov about SRE Growth and SRE Team

Reserach Insights Made Simple
- Видео: Youtube, Vk Video
- Аудио: Podster, Ya Music
Описание отдельных эпизодов
01) Обсуждение paper "API Governance at Scale" от Google
02) Обсуждение paper "Defining, measuring and managing technical debt"
03) Обсуждение paper "Security by Design at Google"
04) Обсуждение "AI-Enhanced API Design" от Google
05) Обсуждение "DORA Metrics, SPACE, DevEx, Human Approach to Dev Productivity"
06) Interview with Nikolay Golov about data platforms
07) Interview with Pavel Lakosnikov about Architecture Governance

#Architecture #Processes #Management #Leadership #Software #Statistics #Project #Productivity #ProductManagement
1,906
Книжный куб

31 Dec, 08:03

Поучаствовал в поздравлении с Новым Годом, что организовывал Гриша Скобелев и сообщество { между скобок }. Порекомендовал новую книгу Влада Хононова про balancing coupling in software design:)
1,766
Книжный куб

31 Dec, 08:03

Поздравляем с наступающим Новым Годом 2025! 🍾🎄🎉

Всем счастья, мира и чтобы все что вы задумали в новом году сбылось.

Полезные ссылки
- Разбор книги "От монолита к микросервисам"
- Разбор книги "Postgres Internal"
- Разбор книги "Learning DDD"
- Balancing Coupling in Software Design: Universal Design Principles for Architecting Modular Software Systems
- https://t.me/book_cube
- https://lisp-lang.org
- https://www.haskell.org
- Логика неудачи. Книга о стратегическом мышлении в сложных ситуациях
- Мониторинг PostgreSQL https://postgrespro.ru/education/books/monitoring
- Карьера Software Engineering Manager. Эффективное управление командой разработчиков ПО | Стэньер Джеймс
- https://t.me/antonovjs
- https://t.me/olezhek28go

Видео уже на YouTube
1,745
Книжный куб

31 Dec, 05:08

Amazon Aurora DSQL (Рубрика #Data)

Вернер Вогель, CTO Amazon, в своем keynote на re:Invent 2024 полчаса рассказывал про новые возможности базы Aurora, которая появилась порядка 10 лет назад, а теперь перещла в класс newSQL и стала по фичам напоминать Google Spanner, который как раз появился больше 10 лет назад. Вот какие фичи выделял Вернер
1) Serverless Architecture - для автоматического масштабирования под нужные нагрузки
2) High Availability - для одного региона 99.99% availability, для мультирегионального master-master сетапа 99.999%
3) PostgreSQL Compatibility - полная подддержка PostgreSQL
4) Performance - обещают 4х скорость по сравнению с другими похожими решениями, видимо, из мира newSQL. Я бы глянул на бенчмарки, чтобы понять с кем они сравнивались:)
5) Active-Active Multi-Region Operations - собственно, мультирегиональный вариант, который может принимать записи и реплицировать их в реальном времени (интересно глянуть насколько это быстро работает в мультирегиональном исполнении)
6) Zero Infrastructure Management - пользователям не надо думать об инфре (кроме как сколько это счастье будет стоить)
7) Innovative Transaction Processing - здесь Вернер пафосно рассказыва про аналог гуглового TrueTime, что был еще 10+ лет назад в Google Spanner. Теперь у Amazon есть свои спутники и атомные часы для микросекундной точности и все это называется Amazon Time Sync Service. Это и позволяет сделать распределенные транзакции с хорошими гарантиями консистентности:)

P.S.
Про Aurora я уже часто упоминал раньше
- Бонусный выпуск Code of Architecture по white paper "Amazon Aurora: Design Considerations for High Troughput cloud-Native Relational Databases"
- AWS re:Invent 2023 - [LAUNCH] Achieving scale with Amazon Aurora Limitless Database (DAT344)

#Databases #Architecture #SoftwareArchitecture #SystemDesign #DistributedSystems #Cloud #Management #Leadership
2,225
Книжный куб

30 Dec, 09:12

Data завтрак в T-Space 13 января (Рубрика #Data)

Мы в Т-Банке начнем новый год митапом про данные, который пройдете 13 января в формате завтрака. На мероприятии будет 2 доклада
1) Дмитрий Аношин, основатель консалтинговой компании Rock Your Data (Северная Америка), специализирующейся на облачной аналитике, представит обзор аналитических решений, инструментов и подходов к формированию команд. Вы узнаете о построении эффективных аналитических команд, преодолении сложностей и разработке архитектур аналитических систем. Дима ведет отличный канал "Инжиниринг Данных" (@rockyourdata), на который я подписан уже давно. Кстати, Дима привез мне в подарок бумажную версию книги Влада Хононова "Balancing Coupling in Software Design", так что к концу новогодних каникул можно ожидать ее обзор.
2) Валерий Поляков, CDO в Т-Банке, поделится опытом трансформации платформы данных в Т-Банке: от централизованных вендорских решений до сложной экосистемы open-source компонентов. С 2011 года он работает с данными в разных ролях: от построения отчетности и хранилищ данных до разработки аналитических продуктов. В Т-Банке Валерий работал с 2012 по 2019 год, а затем вновь присоединился к команде в 2022 году.

Этот митап будет полезен аналитикам, инженерам данных, разработчикам, которые смогут не просто послушать доклады, но и пообщаться за завтраком с экспертами и коллегами за чашечкой кофе. Кстати, во время митапа будет проводиться игра Data-бинго, что позволит получить подарки победителям:)

#Database #Datamesh #Data #Processes #Conference
2,450
Книжный куб

30 Dec, 05:08

AWS re:Invent 2024 - Dr. Werner Vogels Keynote (Рубрика #Architecture)

Несколько недель назад Dr. Werner Vogels, CTO Amazon, выступил на AWS re:Invent с рассказом о концепции simplexity, к которой он пришел за 20 лет работы в Amazon. Само это слово представляет комбинацию двух слов: complexity и simplicity. По-факту, весь цимес в том, чтобы продукты выглядели просто для клиентов, а вся сложность была за сценой. Ну и дальше Вернер рассказывает про шесть принципов и показывает на примерах из AWS как они применяются на практике. Вот эти шесть принципов:

1) Make flexibility a requirement
Единственная постоянная вещь в наашем мире - это изменения, поэтому дизайнить системы надо так, чтобы они были готовы к эволюции технологий, рабочих нагрузок, а также требований пользователей. По-факту, это очень близко с концепциями Continuous Architecture или Evolutionary Architecture. Кстати, обе книги мы разбирали в клубе "Code of Architecture": 1 и 2 соответственно
2) Break complexity into pieces
Это стандартный подход "разделяй и властвуй". Вернер предлагает делить крупные и комплексные системы на части поменьше, которые легче понимать, поддерживать, масштабировать и которыми в принципе проще управлять. Но важно их объединять в loosely coupled стиле. А сами компоненты должны быть с high cohesion внутри. Рекомендую на эту тему почитать книгу Джона Остерхута "A philosophy of software design", которую мы тоже уже разбирали
3) Align organization to architecture
Здесь Вернер Вогель описывает применение обратного маневра Конвея. По-факту, нам надо подстраивать оргструктуру под желаемую архитектуру, что позволяет командам принять на себя ответственность и владение доменами, а также позволит им работать автономно. Я рассказывал про это уже раньше в своем докладе "Как формировать структуру команд под запросы бизнеса"
4) Use a cell-based architecture design
Эта концепция про использование так называемых cells для построения отдельных изолировоанных блоков, которые могут автономно принимать часть нагрузки. Важно, что они достаточно малы, чтобы радиус поражения (blast radius) был не слишком высок, но одновременно не слишком малы, чтобы обслужить максимального размера запрос и получать экономию на масштабе.
5) Design predictable systems
Вернер предлагает дизайнить предсказуемые системы, что уменьшает влияние неопределенности и позволяет обеспечить консистентность при эксплатации систем.
6) Automate everything that doesn’t require high degrees of judgment
Цель в том, чтобы дефолтом стала автоматизация процессов и исключение human in the loop, а люди привлекались только в моменты, когда требуется принятие решений

По большей части Вернер демонстировал эти принципы на примере AWS S3 (Simple Storage Service), а также на примере Amazon Aurora DSQL

#Architecture #SoftwareArchitecture #SystemDesign #DistributedSystems #Cloud #Management #Leadership
2,499
Книжный куб

29 Dec, 15:18

ЦЕХ 4 - Урок #27 "Книга издана. Что теперь?. Эксперт — Дмитрий Утробин" (Рубрика #Writing)

Финальным уроком курса для авторов книг от издательства МИФ был урок про то, а что делать, когда книга уже издана. Урок вел Дмитрий Утробин, партнер и содиректор МИФа. Вот что я вынес для себя из финального урока

1) В России высокая конкуренция на книжном рынке - каждый год выходит примерно 100к книг. Читателям сложно ориентироваться в этом разнообразии и автор и издательство заинтересованы в том, чтобы помочь книге найти аудиторию
2) У книг долгая оборачиваемость - от создания рукописи до книги на полке проходит около года. А это значит, что книга - это долгий инвестиционный проект для издательства
3) На книжном рынке низкая прозрачность - традиционные игроки редко деляться своей статистикой
4) Для того, чтобы выделиться на рынке можно использовать упоквку книги, дизайн обложки, активный маркетинг и правильную дистрибуцию
5) Бумажные книги составляют примерно 80% выручки издательства, а сама цепочка продаж включает издательство, дистрибьютора (наценка 20–25%) и магазин (наценка 80–140%). Для продаж бумажных книг важно представление их на полках магазинов и поддержание оптимального товарного запаса.
6) Электронные и аудиокниги составляют 10–20% выручки. Их стоимость постепенно выросла до 50–70% от цены бумажных версий.
7) Аудиокниги активно развиваются с темпами роста 40–70% в год благодаря удобству приложений для прослушивания.
😍 Федеральные сети («Читай-город», «Буквоед») доминируют, но независимые книжные магазины становятся культурными центрами и лидерами мнений.
9) Маркетплейсы («Озон», «Вайлдберриз») растут быстрыми темпами, но требуют особого подхода к продвижению.
10) Интересен опыт МИФа, где собственный интернет-магазин обеспечивает 35% оборота компании, что позволяет быстро получать обратную связь и адаптировать маркетинговые стратегии. Вообще, выгодно иметь прямую точку взаимодействия с покупателями/клиентами:)
11) Проведение культурных мероприятий с участием авторов помогает укрепить связь с читателями.
12) Автору важно участвовать в продвижении своей книги, так как он лучше всех может рассказать о своём произведении.

На этом курс для меня закончен, а написание книжек все еще in progress:)

Предыдущие посты про этот курс писательского мастерства доступны здесь
1. Увидеть свое имя на обложке может каждый
2. Целевая аудитория и ее потребности в создании книги
3. Жанры и стили. Как найти тему для нон-фикшн-книги
4. Как организовать работу
5. Как преодолеть писательские блоки. Практическое занятие
6. Жду музу, а она все не приходит
7. Книга по полочкам
8. MS Word для работы с большими и сложными текстами
9. Рассказываем истории: сторителлинг в книге
10. Саморедактура: работа с текстом, сокращения, фактчекинг
11. Правила сильной книги захватывающего текста
12. Авторская стилистика
13. Как превратить рукопись в сценарий
14. Рукопись готова. Что дальше?
15. Превращение рукописи в издание
16. Авторские права и договор с издательством
17. Дизайн книги.
18. Продвижение в самиздате.
19. Продвижение автора
20. Social media marketing (SMM)
21. Ведение блога и его продвижение в Телеграме
22. Взаимодействие с обозревателями, критиками и СМИ
23. Продвижение автора. Личный кейс
24. Продающие тексты
25. Как стать брендом?
26. Работа автора с литературным агентом

P.S.
Сейчас открыта запись на курс ЦЕХ #5, который стартанет в марте 2025 года. Если вы планировали написать свою книгу, то этот курс вам может в этом помочь:)

#SelfDevelopment #PublicSpeaking #Storytelling #Writing
2,299
Книжный куб

29 Dec, 05:08

Несведущий маэстро (The ignorant maestro: How great leaders inspire unpredictable brilliance) - Part II (Рубрика #Management)

Внезапно я решил продолжить рассказ про книгу "Несведущий маэстро" ("The ignorant maestro"), про которую писал уже год назад. Это обусловлено лекцией Сергея Бурлака, музыканта, бизнес-тренера и автора канала "МузДиета" (@musicdiet). Я был на этой лекции в четверг вечером и Сергей рассказывал о стилях лидерства, показывал видео великих дирижеров и даже сам исполнял музыку. Основой выступления была третья часть книги "Несведущий маэстро", в которой приводилось следующи 6 стилей лидерства

1. Доминирование и контроль: Риккардо Мути
Риккардо Мути представляет модель лидера, который берет на себя полную ответственность и требует абсолютного контроля. Он настаивает на единственно правильной интерпретации и не допускает отклонений от своих указаний. Такой стиль обеспечивает точность исполнения, но подавляет инициативу и творчество подчиненных. Это приводит к необходимости постоянного контроля со стороны лидера, что может истощать как его самого, так и коллектив. Характерно, что когда Риккардо решили убрать из "Ла Скала" из-за конфликта, то никто из его сотрудников не вступился за него.
2. Крёстный отец: Артуро Тосканини
Артуро Тосканини воплощает стиль строгого, но заботливого лидера. Он относился к своему коллективу как к семье, требуя дисциплины и безупречности, но одновременно проявляя глубокое уважение и поддержку. Его эмоциональность мотивировала музыкантов выкладываться на полную, а его требования воспринимались как стремление к общему совершенству, а не как тирания.
3. Согласно инструкции: Рихард Штраус
Рихард Штраус демонстрирует стиль лидера с четкими инструкциями. Он избегал излишней эмоциональности и личных интерпретаций, предпочитая следование заранее разработанному плану. Такой подход обеспечивает стабильность и безопасность, но ограничивает творческую свободу и инициативу коллектива.
4. Гуру: Герберт фон Караян
Герберт фон Караян характеризуется как лидер без явных инструкций. Он ожидал от музыкантов интуитивного понимания его видения и самостоятельной синхронизации действий. Это развивало в коллективе взаимное слушание и ответственность за общий результат, но могло вызывать стресс из-за отсутствия четких ориентиров.
5. Танец лидера: Карлос Клайбер
Карлос Клайбер представлял собой лидера в потоке — он вел коллектив за собой через совместное творчество, предоставляя каждому участнику свободу для интерпретации. Его стиль напоминал танец, где каждый был автономным, но взаимозависимым. Это требовало высокого уровня доверия и ответственности от всех участников процесса. Интересно, что тут у Сергея Бурлака был другой пример с женщиной дирижером, но смысл был примерно в том же, только стиль назывался в стиле "Каждый голос будет услышан"
6. В поисках смысла: Леонард Бернстайн
Леонард Бернстайн воплощал стиль чуткого лидера, который видел в каждом члене команды личность со своими уникальными качествами. Он строил диалог на эмоциональном, интеллектуальном и моральном уровнях, вдохновляя людей искать смысл в своей работе. Такой подход стимулировал развитие индивидуальности, но требовал значительных усилий для поддержания взаимопонимания.

В общем и целом, мне очень понравилось выступление Сергея, так как он на практике показал и объяснил про все эти разные подходы к лидерству, которые я до этого прочел в этой книге про несведующего маэстро. Сергей как практикующий музыкант смог увлечь аудиторию за собой и провести по этой интересной теме.

P.S.
Более подробный обзор этих стилей лидерства можно прочитать в статье на Lifehacker, там же есть видеозаписи выступлений дирижеров с их оркестрами.

#Management #Processes #Leadership #Self
2,015
Книжный куб

28 Dec, 17:02

Щелкунчик в Большом Театре (Рубрика #Culture)

Вчера был на балете Щелкунчик Петра Ильича Чайковского в Большом Театре вместе с женой. Мне понравилась музыка, декорации и само действие - было ощущение, что проваливаешься в детскую сказку, где Щелкунчик выходит на бой против Мышиного Короля. Правда, мне показалось, что было мало накала и драмы - условно, Мышиный Король пал смертью храбрых в первой четверти второго акта, а все оставшееся время шли праздненства в честь Щелкунчика и его избранницы:) В Лебедином Озере, на котором я был год назад в Большом тоже перед Новым годом напряжение держалось сильно дольше:) Но это я так ворчу, а вообще история была очень красивой и праздничной. Рекомендую к просмотру:)

#Culture #Theater
2,450
Книжный куб

26 Dec, 13:48

Satya Nadella | BG2 w/ Bill Gurley & Brad Gerstner (Рубрика #AI)

Интересное интервью CEO Microsoft, что Сатья Наделла дал двум венчерным инвесторам Bill Gurley и Brad Gerstner. В самом интервью много интересного, но основными были следующие темы:
1) Назначение генеральным директором Microsoft
Наделла делится своим опытом, включая стратегическую записку, направленную в комитет по выбору CEO, и трансформацию компании под его руководством с 2014 года, что привело к значительному увеличению доходов, прибыли и рыночной стоимости. Кстати, про это можно почитать книгу Сатья Наделлы "Hit Refresh", про которую я рассказывал раньше
2) Искусственный интеллект и OpenAI
Сатья и ведущие обсуждают инвестиции Microsoft в OpenAI, гонку вооружений в области ИИ и будущее ИИ-агентов. Наделла подчеркивает трансформирующий потенциал ИИ как для потребительских, так и для корпоративных приложений. Про это подробнее ниже
3) Будущее SaaS и ИИ-агентов
Наделла прогнозирует, что ИИ революционизирует SaaS (программное обеспечение как услуга), разрушая традиционные категории приложений и позволяя ИИ-агентам управлять бизнес-логикой через несколько баз данных.
4) Советы для генеральных директоров
Он делится своими мыслями о лидерстве, акцентируя внимание на понимании структуры рынка и использовании партнерств для достижения успеха.
В ходе беседы также рассматриваются стратегия капитальных расходов Microsoft, безопасность ИИ и дальнейшие шаги в развитии OpenAI.

А теперь подробнее про фразу "SaaS is dead", которая суммаризирует мнение Сатьи о дальнейшем развитии enterprise приложений как сервисы. Это мнение раскладывается на следующие тезисы
1) AI Replacing Static Business Logic
Наделла утверждает, что многие SaaS-приложения по сути являются базами данных CRUD (создание, чтение, обновление, удаление) с заранее определенной бизнес-логикой. Он прогнозирует, что ИИ-агенты возьмут на себя управление этими статическими процессами, динамически обрабатывая бизнес-логику через несколько баз данных, что сделает традиционную архитектуру SaaS менее актуальной
2) Shift to AI-First Architectures
В нашем будущем, бизнес-приложения уйдут от статических моделей, с ориентацией на приложения к системам, что ориентированы на агентов. Эти агенты буду выполнять роль интеллектуального слоя, который будет хранить состояние и выполнять оркестрацию запросов к внешним приложениям, чтобы выполнять задачи автономно без заренее прописанных вручную workflow
3) Collapsing Back-End Systems
По мере успешной работы агентных систем потребность в стандартных бизнес-приложениях с кучей коннекторов и интеграцией между ними уменьшится. Теперь агенты смогут сами интегрировать эту функциональность. По-факту, мне все это напоминает чем-то напоминает переходы, что были раньше
- Когда-то был толстый клиент и тонкое приложение, что, по-факту, только хранило данные
- Потом мы пошли в сторону тонких клиентов и большого количества логики на бекенде
- Потом бекендов стало много и им надо было уметь дружить с собой
- А в новом агентном мире бекенды смогут стать простыми, а вся сложность координации вернется на клиента (на агентнскую систему, что выполняет запросы от имени клиента)
4) Transformation of Tools and Processes
Такие инструменты, как Excel, могут превратиться в платформы, где ИИ-агенты выполняют сложные задачи — от планирования до анализа и исполнения. Например, интеграция Python в Excel уже демонстрирует такие изменения
5) Opportunities for Innovation
Хотя этот переход может нарушить существующие модели SaaS, он также открывает возможности для создания адаптивных решений с приоритетом ИИ. Компании, которые примут этот переход, будут лучше подготовлены к новой парадигме

В итоге, Сатья скорее говорит не про смерть SaaS, а про перерождение в более динамичную и интеллектуальную систему под управлением ИИ. Это знаменует значительную эволюцию в проектировании и использовании программного обеспечения. По-моему мнению, это очень интересно влияет на архитектуру и дизайн софта, но об этом как-нибудь в следующий раз.

#Management #Strategy #Leadership #Vision #Bigtech
968
Книжный куб

26 Dec, 06:09

Обложки книг "Культурный код" и "The Culture Code: An Ingenious Way to Understand Why People Around the World Live and Buy as They Do"
1,450
Книжный куб

26 Dec, 05:08

Культурный код (The Culture Code: An Ingenious Way to Understand Why People Around the World Live and Buy as They Do) (Рубрика #Management)

Книга Клотера Рапая "Культурный код: Как мы живём, что покупаем и почему" раскрывает концепцию культурного кода, который представляет собой бессознательный смысл, придаваемый объектам или явлениям в рамках конкретной культуры. Автор книги, Клотер Рапай - французский психоаналитик, маркетолог и бизнес-консультант, который известнен как раз этой теорией «культурных кодов». Он родился во Франции в 1941 году, но позже эмигрировал в США, где построил свою карьеру. Рапай является основателем и CEO компании Archetype Discoveries Worldwide, которая занимается исследованием культурных архетипов и их применением в маркетинге. В этой книге он описывает свою концепцию в научно-популярном стиле и раскрывает основные идеи

1) Импринтинг и эмоции: Запечатленные в детстве образы и связанные с ними эмоции формируют бессознательные ассоциации, которые влияют на восприятие и поведение человека во взрослой жизни. Эти образы являются основой культурных кодов.
2) Различия между культурами: Каждая культура имеет уникальные коды, которые определяют восприятие таких понятий, как здоровье, красота, секс и молодость.
3) Практическое применение: Знание культурных кодов помогает бизнесу адаптировать продукты и маркетинговые стратегии для разных стран. Успех бренда на мировом рынке зависит от его соответствия культурным ожиданиям.

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

1) Коды любви, обольщения и секса
1.1) Любовь
- В США любовь ассоциируется с обманутыми ожиданиями.
- Во Франции любовь связана с удовольствием.
- В Италии — с весельем.
- В Японии любовь воспринимается как временная болезнь.
1.2) Обольщение. В американской культуре обольщение связано с манипулированием. Например, компания L'Oréal адаптировала свою рекламу в США, делая акцент на уверенности женщины в себе, а не на соблазнительности.
1.3) Секс. Код секса в США — насилие, что объясняет более терпимое отношение американцев к насилию по сравнению с сексуальностью.

2) Коды красоты и лишнего веса
2.1) Красота. В американской культуре красота ассоциируется со спасением мужчины, так как считается, что женщина может сделать мужчину лучше.
2.2) Лишний вес. Код лишнего веса — бегство от проблем и неудач.
3) Коды молодости и здоровья
3.1) Здоровье
- В США здоровье связано с движением, поэтому продукты, связанные с мобильностью, популярны среди американцев.
- В Китае здоровье ассоциируется с гармонией с природой.
-В Японии здоровье воспринимается как долг перед семьей и обществом.
3.2) Молодость. Молодость в американской культуре символизирует энергию и стремление к новым достижениям.

В итоге, сам автор книги использует культурные коды для создания успешных рекламных кампаний, поскольку они позволяют брендам адаптировать свои сообщения к особенностям восприятия целевой аудитории в разных культурах. Это позволяет
1) Учитывать национальные особенности и ассоциации
2) Адаптировать сообщения для разных культур
3) Использовать локальные образы и традиции
4) Стремиться к созданию эмоционального резонанса
5) Избегать провалов благодаря чувствительности к культуре и ее кодам

#Culture #PopularScience #Management
1,474
Книжный куб

25 Dec, 16:51

ЦСКА - СКА (Рубрика #Sport)

Выбрался на хоккейный матч с сыном и друзьями, опоздал на папу минут к началу и пропустил обе стартовые шайбы. Так матч для меня начался с 2:0, а через 10 минут я дождался еще одной шайбы, которую уже увидел.

#ForKids #Sport
1,742
Книжный куб

24 Dec, 09:36

Research Insights Made Simple #7 - Interview with Pavel Lakosnikov about Architecture Governance (Рубрика #Architecture)

В этом выпуске подкаста про инсайты ко мне в гости пришел Павел Лакосников для того, чтобы поговорить про управление архитектурой в крупной компании:) Павел руководит юнитом architecture governance в Авито, распилил один монолит, а также любит метрики. Пришел в Авито 9 лет назад на позицию разработчика.

За время подкаста мы обсудили темы:
- Как Павел начал свою карьеру в IT
- Как дизайн игр связан с архитектурой
- Как от надежности приложений перейти к их архитектуре
- Как мерить надежность и архитектуру, какие метрики бывают
- Зачем нужны процессы и стандарты
- Как происходит эволюция процессов разработки
- В чем роль платформ при создании сложных систем
- Какие советы можно дать инженерам, что хотят прокачивать свои навыки

P.S.
Выпуск доступен в виде подкаста в podster.fm, а чуть позже будет и на Yandex Music.

#Architecture #Software #Evolution #Management #Governance #Management #Leadership
2,189
Книжный куб

23 Dec, 13:16

От продуктов к JBTD или как поток изменений влияет на структуру компании (Рубрика #Management)

В прошлом году на YaTalks 2023 я уже рассказывал про то, как формировать структуру команд под запросы бизнеса. В конце этого лета я рассказывал о том, как выглядит схема управления Т-Банком сейчас. А в этой статье я хотел бы рассказать о том, а как она трансформировалась со временем и куда мы движемся сейчас. В своем описании я буду использовать концепцию матричного управления, но баланс матрицы будет постоянно меняться:)
В новой статье есть рассказ про три структуры
1) Функциональная организация - этот этап я назвал "горизонтальным"
2) Продуктовая организация - этот этап я назыал "вертикальным"
3) Организация, ориентированная на сценарии (JBTD) или сегменты - этот этап я назвал "диагональным"

#Management #Architecture #Software #Engineering
1,812
Книжный куб

23 Dec, 06:09

Муми-тролль и Рождество (#ForKids)

Мы были вчера с младшим сыном на постановке "Муми-тролль и Рождество" в театре "Доммик Фанни-Белл" и нам очень понравилось. В рождественскую пору к актерам Фанни-Белл иногда приезжают гости и в этот раз это был театр «Karlsson Haus» из Санкт-Петербурга, который привез с собой этот спектакль по мотивам произведений Туве Янссон.

Основная суть спектакля в том, что обычно Муми-тролли как медведи зимой впадают в спячку и пропускают зимние праздники. Но в этот раз они заснули, а потом проснулись и пораньше и застали подготовку все долины Муми-троллей к приходу Рождества, чтобы это ни значило. У них возникли вопросы
- А кто это такой?
- Почему его надо радовать подарками?
- Зачем нужна елка и во что ее надо одевать?
- Опасен ли этот неведомый зверь, если все обитатели долины так бояться не успеть подготовиться к его приходу?

В итоге, муми-тролли решают снизить риски и проявить конформизм - они начинают готовиться к рождеству на всякий случай. А потом они узнают, что это лучший праздник на свете, а еще в гости приходит Санта-Клаус (Дед Мороз, Йоулупукки, ...) и дарит всем подарки.

P.S.
Мы любим постановки в теаре "Домк Фанни-Белл" и наши дети тоже их любят. Постановки отлично подходят для дошкольников и поэтому мы уже по второму разу смотрим многие спектакли - первый раз был со средним сыном, а теперь настала очередь младшего:)

#ForKids #ForParents #Culture #Theater
2,124
Книжный куб

22 Dec, 11:14

Продолжение Woke, Inc. или подробнее про DOGE (Department of Government Efficiency) (Рубрика #Management)

В предыдущем посте я рассказывал про книгу Вивека Рамасвами "Woke, Inc.". А в этом посте хотел чуть подробнее поговорить про DOGE, консультативной комиссии, цель которой в сокращении бюрократии, снижении неэффективных расходов и упрощении работы федерального правительства. Руководить этой комиссией будут 2 человека
- Илон Маск - генеральный директор Tesla и SpaceX, известный своей поддержкой дерегуляции.
- Вивек Рамасвами - предприниматель и бывший кандидат в президенты, сторонник политики минимального вмешательства государства.

Основные цели комиссии следующие
- Сокращение федеральных расходов за счёт устранения дублирующих регуляций и агентств.
- Уменьшение численности федерального персонала, с предложением сократить его на 75%.
- Консолидацию федеральных агентств с более чем 400 до менее чем 100.
- Консультирование по вопросам дерегуляции для повышения эффективности и снижения затрат. Руководители комиссии говорят оценивают эффект в 2$ трлн долларов из федрезерва США.
- Реформа Diversity, Equity, and Inclusion (DEI): одной из ключевых целей является полное устранение расходов на инициативы в области разнообразия, равенства и инклюзии (DEI). Это включает ликвидацию соответствующих подразделений в таких ведомствах, как Министерство здравоохранения и Министерство обороны.
- Прозрачность работы DOGE: Все действия министерства будут освещаться онлайн для обеспечения максимальной прозрачности. Это позволит гражданам следить за ходом реформ в режиме реального времени.

DOGE будет работать до 4 июля 2026 года, что совпадает с 250-летием Соединённых Штатов. Трамп описал эту дату завершения как символическую для миссии быстрого достижения эффективности. Не так уж долго придется подождать, чтобы оценить насколько удастся задуманное этими джентельменами:)

Правда, есть ряд проблемок на пути к реализации задуманного
- DOGE не обладает прямыми регуляторными или исполнительными полномочиями, поэтому его роль ограничивается предоставлением рекомендаций.
- Предложения по сокращению программ социального обеспечения или дискреционных расходов могут столкнуться с серьёзным политическим сопротивлением.
- Юридические вызовы могут возникнуть при попытках обойти одобрение Конгресса для реализации некоторых мер дерегуляции.

Рамасвами сравнивает масштабность этих реформ с Манхэттенским проектом времен Второй мировой войны, подчеркивая их потенциальное влияние на всю страну. Он считает, что главной проблемой США является раздутая бюрократия, которая мешает эффективному управлению государством. Таким образом, DOGE под руководством Рамасвами и Маска нацелен на радикальное преобразование структуры управления США с упором на сокращение расходов, упрощение процессов и повышение прозрачности работы правительства.

#Management #Leadership #Thinking
1,988
Книжный куб

22 Dec, 06:09

Обложки книг "Woke, Inc. За фасадом корпоративной риторики о социальной справедливости" и "Woke, Inc.: Inside Corporate America's Social Justice Scam"
2,200
Книжный куб

09 Dec, 08:44

Архитектурная ката от клуба { между скобок } (Рубрика #Architecture)

Несколько недель назад Гриша Скобелев, основавтель клуба { между скобок } (@backend_megdu_skobkah) собрал людей для участия в архитектурной кате. А в группу экспертов он позвал несколько человек, включая меня. Задача была в проектировании масштабируемой и отказоустойчивой системы поддержки клиентов, работающей через чат. Фокус был в том, чтобы разобраться а как обеспечить связь клиента и оператора поддержки в режиме реального времени с минимальными задержками. Сейчас стала доступна запись этой каты

Полезные ссылки:
- ArchDays - конференция по архитектуре, где я в программном комитете
- Объединение ИТ-Архитекторов
- Канал Игоря Антонова про разработку
- Хорошее видео про event storming
- Про микросервисы от Сергея Баранова

#Architecture #DistributedSystems #SystemDesign #Engineering #Software
1,554
Книжный куб

08 Dec, 12:15

Манюня (Рубрика #Kids)

Уже месяц читаю по вечерам детишкам главы из автобиографической книги "Манюня" про двух армянских девочек, что жили еще во времена СССР. Повествование идет от лица Наринэ, которая рассказывает о том, как они с ее подругой, Манюней жили в маленьком армянском городке Берд. Книга состоит от отдельных рассказов, что передают атмосферу советского времени, описывая повседневные радости и трудности через призму детских воспоминаний. Нам эти истории нравятся эффектом дежавю, так как мы успели пару лет назад прожить полгода в Ереване и покататься по армянским достопримечательностям:)

А вообще книга наполнена теплым юмором и, читая ее детишкам, я сам часто улыбаюсь:)

#ForKids #ForParents #Humor
1,904
Книжный куб

08 Dec, 05:08

Сто лет недосказанности: Квантовая механика для всех в 25 эссе (Рубрика #PopularScience)

На прошлой недели я решил почитать что-то легкое и ненапряжное ... и снял с полки эту свежую книгу Алексея Семихатова, лекции которого я с большим удовольствием смотрел на ПостНауке. С тех пор Алексей успел написать две научно-популярные книги "Все, что движется" в 2023 и "Сто лет недосказанности" в 2024 году. Начал я с конца, а точнее со второй книги, в которой автор на пальцах изложил ключевые принципы квантовой механики и ее разнообразные интерпретации. В книге 25 отдельных эссе, которые связаны одной нитью, которая ведет нас как нить Ариадны от вопроса "из чего сделаны вещи" к стандартной модели элементарных частиц, проходя через все основные промежуточные станции, навроде молекул и атомов, электронов и фотонов, уравнений Шредингера и Дирака, горячих дискуссий Бора и Эйнштейна относительно верности копенгагенской интерпретации и так далее. Если говорить про основные моменты, которые осветил автор, то это

1) Принципы квантового мира: автор обсуждает особенности квантовой реальности, которая плохо дружит с человеческой интуицией. Он объясняет, как квантовые законы формируют мир вокруг нас, включая существование атомов, взаимодействие света и вещества, а также процессы, лежащие в основе работы Солнца
2) Эволюция квантовых систем: автор рассматривает правила, по которым развиваются квантовые системы во времени (тут появляется уравнение Шредингера и его кошка), а также роль вероятностей в этих процессах (тут отрабатывает правило Борна). Интересно рассматривается коллапс волновой функции при наблюдении
3) Интерпретации квантовой механики: Семихатов исследует различные подходы к пониманию квантовой реальности — от гипотезы параллельных вселенных до вопросов о разрывах в восприятии. Эти интерпретации очень интересны с точки зрения философии (мне особенно понравился кьюбизм, который напомнил мне солипсизм по своему подходу)
4) Переход к макромиру: В книге объясняется, как привычная нам реальность возникает из чуждого ей квантового мира. Семихатов показывает, что классические законы физики не могут объяснить многие явления без учёта их квантовой природы
5) Спин и его значение: спин электрона проходит через всю книгу, автор описывает его как квантовую меру вращения, и при помощи этого свойства проще всего демонстрируется фундаментальная квантовая природа нашего мира. Для измерения направления спина используется прибор Штерна — Герлаха, который появившись в одной из первых глав дальше упоминается постоянно:)

Итого, книга мне очень понравилась - я прочитал ее буквально на одном дыхании за пяток вечеров. Думаю, что она мне бы пригодилась для наглядной визуализации концепций, изложенных Ландау и Лифшицев в их знаменитой серии, которые я читал лет 20 назад, когда изучал теорфиз на Физтехе:) Особенно, это верно, если учесть, что в книге Алексея Семихатова нет ни одной формулы:)

#PopularScience #Physics #History
1,971
Книжный куб

07 Dec, 12:20

Картинки, что я нарисовал для иллюстрации темы количества мякоти и корочки в арбузах в зависимости от размерности пространства. Правда, я смог нормально нарисовать только одномерный и двухмерный арбуз, трехмерный арбуз получился похуже, а арбузы из большего количества измерений я визуализировать пока не научился:)
1,989
Книжный куб

06 Dec, 18:13

Code of Leadership #25 - Interview with Anastasia Kabishcheva about group dynamics and BART Model (Рубрика #Management)

В этом выпуске подкаста речь идет про групповую динамику и модель BART (boundaries - authorities - roles - tasks), а в гостях у меня Анастасия Кабищева - организационный консультант и ментор, которая помогает разобрать эту сложную тему за счет своего опыта. Настя работала в разных ИТ-компаниях в качестве менеджера проектов и портфельного менеджера проектов, пересобирала команды для проектов заказной разработки, а сейчас заканчивает магистратуру по психоанализу в Вышке и пишет диссертацию на тему профессиональной идентичности продакт менеджеров. Кстати, эпизод доступен и в Ya Music.

За время выпуска мы успели обсудить следующие темы

- Что такое групповая динамика и чем ее знание может быть полезно
- Что такое идентичность человека / компании и как это связано с корпоративной культурой
- Как работают культурные принципы и причем здесь антропология
- Что такое модель BART и как она может помочь руководителю
- Что такое модель Такмана и как она связана с BART
- Как связано лидерство и алгоритм консенсуса Raft
- Как думать о политике внутри компании в парадигме теории игр, шахмат, го, ...
- Как изучить групповую динамику на практике

Дополнительные материалы

0. Сайт Анастасии "Soulcoaching"
1. Конференция про психоаналитические техники работы с бизнесом (10 декабря 2024) - Промокод для подписчиков канала - ENERGY50 (скидка на билет 50%)
2. Конференция GRC онлайн
3. Книга «Бессознательное в организации» (Гирнальзик, Катуржевский, Ломер)
4. Книга "Личность и групповая динамика" (Стейпли)
5. Вопросы для каждого блока модели BART
6. Канал про офлайн конференции GRC
7. Фреймворк SPACE на тему developer productivity
8. Книга "The corporate tribe"
9. Эпизод "Code of Leadership" с разбором книги "5 пороков команды"
10. Интервью "How to Deliver Quality Software Against All Odds • Daniel Terhorst-North & Julian Wood • GOTO 2024"

#Processes #Management #Agile #Leadership #Software #Project #CriticalThinking
1,909
Книжный куб

06 Dec, 05:08

Откуда я беру интересные whitepapers (Рубрика #RnD)

Я люблю изучать научные статьи и уделяю этому много времени. Меня часто спрашивают где я их нахожу и я постоянно отвечают, что самые интересные статьи есть на сайтах bigtech компаний
1) Google Research. Основные области исследований Google включают машинное обучение, алгоритмы, квантовые вычисления, вычислительные системы, а также исследования в области науки, общества и ответственных технологий.
2) Amazon Science. В Amazon фокусируются на машинном обучении, компьютерном зрении, обработке естественного языка, квантовых вычислениях, автоматизации логистики и устойчивом развитии.
3) Meta Research*. Исследования охватывают искусственный интеллект, дополненную и виртуальную реальность, обработку естественного языка и социальные взаимодействия.
4) Mircosoft Research. Microsoft фокусируется на следующих областях: искусственный интеллект, машинное обучение, квантовые вычисления, компьютерное зрение, безопасность, взаимодействие человека и компьютера и технологии для социальных благ.
5) Netflix Research. Основные направления у Netflix сфокусированы на нужных для них темах: персонализация контента, оптимизация потоковой передачи, анализ данных и улучшение качества контента с использованием NLP и компьютерного зрения

Также есть общие библиотеки крупных ассоциаций
1) ACM Digital Library (ACM - Association for Computing Machinery)
2) IEEE Publications (IEEE - Institute of Electrical and Electronics Engineers)

P.S.
Я уже как-то рассказывал про свое увлечение whitepapers
1) Мое выступление на Techlead Conf "Как RnD появляется в крупных IТ-компаниях"
2) Новогодный выпуск "Code of Architecture" по white paper «Google's Hybrid Approach to Research»
3) Перечень изученных и разобранных за 1+ год whitepapers
4) Мой подкаст "Research Insights Made Simple" с разбором whitepapers (пока 5 эпизодов, что доступны на Youtube, Yandex Music)

P.P.S.
Meta - это запрещенная в России организация.

#Whitepaper #Architecture #Management #Science
2,176
Книжный куб

05 Dec, 06:09

The Best Programmer I Know • Daniel Terhorst-North • GOTO 2024 (Рубрика #Leadership)

Интересное выступление Дэниела Терхорст-Норта (презентация тоже доступна), в котором он поделился своими наблюдениями о том, что делает хорошего программиста отличным. Фактически он разбил все наблюдения на три категории
1) Getting the job done
2) Choosing the right tool
3) Caring about the team

Part 1 - Getting the job done
1) Just start - для того, чтобы сделать работу, важно ее начать, а многим инженерам перфекционизм мешает это сделать:)
- Resist procrastinating - иногда перфекционизм превращается в прокрастинацию, с которой надо бороться
- Know you don’t know - первая версия не обязана быть правильной или хорошей, все равно она будет переписана
- Iterate wildly - это про test and learn и извлечение знаний из опыта (Try, fail, learn, repeat)
2) Build a product - мы не просто пишем код, а создаем продукт
- Invest in the outcome - собственно, должна быть какая-то цель и привязанность должна быть не к коду, а к достижению результата
- Study the domain - важно понимать домен и разговаривать на языке домена
- Watch your users - лучший способ получить обратную связь от пользователей — провести время с ними. Так вы сможете понять что мешает им и поправить это в продукте
3) Solve for now
- Learn to see what is really there - важно научиться видеть глубже
- Solve the real problem - важно решать реальные проблемы, а не те, которые кажутся таковыми.
- Strive for simplicity - нужно стремиться к простым решениям, а не плодить complexitty

Part 2: Choosing the right tool
1) Choosing the right tool for the product, not the team! - выбор инструментов должен основываться на продукте и ситуации, а не на предпочтениях команды.
- Teams can learn! - внутри команд работают инженеры, которые могут учиться новому:)
- Do the simplest thing, not the easiest - нужно выбирать инструменты, которые лучше подходят для решения конкретной проблемы.
- The ‘right tool’ may change over time - тут пример Scala для создания первой версии торговой системы, а потом замена ее на другой язык
2) Make the change easy
- Minimise blast radius - для упрощения изменений надо ограничить радиус их поражения:)
- Reduce, reuse, recycle - надо строить модульную систему, чтобы можно было менять отдельные компоненты
- Then do the same with production code! - Дэн рекомендует упрощать и продакшен код (рефакторинг)
3) Be a polyglot - важно быть универсальным разработчиком
- Explore languages, tools, paradigms - Дэну часто помогает с этим Advent of Code - 25-дневная игра с головоломками.
- Be ‘full-stack’ - тут про фронт, бек, API, мобилу
- Be really full-stack - здесь про инженерные процессы, железо и вопросы к тому, а зачем мы вообще делаем задачу:)

Part 3: Caring about the team
1) Caring about others
- Find joy in helping others learn - лидерские качества, работа в команде, наставничество и коучинг важны.
- Send the team home! - нет переработкам
- Be kind - предполагай, что люди вокруг делают лучшее из возможного, а также работай над психологической безопасностью в команде (подробнее я говорил об этом при обзоре проекта "Google's Project Aristotle" про команды)
2) Caring about staying current
- Join communities - контрибьють в коммьюнити и знакомься с новыми крутыми людьми
- Try new things - но подходи к этому со здоровым скептицизмом
- Practise, practise, practise - чтобы быть хорошим инженером, надо практиковаться
3) Caring about yourself
- Have interests outside of programming - нужны хобби вовне:)
- Go home on time - не забывай о доме
- Be kind to yourself - будь добр к себе и ведите себя так, как хотите, чтобы вели себя другие

Итого
- Наша работа - создавать полезные продукты, а не писать программы.
- Выбирайте правильные инструменты для конкретной ситуации.
- Заботьтесь о команде, себе и своем развитии.

P.S.
У Даниэля есть и другие выступления, про которые я рассказывал
- How to Bake a Change
- The Most Dangerous Phrase
- How to Deliver Quality Software Against All Odds

#Processes #Management #Agile #Leadership #Software #Project #CriticalThinking
2,489
Книжный куб

04 Dec, 05:08

Code of Leadership #24 - Interview with Konstantin Evteev (Рубрика #Management)

В этом эпизоде подкаста я беру интервью у Константина Евтеева. Костя - директор департамента ИТ сервисов, поддержки и инфраструктуры X5 Digital. В настоящий момент отвечает за инфраструктуру и развитие платформ для разработчиков. Прошел путь развития стартапа сервисов онлайн-доставки до одного из лидеров рынка. Раньше занимался развитием платформы баз данных и продуктовой разработкой в Авито. Активный участник PostgreSQL и других сообществ.

Мы обсудили следующие темы
- Как Костя начинал свою карьеру в Туле, работая в НИИ
- Как он перебрался в Авито и прошел собеседования
- Как в Авито менялась его роль по мере переноса логики из базы в микросервисы, а потом при разъезде на продуктовые и платформенные команды
- Как Костя участвовал в развитии Postgres и ездил на конфу по Postgres в Ванкувер с докладом
- Как ушел из Авито в X5 Digital (тогда X5 Food tech) за новым вызовом
- Как X5 Digital кратно рос, а Костя с командой справлялся с этим
- Какие советы для инженеров есть, чтобы расти как профессионально

Дополнительные ссылки от Кости
- Качество vs Скорость: технические процессы в растущей команде
- Запуск платформенных команд
- Recovery use cases for Logical Replication in PostgreSQL 10
- Standby in production: scaling application in the second largest classified site in the world
- Pg Saga (Хабр, Youtube)

#Architecture #Software #Management #Leadership #Processes #Architecture #Database
2,239
Книжный куб

03 Dec, 10:13

How to Deliver Quality Software Against All Odds • Daniel Terhorst-North & Julian Wood • GOTO 2024 (Рубрика #Management)

Интересное интервью Дэниела Терхорст-Норта, которое он дал Джулиану Вуду в рамках конференции goto. Интересно, что Daniel - это первый сотрудник лондонского офиса ThoughWorks, который когда-то давно в прошлом помог нанять туда звездную команду, многие из которых уже написали книги и часто выступают на goto конференциях. Но если возвращаться к тезисам доклада, то вот они

1) Дэниэль начинает с воспоминаний о том, как 20 лет назад он в рамках конфы сидел на дискуссии с Мартином Фаулером:) Он говорит, что конференции goto и yow были для него местом получения знаний и инсайтов (там выступали сами создатели технологий)
2) За последние 20 лет многие технологии и подходы прошли путь от новинок до буквально commodity. Например, потрепанный жизнью Agile, который стал просто маркетинговым термином, но вот например adoption CI/CD подходов пока не слишком хорощ (по мнению автора)
3) Сейчас актуальна тема эффективности использования ресурсов, автор упоминает про serverless в этом контексте.
4) Даниэль вспоминает про подход impact mapping от Гойко Аджича, про который я уже рассказывал. Этот инструмент стал популярным для создания гипотез и бизнесовых планов в виде mind maps. А это уже помогает правильно собрать эффективную архитектуру под требования бизнеса. Даниэль предлагает рассматривать архитектуру с точки зрения экономических драйверов
6) Дэниэль был пионером BDD (behavior-driven development) и создал jbehave, поэтому ребята обсудили связь BDD с разработкой, а также с TDD (test-driven development)
7) Даниэль поучаствовал в создании книги 97 вещей, которые должен знать каждый программист", куда он принес принцип о том, что надо писать код, используя язык бизнеса (аля ubiquitous language). Он рассказал пример о том, как это помогло ему в сложном проекте при его рефакторинге и понимании бизнес-правил
😍 Дальше Даниэль размышляет про DDD и важность понимания бизнесовой составляющей для программистов
9) Даниэль интересно рассказывает про свой путь в Thoughtworks, сбор команды и ранние проекты - очень интересно заглянуть за кулисы этого консультанта аля BCG, но из мира технологий:)
10) Так автор доходит до того, что они внедряли CI/CD и DevOps своим клиентам, когда этих слов еще не знали:)
11) Отдельно прикольно, как автор описывает проблемы крупных изменений в организациях - он сейчас консультирует разных заказчиков и есть проблемы с тем, чтобы преодолеит инерцию, запустить изменения и не потерять всю команды на их волне:)
12) К Даниэлю часто заходят топ-менеджеры крупных компаний за помощью в изменениях и он не может рекомендовать ни одной серебрянной пули, поэтому приходиться разбираться на месте с тем, что требуется и как этого достичь:)
13) Даниэль отмечает важность управления продуктом (do the right things), но он говорит, что это не его - он умеет в delivery (do the things right) и зачастую он работает в паре с крутыми CPO (chief product officer), чтобы создавать крутые продукты
14) Даниэль очень точно показывает разницу между продуктами и проектами, которая состоит в том, что мы по разному их финансируем и по разному подходим к управлению рисками (это прямо в точку)
15) У Даниэля есть проблемы с реализацией своих идей - у него их много, но он не умеет доводить свои личные проекты до конца. Уже больше 10 лет он пишет книгу "Software, faster" (еще с 2011-2012 года), но так и не дописал ее, а вот книгу "Patterns of effective teams" он почти дописал и это заслуга со-автора, что ограничил полет фантазии Даниэля:)
16) Напоследок ребята обсудили выступление Даниэля "Лучший программист, которого я знаю", про которое я расскажу отдельно, а дальше финализировали тезисами
- При разработке продукта люди являются ключевыми участниками процесса
- Цель - повлиять на изменение поведения и сделать жизнь веселее

P.S.
У Даниэля есть и другие выступления, про которые я рассказывал
- How to Bake a Change
- The Most Dangerous Phrase

#Processes #Management #Agile #Leadership #Software #Project #CriticalThinking
2,138
Книжный куб

03 Dec, 05:24

Duolingo (Рубрика #SelfDevelopment)

Последние пару лет я ежедневно занимаюсь с этой зеленой совой. Когда-то я тренировал не только английский язык, но сейчас остался только он. Не факт, что duolingo помогает мне со всеми навыками английского языка, но как минимум он помогает мне со словарным запасом и их произношением, а также не дает забыть грамматику. Плюс, я могу заниматься в любой удобный для меня слот и зачастую короткими интервалами по 15 минут:)

#SelfDevelopment
2,361
Книжный куб

02 Dec, 11:20

Про system design interview на Highload++ (Рубрика #Architecture)

Сегодня я на конференции Highload++ буду участвовать в дискуссии относительно границ применимости system design interview. Я достаточно много рассказывал о том, что это и чем помогает в найме нам, но есть мнение, что этот тип интервью стал карго-культом, который многие используют просто в силу моды. Собственно, про это мы и поговорим с Филиппом Дельгадо и Владимиром Невзоровым сегодня вечером.

Интересно, что недавно я познакомился с бренд-менеджером издательства Питер и она любезно решила предоставить мне книжку Alex Xu "System Design. Подготовка к сложному интервью", которую я вручу слушателю за лучший вопрос во время дискуссиии. Кстати, у ребят до 3 декабря продолжается черная пятница со сидками: 40% на бумажные книги и 50% на электронные по промокодам "Бумажная" и "Электронная" соответственно. Отдельно отмечу, что при знакомстве я рассказал о качестве переводов, которые могли быть лучше и мне сказали, что над улучшением качества переводов в последнее время активно работают. И я бы хотел помочь в будущем с редактурой книг на темы engineering management и архитектуры.

В итоге, я подготовил подборку книг, доступных в издательстве Питер, которые могут быть полезны при прокачке навыков проектирования систем (список отчасти повторяет мою статью из блога)
1) System Design. Подготовка к сложному интервью - классическая книга про system design interview. В ней неплохо описывается сам подход + есть практические примеры. Конечно она не слишком подробна и местами слабо написана, но это отличный способ познакомиться с этим типом интервью.
2) System Design. Машинное обучение. Подготовка к сложному интервью - книга о том, как выглядят system design задачки в контексте ML инжиниринга. Качество примерно такое же, как у первой книги Alex Xu

Дальше идут более фундаментальные книги, которые позволяют наработать базу для практической работы, а также помогут на интервью
3) Современные операционные системы. 4-е изд.. - классическая книга от Эндрб Танненбаума и ко, из которой можно узнать об устройстве OS. Конечно эта книга достаточно академична, но в ней изложен фундамент. Для изучения вашей любимой OS рекомендую взять ту книгу, которая посвящена конкретно ей
4) Архитектура компьютера. 6-е изд. - классическая книга от Таненбаума про устройство компьютеров. Важно, что написанный нами код исполняется на железе, которое работает определенным образом. Понимание этого позволяет понять какие гарантии мы можем получить, насколько производительными могут быть узлы системы, а также насколько надежна получившаяся конфигурация. Лучше читать вместе с книгой про операционные системы, так как с голым железом большинство инженеров не взаимодействуют, а полагаются на абстракции от OS
5) Компьютерные сети. 6-е изд. - это классическая книга от Таненбаума про сети. В мире распределенных систем от сетей зависит очень многое, поэтому их точно надо изучить. Бонусом идут паттерны из сетевого мира, которые потом реплицируются часто на уровне приложений. Можно глянуть например на ретраи и exponential backoff или подходы к управлению QoS
6) Компьютерные сети - классическая книга про сети от Олиферов. В этой книге рассматриваются примерно те же вопросы, что у Таненбаума, но менее академично и более практично
7) Высоконагруженные приложения - классическая книжка с кабанчиком. В конце 2025 года будет новое издание, но и старое все еще ничего (я про него уже рассказывал)
😍 Распределенные данные - перевод книги "Database internals", которую я разбирал в двух частях: storage engines и distributed systems, а также обсуждали в подкасте "Code of Architecture"
9) Безопасные и надежные системы как в Google - перевод крутой книги "Building Secure and Reliable Systems", про которую я уже рассказывал раньше
10) Делай как в Google. Разработка программного обеспечения - перевод крутой книги "Software Engineering at Google", про которую я уже рассказывал

#Software #Architecture #DistributedSystems #SystemDesign #Engineering
2,412
Книжный куб

02 Dec, 06:09

System Design Interview by Groks King (Рубрика #Architecture)

На выходных прочитал очередную книгу по system design, которую как-то прикупил с Амазон еще пару лет назад. Меня часто упрекают, что я слишком добро обозреваю книги, но обычно я пытаюсь вытянуть из книг лучшее, но с этой книгой это сложно - в этой книге про system design
- Очень кратко даются теоретические основы и как-то обраывками, из которых не собирается общая картинка
- Нет ни одной схемы - автор предпочитает все описывать словами, поэтому формат взаимодействия компонентов между собой приходится наполовину угадывать
- Разборы практических задач состоят из отдельных частей, которые не всегда собираются в единое целое - например, в задачке про web crawling концовка посвщена защите робота от ловушек для спкам ботов, но рассказ не бьется с предыдущими частями
- В задачках бывают отсылки к векторным часам, CAP и PACELC, моделям консистентности, репликации, но ничего из этого автор не удосуживается не то, чтобы объяснить, а даже расшифровать:)

В общем, книга ужасна для тех, кто хочет подготовиться к интервью. А вот мне было интересно почитать и попробовать сложить из этой россыпи букв что-то осмысленное. Если бы книга не вышла в 2021 году, то я решил бы, что ее написал chatGPT первого поколения:)

P.S.
Если понравился формат и хочется еще отзывов с прожаркой книг, то напишите в комментах и поделитесь своими историями о книгах, что вас разочаровали:)

#Software #Architecture #DistributedSystems #SystemDesign #Engineering
2,529
Книжный куб

01 Dec, 16:02

System Design for Interviews and Beyond - Курс на Leetcode - Part III (Рубрика #Architecture)

Заканчивая разбор курса о System Design Interview, я хотел рассказать про все оставшиеся части, которые не были в первом посте и втором посте. Первый пост рассматривал работу с требованиями, важные архитектурные характеристики, инфраструктуру, кеширование и очереди. Второй пост был посвящен хранению данных,  взаимодействие компонентов системы, доставке данных быстро и надежно. В этом заключительном посте речь пойдет про защиту серверов от клиентов и наоборот, а также несколько практических задачек

11. How to protect servers from clients
Здесь автор рассказывает о том, как обычно выглядит overload системы, что такое autoscaling, как применять load shedding и как ограничивать количество запросов при помощи rate limiting. В общем, тут идет речь про базовые паттерны для построения надежных систем.

12. How to protect clients from servers
Здесь все начиналось с рассмотрения того, а какие типы клиентов бывают: синхронные и асинхронные. Дальше автор разобрал как работает circuit breaker и как он помогает как клиентам, так и серверам. Дальше речь зашла про fail fast principle, который в моем представлении противоречит концепции resiliency. Ну или это мой bias, когда я видел слишком много примеров небезопасного кода, который оправдывали подходом fail fast:) Следующий принцип bulkhead - я сам его люблю вспоминать в контексте переборок на Титанике, которые были сделаны хреново и на самом деле не защищали от проблем. Ну и финальный паттерн - shuffle sharding, который выглядит действительно интересно в разрезе количества пользователей, которых затрагивает проблемы при выходе нод из строя.

13. Практические задачки
В конце курса автор предлагает потренироваться в проектировании на достаточно стандартных задачках:
- Классический url shortener
- Fraud detection system
- Authn и authz система
- Мониторинговая система

#Software #Architecture #DistributedSystems #SystemDesign #Engineering
2,641
Книжный куб

01 Dec, 11:45

System Design for Interviews and Beyond - Курс на Leetcode - Part II (Рубрика #Architecture)

Я продолжаю рассказ про крутой курс с Leetcode, в котором доступно и понятно рассказывали о том, что такое system design interview и что он призван проверять у кандидатов. В предыдущем посте мы обсудили работу с требованиями, важные архитектурные характеристики, инфраструктуру, кеширование и очереди. В этой части мы продолжим говорить про хранение данных,  взаимодействие компонентов системы

6. Data store internals.
Здесь автор кратко рассматривает тему хранения данных:
- Log - самый простой способ сохранения данных, но вот читать их сложно в таком виде (full scan на любой запрос)
- Index - индексы в качестве способа подготовки данных для эффективных запросов на чтения
- Time series data - отдельный тип данных, которые полезны, например, при мониторинге
- Simple key/value database - автор объясняет как будет работать база с простейшей моделью данных
- B-Tree index - автор рассказывает про вездесущие b-tree индексы, как они устроены и для каких сценариев подходят оптимально
- Embedded databases - иногда удобно встроить базу прямо в процесс приложения, например, так могут LevelDB, RocksDB, DuckDB
- RocksDB - автор рассказывает как устроена эта база и тут речь про memtable, write-ahead log и SSTables
- Сравнение LSM-tree и B-Tree - автор показывает компромиссы каждого из подходов и сравнивает их границы применимости
- Page cache - заканчивает автор рассказом о том, как все это приземлить на файловую систему внутри OS. Без этих знаний многое из описанного выше не будет хорошо работать

7. How to build efficient communication in distributed systems.
В этой части автор говорит про классику коммуникаций
- Push vs pull модели взаимодействия
- Как выглядит host и service discovery (тут появляется DNS), а также peer discovery
- Как выбирать сетевой протокол под задачу (UDP, TCP, HTTP) и как они ведут себя на практике
- Как обычно передается видео-поток и что такое CDN (content delivery network)
- Что такое short pooling, long pooling, web-socket, server-sent events, зачем они нужны и как они ведут себя на практике
- В конце раздела автор показывает как могут работать пуши на клиентов на большом масштабе (аля Netflix)

8. How to delivery data reliably.
Этот раздел начинается с известного списка fallacies of distributed systems, а дальше автор переходит к практическим средствам обеспечения надежности
- Таймауты и стратегии действий с неуспешными запросами: cancel, retry, failover, fallback
- На конкретных примерах автор разбирает когда и как делать retries
- Дальше наступает время обсудить гарантии доставки сообщений: at most once, at least once, exactly once
- Дальше автор рассматривает как работают log-based message queues (аля Kafka) и что такое consumer offset

9. How to deliver data quickly
Здесь автор рассказывает про подходы к батчингу и компрессии данных, что обеспечивает лучшую пропускную способность.

10. How to deliver data at large scale
В этой части наступает время обсудить вопросы масштабирования обработки данных. Автор рассказывает про
- Партиционирование (шардирование) и рассматривает стратегии: lookup strategy, range strategy, hash strategy
- Как партиционирование работает в реальном мире и какие плюсы/минусы имеет
- Как выглядит роутинг запросов
- Что делать с ребалансировкой шардов
- Что такое consistent hashing

Продолжение обзора будет в следующем посте.

#Software #Architecture #DistributedSystems #SystemDesign #Engineering
2,637
Книжный куб

01 Dec, 06:30

System Design for Interviews and Beyond - Курс на Leetcode - Part I (Рубрика #Architecture)

Я наконец-то закончил этот курс с Leetcode, в котором доступно и понятно рассказывали о том, что такое system design interview и что он призван проверять у кандидатов. В этом курсе много теории, но она подана в практико-ориентированном виде - автор не рассказывает про условные сети с начала времен и по сегодняшний день, а раскрывает основные концепции тогда, когда речь заходит про общение компонентов системы между собой. Похожее происходит и с хранением данных - легко уйти глубоко в теорию, но сложно удержаться и рассказать про b-tree и lsm-tree по ходу дела, рассматривая реальные вызовы проектирования системы. Но автор отлично справляется с вызовом и рассказывает одновременно понятно и достаточно точно. Если же возвращаться к содержанию курса, то он состоит из следующих частей

1. How to define system requirements.
Здесь автор говорил про важность функциональных и нефункциональных требования, а дальше проходил по типовым архитектурным характеристикам (-ilities), с которым обычно имеют дело на system design interview: high availability, fault tolerance, scalability, performance, durability, consistency, maintainability, security, cost efficiency. У автора курса отлично получилось объяснить все эти характеристики буквально на пальцах, а также показать их связь между собой, условно, все можно сделать безопасно просто отключив систему и сделав ее недоступной, но кажется, что нам нужен баланс:)

2. How to achieve certain system qualities with the help of hardware.
Здесь автор проводит связку между архитектурными характеристиками системы и тем, как она развернута. Он рассказывает про концепции регионов, зон доступности, дата центров, стоек и финально серверов. Дальше он переходит к рассказу про сервера, виртуальные машины, контейнеры и даже serverless. Я считаю, что эту базу нужно знать, чтобы дизайнить внятные системы.

3. Fundamentals of reliable, scalable, and fast communication.
Для того, чтобы из отдельных частей получилась система, этим частям надо уметь эффективно общаться между собой. В ээтой главе автор про это и рассказывает, а для этого он проговаривает основы
- Синхронные и асинхронные коммуникации
- Паттерны асинхронных коммуникаций (messaging queue, publish/subscribe, competing consumers, request/response, priority queue, claim check)
- Сетевые протоколы (UDP, TCP/IP, HTTP)
- Блокирующие и неблокирующие операции ввода/вывода (i/o)
- Формат кодирования данных (текстовые и бинарные, как шарить схему данных, backward/forward compatibility)

4. How to improve system performance with caching.
В этом разделе автор рассказывает про кеширование, но мне сам раздел показался вырванным из контекста рассказа - условно еще не поговорили про хранение данных, а уже воткнули куда-то кеши:)

5. The importance of queues in distributed systems.
Важный раздел, в котором автор детально разбирает очереди и их использование в распределенных системах (а в system design вы обычно дизайните как раз распределенную систему). В общем, автор говорит про следующие концепции
- Bounded и unbounded queue, а также про circular buffer (например, когда у вас логи по кругу перезаписываются в одно ограниченном по размеру файле)
- Что делать с переполнением очередей и пустыми очередями: load shedding, rate limiting, dead letter queues, backpressure, elastic scaling
- Паттерны producer-consumer, блокирующие очереди, семафоры
- Как работают thread pools, в чем разница между cpu-bound и i/o-bound задачами, как обеспечить graceful shutdown
- Как работает batching и параллельная обработка jobs

Продолжение обзора будет в следующем посте.

#Software #Architecture #DistributedSystems #SystemDesign #Engineering
2,322
Книжный куб

30 Nov, 15:18

Research Insights Made Simple #5 "DORA Metrics, SPACE, DevEx, Human Approach to Dev Productivity" (Рубрика #Management)

Очередной выпуск подкаста с разбором whitepapers посвящен разбору темы developer productivity, где мы говорим про DORA метрики, фреймворк SPACE, подход DevEx, а также про human approach от Google к теме developer productivity. Для обсуждения этих тем ко мне пришел гость, Артем Арюткин, руководитель проектного и продуктового офиса в RideTech & e-com Яндекса. Артем отвечает за развитие платформы для разработчиков, а раньше в Сбере занимался развитие платформы Сбербанк онлайн и рекомендательной платформы. Артем ведет интересный телеграм канал "Плохой Project" (https://t.me/badTechProject). Кстати, выпуск доступен на двух площадках (Yandex Music и Youtube)

1) Мое выступление "Как и зачем измерять инженерную продуктивность в крупной компании" на MTS конференции
2) Обзор книги канонической книги "Accelerate" в трех частях:
-- Общая информация по книге, формат исследования и DORA метрики
-- Технические практики, архитектуру и интеграцию вопросов безопасности в процессы разработки
-- Менеджерские и лидерские практики
3) Выпуск подкаста "Code of Leadership" про "Accelerate" с Игорем Курочкиным
4) Разбор темы developer productivity в фреймворках SPACE, DevEx
5) Разбор начальной статьи ребят из Google "A Human-Centered Approach to Developer Productivity" и рассказ про целую колонку в IEEE журнале от этих авторов
6) Разбор статьи "Measuring Developer Goals" от ребят из Google (продолжение серии про Human-Centered Approach)
7) Разбор статьи "Developer productivity for Humans, Part 7: Software Quality" от ребят из Google (продолжение серии про Human-Centered Approach)
😍 Разбор выступления моего коллеги Вовы Калугина "Почему DevEx важен при разработке IDP и как его померить", где он рассказывает про нашу платформу Spirit и как мы подходим к вопросам developer experience и developer productivity
9) "Грокаем Continuous Delivery" - отличная книга, которая расскажет о CI CD и проведет вас по всему пути эволюции
10) "Гормоны счастья. Как приучить мозг вырабатывать серотонин, дофамин, эндорфин и окситоцин" - прекрасная книга, раскрывающая многие наши поступки. Мы слегка затронули тему длительного цикла обратной связи для менеджера и эта книга попадает туда, чтобы раскрыть тему. Но желание покрасить все тесты в зеленый простым их перезапуском - это, внезапно, про то, как работает наш мозг и желание получения быстрого дофамина. И когда занимаешься Developer Experience такое нужно учитывать

#Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes
2,685
Книжный куб

30 Nov, 05:08

ЦЕХ 4 - Урок #23 "Продвижение автора. Личный кейс. Эксперт — Лариса Парфентьева" (Рубрика #Writing)

В очередном уроке разбирался пример личного продвижения автора. О своем пути рассказывала Лариса Парфентьева. Основные моменты, что я вынес из урока такие
1) У авторов есть внутренние стандарты при написании книг, иногда они мешают довести ее до конца, а значит надо уметь вовремя останавливаться
2) Сначала надо написать книгу, а потом ее продвигать:) Иначе может случиться фальстарта
3) Личный бренд автора включает книгу-бестселлер, личную историю, социальное подтверждение и профессиональные награды.
4) Круто, если биография автора интересна и легко запоминается читателями
5) Важно презентовать свою книгу друзьям, знакомым, чтобы запустить сарафанное радио
6) Завершение книги увеличивает самоуважение и уверенность в других сферах жизни
7) Авторам стоит участвовать в профильных концеренциях и работать с профильными СМИ (писать статьи по своей профильной теме)
😍 Профессиональные награды могут помочь в продвижении книги, но можно обойтись и без них
9) Маркетинговая деятельность требует энергии, за которую она конкурирует с написанием книги
10) Если вы интроверт и не хотите внимания, просто пишите блестящие книги. Издательства сами займутся продвижением.
11) Личная история может помочь в продвижении, особенно если она связана с вашей экспертной книгой.
12) Можно нанять специалиста в SMM (social media marketing) для помощи в продвижении книги, а можно самому вести соцсети
13) Но важнее всего писать хорошие книги, так как без этого маркетинговые активности пропадут втуне

Предыдущие посты про этот курс писательского мастерства доступны здесь
1. Увидеть свое имя на обложке может каждый
2. Целевая аудитория и ее потребности в создании книги
3. Жанры и стили. Как найти тему для нон-фикшн-книги
4. Как организовать работу
5. Как преодолеть писательские блоки. Практическое занятие
6. Жду музу, а она все не приходит
7. Книга по полочкам
8. MS Word для работы с большими и сложными текстами
9. Рассказываем истории: сторителлинг в книге
10. Саморедактура: работа с текстом, сокращения, фактчекинг
11. Правила сильной книги захватывающего текста
12. Авторская стилистика
13. Как превратить рукопись в сценарий
14. Рукопись готова. Что дальше?
15. Превращение рукописи в издание
16. Авторские права и договор с издательством
17. Дизайн книги.
18. Продвижение в самиздате.
19. Продвижение автора
20. Social media marketing (SMM)
21. Ведение блога и его продвижение в Телеграме
22. Взаимодействие с обозревателями, критиками и СМИ

#SelfDevelopment #PublicSpeaking #Storytelling #Writing
2,510
Книжный куб

29 Nov, 16:45

Обложки для книг "Radical Candor: Be a Kick-Ass Boss Without Losing Your Humanity" и "Радикальная прямота"
2,422
Книжный куб

29 Nov, 16:40

Radical Candor: Be a Kick-Ass Boss Without Losing Your Humanity (Радикальная прямота) (Рубрика #Management)

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

Часть I - Новая философия менеджмента
1. Выстраивание радикально откровенных отношений. В этой главе описывается основная идея книги - важность сочетания личной заботы о сотрудниках с прямым вызовом. Автор объясняет, как это помогает улучшать рабочие отношения и повышать производительность команды.
2. Получать, отдавать и помогать. Эта глава посвящена методам установления доверительных отношений в команде, что является основой для успешного применения радикальной откровенности. Для этого автор описывает модель, которая визуализируется как двухмерный график. На графике вертикальная ось представляет "Личную заботу", а горизонтальная ось - "Прямой вызов". Цель состоит в том, чтобы работать в квадранте, где оба элемента высоки, создавая среду открытой и конструктивной обратной связи. Это и есть квадрант радикальной откровенности, а также есть разрушительное сочувствие, оскорбительная агрессивность и манипулятивная неискренность.
3. Что мотивирует каждого члена вашей команды. Здесь автор приводит свою модель суперзвезд и надежных сотрудников: фактически есть "суперзвезды", которые находятся на крутой траектории роста, и "надежные сотрудникы", которые предпочитают стабильность и устойчивую производительность. Признание этих различий помогает эффективно управлять ростом команды.
4. Добиться успеха вместе. В этой главе автор рассказывает про свою модель работы с людьми в команде "Выслушать" - "Объяснить" - "Обсудить" - "Решить" - "Убедить" - "Выполнить" - "Усвоить" и дальше опять "Выслушать". На протяжении всей главы автор рассказывает как должен работать этот цикл в компании.

Часть 2 - Инструменты и техники
5. Взаимоотношения. Эта глава посвящена построению и поддержанию эффективных отношений в команде. Автор подчеркивает важность доверия и открытого общения между коллегами. Она предлагает стратегии для улучшения взаимодействия, чтобы создать более сплоченную и продуктивную рабочую среду.
6. Наставничество. В этой главе рассматривается роль наставничества в развитии сотрудников. Автор объясняет, как руководители могут эффективно наставлять своих подчиненных, помогая им расти и развиваться в профессиональном плане. Она делится методами, которые позволяют вдохновлять и мотивировать сотрудников через личный пример и поддержку.
7. Команда. Глава фокусируется на создании эффективных команд. Автор обсуждает, как собрать команду, которая будет работать слаженно и продуктивно, а также как управлять различиями в характерах и навыках сотрудников. Автор подчеркивает важность разнообразия и инклюзивности для достижения лучших результатов.
8. Результаты. Заключительная глава посвящена достижению результатов через применение принципов радикальной откровенности. Автор делится инструментами и техниками, которые помогают руководителям не только устанавливать высокие стандарты, но и достигать их вместе с командой. Она акцентирует внимание на том, как измерять успех и корректировать подходы для постоянного улучшения.

Интересные факты о книге
- Ким Скотт активно использует свой опыт работы руководителем в bigtech компаниях, таких как Google и Apple.
- Она подчеркивает необходимость адаптации радикальной откровенности к различным культурным контекстам, чему она научилась в процессе работы с разнообразными командами по всему миру
- Книга не только теоретическая - она включает практические инструменты, такие как сценарии для сложных разговоров и основы для эффективных встреч.

#Engineering #Management #Leadership #Processes #SystemDesign #SystemThinking #SystemEngineering
2,246
Книжный куб

29 Nov, 05:08

Вакансия партнера по работе с данными (Рубрика #Vacancy)

В Т-Банке мы привыкли принимать решения на основе данных, а данных от 46+ млн клиентов и целой экосистемы продуктов у нас очень много. Для того, чтобы использовать более эффективно мы переносим ответственность за данные с централизованной дата платформы в сами домены. Мы считаем, что это позволит эффективнее работать с данными в каждом из направлений, за счет синка с продактами, аналитиками, разработчиками приложений. По-факту, в моей домен входят
- Клиентские интерфейсы: платформенные команды веба, мобилы и API
- Маркетинговые технологии: внешняя реклама, маркетинговая платформа
- Соц-медиа платформы: социальные сети, медиаплатформа, медиапроекты (ТЖ, Бизнес-секреты), игры
- Цифровые экосистемы: аутентификация/авторизация, биометрия, главная страница приложения, финздоровье
- Продуктовая аналитика и a/b платформа

В итоге, я ищу к себе человека, который поможет мне составить стратегию по работе с данными внутри этих доменов так, чтобы мы как компания получили дополнительный value. А дальше этот партнер по данным будет помогать реализовывать эту стратегию силами команд разработки внутри моего домена, используя инструменты дата платформы, которая сейчас уходит от стандартного DWH подхода в сторону data lake и lake house. Например, в этому году мы уже перенесли ответственность за отгрузку данных на сторону команд разработки, а также реализовали в новых инструментах (streaming data platform) возможность задавать контракты данных. Если выкинуть за скобки старые интеграции через базу (которых большинство), то мы уже живем в мире, где поток данных в data platform - это контракт примерно такой же, как публичный REST API. И на проблемы с этим контрактом реагируют продуктовые SRE команды. Собственно, у data platform есть еще много планов по тому, как нам двигаться в сторону data mesh технологически, а мне нужен помощник, что будет помогать мне двигать мои продуктовые команды в эту сторону светлого будущего.

Если приземляться на грешную землю, то успешному кандидату придется
- Выстраивать стратегию работы с данными, управления ими и эксплуатации в контексте домена
- Отвечать за people management: участвовать в процессах найма, развития и оценки, проводить one-to-one-встречи
- Выявлять проблемы и прогнозировать их
- Оптимизировать взаимодействие команд направления и платформы данных
- Собирать фидбэк от пользователей и заносить его в платформу
- Регулярно проводить аудит процессов или автоматизировать его
- Прогнозировать затраты ресурсов — например, в случае открытия нового продукта в своем направлении
- Участвовать в проектировании архитектуры данных домена и обеспечивать ее связность с данными организации

Само собеседование будет состоять из трех этапов:
- System design interview - тут нужно будет показать умения в дизайне несложных систем. Я много рассказывал про этот вид интервью
- Data architecture и технологии - здесь нужно будет тоже решить задачку о том, как спроектировать data архитектуру решения для построения аналитики по одному из доменов, а также про распределение ответственности между ролями
- Engineering management - этот тип интервью мы даем для руководителей, кто уже управлял несколькими командами. Я про него тоже рассказывал.

Если вам понравилась вакансия, то пишите в личку @apolomodov

P.S.
Для того, чтобы лучше понять мои ожидания от кандидата рекомендую
1) Послушать эпизод подкаста "Все считается" про проект "Данные под рукой"
2) Почитать whitepaper "What Goes Around Comes Around... And Around..." про развитие баз данных за последние 20 лет (есть мой обзор из трех частей: модели данных и языки запросов, системная архитектура, общие выводы и комментарии на будущее) Я рассчитываю, что мой партнер по данным понимает куда двигаются технологии и почему, а также как это выглядит у нас в компании
3) Полистать книгу Zhamak Dehghani "Data Mesh: Delivering Data-Driven Value at Scale", чтобы знать куда мы идем и быть готовым драйвить эти изменения в моем домене (я уже рассказывал про эту книгу)

#Management #Data #Leadership #Vacancy #Career
2,369
Книжный куб

28 Nov, 11:03

Observability in an Asynchronous World • James Eastham • GOTO 2024 - Part I (Рубрика #Architecture)

Интересное выступление от James Eastham, Serverless Developer Advocate из Datadog, на тему событийно-ориентированной архитектуры и тому, как в ней обеспечивать observability. В самом докладе нет ничего про Datadog, но есть сквозной пример пиццерии, архитектуру которой автор делает в EDA стиле и показывает как обеспечить ей наблюдаемость. Тезисы примерно такие

1) В распределенных системах сложно понять, что пошло не так при какой-то проблеме
2) В случае синхронный взаимодействий - это +/- понятно как делать, но в асинхронном мире наблюдаемость еще больше усложняется
3) В какой-то момент по мере роста масштаба систем мы пришли к большому количеству отдельных сервисов
4) При их построении принято стремиться к low coupling и high cohesion, условно связи между сервисами нужно делать несильными, а вот внутри сервиса логика должна быть сильно завязана друг на друга
5) Одним из вариантов решения проблемы связей между сервисами был переход на event-driven architecture. Тут автор показывает свою архитектуру для пицерии, где есть order processing service, kitchen service, delivery service, которые взаимодействую посредством событий
6) Дальше автор разбирает что такое событие (это непреложный факт, который нельзя изменить). Важно, что автора интересуют именно бизнес-события, которые приводят систему в движение. На эту тему рекомендую изучить технику event storming, про которую я рассказывал раньше
7) События - это разновидность сообщения, но событие уже произошло в прошлом. Также есть сообщение типа "команда", которое предписывает что-то сдлеать в будущем.
😍 События бывают трех видов: нотификации, события с передачей состояния (event-carried state transfer) и доменные события (это из event sourcing). Рекомендую почитать мой разбор главы про EDA и event sourcing из книги "Learning DDD" Влада Хононова
9) Собственно взаимодействие сервисов осуществляется через publish/subscribe шаблон, производители публикуют события с определенной схемой, а потребители могут их использовать (или не использовать)
10) Такое взаимодействие позволяет сделать асинхронную систему, что позволяет отвязать производителей от потребителей событий. Ответственность за контроль и потребление событий на консьюмерах

Продолжение в следующем посте.

#SRE #Architecture #DistributedSystems #Software
2,343
Книжный куб

27 Nov, 17:25

Иллюстрация результатов опроса для исследования про успешность IT проектов. В этой диаграмме 7 считается полным успехом, 5 и 6 - это выше mid-level, а ниже 5 считается неудачей.
2,300
Книжный куб

27 Nov, 05:08

Code of Leadership #23 - Interview with Andrew Marchenko (Рубрика #Architecture)

В этом эпизоде ко мне пришел крутой гость, Андрей Марченко, мой бывший коллега, который сделал много хорошего для веба Tinkoff.ru. Андрей является software engineer высокого грейда с большим опытом разработки платформенных решений для внутренних разработчиков. Много лет он работал над тем, чтобы сделать разработчикам жизнь проще, а продукты качественнее на разных позиций от разработчика, до руководителя 16+ инженеров. В последнее время он перешел в продуктовую разработку в одной из FAANG компании на позиции инженера. Сейчас он с интересом изучает как все устроено внутри, находит отличия от Российского IT, а также ищет путь для быстрого роста и повышений внутри компании.

Мы поговорили про следующие темы
- Начало карьеры Андрея в общем
- Как Андрей оказался в Тинькофф
- Как выглядел рост Андрея в Т
- Важность взаимодействия с людьми
- Переход в платформенную команду
- Про Statist и продуктовую аналитику
- Инфраструктурные проекты Андрея
- Коммуникации и убеждение
- Высокоуровневые инженеры
- Опыт работы в Тинькофф и переезд зарубеж
- Работа в Booking и изучение баз данных
- Ведение блога и улучшение английского
- Переход в FAANG компанию и текущие проекты
- Проблемы роста в американской компании
- Планы на будущее и как пришел к желанию переехать
- Потеря влияния в новой компании (карма и доверие)
- Решение сложных задач как залог роста
- Изучение дизайна крупных и высоконагруженных систем FAANG компаний изнутри
- Личный опыт и советы Андрея о том, как стать таким же крутым
- Проблемы Андрея с учебой из-за дислексии и их преодоление
- Важность работы и упорства

Дополнительные ссылки
- Блог Андрея со статьями, которые он иногда пишет на тему инфрастуктуры/архитектуры
- Телеграм канал Андрея
- Выступление Андрея про tramvai - "Tramvai, модульный фреймворк для React-приложений от Tinkoff"
- Выступление Андрея "Пять лет эволюции React-приложения"

#Architecure #Software #SystemDesign #Management #Staff #Engineering #PlatformEngineering
2,183
Книжный куб

26 Nov, 10:13

Database Internals Meetup #5 (офлайн + онлайн): 5 докладов на конференции ISPRAS Open

Последние пару дней у меня в канале посвящены базам данных, поэтому позволю себе порекомендовать посетить пятый митап российского сообщества разработчиков СУБД и распределенных систем, на котором будут доклады от основателей и ведущих разработчиков YDB, Picodata, Tarantool, openGauss и CedrusData. Мероприятие пройдет 11 декабря офлайн и оно будет частью конференции ISPRAS Open в Москве. Регистрация бесплатна и доступна здесь.

Программа митапа будет плотной и насыщенной:
- 13:00 - 14:00 - Эволюция архитектуры СУБД на примере YDB, Андрей Фомичев, Яндекс, основатель и руководитель YDB
- 14:00 - 15:00 - Blue/green deploy для хранимых процедур в кластерной СУБД на примере Picodata, Константин Осипов, Picodata, основатель Picodata
- 15:00 - 16:00 - Оптимизация подсказками: ускоряем запросы, не изменяя планировщик. Сергей Зинченко, OpenGauss, Инженер
- 16:30 - 17:30 - Columnar In-Memory в Tarantool: зачем нужно строить еще одну колоночную СУБД, да еще и в памяти? Николай Карлов, VK, Head of Innovations, tarantool.io
- 17:30 - 18:30 - Переписывание запросов на основе материализованных представлений в аналитической системе CedrusData. Владимир Озеров, Александр Блажков, генеральный директор и разработчик CedrusData

#Database #Architecture #Management #DistributedSystems #Software #Engineering
2,737
Книжный куб

26 Nov, 05:08

Архитектура в Т-Банке: вчера, сегодня, завтра — выступление на ArchDays 2024 (Рубрика #Architecture)

В этой статье я рассказываю про наши подходы к проектированию и построению архитектуры систем. Я в "Т" уже 8 лет и видел как эти процессы эволюционировали во времени, а также знаю к чему мы пришли. Я выделил следующие четыре стадии и объяснил как и почему они сменяли друг друга во времени
1. COTS (commercial of the shelf)
2. Свой собственный софт
3. Platform Engineering
4. Большие мегапроекты и governance

Напоследок я рассказал про подходы корпораций и технологических компаний к должностям/ролям архитекторов, а также поделился своим видением того, как нам дальше стоит развиваться. Эта статья является расшифровкой моего доклада на ежегодной конференции "ArchDays 2024", которая прошла в этом году уже в шестой раз.

#Architecture #Software #Evolution #Management
2,384
Книжный куб

25 Nov, 05:08

What Goes Around Comes Around... And Around... Part II (Рубрика #Data)

В продолжение рассказа про эту статью 2024 стоит поговорить про разные подходы к системной архитектуре, которые развивались в последние два десятилетия. Эти архитектуры отражают изменения в software (менялись типы приложений и их требования), а также изменения в hardware, а точнее изменения в параметрах аппаратного обеспечения (мощность CPU, скорость оперативной памяти, разные типы дисков, скорость сети и так далее).

1. Колоночные системы (columnar systems)
Эти системы стали стандартом де-факто в мире аналитических баз данных. Суть в том, что там запросы часто обращаются только к небольшому числу атрибутов таблиц. Колоночное хранение данных позволяет читать только нужные данные, а также лучше сжимать их благодаря однородности значений. Кроме того, можно добиться ускорения выполнения запросов за счет векторизованной обработки данных. Примерами таких баз данных являются Vertica, Amazon Redshift, Google BigQuery, Clickhouse, DuckDB.

2. Облачные базы данных (cloud databases)
Эти базы данных предоставляются в облаках, в которые было модно перевозить свою инфраструктуру. Такие базы обеспечивали масштабируемость и эластичность, что позволяло клиентам динамически изменять ресурсы. Восход этих баз данных связан с тем, что за последние 20 лет скорость сети увеличивалась гораздо быстрее, чем скорость диска, поэтому использование NAS (network attached storage) стало привлекательной альтернативой для стандартного устройства хранения. Собственно, основные вендоры в качества NAS используют объектные хранилища (например, AWS S3). Такая архитектура приводит к тому, что у нас разделяется compute и storage и мы имеем такие преимущества
- Можно обеспечить эластичность на уровне отдельных запросов
- Вычислительные ноды можно отправить на другие задачи, если DBMS не полностью утилизируется
- Можно переместить вычисления прямо на ноды хранения данных - подход называется "pushing the query to the data" и он показывает себя лучше, чем стандартный "pulling the data to the query".
Интересно, что два первых подхода называются serverless computing и в мир DBMS их принесла Snowflake. А среди популярных облачных баз данных есть
- Google Spanner - рекомендую интересный whitepaper
- Amazon Aurora - рекомендую интересный whitepaper, который мы даже как-то разбирали в выпуске подкаста "Code of Leadership", а также рекомендую глянуть рассказ с AWS Re:Invent 2023 о том, как они завезли туда шардирование

3. Озера данных (Data Lakes) и Lakehouses
Облачные платформы разожгли интерес к тому, чтобы отказаться от монолитов в аналитике и перейти к data lakes, где данные как есть загружались в объектные хранилища (S3 like). То есть тут был отход от стандартных ранее ETL (extract-transform-load) к ELT (extract-load-transform). После загрузки, прямо поверх данных выполнялись вычисления при помощи движков lakehouse, минуя стандартные DBMS (типа Greenplum). Собственно lakehouse - это комбинация из data warehouse и data lake:) Данные в data lake хранятся в бинарном виде: Parquet, ORC (optimized row columnar), а для обмена данных in-memory можно использовать формат Apache Arrow. В каждом облаке есть managed data lake сервисы, а также есть отдельные варианты в виде Databricks, Dremio, PrestoDB, Trino.

4. NewSQL-системы
В 2010х годах появился этот класс систем, чтобы совместить ACID транзакции из RDBMS и масштабируемость NoSQL решений. Одним из первых представителей стал уже упоминавшийся Google Spanner. По-факту, тут было 2 типа систем in-memory и стандартные disk-oriented. Часть стартапов ставили на больший спрос на in-memory подходы, но ставка не сыграла. На смену этим подходам пришли распределенные и транзакционные SQL RDBMS навроде TiDB, CockroachDB и думаю, что можно туда добавить YDB с их Calvin-транзакциями. Эти системы подходят для приложений, требующих как высокой производительности, так и строгой консистентности данных.

В продолжении окончание разбора статьи.

#Architecture #Software #DistributedSystems
2,101
Книжный куб

24 Nov, 13:25

What Goes Around Comes Around... And Around... Part I (Рубрика #Data)

Интересная обзорная статья 2024 года от Michael Stonebraker и Andrew Pavlo про развитие баз данных за последние 20 лет. Оба автора являются корефееями в области баз данных: Michael создал Postgres и еще кучу других баз, а Andrew - исследователь в области баз данных, профессор и преподаватель, лекции которого доступны на Youtube.

Сама статья продолжает статью 2005 года "What Goes Around Comes Around", которую написали Michael Stonebraker и Joseph M. Hellerstein. Они проанализировали историю развития баз данных за 35 лет и предсказали что модные тогда объектные и xml базы данных не смогут обойти по реляционную модель.

С тех пор прошло порядка 20 лет и пришло время сделать новый обзор мира баз данных. Для этого авторы решили посмотреть на это с двух сторон:
- Модели данных и языки запросов
- Архитектура баз данных

Начнем с разбора существующих data models и query languages:

1. MapReduce-системы
Изначально они были разработаны в Google для обработки больших объемов данных (веб-краулер). MapReduce не использует фиксированную модель данных или язык запросов, они выполняют пользовательские операции map и reduce. Открытой версией MapReduce стал Hadoop, который сейчас не очень популярен из-за низкой производительности и заменяется более современными платформами аля Apache Spark или просто СУБД.

2. Key-Value хранилища
У них максимально простая модель данных: пары "ключ-значение". Они используются для задач кэширования (Memcached, Redis) или хранения сессий. Возможности в модели ограничены - нет индексов или операций join, что усложняет применение для сложных приложений. Многие KV-хранилища (например, DynamoDB, Aerospike) эволюционировали в более функциональные системы с поддержкой частичной структуры (JSON). Среди популярных встроенных k/v решений популярны LevelDB и RocksDB.

3. Документные базы данных
Они хранят данные в виде документов (например, в формате JSON). Изначально получили популярность благодаря простоте интеграции с веб-приложениями (например, MongoDB), предлагая подход schema on read. Интресно, что к 2020-м годам большинство документных СУБД добавили SQL-подобные интерфейсы и поддержку ACID-транзакций, а иногда и schema on write.

4. Column-Family базы данных (wide columns)
По-факту, это упрощенная версия документной модели с ограниченной вложенностью. Начиналось все с Google BigTable, а в миру есть open source реализация в виде Apache Cassandra. Изначально в Cassandra не было вторичных индексов и транзакций. Но по мере развития они появились (но там все очень интересно)

5. Поисковые движки
Они нужны для полнотекстового поиска (Elasticsearch, Apache Solr). Поддерживают индексацию текста, но ограничены в транзакционных возможностях. Реляционные СУБД также предлагают встроенный полнотекстовый поиск, но с менее удобным API.

6. Базы данных для массивов
Они предназначены для работы с многомерными массивами, например, научные данные (SciDB, Rasdaman). Ниша ограничена специфическими областями применения: геоданные, изучение генома.

7. Векторные базы данных
Используются для хранения эмбеддингов из машинного обучения (Pinecone, Milvus). Основное применение — поиск ближайших соседей в высокоразмерных пространствах. Реляционные СУБД уже начали добавлять поддержку векторных индексов.

8. Графовые базы данных
Моделируют данные как графы (узлы и связи). Примеры: Neo4j для OLTP-графов, TigerGraph для аналитики. Большинство графовых задач можно реализовать на реляционных СУБД с помощью SQL/PGQ (новый стандарт SQL:2023).

Общие выводы
- Большинство нереляционных систем либо занимают нишевые рынки, либо постепенно сближаются с реляционными СУБД.
- SQL остается основным языком запросов благодаря своей гибкости и поддержке современных приложений.
- Реляционные СУБД продолжают развиваться и интегрировать новые возможности (например, JSON, векторные индексы), что делает специализированные системы менее конкурентоспособными.

В продолжении поста будет про архитектуру баз данных.

#Data #Architecture #Software #DistributedSystems
7,505
Книжный куб

23 Nov, 16:45

Финал Медиа Баскет Лиги (#Sport)

Утром открыл IT конфу своим докладом, а вечером пошел на финал медиа лиги по баскетболу. Про эту лигу я узнал неделю назад, команд и игроков не знаю, но сами полуфиналы получаются динамиными. Жду финального матча:)

#Sport
2,914
Книжный куб

23 Nov, 06:09

Как стать продуктивнее в IT, если вы уже прокачали свои харды (Рубрика #Management)

Сегодня я выступлю на конференции soft weekend, первой софтовой офлайн-конференция в России (что бы это ни значило). Я не могу сказать, что люблю рассказывать чисто про софты, но эту конференцию организует мой знакомый, Андрей Смирнов, автор подкаста "Frontend Weekend", куда я ходил в гости в прошлом году. В итоге, я решил рассказать что-то из серии набора качеств и навыков, что важны для всех: и для крутых инженеров и для хороших менеджеров.

Доклад будет состоять из 4х частей, которые описаны ниже, причем фокус будет на третьем пункте, а точнее навыках и умениях помимо hard skills, что помогали лично мне расти на протяжении всей карьеры

1) Зачем нам нужны soft skills
- В современном мире процессы разработки становятся все сложнее, зона ответственности IC (individual contributor) все увеличивается и включает system design, operation, data, security, ... (подробнее в моем рассказе о современном SDE и SDLC)
- Для борьбы с этой сложностью обычно применяют разные абстракции, например, для инфры это IaaS -> PaaS -> SaaS -> ...(подробнее в моем рассказе об облачных технологиях для Финтех Школы)
- Мы все живем в комплексном и хаотичном мире (complex и chaotic из фреймворка Cynefin)

2) Как расти в таких условиях
- Для инженеров есть две стандартные дороги: индивидуального контрибьютора или менеджера. В обоих, с какого-то уровня надо уметь проявлять лидерство. Условно, до middle+ IC можно дорасти только на хардах, а вот дальше ...(подробнее здесь)
- Например, в T есть матрица для инженера вида: scope, impact, complexity, leadership, improvement. По этой матрице оцениваются достижения инженеров в Т-рост (подробнее в отдельном посте)
- Т-рост - это процесс, по которому проходят повышения в Т. Инициатором является сам сотрудник, который готовит заявку на повышение с учетом своих достижений, упирая на то, что он закрыл оси вышеуказанной матрицы, а также прикладывает артефакты, которые это доказывает

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

4) Важность hard skills как базы для дальнейшего роста (пи... не мешки ворочать)
Если вы раскачаете софт скиллы с отсутствующей базой в виде hard skills, то это будет шатким фундаментом, который может рухнуть в произвольный момент. А в некоторые компании без них в принципе не попасть - например, у нас для инженеров есть интервью по программированию, языку разработки и system design. Такой набор эффективно отсеивает мастеров разговорного жанра.

P.S.
Запись выступления будет и потом я поделюсь ей в этом канале.

#Leadership #Processes #Management
2,107
Книжный куб

22 Nov, 05:40

Опыты и эксперименты для детей 10 в 1 (Рубрика #ForKids )

Уже приближается конец недели, а завтра начнутся выходные, которые можно провести с семьей. А у меня в семье три сына, которые не любят скуку. Если не придумать для них развлечения, то они могут перевернуть весь дом. Одним из таких развлечений являются разнообразные химические/физические фокусы, которые позволяют сделать руками что-то интересное и немного рассказать о научной составляющей вопроса. Достаточно хорошим является вариант опытов "10 в 1", в котором мы сделали за прошлую неделю все эксперименты, а некоторые их результаты украшают интерьер нашей кухни, например, разноцветные кристаллы, приложенные к посту в качестве снимков. В общем, я рекомендую знакомить малышей с наукой при помощи научпоп подходов (особенно учитывая, что такие эксперименты очень простые и красочные).

#Physics #PopularScience #ForKids #ForParents
2,490
Книжный куб

21 Nov, 10:13

Зачем заниматься темой developer productivity в большой компании - D-Day (Рубрика #Management)

В выходные я выступал на конференции D-Day, что оффлайн проводится в Тирасполе.Я рассказывал про тему developer productivity: зачем заниматься этой темой, как это принято делать в индустрии, как мы подходим к этому в Т-Банке. В конце я порекомендовал такой набор источников для более глубого знакомства с темой.

1) Мое выступление "Как и зачем измерять инженерную продуктивность в крупной компании" на MTS конференции
2) Обзор книги канонической книги "Accelerate" в трех частях:
-- Общая информация по книге, формат исследования и DORA метрики
-- Технические практики, архитектуру и интеграцию вопросов безопасности в процессы разработки
-- Менеджерские и лидерские практики
3) Выпуск подкаста "Code of Leadership" про "Accelerate" с Игорем Курочкиным
4) Разбор темы developer productivity в фреймворках SPACE, DevEx
5) Разбор начальной статьи ребят из Google "A Human-Centered Approach to Developer Productivity" и рассказ про целую колонку в IEEE журнале от этих авторов
6) Разбор статьи "Measuring Developer Goals" от ребят из Google (продолжение серии про Human-Centered Approach)
7) Разбор статьи "Developer productivity for Humans, Part 7: Software Quality" от ребят из Google (продолжение серии про Human-Centered Approach)
😍 Разбор выступления моего коллеги Вовы Калугина "Почему DevEx важен при разработке IDP и как его померить", где он рассказывает про нашу платформу Spirit и как мы подходим к вопросам developer experience и developer productivity

#Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes
2,168
Книжный куб

21 Nov, 05:08

How to Make the World Add Up (Ложь, наглая ложь и статистика) - Part II (Рубрика #Math)

Продолжая рассказ про книгу Тима Харфорда "How to Make the World Add Up", закончу списком оставшихся правил:

4. Чтобы увидеть всю картину, отступите на шаг назад. Важно уметь видеть информацию в контексте, тогда утверждения вида "случился еще один ужасный инцидент" могут заслонять тенденцию, что "в целом количество инцидентов снизилось":) То есть нам необходимы сравнения и контекст, чтобы понять как тезисы согласуются между собой.
5. Узнайте предысторию. Когда мы видим интригующие результаты исследований, то это часто связано с эффектом публикации (publication bias). Если смотреть шире, то нам нужно определить источник статистических данных и изучить, а все ли данные были учтены.
6. Спросите, кого не хватает. Надо всегда задавать себе вопрос, а все ли группы людей были учтены в исследованиях и если не все, то как бы поменялось исследование. В большинстве старых классических психологических исследованиях участниками были студенты колледжей, а не репрезентативная выборка всего населения. Одновременно, там не хватало даже студенток, которых можно было относительно легко привлекать к исследованиям, но об этом как-то не думали раньше. Про это подробнее можно прочитать в посте про "Опрос, что изменил опросы"
7. Требуйте прозрачности от компьютера. Этот пункт особенно актуален в наше время, когда у нас много больших данных и сложных алгоритмов. Важно не бояться задавать неудобные вопросы о том, что это за данные и как именно работает алгоритм. Интересно, что условный perplexity.ai сразу вместе со сгенерированным ответом дает ссылки на источники, откуда он брал информацию. Это не всегда спасает от галлюцинаций, но вы хотя бы можете сделать факт-чекинг.
8. Цените краеугольный камень статистики. Автор предлагает ориентироваться на официальную статистику, особенно в тех странах, где ей не принято манипулировать в угоду политическому курсу.
9. Помните, что дезинформация тоже бывает привлекательной. Если вам показывают красивую визуализацию, график или дашборд, то надо не стесняться и задавать вопросы о том, а что стоит за такой красотой:)
10. Не бойтесь изменить свое мнение. Автор говорит о том, что надо уметь менять свое мнение при появлении нового опыта или доступной информации. То есть надо рефлексировать относительно того, а не заблуждаемся ли мы, настаивая на старой точке зрения.
11. Золотое правило. Сохраняйте любознательность. В общем, автор предлагает копать глубже и задавать больше вопросов. Он выдвигает гипотезу, что любознательность можно прокачивать ...

Я не знаю можно ли прокачивать любознательность, но у меня она с детства была где-то на уровне 10 из 10. Помню как я доставал родителей, воспитателей, тренеров и учителей своими вопросами "А почему все работает именно так":) Походу, любознательность действительно дает хорошие плоды. Развивайте любознательность у себя и своих детей и изучайте с интересом мир вокруг вас!

P.S.
В своей книге автор упоминает и другие книги про статистику
1) Как лгать при помощи статистики (How to Lie with Statistics) - книга, где на пальцах объясняется как врут с помощью статистики. Собственно, автор книги зарабатывал на жизнь тем, что тасовал данные, убеждая в том числе, что курение не приводит к раковым заболеваниям
2) Темные данные (Dark Data. Why What We Don’t Know Is Even More Important Than What We Do) - книга про то, как можно облажаться с данными и что с этим можно сделать
3) The Tyranny of Metrics (Тирания показателей) - эта интересная книга, название которой идет наперекор стандартному подходу к измерению всего и вся:) Она напоминает по структуре научную статью и классно описывает проблемы, которые во многом рождены из закона Гудхарта "Когда мера становится целью, она перестает быть хорошей мерой".

#Math #Management #Statistics
1,953
Книжный куб

20 Nov, 13:55

Черная пятница в издательстве «Питер» (Рубрика #Sales)

В издательстве Питер очередная распродажа со скидками в 40% на бумажные книги и 50% на электронные. Для получения этой скидки надо использовать промокод "Бумажная" (или "Электронная", если покупаете элетронную версию) при оформлении заказа. На прошлых распродажах я уже купил себе пачку книг и докупил на этой распродаже еще книг

Новые купленные книги
- Производительность систем - интересная книга о производительности от Brendan Gregg, крутого эксперта, который одновременно много сделал для внедрения eBPF, о чем можно узнать из документалки
- Креативный программист - я решил изучить креативные методы, что могут помочь в решении инженерных задач
- Продвинутые алгоритмы и структуры данных - книжка о самых необходимых алгоритмах решения сложных задач программирования в области анализа данных, машинного обучения и графов. Хочу подтянуть свои знания алгоритмов
- Ненормальные личности. Учение о психопатах - решил почитать про ненормальность от Ганнушкина
- Об уме вообще - книга Павлова (хозяина знаменитой собаки из экспериментов), который писал интересно о работе мозга

Книги, что я уже успел прочитать
- Чистый Python. Тонкости программирования для профи - решил вспомнить теорию по python
- Компьютерные сети. Принципы, технологии, протоколы: Юбилейное издание, дополненное и исправленное - я уже как-то читал книгу Олиферов, но это было много лет назад и она была ок. Сейчас я прочитал 150 страничек из нового издания и могу сказать, что книга не ухудшилась:)
- Гейм-дизайн: как создаются игры - эта книга про геймдизайн, про который я и до этого много читал и писал (1, 2, 3), а сейчас я уже прочитал и рассказал об этом
- Разработка приложений на базе GPT-4 и ChatGPT - базовая книга про chatGPT, я ее уже прочел и даже рассказывал оо ней
- Мифический человеко-месяц, или Как создаются программные системы - классическая книга Фредерика Брукса, которая в следующем году справляет свой юбилей. Я раньше уже рассказывал про эту книгу
- Распределенные данные. Алгоритмы работы современных систем хранения информации - в девичестве на английском эта книга Алекса Петрова называлась Database Internals и я про нее много рассказывал (1 и 2), а также мы ее обсуждали в подкасте "Code of Architecture"
- Безопасные и надежные системы: Лучшие практики проектирования, внедрения и обслуживания как в Google - эту книгу я читал в оригинале и она называлась "Building secure and reliable systems", а также уже рассказывал про нее.

Книги, что мне еще предстоит прочитать
- Data mesh в действии - интересная тема о переходе от DWH в сторону Data Mesh и Lake House. До этого я читал частями книгу "Data Mesh: Delivering Data-Driven Value at Scale".
- Грокаем алгоритмы искусcтвенного интеллекта - просто тема интересная для меня:)
- Настоящий CTO: думай как технический директор - тут я решил сравнить насколько я думаю как настоящий технический директор, а то вдруг я думаю как-то не так:)
- README. Суровые реалии разработчиков - книга про будни разработчиков и практиками инжиниринга
- Software: Ошибки и компромиссы при разработке ПО - эта книга подкупила меня своей второй главой, которая называется "Дублирование кода не всегда плохо".
- Грокаем Continuous Delivery - я вроде неплохо понимаю в CI/CD, но хочется почитать про него подробнее
- Грокаем функциональное программирование - интересно почитать просто про функциональщину
- Дизайн для разработчиков - я довольно много книг читаю про дизайн для дизайнеров (1, 2, 3), а тут хочу посмотреть как это подают разработчикам
- Карьера Software Engineering Manager. Эффективное управление командой разработчиков ПО - в рамках работы над книгой про engineering management полезно изучить другие источники
- Карьера продакт-менеджера. Все что нужно знать для успешной работы в технологической компании - для инженеров и технических руководителей сейчас полезно думать продуктово, особенно если вы работаете не в галере. Яуже писал про книги на эту тему: 1, 2, 3, 4, 5
- Паттерны проектирования API - я люблю паттерны, люблю хорошие API, плюс мне понравилось оглавление.

#Sales
2,321
Книжный куб

19 Nov, 13:05

Code of Leadership #22 - Интервью с Дмитрием Аношиным про data engineering (Рубрика #Data)

В этом выпуске ко мне пришел в гости крутой гость, Дмитрий Аношин. Дима является экспертом в data engineering, ведет канал @rockyourdata, также Дима почти 10 лет работал западных Bigtech компаниях. Кстати, выпуск доступен в виде подкаста и в Яндекс Музыке.

Мы обсудили следующие темы:
- Как Дима входил в IT порядка 15 лет назад
- Как он развивал свои навыки как дата инженер
- Как он уехал в Канаду и адаптировался там
- Как развивалась карьера Димы в Amazon, Microsoft и что он вынес из этого опыта
- Как Дима стал создателем обучающих проектов datalearn, surfalytics, а также как ему удалось написать целую гору книг
- Как находить мотивацию для роста и развития

Если говорить подробнее про Дмитрия, то он уже больше 15 лет занимается аналитикой и инжинирингом данных, а 10 последних лет проработал в Северной Америке. Из них 5 лет в Амазоне, где работал в нескольких командах, включая Alexa AI (в Бостоне) и Customer Behaviour Analytics (в Сиэтле). Поучаствовал в действительно инновационных проектах, где драйвером являются данные. Видел и Big Data и Machine Learning в действии в масштабе крупнейшей компании мира. После Амазона работал 4 года в Microsoft Xbox и Microsoft Azure Data&AI. Активно принимал участие в развитии Microsoft продуктов для аналитики - Synapse, Fabric, Azure Databricks.

Теперь, Дмитрий помогает создавать инновационные аналитические решения, дата команды и модернизировать устаревшие решения через свою компанию rockyourdata.cloud и глобально готовит инженеров и аналитиков через свое сообщество Surfalytics.com (на английском), до этого несколько лет развивал проект Datalearn.ru, на котором делился фундаментальными знаниями и помогал бесплатно всем желающим войти в ИТ, знания там все еще актуальны.

Дмитрий написал несколько книг по аналитике и преподает несколько лет Облачные Вычисления (Cloud Computing) в партнерстве с Microsoft в Университете Виктории.

Еще из интересных проектов:
- Создал онлайн выставку писем CEO про увольнения в крупных компаниях - https://www.layoffmemos.com/
- Совместно с Московским Зоопарком и Вконтакте организовал группу по наблюдению за популяцией пеликанов и экомониторинга с использованием AI - https://www.scifly.ai/

Из последнего, Дмитрий создает главный Российский портал Дата Инженеръ посвященный карьере дата инженера, куда он планирует добавить road map для вакансий Инженера Данных, Аналитика и BI разработчика и ссылки на лучшие бесплатные ресурсы: книги, тренинги, курсы, видео, телеграмм каналы, и многое друго, что поможет понять, кто такой иженер данных и как таким стать, преимущественно на русском языке.

#Database #Architecure #Software #Data #SystemDesign #Management
3,083
Книжный куб

19 Nov, 05:08

Insights on How Team Topologies Drive Organizational Success - Manuel Pais - GOTO 2024 - Part II (Рубрика #Management)

Этим постом я заканчивую рассказ про выступление Manuel Pais, со-автора книги "Team Topologies". В прошлом посте я начинал обзор этого рассказа про инсайт из практического применения топологии команд.

7. Автор затрагивает неконсистентный опыт пользователей. В качестве кейса приводится история BBC (ее тоже не на сайте). Здесь суть была в том, что у BBC было много продуктов, каждый из которых имел свой особенный интерфейс и это не очень нравилось пользователям:) В итоге, BBC просто выделили стандартные фронтовые компоненты, но и сделали большой реорг, что они описывали у себя на Medium. В итоге, автор выделяет следующие
- Принцип: optimize for innovation & speed when those are needed, allow "eventual consistency" and standartization to emerge later
- Practice: Collaborate, facilitate, x-as-a-service. Платформенным командам важно правильно выбирать тип взаимодействия
8. Автор переходит к медленному time-to-market. Рассматривается пример SAP, у которого сложности со скоростью из-за соблюдения требований законодательства и обеспечения безопасности (и наверное не только из-за этого). В итоге, ребята занялись внутренней платформой для упрощения работы команд разработчиков. Платформа рассматривалась как продукт, ориентированный на группы команд, страдающих от сложных процессов соответствия требованиям и безопасности.
- Принцип: turn blocking dependencies into unblocking ("dependency inversion" for teams)
- Practice: Product management in platform. Подробнее про это можно прочитать в моем разборе CNCF Platform White Paper: 1, 2 и 3
9. Автор переходит к работе с тезисом "we can't do that in my organization". Это кейс GfK/NIQ. У ребят аля SAFE и все команды заняты продуктовой разработкой. Они придумали, что каждый пятый спринт будут работать над платформенными задачами
- Принцип: "behaviors over structures". don't wait for the ideal org / process / scale
- Practice: Thinnest viable platform. Можно начать с максимально тонкой платформы, что уже приносит пользу организации
10. Топология команд рассматривается как социально-технический подход для увеличения потока и повышения удовлетворенности. Организации могут применять идеи топологии команд в разных сферах бизнеса, адаптируя их под свои нужды. Важно иметь видение и понимать принципы топологии команд. Примеры выше показывают, как можно адаптировать идеи и принципы для текущей ситуации. Сообщество вокруг топологии команд активно и заинтересовано, и есть множество ресурсов для изучения и применения этих идей.

#Management #Leadership #PlatformEngineering #Software #SoftwareDevelopment #Architecture #Processes
1,509
Книжный куб

18 Nov, 12:15

Insights on How Team Topologies Drive Organizational Success - Manuel Pais - GOTO 2024 - Part I (Рубрика #Management)

Интересное выступление Manuel Pais, со-автора книги "Team Topologies", в котором он делится инсайтами из практического применения топологии команд. Для меня это видео супер-интересно, так как я давно сделал краткий обзор этой книги в трех частях
- Teams as means of Delivery
- Team Topologies that work for flow
- Evolving team interactions for innovation and rapid delivery
А потом еще записал и первый эпизод подкаста "Code of Leadership" вместе со Станиславом Халупом.

Это же выступление Manuel Pais содержит следующие интересные моменты
1. Ни один подход не решает все проблемы сразу, это относится и к топологии команд
2. Комикс Comic Agile забавно рассказывает про Team Topologies, но не слишком правильно (по мнению автора):)
3. Team topologies - это социо-технический подход для улучшения flow и hapiness. Быстрый flow требует большей автономии и четкой цели.
4. Крупные организации задаются вопросами: как расти устойчиво, как становится высоко-производительными, как вовлекать сотрудников
5. Автор разбирает проблему медленного delivery из-за высокой связности команд. В качестве case study приводится пример JP Morgan, где автор решали это через business aligned value streams. Для этого пришлось разобраться с природой зависимостей, сделать команды кросс-функциональными и улучшить коммуникации между ними. На выходе у ребят получилось уменьшить на 60% зависимости между командами. Вообще, публичные case studies доступны на сайте teamtopologies.com, но кейса JP Morgan в публичном доступе нет. Отсюда автор выводит
- Принцип: decouple teams by decoupling their streams/products ("decoupling responsibilities")
- Practice: Independent service heuristics (ISH). Суть в том, чтобы выделить independently-viable services. Начать можно с вопроса, а может ли такой кандидат в стримы работать как отдельный SaaS продукт в облаке
6. Автор переходит к отсутствию бизнес гибкости из-за организационных трений (org frictions). Здесь в качестве кейса приводится история Telenet (его тоже не на сайте). В этом кейсе для любой фичи требовалось участие огромного количества команд. Это замедляло любые изменения до предела. На выходе автор опять приводит
- Принцип: "minimize structural complexity" through grouping closely related streams of value
- Practice: Team (Tribe) interaction modeling. Надо идентифицировать и совместно стратегировать относительно командной структуры, которая сможет эволюционировать в дальнейшем

Продолжение обзора в следующем посте.

#Management #Leadership #PlatformEngineering #Software #SoftwareDevelopment #Architecture #Processes
1,693
Книжный куб

18 Nov, 08:22

Подъехали фотки с моего выступления на выходных га конференции D-Day, где я выступал из онлайна. Мне понравилась организация этого мероприятия, мне было приятно выступить перед таким количеством заинтересованных людей.
1,831
Книжный куб

18 Nov, 05:08

ЦЕХ 4 - Урок #22 "Взаимодействие с обозревателями, критиками и СМИ. Эксперт — Екатерина Северина" (Рубрика #Writing)

Очередной урок из курса книгописания и книгоиздания от МИФ вела PR-менеджер, драматург и книжный обозреватель. Из этого урока я вынес следующие моменты

1) Успеху книги может способствовать личный бренд, который можно повышать за счет работы со СМИ. Это помогает и в плане SEO (по вашему имени находится релевантная информация в поисковиках)
2) СМИ тоже выгодно работать с авторами - это помогает им закрыть контентный голод и получить эксклюзивный материал, а также сэкономить силы штатных журналистов
3) Важно понимать какие СМИ интересны вашей аудитории и взаимодействовать с ними. Тут пригодится анализ публикаций СМИ и их целевой аудитории (часто у СМИ есть медиакиты для рекломадателей, где эти вещи базово описаны)
4) Для анализа СМИ можно почитать и их соцсети и комментарии читателей в них
5) СМИ выстроены в пирамиду: массовые СМИ ориентированы на новичков и не погружаются в глубокие темы, тематические СМИ, такие как "Мир фантастики", предлагают материалы для профессионалов, профи и эксперты в тематических СМИ готовы платить за качественный продукт и не совершают поверхностных суждений.
6) Профи и эксперты в тематических СМИ интересуются не только книгами, но и функционированием индустрии.
7) Также можно сотрудничать с книжными обозревателями и блоггерами - это помогает запустить сарафанное радио и литературный нетворкинг.
8) В общем, для того, чтобы эффективно работать со всеми этими людьми нужна база контактов, которая должна быть рабочей, приносить результат, динамичной и актуальной.
9) Основные элементы записи в базе контактов: фамилия, имя, СМИ, адрес, электронная почта, tg-канал.
10) Важно анализировать эффективность коммуникаций через свою базу и адаптировать подходы в зависимости от результатов (в уроке приводилось куча примеров как писать правильные письма и сообщения)
11) Вообще, есть целая пачка книжных материалов, что автор может предложить СМИ/обозревателям/блоггерам
- Обзор: краткое описание новых книг для привлечения читателей.
- Рецензия: критический анализ и оценка произведений.
- Препринт: отрывок из книги до её выхода.
- Тематическая подборка: рекомендации книг по темам.
- Интервью: редко встречаются, требуют весомого литературного капитала.
- Новости: большие материалы о значимых событиях, таких как смерть автора.

Предыдущие посты про этот курс писательского мастерства доступны здесь
1. Увидеть свое имя на обложке может каждый
2. Целевая аудитория и ее потребности в создании книги
3. Жанры и стили. Как найти тему для нон-фикшн-книги
4. Как организовать работу
5. Как преодолеть писательские блоки. Практическое занятие
6. Жду музу, а она все не приходит
7. Книга по полочкам
8. MS Word для работы с большими и сложными текстами
9. Рассказываем истории: сторителлинг в книге
10. Саморедактура: работа с текстом, сокращения, фактчекинг
11. Правила сильной книги захватывающего текста
12. Авторская стилистика
13. Как превратить рукопись в сценарий
14. Рукопись готова. Что дальше?
15. Превращение рукописи в издание
16. Авторские права и договор с издательством
17. Дизайн книги.
18. Продвижение в самиздате.
19. Продвижение автора
20. Social media marketing (SMM)
21. Ведение блога и его продвижение в Телеграме

#SelfDevelopment #PublicSpeaking #Storytelling #Writing
1,813
Книжный куб

17 Nov, 16:38

Comic Agile - Team Topologies (Рубрика #Humor)

В эти выходные я смотрел лекцию Manuel Pais, со-автора книги "Team Topologies", на конференции GoTo. В самом начале своего выступления он ссылается на этот комикс "Comic Agile". На этом ресурсе много забавных комиксов, включая тот, что про Team Topologies. В общем, рекомендую, если вам тоже нравится с юмором подходить к менеджменту:)

#Humor #Management #Leadership #Processes #Software
2,093
Книжный куб

17 Nov, 09:01

Зачем измерять developer productivity в крупной компании? И как это делать правильно? (Рубрика #Management)

Сегодня я выступаю онлайн на конференции D-Day, что оффлайн проводится в Тирасполе. Я уже выступал на этой конференции 5 лет назад, но тогда это было очно:) В этот раз я решил рассказать про тему developer productivity, начать с того, а зачем ее мерить и дальше рассказать как, а напоследок поделиться тем, как это принято делать у нас в компании. По традиции в день доклада я публикую список материалов по теме, которые позволят изучить тему сильно глубже, чем я успею рассказать за 25 минут

1) Мое выступление "Как и зачем измерять инженерную продуктивность в крупной компании" на MTS конференции
2) Обзор книги канонической книги "Accelerate" в трех частях:
-- Общая информация по книге, формат исследования и DORA метрики
-- Технические практики, архитектуру и интеграцию вопросов безопасности в процессы разработки
-- Менеджерские и лидерские практики
3) Выпуск подкаста "Code of Leadership" про "Accelerate" с Игорем Курочкиным
4) Разбор темы developer productivity в фреймворках SPACE, DevEx
5) Разбор начальной статьи ребят из Google "A Human-Centered Approach to Developer Productivity" и рассказ про целую колонку в IEEE журнале от этих авторов
6) Разбор статьи "Measuring Developer Goals" от ребят из Google (продолжение серии про Human-Centered Approach)
7) Разбор статьи "Developer productivity for Humans, Part 7: Software Quality" от ребят из Google (продолжение серии про Human-Centered Approach)
8) Разбор выступления моего коллеги Вовы Калугина "Почему DevEx важен при разработке IDP и как его померить", где он рассказывает про нашу платформу Spirit и как мы подходим к вопросам developer experience и developer productivity

#Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes
2,238
Книжный куб

16 Nov, 07:27

Обложки книг Джона Маэды "Законы простоты" и "The Laws of Simplicity"
2,092
Книжный куб

16 Nov, 07:24

Законы простоты (The Laws of Simplicity) (Рубрика #Design)

На днях я прочитал книгу Джона Маэды о законах простоты. Сам Джон является выдающимся американским дизайнером, ученым и педагогом, который известный своими работами на стыке бизнеса, дизайна и технологий. Сейчас он работает вице-президентом по дизайну и искусственному интеллекту в Microsoft. Интересно, что это уже вторая книга этого автора, которая мне понравилась, первой была "ReDesisning Leadership" ("Редизайн лидерства"), о которой я уже писал в канале. Если же возвращаться к самой книге о законах простоты, то интересно, что он написал ее почти 20 лет назад, еще до выхода айфонов на рынок. Тогда она стала бестселлером, но дизайнеры с тех пор двигаются скорее в сторону сложности:)

Джон предложил использовать следующий список законов для нахождения баланса между сложностью и простотой в различных аспектах жизни и работы, делая системы более интуитивными и эффективными
1. Сокращение (Reduce) — Самый простой способ достичь простоты — это осознанное сокращение. Убирайте лишнее, но будьте осторожны, чтобы не убрать что-то важное.
2. Организация (Organize) — Организация помогает сделать систему с множеством элементов более понятной и управляемой. Правильная структура делает сложное проще.
3. Время (Time) — Экономия времени создает ощущение простоты. Чем меньше времени требуется на выполнение задачи, тем проще она воспринимается.
4. Обучение (Learn) — Знания упрощают все. Чем больше вы знаете о системе или процессе, тем легче с ними работать.
5. Различия (Differences) — Простота и сложность взаимосвязаны. Чтобы оценить простоту, необходимо иметь возможность сравнивать ее с чем-то более сложным.
6. Контекст (Context) — То, что находится на периферии простоты, не является незначительным. Контекст важен для понимания и восприятия системы.
7. Эмоции (Emotion) — Больше эмоций лучше, чем меньше. Эмоциональная связь с продуктом или системой делает их более привлекательными и понятными.
8. Доверие (Trust) — Простота требует доверия. Пользователи должны доверять системе, чтобы она казалась простой в использовании.
9. Неудача (Failure) — Некоторые вещи невозможно упростить. Не все попытки создать простоту будут успешными, но важно учиться на ошибках.
10. Единое (The One) — Простота заключается в вычитании очевидного и добавлении значимого. Это объединяющий принцип всех предыдущих законов.

В общем, у меня после прочтения не сложилось ощущение, что это прямо законы. Я скорее бы назвал это интересными аспектами, с точки зрения которых надо смотреть на систему, чтобы сбалансировать в ней сложность и возможности так, чтобы для пользователей она выглядела простой:)

#Design #Leadership #Management #SelfDevelopment #Processes
2,090
Книжный куб

15 Nov, 11:14

Менторинг сессия на канале SouthHub (Рубрика #Management)

Во вторник вечером я проводил менторинг сессию, запись которой доступна на Youtube. Моим менти был Антон Числов, технический директор МТС Авто. Запрос был на меторинг по теме как осуществлять крупные изменения в больших компаниях. Суть в том, что у ребят на носу 2 больших изменения
1) Переход от разработки по компонентам к stream-aligned командам
2) Переезд из MTS Digital в отдельную компанию внутри экосистемы

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

#Management #Leadership #Processes #Software
2,218
Книжный куб

15 Nov, 05:08

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

#SelfDevelopment
2,169
Книжный куб

15 Nov, 05:08

#psy
Мы с группой коллег проводим исследование, посвященное
формированию и развитию новой профессиональной идентичности.
Для практической части мы выбрали профессии, связанные с управлением продуктом.
Если вы недавно перешли в такую профессию, находитесь в процессе перехода или планируете его, приглашаю принять участие в нашей психаналитической группе "Как занять свое место в профессии".

Примеры вопросов, которые могут возникать:
- Вокруг все говорят, что ты product manager, а сам ты про себя так не говоришь/не можешь сказать кто ты;
- Хочешь стать product manager, но не дают\не получается (по разным причинам);
- Уже работаешь в управлении продуктом, но не можешь понять, кто ты такой в своей текущей роли на работе

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

Состав группы - 12-15 человек
Длительность встречи - 2 часа
Встречи будут онлайн по субботам, 6 встреч, 1 раз в неделю.

Перед стартом группы будет проведена индивидуальная встреча с одним из консультантов (1 час) для знакомства с методом и друг с другом.

Вся информация строго конфиденциальна и будет обезличена в рамках исследования.

Если вам интересно, пишите в лс
2,284
Книжный куб

14 Nov, 16:19

0b1000 в Т-Банке

Сегодня у меня юбилей в Т-Банке, 8 лет:) Именно столько лет назад я пришел в тогда еще Тинькофф. Я пришел из Банки.ру, где был лидом команды разработки, что отвечала за рейтинги банков, страховых и остальной UGC (user generated content), а также лидогенерящие странички:) В Тинькофф я вышел на позицию engineering manager заниматься проектами привлечения. Планы на старте были наполеоновскими и они действительно драйвили меня. Это был период роста и моя зона ответственности постоянно менялась. Я чувствовал себя не просто engineering менеджером, а скорее менеджером непрерывных изменений с девизом "пересобери себя и свою команду или умри"... Но как только я справлялся с новым вызовом, то получал следующий. Это происходило примерно каждые полтора-два года. Про многие из этих изменений я рассказывал на YaTalks в прошлом году и в расшифровке этого выступления. С тех пор я собрал у себя dream team из руководителей, которые отвечают за отдельные большие подразделения в 200-300 человек
- Клиентские интерфейсы: платформенные команды веба, мобилы и API
- Маркетинговые технологии: внешняя реклама, маркетинговая платформа
- Соц-медиа платформы: социальные сети, медиаплатформа, медиапроекты (ТЖ, Бизнес-секреты), игры
- Цифровые экосистемы: аутентификация/авторизация, биометрия, главная страница приложения, финздоровье

А еще у меня в подразделении есть важный для меня продукт в виде продуктовой аналитика и a/b платформы. Это важно для компании для того, чтобы быть data-driven, а для меня - это возможность закрыть гештальт относительно математики (теорвер, матстатистика), которая мне нравилась всю дорогу от лицея до физтеха и дальше:) Также я отвечаю за архитектуру как функцию в компании. Это мне близко как технарю, для которого важна engineering excellence и design крутых систем.

Напоследок, я хотел сказать спасибо ребятам из моего юнита "Клиентские интерфейсы, маркетинг и вовлечение". Ребята и делают всю работу, которая приносит радость нашим клиентам, деньги компании, а мне позволяет рассказывать об этом. Кстати, с частью ребят я записывал интервью
- Про архитектуру с моим замом, Антоном Костериным. Антон руководит архитектурной группой при мне
- Про про системных аналитиков с Кириллом Крайневым. Кирилл руководит маркетинговыми технологиями, а также драйвит развитие профессии системных аналитиков
- Про Staff+ инженеров, архитектуру и SDLC с Алексеем Тарасовым. Алексей руководит соц-медиа платформой, а также драйвит наши system design interview и помогает развивать направление staff+ для инженеров
- Про систему для продуктовой аналитики (Statist) с Андреем Цыбиным. Андрей руководит продуктовой аналитикой и a/b платформой.

Думаю, что мы не будем останавливаться на этом и будем делать все более крутой продукт, а также рассказывать о том, как мы это делаем:)

P.S.
В общем, 8 лет - это большой срок, который можно и отметить. Особенно с учетом того, что я не уверен в том, что "доживу" до следующего круглого юбилея в двоичной системе:)

#Management #SelfDevelopment #Engineering #Processes #Software
2,401
Книжный куб

14 Nov, 07:01

Бегущий по лезвию 2049. Вселенная фильма (Blade Runner 2049) (Рубрика #SciFi)

В конце прошлой сложной недели я взял полистать этот артбук перед сном:) Отчасти решение выбрать именно эту книгу было принято из-за получения в этот день двухтомника Сергея Маркова "Охота на электроовец", который посвящен искусственному интеллекту. Это название отсылает к книге "Мечтают ли андроиды об электроовцах" ("Do Androids Dream of Electric Sheep?") Филиппа Киндреда Дика (кстати, про него я уже рассказывал при обзоре его биографии в комиксах). Именно эта книга про мечты андроидов послужила Ридли Скотту основой для его классического фильма "Бегущий по лезвию", что вышел больше 40 лет назад. А меньше 10 лет назад появилось продолжение от Дэни Вильнева "Бегущий по лезвию 2049". В итоге, в этой книге рассказывается про создание фильма и приводится куча иллюстраций того, как выглядели локации фильма на этапе задумки и как они модифицировались дальше до того состояния, что мы видим в самом фильме.

P.S.
У меня есть книга про Ридли Скотта "Ридли Скотт. Гений визуальных миров. От Чужого до Марсианина", в которой значительное место уделено "Бегущему по лезвию". Но ее я прочитаю в следующий раз:)

#SciFi
2,081
Книжный куб

13 Nov, 16:02

T=Математика (#PopularScience)

1 декабря будет день математики и мои коллеги из Т-Образования устраивают большой праздник с кучей активностей: лекции, математические игры, интенсив по финграмотности и многое другое
- 11 — 24 ноября - Интенсив по олимпиадным задачам (онлайн) - подготовка к муниципальному этапу ВсОШ (разборы от опытных преподавателей, тренировки в решении задач
- 16 ноября - Интенсив по финграмотности (оффлайн и онлайн) - мероприятие пройдет в T-Space (Москва, м. Белорусская), в программе будет несколько докладов
- 28-30 ноября - Турнир по математическим играм (онлайн) - на турнире будут командные игры: «Математический квадрат», «Математическая карусель» и «Семь чудес». Победители получат памятные призы от Т-Образования
- 1 декабря в T-Space в Москве - День математика (оффлайн) - мероприятие пройдет в T-Space (Москва, м. Белорусская), в программе будут лекции, нетворкинг и фуршет.

#PopularScience #Math
1,931
Книжный куб

13 Nov, 10:13

Интересная информация от канала "эйай ньюз", за которым я слежу, чтобы не отставать от новостей AI.
Здесь интересна информация о том, а как крупные компании используют AI в своих процессах и оказалось, что все просто
1) Customer support/service - тут всеми "любимые" чатботы и не только
2) Marketing/content generation - генерация маркетингового контента, рекомендаций продуктов (eBay)
3) Document processing / infromation retrieval - обработка документов, суммаризация встреч, поиск по данным
4) Development/code generation - генерация кода (Gitlab, Autodesk), теста (Notion), ...
5) Employee/internal tools - внутренние инструменты для сотрудников

В принципе, список неполный, но достаточно полезный. У нас, например, по всем из этих направлений тоже ведется работа.
1,736
Книжный куб

13 Nov, 05:08

Research Insights Made Simple #4 - Обсуждение "AI-Enhanced API Design"

В этом эпизоде мы обсуждаем интересный whitepaper "AI-Enhanced API Design" от ребят из Google, где рассказывалось о том, как подходы к управлению API влияют на продуктивность и usability. Исследователи показали, что общие стандарты вместе с инструментами, которые помогают им следовать, приводят к статистически значимым улучшениям в качестве дизайна API.

В разборе мне помогает крутой гость - Павел Каравашкин, мой коллега. Павел является руководителем разработки платформы T-API, а также лидером профессии системного анализа в Т-Бизнес, соведущим подкаста SA Т-Банка InSAйт. Паша любит велоспорт, Warhammer 40k и читать случайные статьи на Википедии.

Кстати, эпизод доступен и в подкасте Яндекс Музыки.

Материалы:
- AI-Enhanced API Design: A New Paradigm in Usability and Efficiency
- Мой обзор этой научной статьи
- Публичное T-API для партнеров
- Подкаст InSAйт

Мы обсудили следующие моменты
- Обзор статьи и личные впечатления Павла
- Обсуждение структуры статьи
- Проблемы и аспекты проектирования API
- Процесс разработки API в Google
- Гибкость и стандартизация в разработке API
- Методология исследований в Google
- Подходы к исследованием вокруг API в T-банке
- Проблемы и решения в персонализации
- Использование линтеров и метрик
- Анализ логов и задач разработчиков
- Исследования и метрики в Google
- Генерация контрактов
- Проблемы с архитекторами
- Методология эксперимента в Google и его результаты
- Ограничения эксперимента
- В общем про процесс разработки и помощь автоматизированных средств
- Важность этапа реализации
- Архитектура и улучшение процессов
- Измерение эффективности инструментария (отсылка к статье "Measuring developer goals" от ребят из Google)
- Роли в разработке
- Автоматизация кибербезопасности (отсылка к предыдущему подкасту)Заключение и планы на будущее

#Architecture #Software #DistributedSystems #SystemDesign #SystemEngineering #API #Governance
1,705
Книжный куб

12 Nov, 14:17

What Is This OpenTelemetry Thing? • Martin Thwaites • GOTO 2024 (Рубрика #Architecture)

Интересное выступление на goto конференции от Martin Thwaites, Principal Developer Advocate из Honeycomb. Основная суть выступления примерно такая
1) Автор начинает с истоков наблюдаемости, когда люди ориентировались еще на мигающие лампочки на самих устройствах:)
2) В 2000х годах использовались метрики для мониторинга производственных систем, так как места было мало и производительность систем была не слишком большой. Тут важно было правильно предагрегировать данные, изначально понимая какая информация будет нужна, так как метрики расчитывались заранее, а оригинальные события не хранились. Где-то в 2010х годах для хранения метрик стали использовать time-series базы данных
3) Дальше стали популярны логи, для которых зачастую использовался ELK стек (Elastic, Logstach, Kibana). Это позволило уйти от предварительной агрегации данных и улучшить наблюдаемость. По-факту, в Kibana можно было пост-фактум строить красивые дашборды, агрегируя данные так, как необходимо
4) Где-то с середины 2010х годов системы стали сложнее и распределеннее и дальше появились инструменты для распределенной трассировки и стандарты OpenTracing и OpenCensus
5) В какой-то момент они объединились и превратились в OpenTelemetry - это проект CNCF в статусе incubating, что наряду с graduated считается стабильным и пригодным для использования в проде
6) OpenTelemetry хорош тем, что он пришел на смену двум предыдущим стандартам, что со временем стали deprecated и позволил отвязать инструментализацию телеметрии от бекендов, в которые она отправляется. У этого стандарта есть протокол и SDK для всех популярных языков программирования
7) У OpenTelemetry есть и проблемы - он развивается через комитеты, что замедляет процесс доработок и расширений стандарта
😍 В OpenTelemetry есть логи, метрики, трейсы. Трейсы - это способ для описания взаимодействия сервисов с учетом причинно-следственных связей (это делается через связи между спанами). Вообще, трейсы позволяют очень удобно разбираться с поведением сложной распределенной системы.
9) Логи предназначены для людей и имеют шаблон сообщения, они полезны для локальной отладки и проверки работы трассировок
10) Метрики - это агрегированные временные ряды данных. Они используются для измерения и анализа производительности. Дешевы в хранении и быстры в обработке, но ограничены в контексте и размерности.
11) OpenTelemetry позволяет думать о соединениях между системами. Распространение данных включает корреляцию и передачу информации о состоянии. Спецификация контекста трассировки W3C определяет заголовки и данные для передачи.
12) Автор подробно говорит про W3C Baggage, propagation format for distributed context. Он как раз позволяет передавать дополнительный контекст между службами, но есть там и проблемки, например, передача данных через сторонние API может привести к утечке конфиденциальной информации.
13) Круто, когда инструментализация OpenTelemetry встроена в шаблоны ваших приложений - это помогает командам SRE получать стандартизированные observability данные
14) У OpenTelemetry есть collector, который используется для проксирования и обработки данных телеметрии. Он позволяет централизовать конфигурацию и отправку данных нескольким поставщикам, а также обеспечить центральную точку для инфобезов или обогощения данных
15) В OpenTelemetry можно настраивать семплинг для уменьшения затрат на наблюдаемость
16) Прикольно семплировать не с головы, а с хвоста, когда мы знаем что попало в трейсинг. Хвостовой сэмплер может сообщать о медленных процессах и ошибках, но компромисс здесь в том, что задержка отправки данных и большие затраты памяти.
17) У OpenTelemetry есть и проблемки - отправка данных через перекрестные зоны доступности может быть дорогой. Решения по отправке данных требуют компромиссов. OpenTelemetry требует постоянного внимания и настройки.
18) В будещем в OpenTelemetry ожидается больше семантических соглашений и библиотек

#SRE #Architecture #DistributedSystems #Software
2,065
Книжный куб

12 Nov, 05:08

Ководство (Рубрика #Design)

Недавно я прочитал седьмое издание книги Артемия Лебедева, которое доступно на его сайте онлайн под названием ".ру/Ководство". Если кратко, то кажется в далеком детстве Рунета Артемий Лебедев был достаточно интересен как в плане дизайна, так и текстов. Условно, если бы я читал его мысли в начале двухтысячных, когда только начинал свой путь в софтостроении, то это было бы полезно. Сейчас же эти статьи читаются скорее как байки о старых временах от интересного человека из той эпохи ... они пахнут нафталином как в детстве, когда шубу или пальто доставали из шкафа с зимней одеждой. В общем, почитать книгу можно ради воспоминаний ... и интересных мыслей про типографику. Кстати, книгу покупать не обязательно - их можно почитать и на сайте автора.

P.S.
Мне книга скорее понравилась, но допускаю, что это из-за того, что я помню как все начиналось ... в рунете:)

#Design #Visualization
2,009
Книжный куб

11 Nov, 10:13

Архитектурные материалы для изучения от облачных провайдеров (Рубрика #Architecture)

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

1) У AWS это называется AWS Well-Architected Framework, у него 6 ключевых столпов
- Operational excellence (операционная эффективность): Фокус на управлении и мониторинге систем для обеспечения бизнес-ценности и постоянного улучшения процессов.
- Security (безопасность): Защита информации и систем с помощью надежного управления идентификацией, защиты данных и обнаружения инцидентов.
- Reliability (надежность): Обеспечение того, что рабочие нагрузки выполняются в соответствии с ожиданиями и быстро восстанавливаются после сбоев.
- Performance efficiency (эффективность): Оптимальное использование ресурсов для удовлетворения требований системы.
- Cost optimization (оптимизация затрат): Помощь в отсутствии ненужных расходов при сохранении производительности.
- Sustainability (устойчивость): Фокус на минимизации воздействия на окружающую среду за счет оптимизации энергопотребления.

2) У Microsoft это называется Azure Well-Architected Framework. Он имеет схожие цели и структуру с AWS фреймворком, в нем даже то же самое название, но столпов всего 5 (выпала часть про sustainability)
- Cost optimization (оптимизация затрат): Максимизация ценности при минимизации расходов.
- Operational excellence (операционная эффективность): Эффективное управление операциями и автоматизация процессов.
- Performance efficiency (эффективность): Обеспечение производительности и масштабируемости приложений.
- Reliability (надежность): Построение отказоустойчивых архитектур, способных восстанавливаться после сбоев.
- Security (безопасность): Защита данных и систем через надежные методы безопасности.

3) У Google это называется Cloud Architecture Framework. Он имеет немного другую структуру, но также фокусируется на ключевых принципах построения облачных решений. У него пять столпов:
- Operational excellence (операционная эффективность): Эффективное развертывание, эксплуатация, мониторинг и управление рабочими нагрузками.
- Security, privacy, and compliance (Безопасность, конфиденциальность и соответствие требованиям): Обеспечение безопасности данных, их конфиденциальности и соблюдения нормативных требований.
- Reliability (надежность): Построение отказоустойчивых систем, способных выдерживать сбои.
- Cost optimization (оптимизация затрат): Максимизация бизнес-ценности за счет оптимизации использования ресурсов.
- Performance optimization (оптимизация производительности): Настройка ресурсов для достижения оптимальной производительности.

Из этого краткого описания фреймворков видно, что у них похожие фокусы на оптимизацию затрат, безопасность, оптимизацию производительности, надежность. В общем, на вопросы, которые важны для клиентов, что планируют заезжать в облака (но важны также и при разворачивании on-prem). Эти фреймворки направлены на то, чтобы помочь организациям постоянно оценивать и улучшать свои облачные архитектуры на основе лучших практик, предоставляемых соответствующими облачными провайдерами. Хотя конкретные детали реализации могут различаться между провайдерами, основные принципы остаются схожими на всех платформах.

Кстати, часть научных статей ребят превращаются в мануалы внутри этих фреймворков. Например, раздел "Deployment archetypes" из документации Google изложен в научной статье "Deployment Archetypes for Cloud Applications", которую я разбирал больше года назад в своем блоге.

#DistributedSystems #ExternalReview #SoftwareDevelopment #SoftwareArchitecture #Architecture #SystemDesign #SystemEngineering #Cloud
2,165
Книжный куб

11 Nov, 05:08

Корпоративный мессенджер Time

Около полугода назад я уже рассказывал про наш корпоративный мессенджер Time, на который мы оперативно переехали, когда Slack отказался работать с русскими компаниями. За эти пару лет само решение прошло испытание огнем, водой и медными трубами и показало то, что этот мессенджер можно использовать для общения в компании с десятками тысяч сотрудников. Также поверх него можно строить бизнес-процессы и автоматизации (аля chat-ops). Какое-то время назад мы начали продавать это решение разным заказчикам сначала в on-prem варианте, а за последние полгода добавился SaaS вариант, а также mvp для видео-конференц связи. С учетом такого большого количества изменений коллеги решили провести вебинар с продактом и парой клиентов (Атом и Юрент), чтобы рассказать про плюсы и минусы продукта, а также поделится опытом переезда в Time и тем, как они выбирали из доступных на рынке решений.

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

P.S.
Кстати, сайт сильно обновился и стал содержать больше полезной информации навроде базового описания стека решений и интеграций
- Time - это cloud-native решение, которое у нас развернуто в наших целевых runtime окружениях (kubernetes кластерах)
- TIme можно развернуть в геораспределенном режиме (у нас, например, он развернут на 2 геораспределенных дата центра)
- Под капотом используются стандартные стек: Postgres, Kafka, Redis, Open search / Elastic search
- Есть разные виды авторизаций (SAML, AD/LDAP, openID)
- Есть возможность мигрировать с других мессенджеров (Slack, MM, RocketChat)

А также есть чиселки для технарей про один из наших инстансов Time
- 45 тысяч пользователей на инстансе в день
- 2 миллиона cообщений в день
- 80 тыс пользователей
- 5,4 миллиона диалогов создали пользователи
- 186 тысяч каналов создано этими пользователями
- более 1200 ботов создано пользователями благодаря удобной документации
- 99,9% - SLA на доступность

#Software
2,264
Книжный куб

10 Nov, 11:28

Экскурсия по стадиону ЦСКА

Были сегодня на часовой экскурсии по стадиону и она нам понравилась:
- На экскурсию пришло человек 30-40, половина из них детей
- Экскурсовод был с хорошим чувством юмора и не просто рассказывал истории, но и делился анекдотами и байками
- Мы прошли через вход, куда заходят футболисты, дошли до раздевалки, прошли к выходу на поле и походили около скамеек команд, сделав ряд снимков, а дальше прошли в комнату для пресс-конференций каа обычно и бывает после окончания матчей

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

#Family #ForKids
2,219
Книжный куб

10 Nov, 05:08

ЦЕХ 4 - Урок #21 "Ведение блога и его продвижение в Телеграме. Эксперт — Олеся Полянская" (Рубрика #Writing)

Очередной урок из курса книгописания и книгоиздания от МИФ вела Олеся Полянская, руководитель команды по социальным сетям в МИФ, которая поделилась опытом и знаниями в области ведения блога в telegram. Интересно было послушать этот урок и сравнить со своим опытом:) Мне запомнились следующие тезисы из этой лекции:

1) Telegram по разному используют люди разных возрастов - молодые люди больше общаются, а люди постарше читают каналы
2) После бана части других соцсетей пользователей в tg в последнее стало больше
3) Часть каналов в tg фокусируются на новостях, а другие говорят про "вечные темы"
4) Часто важна не сама информация, а ее интерпретация автором канала, у которого есть свой голос и мнение
5) В tg не очень много алгоритмов, которые рекомендуют контент - это отличает tg от других соцсетей. Поэтому авторам важно сарафанное радио и/или стратегия промотирования через рекламу
6) Важно понимать зачем создаешь канал, какая у него будет аудитория и сколько времени получится на него уделять
7) Логотип канала очень важен, также важны контакты автора, а также способ форматирования текста для его удоства
😍 Теперь есть истории и видео-кружочки, их надо использовать с умом, учитывая ожидания аудитории. В tg также можно вести прямые эфиры
9) Важно писать о том, что интересно автору, а также писать регулярно, чтобы поддерживать доверие и интерес аудитории
10) Каналы в tg можно монетизировать через рекламу в них, но скорее всего и самому придется потратиться на рекламу канала
11) Зарабатывать можно не только на рекламе, но и на консультациях, продаже своих книг и всему остальному - популярный канал поможет этому

Предыдущие посты про этот курс писательского мастерства доступны здесь
1. Увидеть свое имя на обложке может каждый
2. Целевая аудитория и ее потребности в создании книги
3. Жанры и стили. Как найти тему для нон-фикшн-книги
4. Как организовать работу
5. Как преодолеть писательские блоки. Практическое занятие
6. Жду музу, а она все не приходит
7. Книга по полочкам
8. MS Word для работы с большими и сложными текстами
9. Рассказываем истории: сторителлинг в книге
10. Саморедактура: работа с текстом, сокращения, фактчекинг
11. Правила сильной книги захватывающего текста
12. Авторская стилистика
13. Как превратить рукопись в сценарий
14. Рукопись готова. Что дальше?
15. Превращение рукописи в издание
16. Авторские права и договор с издательством
17. Дизайн книги.
18. Продвижение в самиздате.
19. Продвижение автора
20. Social media marketing (SMM)

#SelfDevelopment #PublicSpeaking #Storytelling #Writing
1,961
Книжный куб

09 Nov, 05:08

DuckDB: Crunching Data Anywhere, From Laptops to Servers • Gabor Szarnyas • GOTO 2024 (Рубрика #Architecture)

Интересный доклад про аналитическую реляционную базу данных DuckDB, которую можно запускать на своем ноутбуке и успешно обрабатывать объемы где-то до 1 Tb сильно эффективнее, чем на кластере Apache Spark. DuckDB имеет полную поддержку SQL и может читать/писать такие форматы, как CSV, Parquet и JSON. Он построен в соответствии с современной архитектурой, которая позволяет выполнять сложные запросы параллельно и выгружать на диск рабочие нагрузки, превышающие объем памяти.

В этом докладе Габор, технический писатель из DuckDb, рассказывает про ключевые составляющие DuckDB и демонстрирует, как DuckDB может обрабатывать сотни ГБ данных на ноутбуке или терабайты данных на одном сервере. Основные моменты следующие

1) Демо работы с CSV файлом на 15 Gb для анализа информации о задержках прибытия поездов - в демке видно, что все работает очень быстро. В продолжении демки Габор показывает, что можно увеличить количество данных в 40 раз и дальше после 15 минут загрузки данных те же самые запросы будут уже занимать десятки секунд, но это все равно быстрее, чем грузить данные в облако и дальше выполнять их там. Потом Габор показывает как DuckDB поддерживает стандартные SQL функции вида rank over, pivot, unpivot
2) Архитектура DuckDB выглядит как single-file database:) Условно, вы взаимодействуете с ней внутри вашего приложения и отдельного сервера как такового нет. Здесь она похожа на SQLite, который похожим образом работает для OLTP нагрузок, а DuckDB предназначен для аналитических нагрузок
3) Дальше автор переходит к обсуждению хранения и обработке данных и вспоминает про строчное и колоночное хранение (row-oriented vs column-oriented)
- Транзакционные системы используют строчное хранение, а системы на основе столбцов — столбцовое.
- Столбцовое хранение позволяет эффективно сжимать данные и удалять ненужные столбцы.
- Выполнение по столбцам удобно для аналитики, но может привести к нехватке памяти.
И дальше он рассказывает про векторизацию и кеш процессора, которая позволяет обрабатывать данные векторами, что экономит память. Векторы выбираются такого размера, чтобы помещаться в кэш процессора. Вообще, векторизация кода усложняет перенос между архитектурами, но современные компиляторы автоматически векторизуют код. И в DuckDB используются zonemaps для оптимизации индексации, а также DuckDB не имеет внешних зависимостей, что делает его портируемым на разные архитектуры.
4) DuckDB поддерживает множество форматов и протоколов, включая CSV, Spark, JSON, Delta и Iceberg. Есть поддержка протоколов HTTPS, AWS S3 и Azure Blob. Существует возможность подключения к транзакционным базам данных и интеграция с Pandas и NumPy.
5) У DuckDB есть интеграция с Pandas и NumPy что позволяет читать данные без создания копий. DuckDB работает параллельно, что ускоряет чтение данных по сравнению с самим Pandas
6) DuckDB в июне выпустил обновление и достиг 19 тысяч звезд на GitHub и 30 тысяч подписчиков в LinkedIn и Twitter. Недавно вышла версия Snow Duck с акцентом на стабильность и обратную совместимость.
7) У DuckDB есть множество расширений, которые основаны на механизме для добавления новых функций, типов данных и операторов. Примеры расширений: HTTPFS, JSON, Parquet
😍 DuckDB можно использовать для сокращения расходов на облачные хранилища данных за счет выполнения части вычислений локально. Автор показал TPC-H эксперимент с обработкой Parquet файлов через DuckDB и Apache Spark. Если файл небольшой, то затраты на координацию в Spark убиывают всю производительность
9) У DuckDB есть ограничения - она не поддерживает параллельные запросы на запись, а также работает на одной ноде
10) DuckDB финансируется за счет прибыли и консультирует крупные компании, фонд DuckDB обладает правами на код, а MotherDuck сооздает облачную версию DuckDB

#Database #Architecure #Software #Data #SystemDesign
2,085
Книжный куб

08 Nov, 05:08

The Engineering Executive's Primer - Part III (Рубрика #Management)

Продолжая первые посты об этой крутой книге (0, 1, 2) с обзором книги, я хотел бы рассказать про следующие главы.

7) Participating in Mergers and Acquisitions
В этой главе автор говорит про участие ИТ топ-менеджеров в merge & acquisitions процессах. Для начала автор разбирает про сложные мотивы для m&a действий - условно цели команды, что ведет сделки, отличаются от целей инженерных команд. В общем, важен общий взгляд на процесс и понимание бизнес-стратегии, чтобы оценить соответствует ли поглощение целям компании и выявить потенциальные риски. Отдельно автор описывает структурированный подход к оценке поглощений с инженерной точки зрения, куда входит создание шаблонов для оценки сложности внедрения, проблем интеграции, масштабируемости, безопасности, соответствия требованиям, затрат и инженерной культуры. Важно также запланировать интеграции между объединяемыми компаниями - важен четкий план интеграции для эффективного управления переходом после поглощения. Это включает решения по интеграции технологий, реструктуризации команд и роли лидерства. А дальше надо управлять этим процессом.

😍 Developing Leadership Styles
Автор предлагает модель из трех подходов к управлению
- Leading with policy - для повторяемых решений, которы надо делать консистентно разными людьми внутри организации
- Leading from consensus - для нечастых решений с контекстом, который распределен между несколькими заинтересованными сторонами.
- Leading with conviction - для решений без четкого предложения, когда вовлеченные лица сильно расходятся во мнениях или когда решение оказывает значительное долгосрочное влияние на вашу организацию
В этой главе автор приводит примеры из своего опыта в разных компаниях (Digg, Uber, Stripe, Calm). А дальше говорит о том, что надо уметь работать над прокачкой тех стилей лидерства, что несвойственны вам. Это позволит вам стать более универсальным руководителем:)

9) Managing Your Priorities and Energy
В этой главе автор рассказывает про свою стратегию к решению задач вида "Компания - Команда - Я". Изначально автор рекомендовал принимать решения, основываясь на иерархии: сначала компания, затем команда, и в последнюю очередь — личные интересы. Этот подход использовался для обеспечения соответствия решений целям компании, а не личным или командным предпочтениям. Однако позже автор осознал, что такая жесткая структура может привести к выгоранию и потере мотивации среди сотрудников. Но дальше автор подчеркивается важность управления энергией как процесса с положительной суммой. Предполагается, что предоставление людям возможности заниматься работой, которая их вдохновляет, даже если она не соответствует непосредственным приоритетам, может повысить общую продуктивность и удовлетворенность работой.

В итоге, концепт "Company, Team, Self" изменяется на подход "Eventual Quid Pro Quo", которая балансирует приоритеты компании с личными потребностями в энергии. Этот подход поощряет приоритизацию вдохновляющей работы при необходимости для поддержания долгосрочной вовлеченности и эффективности. Автор подчеркивает необходимость гибкости в применении стратегий. Утверждается, что хотя следование правильным приоритетам важно, это не должно происходить за счет личной энергии и мотивации. Лидеры должны адаптировать свои подходы в зависимости от личных нужд и контекста их ролей.

Продолжение будет в следующем посте.

#Engineering #Management #Leadership #Processes #SystemDesign #SystemThinking #SystemEngineering
2,076
Книжный куб

07 Nov, 05:08

Кем может стать системный аналитик - подкаст InSAйт (Рубрика #Career)

Недавно сходил в гости к своим коллегам на подкаст InSAйт, который ведут Павел Каравашкин, руководитель группы разработки T-API, и Есения Киселева, старший системный аналитик, управление разработки продуктов эквайринга в Т-Банке. Темой разговора было карьерное развитие системных аналитиков, о котором я когда-то размышлял на конференции Flow. В итоге, мы обсудили темы
- Почему я когда-то не захотел быть системным аналитиком, а Паша – системным архитектором;
- Можно ли одновременно сохранять фокус на менеджерских и технических скиллах;
- Кем может стать системный аналитик и какие навыки ему важно качать;
- Что такое white paper и чем этот формат может быть полезнее книг;
- Как сделать доменные области более понятными для разработчика.

У этого подкаста есть свой канал в tg (@insight_t_bank), подписавшись на который можно узнавать о новых выпусках.

#Analyst #SoftwareDevelopment #Career #Podcast #SystemDesign #SystemThinking
2,310
Книжный куб

06 Nov, 15:00

В выходные у нашего младшего сына Кирилла был день рождения, ему исполнилось 4 года. На день рождения мы придумали активность для него и всех гостей - пойти в детский клуб, где дети побесились 3 часа в сумме, причему последний час был посвящен раскаршиванию помещения и друг друга. Так у меня появилась новая красочная аватарка:)
2,496
Книжный куб

06 Nov, 12:15

Масштабирование комплаенс-контроля надежности на сотни сервисов - Салих Фахрутдинов, Т-Банк

Интересный доклад моего коллеги, Салиха, который Staff SRE инженер в Origination Business Platform. В этом докладе Салих рассказал о том, как можно обеспечивать надежность сотен разных сервисов за счет контроля инвариантов, который реализован через стороннее приложение. В этом приложении настраиваются различные правила для проверок, например, использование разных портов для проб (liveness, readiness, startup), настроек java приложений (падение от OOM), параметров СУБД, наличие алертов на критические SLA и так далее. Дальше эти правила можно пополнять реактивно (после инцидентов) или проактивно по результатам исследований на улучшение надежности приложений. Само это приложение собирает информацию о соблюдении правил и позволяет сформировать отчет в виде leaderboard. Те руководители, чьи сервисы оказываются внизу лидерборда, обычно имеют нехилую мотивацию на устранение найденных проблем.

В принципе, другой вариант реализации этой логики проверок - это реализация внутри пайплайна поставки, примерно так работает наш Quality Gate, который проверяет уровень автоматизации тестирования. Но ребята решили пойти другим путем, чтобы иметь возможность проверить проиложения не только перед деплоем или вовремя деплоя, но и дальше по мере их работы в продакшене.

P.S.
В software architecture такие проверки предлагается делать через fitness functions, которые предлагались в книге "Building evolutionary architecture". Вот эпизод подкаста "Code of Architecture", в котором мы говорили об этом концепте.

#Architecture #Management #Leadership #SRE #Engineering #Software
2,572
Книжный куб

06 Nov, 05:08

Research Insights Made Simple #3 - Обсуждение paper "Security by Design at Google" (Рубрика #Security)

В третьем эпизоде подкаста мы обсуждаем интересный whitepaper "Secure by Design at Google" от Chirstoph Kern на тему security с человеческим лицом от Google, где рассказывалось о том, как создавать безопасный софт на большом масштабе. В разборе мне помогает крутой гость - Артем Мерец, мой коллега. Артем был разработчиком и 10 лет назад перешел в информационную безопасность. Он активно строил AppSec, когда он начал зарождаться в РФ как стрим, а затем увлекся атаками и несколько лет ломал инфраструктуру и приложения разных компаний в РФ и за пределами. И с 2021 помогаю выстраивать защиту Т-Банка в роли архитектора.

Сама научная статья доступна на сайте Google, а в моем блоге есть разбор

В этом выпуске мы обсудили следующие темы
- Общие впечатления от статьи
- Логические уязвимости и подходы Google
- Сложности безопасной разработки
- Концепция Security by Design
- Примеры безопасности из автомобильной индустрии
- Проблемы аудита кода
- Принципы безопасного дизайна
- Проблемы с инвариантами
- Автоматизация и категоризация инвариантов
- Применение инвариантов
- Проблемы безопасности в системах
- Примеры защиты от злонамеренных действий
- Дизайн для безопасности
- Shift left everything в разработке
- Проблемы и решения в безопасности
- Проект Yaga в Т-Банке
- Логические уязвимости
- Безопасная экосистема разработки
- Проблемы с памятью и микросервисной архитектурой
- Проблемы с безопасностью и инфраструктурой
- История о стажере-саботажнике в ByteDance
- Контроль артефактов и безопасность
- Экосистема для разработчиков

#Architecture #Security #CI #CD #Devops #Software #Management #Leadership #Engineering #Podcast
2,701
Книжный куб

04 Nov, 05:28

Обложки книг "Ухожу в Stand Up!" и "Mastering Stand-Up"
2,565
Книжный куб

04 Nov, 05:27

Ухожу в Stand Up! (Mastering Stand-Up) (Рубрика #Humor)

Это не утверждение, а название очередной книги, которую я дочитал буквально этой ночью. Книга попала ко мне интересным образом - пару месяцев назад меня позвали выступить на внутреннее мероприятие на всю компанию в формате стендапа. Я немного подумал над темами и выбрал одну из двух, про которые я обычно рассказываю - это была тема "Архитектуры", потому что про менеджмент шутили два других спикера. Как обычно, когда я сталкиваюсь с новой темой, то покупаю книги по ней - кажется, что еще с детства у меня пошла история о том, что получение книги == получению знаний из книги. В итоге, выступление на стендап я подготовил, но книгу прочитать не успел. Хорошо, что я заявился с этой же темой "Архитектура в Т-Банке: вчера, сегодня, завтра" на ArchDays и взял книгу в проработку. На прошлой неделе я рассказал этот доклад, а ночью дочитал последние страницы книги. Конечно, конференция по архитектуре - это не стендап-шоу, поэтому пришлось разбавлять шутки занудной теорией до гомеопатического состояния, но часть пользователей в отзывах к докладу отметила чувство юмора (ладно, это заметил один человек).

Если говорить о самой книге, то ее написал Стивен Розенфилд, основатель Американской школы комедии, который поставил обучение комиков на поток и в этой трехсотстраничной книге поделился своими рецептами становления хорошим стендапером. В книге 5 частей
1) Начинаем сотрудничать - в этой части автор подбадривает читателя и рассказывает о пути, который ему предстоит пройти, чтобы стать успешным: выясни в чем, твоя оригинальность, научись писать тексты для стендапа, отточи мастерство выступлений, придумай сценического персонажа, постоянно выступай и так далее
2) Виды стендап-комедии - здесь автор перечисляет виды, показывает примеры и объясняет разницу между ними. Например, он говорит о комедии наблюдений, сторителлинге, стендап-скетчах, акт-аутах, унижениях знаменитостей или людей из своего окружения, самоиронию, юмор на грани фола и так далее
3) Руководство по созданию материала для стендап-комедии - здесь автор рассказывает что делать до того как сесть за черновик, дальше как работать с черновиком, как обкатывать материал из него, как дорабатывать шутки формата сетап - панчлайн через фидбек аудитории на выступлениях (тут используется принцип working backwards для шлифовки и усиления шуток)
4) Руководство по выступлению со стендап-комедией - автор описывает что делать с волнением перед выступлением, как вести себя на сцене, как уложиться в регламент и что делать если шутка не зашла:)
5) Как добиваться непревзойденного мастерства - здесь автор рассказывает про классификацию шуток "A", "B", "C" и описывает как составить сет из шуток класса "А". Как создать удачный сценический образ, который должен быть оригинальным, правдоподобным, ярким, вызывать симпатию, иметь сценическое обаяние и смешную суть. Прикольно, что автор дает список причин почему шутка, которая раньше разрывала зал, стала уходить в тишину - а дальше он дает рекомендации как это можно исправить. Финалит последнюю часть автор рассказом про то, как быть ведущим и как победить свой внутренний голос, который мешает достигать своих целей (в данном случае быть смешным).

В общем, книга мне показалось интересной и полезной, даже с учетом того, что я не ухожу в StandUp!

#Humor #PublicSpeaking #Leadership #SelfDevelopment
2,410
Книжный куб

03 Nov, 05:40

Как стать продуктивнее в IT, если вы уже прокачали свои харды (Рубрика #Management)

Через 3 недели я выступлю на конференции soft weekend, первой софтовой офлайн-конференция в России (что бы это ни значило). Я не могу сказать, что люблю рассказывать чисто про софты, но эту конференцию организует мой знакомый, Андрей Смирнов, автор подкаста "Frontend Weekend", куда я ходил в гости в прошлом году. В итоге, я решил рассказать что-то из серии набора качеств и навыков, что важны для всех: и для крутых инженеров и для начинающих маркетологов. В этот список вошли
- Умение планировать свое время (а дальше если повезет и своей команды)
- Умение и желание брать на себя ответственность (и главное доводить сложные дела до конца)
- Навыки общения с коллегами и договороспособность (эта часть часто западает)
- Навыки самомотивации и мотивации окружающих (правда, если разбираться в вопросе, то внешняя мотивация - это скорее стимуляция)

В общем, после прокачки хардов по максимуму, часто так называемые софты становятся очень важны. Поэтому я сначала в докладе расскажу про харды, что важны для ITшников, а потом поделюсь своими рецептами о том, как быть эффективнее с точки зрения софтов:)

Конференция пройдет очно 23 ноября в Пространстве Весна, Спартаковский п., 2с1. Купить билет можно здесь

#Leadership #Processes #Management
2,804
Книжный куб

02 Nov, 08:11

Открытая менторинг сессия со мной на SouthHub (Рубрика #Management)

12 ноября в 19:00 я проведу открытую сессию менторинга на канале SouthHub. Менти выберут организаторы канала SouthHub, а подать заявку на участие может любой желающий. Запрос по менторингу может быть на одну из следующих тем
- Как выбрать орг. дизайн команд под задачи бизнеса: как понять, что требуется, как организовать команды.
- Как выстроить процессы в командах — discovery & delivery, архитектурные процессы и процессы обеспечения надежности.
- Как измерять эффективность процессов — какие метрики бывают и насколько им можно верить.
- Как осуществлять крупные изменения в больших компаниях.
- Как работать над техническим брендом параллельно с основной работой.

Сама сессия будет доступна в виде видео на канале SouthHub.

#Management #Leadership #Processes #Engineering #Software
3,121
Книжный куб

01 Nov, 12:00

"Архитектура в Т-Банке: вчера, сегодня, завтра" на конференции ArchDays 2024 (Рубрика #Architecture)

Сегодня в 15.40 я выступаю на конференции ArchDays с докладом "Архитектура в Т-Банке: вчера, сегодня, завтра", в котором я расскажу про развитие подходов к проектированию и архитектуре в Т-Банке с начала времен и до текущего момента. Я постараюсь объяснить какие причины побуждали нас меняться и как мы осуществляли сами изменения. Я расскажу про процессы и людей, которые занимаются у нас проектированием и почему архитектор - это не должность, а роль. А закончу тем, что расскажу куда мы движемся дальше.

Вот дополнительные материалы для изучения, которые я рекомендую к своему выступлению
1) "Эволюция web’а tinkoff.ru за последние 3 года" (youtube) - мое выступление на ArchDays 2019, в котором я рассказываю как мы переходили от коробочного решения к собственной разработке в одном из доменов
2) "Архитектура в масштабе или как мы в Tinkoff принимаем архитектурные решения" (youtube, статья с расшифровкой) - мое выступление на ArchDays 2020, в котором я рассказываю про архитектурные подходы, к которым мы пришли по итогам масштабной собственной разработки и какую мы ставку делали на платформизацию
3) "DevOps-эры в Тинькофф: культура, люди, инструменты" - выступление моего бывшего коллеги Станислава Халупа на Kuber Conf 2021 года, где он рассказывал про platform engineering и почему это направления стало важным для нас (мое саммари по выступлению, само выступление на youtube)
4) "Technical Governance для IDP на 7000 разработчиков" - статья Дмитрия Гаевского про governance для нашей внутренней платформы разработки Spirit (это расшифровка его выступления на Highload++ 2021)
5) Раздел про технологии на нашем сайте - здесь можно почитать про наши платформенные решения
6) "Code of leadership #17 - Interview with Anton Kosterin about Architecture" (youtube, ya music, пост) - серия подкаста с Антоном Костериным, моим замом, который помогает мне строить architecture governance
7) "Research Insights Made Simple #1 - API Governance at Scale" (youtube, ya music, пост) - первая серия подкаста с разбором научных статей, где я с моим коллегой разбирал подход к API Governance в Google, а также мы активно проводили параллели с architecture governance в нашей компании
8) "Measuring Developer Goals" - мой обзор статьи от Google на тему того, куда стоит двигаться платформе разработки, чтобы оптимально поддерживать цели инженеров при разработке софта

#SoftwareArchitecture #Architecture #Software #SoftwareDevelopment #SystemDesign #SystemDesignInterview #DistributedSystems
2,888
Книжный куб

31 Oct, 15:17

Code of Leadership (Рубрика #Management)

Примерно год назад я стартанул подкаст про engineering management с названием Code of Leadership. За это время получилось выпустить 21 эпизод, но я не планирую на этом останавливаться:) Подкаст доступен в Youtube и Ya Music.
Вот ссылки на материалы по каждому эпизоду:

1) Team topologies со Станиславом Халупом
2) "Antifragility in IT" с Александром Бындю
3) "Herding Cats" с Женей Кузовлевым
4) "Turn the ship around" с Екатериной Шестимеровой
5) "Project Phoenix" с Иваном Михеевым
6) Интервью про Staff+ инженеры, архитектура и SDLC с Алексеем Тарасовым
7) "Your brain at Work" с Эрнесто Инаркиевым
8) Интервью с Андреем Цыбиным про Statist (система для продуктовой аналитики)
9) "An Elegant Puzzle - System of Engineering Management (часть 1)" с Eugene Sergueev
10) "An Elegant Puzzle - System of Engineering Management (часть 2)" с Eugene Sergueev
11) Интервью с Кириллом Крайневым про системных аналитиков в Тинькофф
12) Интервью с Димой Гаевским про платформу Spirit (Internal developer platform) в Тинькофф
13) "Accelerate" с Игорем Курочкиным
14) Interview with Artem Ivanov about Risk Tech
15) Interview with Roman Lebed about Information security
16) "The Five Dysfunctions of a Team" с Андреем Соколовым
17) Interview with Anton Kosterin about Architecture Governance
18) Interview with Pavel Akhmetchanov about Processes and Tools
19) Interview with Evgeny Sokolov about Modern Education
20) Interview with Alexey Grishin about Software Architecture
21) "A Philosophy of Software Design" с Гришей Скобелевым

#Architecture #Processes #Management #Leadership #Software #Statistics #Project #Productivity #ProductManagement
2,913
Книжный куб

30 Oct, 07:40

CPU, Memory Models, Concurrency, Multiprocess, Multithreading и Async (Рубрика #ComputerScience)

Я часто рассказываю про то, что надо знать базу для того, чтобы развиваться в software engineering. Но обычно сложно описать, а что же входит в это определение "база" и является джентельменским набором хорошего инженера. Но тут мой коллега, Женя Козлов, крутой инженер, написал серию статей про процессоры, модели памяти, многозадачность и конкурентность. В этой серии разбираются моменты, которые полезны инженерам, что делают высоконагруженные системы, которые плотно работают с данными. Собственно, сам Женя у нас лидит команду, что занимается Statist - это наша система продуктовой аналитики, которая давно заменила нам Amplitude и по всем характеристикам тянет на data intensive application. В общем, я очень рекомендую вам эту серию статей от Жени, если вам интересно понять как компьютер обрабатывает под капотом те программы, что вы пишите на своем любимом языке программирования.

1) Начальный пост про многозадачность в OS
2) Про развитие процессоров и взаимодействие OS с ними
3) Про Hyper Threading
4) Процессы. Начало
5) Процессы в Linux
6) Потоки. Начало
7) Потоки в Linux
😍 Модели ввода-вывода. Универсальная(блокирующая) модель ввода-вывода
9) Multiplexed IO
10) Asynchronous IO

#Software #ComputerScience #Engineering #SRE #Architecture
3,145
Книжный куб

29 Oct, 05:08

Research Insights Made Simple #2 - Обсуждение paper "Defining, measuring and managing technical debt" (Рубрика #Management)

Это второй выпуск подкаста с разбором научных статей, которые посвящены разным темам computer science и engineering management. В этом выпуске мне помогает мой коллега, Дмитрий Гаевский, Technical CPO (Chief Product Owner) нашей внутренней платформы разработки Spirit. Для второго выпуска мы взяли научную статью про технический долг и то, как он влияет на продуктивность инженеров. Эта статья от ребят из Google вышла в 2023 году.

Основные материалы
- Whitepaper доступен здесь
- Мой разбор whitepaper есть в блоге

В этом выпуске мы успели обсудить темы
- Исторический контекст и метафора технического долга
- Долг или инвестиции в качество кода
- Исследование технического долга в Google
- Категории технического долга в общем
- Категории, выбранные для исследования
- Измерение технического долга
- Проблемы с метриками и целевыми состояниями
- Концепция opportunity cost
- Проблемы с термином "технический долг"
- Управление техническим долгом
- Альтернативы термину "технический долг"
- Результаты работы с техническим долгом в Google
- Объединение объективных и субъективных данных
- Проблемы разделения технической и продуктовой работы
- Альтернативные подходы к техническому долгу

#Architecture #Software #Management #Leadership #Engineering #Podcast
2,648
Книжный куб

28 Oct, 05:24

Иллюстрации для книги "Карта гипотез"
2,820
Книжный куб

26 Oct, 06:35

The Engineering Executive's Primer - Part I (Рубрика #Management)

Продолжая нулевой пост с обзором книги, я хотел бы сказать, что Will не поскупился на контент и сгенерировал целых 24 главы, вступление, заключение и еще пяток дополнительных материалов. Разобрать все это добро за один раз не получится, поэтому постов будет много, но начнем мы с первого:)

0) Preface
Во введении автор рассказывает про то, как он пришел к идее этой книги после предыдущих книг "Staff Engineer" и "An Elegant Puzzle. Systems of Engineering Management". Первая является классным источником информации по карьерному пути для инженеров, которые переросли уровень senior и отправились покорять новые моря. Я про нее уже рассказывал: 1 и 2. Вторая книга хороша для engineering managers, про которую я рассказывал раньше, а потом было две серии подкаста "Code of Leadership" с разбором этой книги вместе с Eugene Sergueev, senior engineering manager из Flo health: 1 и 2
1) Getting the Job
Начинает книгу автор с того, чтобы рассказать про то, а как же можно получить работу в качестве engineering executive. Для начала стоит ответить себе на вопрос, а точно стоит в это вписываться? Дальше возникают вопросы, а где это делать: внутри текущей компании или во внешней. Дальше автор обсуждает хаотичный процесс найма топов, который отличается от компании к компании, а дальше еще идет и обсуждение условий. Ну и заканчивается все тем, а как размышлять относительного того, а принимать офер или нет. В общем и целом, глава действительно неплохо описывает этот непростой процесс и дает структуру и подход для взвешенного принятия решений.
2) Your First 90 Days
Здесь автор говорит о том, что в первые 90 дней придется серьезно попотеть и начать с того, чтобы разобраться с тем как работает бизнес и откуда приходят деньги, что определяет культуру компании, как установить здоровые взаимоотношения со стейкхолдерами и своими peers, насколько хорошо функционирует инженерная команда с точки зрения delivery, насколько высоко техническое качество софта и инструментов для поддержки процессов разработки, что с моралью инженерной команды и насколько сама команда устойчива для выбранного темпа развития команды. Дальше важно ограничить количство ранних изменений, что вы делаете в первые 90 дней. Кроме этого важно выстроить доверие с коллегами и позаботиться о поддержке с их стороны. Вообще, классно разобраться как в компании осуществляется работа и как выглядят технологии (включая код и деплой, дежурства, работа с инцидентами, ...)
3) Writing Your Engineering Strategy
Эту главу я разбирал еще тогда, когда она была просто статье в блоге автора. Статья была отличной и она не стала хуже после превращения в книжную главу:)
4) How to Plan
Автор рассказывает про стандартный подход к планированию в компаниях:
- Ежегодное финансовое планирование (включая план по headcount)
- Полугодовые или квартальные планы, например в виде OKRs для команд. Эти планы таргетируют бизнес результаты или список проектов, что надо сделать
- Внутрикомандные процессы управления работой (Kanban, Scrum, etc), которые направлены на то, чтобы уложиться в квартальные/полугодовые планы
- Отдельно автор говорит о том, что могут быть еще и периодические ревью, например, каждый месяц. Эти ревью направлены на отслеживание прогресса по выполнению целей компании

Продолжение в следующих постах: 2

#Engineering #Management #Leadership #Processes #SystemDesign #SystemThinking #SystemEngineering
2,683
Книжный куб

26 Oct, 06:33

The Engineering Executive's Primer - Part 0 (Рубрика #Management)

Я уже давно прочел новую книгу Will Larson для IT топ-менеджеров, про которую я писал раньше. Прочел и прочел, но все как-то не доходили руки написать про нее, но сейчас я в очередной раз сижу в аэропорту и жду самолета, поэтому время есть:) Сразу скажу, что книга мне понравилась - у Вилла как обычно отлично со структурой книги, а отдельные главы достаточно емкие и наводят на размышление (интересно, что они обычно появляются как статьи в блоге lethain.com, один из немногих блогов, что я читаю)

Продолжение в следующем посте.

#Engineering #Management #Leadership #Processes #SystemDesign #SystemThinking #SystemEngineering
2,652
Книжный куб

25 Oct, 15:36

System Design Interview - Highload++ 2024 (Рубрика #Architecture)

В этом году я зайду в декабре на Highload++, чтобы подискутировать на тему system design interview. Этот формат собеседования стал достаточно популярным в крупных компаниях6 а кто-то его вкручивает в свой процесс собеседований как карго-культ. В этои дискуссии мы обсудим
- Что это за тип интервью
- Зачем он нужен компаниям и можно ли обойтись без него
- Какие у него есть плюсы и минусы

Надеюсь, что дискуссия будет интересной и понравится всем зрителям:)

P.S.
До этого я уже рассказывал про процессы найма в большие компании и типы интервью на примере Т-Банка. Про System Design у меня тоже было много материалов. Например можно посмотреть в общем про system design в Tinkoff, больше про то, как мы оцениваем прохождение собеседования и как подготовиться к собеседованию или публичные интервью на ArchDays

#Career #HR #Management #Architecture #Software #Leadership #Processes
2,784
Книжный куб

23 Oct, 11:14

API Design Patterns (Паттерны проектирования API) (Рубрика #Architecture)

В последнее время я много изучаю материалов на тему governance. Туда входит architecture governance, API governance и другие подходы для того, чтобы двигаться в сторону engineering excellence. И так получилось, что я в выходные снял с полки эту книгу "API Design Patterns" из последней закупки на распродаже в издательстве "Питер". Книгу написал Джей Джей Гивакс, соавтор статьи "API Governance at Scale" про подходы в Google. Он же был сооснователем ресурса aip.dev и одним из главных идеологов процесса AIP (API Improvement Proposals), про который я рассказывал раньше. Интересно, что с момента издательства книги Джей Джей уже успел перейти в Meta - это видно по заглавной страничке с авторами whitepaper:)

Когда я начал читать эту книгу, то понял, что она очень хороша - автор четко и методично рассказывает про паттерны для создания ресурсно-ориентированных API. Он делится теми подходами, к которым пришли ребята в Google и делает очень доступно. В общем, пока я еще всю книгу не прочитал, но уже могу порекомендовать ее для прочтения.

P.S.
Я разбирал статью "API Governance at Scale" в первом выпуске нового подкаста "Research Insights Made Simpe" (видео в Youtube, подкаст в Ya Music). Отдельно разбор есть в моем блоге в виде статьи.

#Architecture #Software #DistributedSystems #SystemDesign #SystemEngineering #API #Governance
2,821
Книжный куб

22 Oct, 08:13

Testing strategy: avoid the waterfall strategy trap with iterative refinement (Рубрика #Management)

Очередная интересная статья от Will Larson, который постепенно создает свою новую книгу про стратегию. В этой главе речь идет про гибкое тестирование стратегии и улучшение ее на основе обратной связи:) Как обычно у Вилла все очень структурно

1) Когда стоит тестировать стратегию?
Когда хочется понять насколько она достижима и сколько реально будет стоить. По-факту, автор предлагает перед ее финализацией делать аля PoC (proof of concept), который позволит собрать недостающую информацию. Но иногда это можно не делать - например, при разрешающей стратегии (ее имплементация стоит не дорого), при слишком долгом ожидании обратной связи (вопросы с наймом в разных регионах) или когда мы почти уверены в своей стратегии

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

3) Роли для тестирования стратегии
Автор выделяет роль спонсора и руководителя (guide). Собственно один авторизует стратегию и помогает ей случиться, а второй ее реализует, отслеживает выполнение и эксалирует в случае проблем. Забавно, что я успел побывать и тем и другим за время карьеры:) Важно, чтобы эта пара могла принимать сложные решения быстро, а не уходила в paralysis of analysis

4) Meetings & Metrics
Единственное обязательное требование для этапа тестирования стратегии — спонсор, руководитель и все ключевые лица, работающие над стратегией, должны встречаться каждую неделю. В ходе этой встречи надо смотреть на показатели, что отражают текущие области, которые вы пытаетесь улучшить, обсуждать, чему вы научились на основе предыдущих показателей или данных, а также планировать разовые контрольные проверки, чтобы убедиться в прогрессе.

5) Выявление стратегий, не прошедших тестирование
Хотя не все стратегии должны быть уточнены в ходе фазы тестирования, по сути, все неудачные стратегии пропускают фазу тестирования, чтобы перейти непосредственно к реализации. Стратегии, которые пропускают тестирование, звучат правильно, но не достигают многого. Один из самых стандартных паттернов провала - это "давление без плана", когда стратегия представляет собой лишь аспект «звучит правильно» без каких-либо деталей. Я видел много таких стратегий

6) Восстановление после пропущенного тестирования
После нахождения зависшей стратегии, что пропустила этап тестирования автор предлагает написать новую стратегию и на этот раз включить туда тестирование отдельным шагом, а дальше начать реализовывать ее.

В финале автор говорит о том, что тестирование не поможет понять, а может ли стратегия быть хорошей. Но оно позволит выявить недостающие детали, необходимые для перевода стратегии в работающее состояние:)

#Management #Strategy #Leadership #Software
2,536
Книжный куб

21 Oct, 06:09

Обложки для книг "The Tyranny of Metrics" и "Тирания показателей"
2,423
Книжный куб

21 Oct, 05:08

The Tyranny of Metrics (Тирания показателей) (Рубрика #Management)

Эта интересная книга за авторством Muller Jerry вышла в 2018 году в Princeton University Press, а в 2020 году ее перевели в Альпине. Мне понравилось название, которое идет наперекор стандартному подходу к измерению всего и вся:) В итоге, книга напоминает по структуре научную статью. А когда я начал читать эту книгу, то легко узнавал проблемы, которые классно описывал автор. Во многом они рождены из закона Гудхарта "Когда мера становится целью, она перестает быть хорошей мерой". В итоге, автор не предлагает отказаться от показателей, а скорее говорит о том, что помимо них должны быть качественные показатели и мнение разбирающихся в теме людей, которые принимают решение. Иначе получится как с XSolla, где были уволены сотрудники с аргументацией, что "биг дата» показала их невовлеченность".

Вот содержание книги
0) Введение - автор рассказывает о том, как он, работая в сфере образования профессором и завкафедрой, оказался вынужден сдавать все больше и больше отчетов по мере обвешивания системы образования метриками. Дальше он заинтересовался историей вопроса и в итоге получилась эта книга
1) Постановка проблемы - в этой части автор рассказывает об одержимости показателями и к чему это может приводить. Делает это он в главах с кратким описанием проблемы и перечнем характерных ошибок
2) История проблемы - так как автор - это учений с интересами в истории, экономики и политики, то он глубоко погружается в историю вопроса и рассказывает про
- Происхождение системы вознаграждения в зависимости от результата (pay for performance)
- Почему количественные показатели стали такими популярными
- Принципалы, агенты, мотивация (внутренняя и внешняя)
- Философия и критика
3) Можно ли применять количественные оценки ко всему подряд - тут автор разбирает на конкретных примерах результаты применения чрезмерной количественной оценки
- В образовании - автор разбирает колледжи и университеты
- Школы - автор рассказывает про зарубежный опыт, но мы все можем видеть результаты ЕГЭ
- Здравоохранение - тут автор показывает как рейтинг хирургов на основе успешных операций приводит к тому, что они отказываются от сложных операций и предлагают сразу ехать на кладбище
- Охрана правопорядка - тут цель в снижении преступности приводит к тому, что часть преступлений классифицируют как менее тяжкие, которые не входят в рейтинг или просто не реагируют на часть обращений
- Вооруженные силы - тут гонка за показателями особенно вредна в сценариях борьбы с террористами, повстанцами и другими иррегулярами
- Бизнес и финансы - тут автор проходит по KPI, OKR, вспоминает разгон показателей для радости инвесторов, подделывание отчетности. В итоге, часто менеджеры концентрируются на операционных показателях и перестают думать о стратегии развития
- Благотворительность и помощь другим странам - автор говорит о том, что тут методы бизнеса работают не очень, так как вовлеченные в благотворительность часто ориентируются на свою внутреннюю мотивацию, а внешние KPI начинают ее подмывать:)
4) Экскурсы. Автор показывает что иногда прозрачность - это враг результативности. Он делает это на примере политики, дипломатии, разведки и браков:)
5) Выводы. Сначала автор рассказывает о непредвиденных, но предсказуемых последствиях увлечения показателями, а потом говорит о том, а когда и как применять количественные показатели. Про эту часть я расскажу отдельно позже.

В общем, книга мне очень понравилась, так как я часто вижу описанные автором проблемы и стремлюсь их исправить. Иронично, что продуктовая аналитика и a/b платформа, что нужна для контролируемых экспериментов, а также metric store, где должны считаться метрики по продуктам для всей организации, сейчас находится в моем юните, а значит правильное применение данных - это отчасти и моя профессиональная задача:)

Продолжение в следующем посте.

#Data #Statistics #Management #Leadership #Processes
2,826
Книжный куб

20 Oct, 05:08

Research Insights Made Simple #1 - Обсуждение paper "API Governance at Scale" (Рубрика #Architecture)

Это первый выпуск подкаста с разбором научных статей, которые посвящены разным темам computer science и engineering management. В этом выпуске мне помогает мой коллега, Даниил Кулешов, Staff Engineer, который развивает вместе со мной в Т-Банке архитектурную функцию на уровне всей компании.

Для первого выпуска мы взяли научную статью про governance, а точнее про API governance от ребят из Google, которая вышла в 2024 году. Сама статья достаточно хорошо раскрывает тему governance, что позволяет закрыв глава подставить на место API слово architecture и многие мысли и выводы авторов останутся корректными.

Основные материалы
- Whitepaper доступен здесь - https://research.google/pubs/api-governance-at-scale/
- Мой разбор whitepaper есть в блоге - https://tellmeabout.tech/review-whitepaper-api-governance-at-scale-fdab581b8489
- Перечень Google стандартов на API доступен здесь - https://google.aip.dev/

#Software #Architecture #DistributedSystems #Whitepaper #Management #Processes #Leadership
2,799
Книжный куб

19 Oct, 09:12

Сервис Unidraw.io от T-Bank - наш ответ Miro - Продолжение (Рубрика #Visualisation)

Раньше я уже анонсировал этот инструмент в отдельном посте, а теперь
1) Я уже обкатал этот инструмент при создании обзоров всех whitepapers, про которые я рассказывал с сентября, а также при проведении System Design Interview
2) Пару дней назад на Хабре появился рассказ про бекстейдж развития этого инструмента у нас в компании "Unidraw — путь длиной в два года"

Если говорить про обзоры статей, то визуализаций в Unidraw мне хватает и я не часто вспоминают про Miro. Для демонстрации тезиса я решил пошарить все эти доски, чтобы вы могли проверить все сами - ближайший месяц они будут доступны и неавторизованным пользователям, а потом придется все-таки заводить аккаунт, чтобы их посмотреть:)
1) Defining, measuring and managing technical debt - статья с обзором и доска
2) API Governance at Scale - статья с обзором и доска
3) Hybrid Productivity - статья с обзором и доска
4) A Human-Centered Approach to Developer Productivity - статья с обзором и доска
5) Measuring Developer Goals - статья с обзором и доска
6) Software quality - статья с обзором и доска
7) AI-Enhanced API Design: A New Paradigm in Usability and Efficiency - статья с обзором и доска
8) Secure by Design at Google - статья с обзором и доска

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

У инструмента есть свой канал t.me/unidrawio и чат для пользователей t.me/unidrawiochat, так что у пользователей есть возможность быть в курсе новостей и доносить обратную связь напрямую команде.

#Data #Visualization
2,453
Книжный куб

19 Oct, 05:08

Architecture Modernization: Aligning Software, Strategy & Structure • Nick Tune • GOTO 2024 (Рубрика #Architecture)

Интересный и полезный доклад на тему модернизации архитектуры существующих систем от Nick Tune, principal consultant at Empathy Software. Если сократить доклад, то тезисы примерно такие:
- Успешным компаниям часто требуется модернизация архитектуры, так как их прежняя архитектура: предназначена для меньшего объема клиентов и не тяент нужную нагрузку, опирается на старые технологии, которые не позволяют добавлять фичи с нужной скоростью. В итоге, модернизация может превратить недостатки в достоинства
- Такая модернизация касается не только технических вопросов - на самом деле надо оценивать весь стек от UX до глубоких бекендов, включая огрструктуру и процессы работы сотрудников
- В модернизации могут помочь разные инструменты, но автор выделяет следующие 5 штук
1) Listening Tours - сюда обычно входят опросы, интервью с сотрудниками, фокус-группы, gemba и так далее. Задача в том, чтобы услышать своих сотрудников
2) Impact mapping - это простая методика совместного планирования для команд, которые хотят добиться большого эффекта с помощью программных продуктов.
3) Wardley mapping - это карта бизнес-стратегии, где компоненты располагаются по оси Y, что обозначает положение в цепочке создания стоимости и привязаны к потребностям пользователя, а ось X описывает эволюцию компонентов (от зарождения до commodity)
4) Event storming - это крутая техника проведения воркшопов для коллаборативного изучения сложного бизнес домена, про которую я уже рассказывал
5) Modernization strategy selector - модель выбора оптимальной стратегии модернизации для каждой подсистемы, которая позволяет использовать портфельный подход к модернизации, где оптимальный возврат инвестиций может быть определен на гранулированной основе для достижения оптимального общего возврата инвестиций в модернизацию.
- Ну и напоследок автор говорит о том, что для старта надо выбирать область, где модернизация может принести обозримые результаты за ограниченный промежуток времени. В общем, надо уметь срывать низковисящие плоды - это позволяет показать, что модернизация может приносить пользу, а не превратится в очередное бесконечное начинание без конца и без края и без ощутимых результатов:)

#Management #Software #Engineering #SoftwareDevelopment #Processes #ChangeManagement #Strategy #Architecture
2,797
Книжный куб

18 Oct, 11:14

A Brief Outlook of Enterprise Architecture Role in the Digital Age (Рубрика #Architecture)

Когда я выбирал научные статьи с research разделов bigtech компаний, то мне казалось, что большая часть whitepaper интересна. Но тут я решил поискать материалы про enterprise architecture в ACM Digital Library и нашел ... Пока ощущение от их чтения грустное. Конкретно в этой статье 2022 года от Ахмеда из Египта (Ahmed S. Elsheikh) сделано все достаточно топорно и как-то механистически, но давайте ниже я расскажу подробности

1) В абстракте автор начинает с того, что с 1980х годов корпоративная архитектура существует как отдельная дисциплина, которая помогала бороться со сложностью
2) Но с 2010х годов появилась отдельная волна цифровых трансформаций (digital transformation), которая привела к волне подрывных инноваций и бизнес и технологические ландшафты изменились навсегда:)
3) Автор решил исследовать как эти две волны связаны межжду собой через исследование статей на тему digital enterprise architecture
4) Для начала автор рассказывает про святую троицу: Enterprise architecture => TOGAF => Archimate, где корпоративная архитектура - это околонаучная дисциплина, TOGAF - это фреймворк, а Archimate - это фреймворк для моделирования архитектуры. Дальше автор рассказывает про application portfolio management strategy, capability architecture и capability-based planning
5) Но возникает вопрос как это все добро применять с цифровизации, цифровой трансформацией и другими историями про трансформаторов и трансформации:)
6) Автор погуглил словосочетание "digital enterprise architecture" в Clavirate "Web of science" и нашел 55 статей
7) Дальше автор взял базовую статистику по году выхода, авторам, количеству цитат и построил графики - походу статья без графиков не очень научна
😍 Из графиков видно, что с 2015 года пошли не разовые публикации, а косяком, где в 2017 году был пик в 10 публикаций, дальше небольшое проседание и в 2021 году был новый рекорд в 14 публикаций. Из этой статы видно, что исследователи корпоративной архитектуры сразу подхватили тренд цифровой трансформации:)
9) Дальше автор разбил эти 55 статей по 3 группам, выделив отсечку по количеству отсылок к публикациям (количество цитат из них)
10) Получилось 3 группы:
- Взаимное влияние корпоративной архитектуры как отдельной дисциплины и цифровой трансформации как отдельной волны подрывных технологий и бизнес потребностей в одно и то же время
- Как корпоративная архитектура как отдельная дисциплина может помочь и поддержать корпорации, что цифровые и глобальные одновременно
- Как корпоративная архитектура как отдельная дисциплина может помочь и поддержать цифровые трансформации в разных контекстах и секторах индустрии
11) Автор кратко буквально в одной строке характеризуют каждую статью из этих групп (очень глубокая проработка материала)
12) Напоследок автор формулирует направления для исследования примерно так
- Связь между глобальными цифровыми корпорациями и конкретные трансформации, например, корпоративная архитектура может отличаться между индустриями
- Не хватает некоторых логичных областей (указанные три категории выше не закрывают все сценарии)
- Как отличаются корпоративные архитектуры, когда в основе цифровых трансформаций разные подрывные технологии (автор делает отсылку к блокчейну и бигдата - чуток подпротухшими сейчас кажутся предложенные автором disruptive technologies)
- Как фреймворки для корпоративной архитектуры и фреймворки для цифровых трансформаций (походу и такая дичь штука есть)

В итоге, книга заканчивается выводом, что автор сделал обзор литературы и даже дал рекомендации по новым исследованиям.

P.S.
А я подумал, что лучше бы я прочитал еще одну научную статью от Google:)

#SoftwareArchitecture #Architecture #SystemDesign #Software #SoftwareDevelopment
2,375
Книжный куб

18 Oct, 05:08

Обзор paper "Defining, measuring and managing technical debt" (Рубрика #Architecture)

Я продолжаю читать и писать о статьях из серии developer productivity, о которых рассказывал в обзоре первого whitepaper "A Human-Centered Approach to Developer Productivity". В третьем whitepaper с заголовком "Defining, Measuring, and Technical Debt" речь идет про технический долг и как он влияет на продуктивность разработчиков. Эта тема часто поднимается, но редко когда можно услышать четкое определение термина, а также объяснение как его считать и что с ним делать. Авторы решили закрыть этот пробел и написать как с этим дела в Google. А я решил сделать обзор этой статьи.

#Architecture #Software #Management #Leadership #Engineering
2,307
Книжный куб

17 Oct, 09:48

Как формировать структуру команд под запросы бизнеса (Рубрика #Management)

Недавно меня позвали выступить на митапе с этой темой, которую я рассказывал на YaTalks в 2023 году. Это знаковое для меня выступление, так как я делился основами и принципами дизайна команд, которые помогали мне на протяжении 7 лет работы в Тинькофф. Это приглашение показалось мне отличной причиной рассказать сразу и продолжение о том, как за 2023 и 2024 года мы трансформировали мое подразделение в 1000 инженеров в 5 отдельных самостоятельных технических доменов со своими engineering директорами. Но оказалось, что я не сделал краткого саммари прошлого выступления. Поэтому я решил исправиться и написать расшифровку (а видео досупно на youtube).

В итоге, я сегодня выступаю на митапе в Selectel, где расскажу сокращенную версию доклада про оргдизайн с фокусом на тимлидах, а вот продолжение расскажу на одной из следующих конференций - просто вся история с продолжением не влезла в тайминг + не очень попадает в целевую аудиторию митапа.

Вот список рекомендаций для дальнейшего изучения
Принципы и подходы
- Backcasting мы обсуждали в серии Code of Architecture про Technology Strategy Patterns
- Про working backwards написана целая книга
- Про проектный и продуктовый подход у меня есть хорошая статья
- Про Kanban рекомендую почитать пару книг: “Визуализируйте работу” (“Making Work Visible”), про которую я рассказывал, а также "Канбан Метод. Базовая практика", про которую я тоже рассказывал
- Про закон Конвея можно почитать в wikipedia
- Обратный маневр Конвея в 2014 году попал в техрадар от ThoughtWorks
- Про team topologies можно почитать мои краткие саммари: Teams as means of Delivery, Team Topologies that work for flow, Evolving team interactions for innovation and rapid delivery
- Про управление изменениями классно написано в книге "Наш айсберг тает", про которую я уже писал
Отдельные выступления про их применение
- В 2019 году на ArchDays я рассказывал про эволюцию всей связки фронт - бек - система a/b тестов, где фокус больше на архитектурных изменениях
- В 2021 году на Techlead Conf я рассказывал про то "Как мы меняли разработку лучшего* мобильного банка под требования бизнеса"
- В 2022 году на Highload++ Spb я рссказывал доклад "Канал. Продукт. Платформа” или эволюция подходов к развитию мобильного банка Тинькофф"

#Management #Leadership #Project #ProjectManagement #SoftwareDevelopment #Software
2,790
Книжный куб

17 Oct, 06:09

Обложки для книг "Continuous API Management, 2nd Edition" и "Непрерывное развитие API"
2,435
Книжный куб

17 Oct, 05:08

Continuous API Management, 2nd Edition (Непрерывное развитие API) (Рубрика #Architecture)

Второму изданию этой книге уже порядка 3х лет, а читал я ее последние несколько месяцев и только недавно закончил. Книга мне действительно понравилась и я решил поделиться с читателями канала. В этой книге 12 глав, которые закрывают многие вопросы, связанные с governance, которые обобщаются дальше вопросов управления API

1. The Challenge and Promise of API Management - зачем компании хотят управлять своими API, какие проблемы при этом возникают и какие возможности это дает. Здесь авторы рассказывают в общем об основных вопросах, рассмотренных в книге. Отдельно отмечу важность разделения для API интерфейсов (контракты), имплементации (код) и развертывания (инфра)
2. API Governance - глава с фундаментальными концепциями для управления API и какое это значение имеет для принятия решений
3. The API as a Product - глава про важность восприятия API как продуктов (API as a Product). При этом на API можно смотреть с точки зрения целевой аудитории и принимать решения, которые являются лучшими для них
4. The Pillars of an API Product - основные колонны, на которых основаны API. Авторы выделяют следующие области, которые рассматривают детально: strategy, design, documentation, development, testing, deployment, security, monitoring, discovery, change management
5. Continuous API Improvement - глава про то, как жить с непрерывными изменениями и как ими управлять
6. API Styles - здесь авторы рассказывают об основных стилях, которых они насчитывают 5. Вот они: tunnel style (RPC), resource style (REST), hypermedia style (RESTful), query style (graphql), event-based style
7. The API Product Lifecycle - жизненный цикл одного API, который состоит из этапов: create => publish => realize => maintain => retire ... Авторы подробно разбирают как на каждом этапе требуется прорабатывать конкретные pillars
8. API Teams - какие роли нужны в командах для эффективного развития API как продукта. Причем не просто в вакууме, а в зависимости от зрелости самого API
9. API Landscapes - здесь авторы переходят от единичных API к их множеству, которое можно воспринимать как ландшафт. Авторы рассказывают про API Management at Scale, который опирается на принципы, протоколы и практики. Это очень сильно пересекается с paper "API Governance at Scale" от Google, про которое я рассказывал раньше. Плюс авторы вводят модель 8v, которая позволяет управлять ландшафтом, ориентируясь на разные ракурсы. Вот эти восемь V: variety, vocabulary, volume, velocity, vulnerability, visibility, versioning, volatility
10. API Landscape Journey - рассказ о том, а как внедрять API Governance. Авторы предлагают модель enabling team, которая поможет внедрить и раскатить процессы API Governance на всю организацию
11. Managing the API Lifecycle in an Evolving Landscape - здесь авторы пересекают pillars и 8vs и рассказывают о том, как они связаны между собой
12. Continuing the Journey - последняя глава подводит итог книге и готовит читателей к старту Continuous API Management внутри компании

P.S.
Обложки книг представлены в следующем посте.

#Architecture #Software #Governance #Management #Leadership #Processes #Leadership
2,552
Книжный куб

16 Oct, 14:08

Обзор whitepaper "API Governance at Scale" (Рубрика #Architecture)

Я дописал обзор статьи про API Governance от ребят из Google, про которую я уже несколько раз упоминал (1 и 2). В общем, статья получилась интересной и полезной - ее подходы хорошо масштабируются за границы governance именно API, например, мы многое из этого пытаемся применять в процессах architecture governance на уровне компании. В общем, читайте статью, а в следующий понедельник по ней выйдет первая серия подкаста "Research insights made simple", где я буду ее обсуждать со своим коллегой Даниилом Кулешовым.

#Architecture #Management #Governance #SystemDesign #Software #Leadership
2,253
Книжный куб

16 Oct, 05:08

Массовое вымирание стартапов: что происходит на глобал tech-рынке и как это влияет на рынок труда (Рубрика #Management)

Интересное интервью Дениса Калышкина, венчурного инвестора из фонда I2BF (инвестируют в американские стартапы) Кире Кузьменко из New HR
Обсуждение было сконцентрировано вокруг тем
— Вымирают ли стартапы или нет?
— Как инвесторы выбирают, куда инвестировать в текущей ситуации?
— Что происходит с внутренними стартапами в крупных компаниях?
— Как оценивать стартап кандидату, который хочет там работать?
— Когда будет дно кризиса и надолго ли текущий кризис с нами?
— Надо ли идти сейчас в предпринимательство вместо найма?

#Startup #Management #Leadership #Invest
2,519
Книжный куб

15 Oct, 05:00

Архитектура на старте: подготовка к успеху - Podlodka Techlead Crew (Рубрика #SRE)

Поучаствовал вчера в дискуссии на подлодке насчет проектирования надежных систем. В ней участвовали Олег Бондарь, Филипп Дельгядо и я. Мы поговорили про ключевые принципы для построения надежной архитектуры. Дискуссия была интересной и динамичной. Мы уделили много вопросам observability и я позвал всех участников на конфу T-Observability Day Tech 2024, что пройдет 23 октября в нашем московском офисе T-Space. Кстати, про конфу я уже рассказывал тут в канале

P.S.
Год назад я выступал на конференции с докладом "Проектируем надежные системы — стоит ли игра свеч", про который я уже рассказывал. И тот доклад был основан на солидном списке материалов
- "Site Reliability Engineering" - книга от ребят из Google, с которой началась серия SRE книг и они рассказывают про процесс в общем
- "Building Secure and Reliable Systems" - книга от ребят из Google, где они рассказывают про принципы проектирования надежных систем (продолжает серию SRE книг)
- "AWS Fault Isolation Boundaries" - интересный white paper от AWS на тему границ изоляции сбоев в AWS (здесь интересно написано про инфраструктурные абстракции: зоны, регионы, globl, а также про разделение control plane и data plane при проектировании сервисов и концепцию static stability)
- "A Model-based, Quality Attribute-guided Architecture Re-Design Process at Google" - интересный white paper от ребят из Google, где показано как редизайнится система для повышения ее надежности, причем сам редизайн выполняется достаточно формально, чтобы по модели оценить позитивное влияние на надежность
- "Deployment Archetypes for Cloud Applications" - интересный white paper от ребят из Google, в котором они рассказывают про разные модели deployment приложений, которые позволяют достигать разных уровней availability (зональный, региональный, мультирегиональный, глобальный, гибридный, мультиоблачный)
- Глава про resilience из книги "Continuous Architecture in Practice" - глава крутой книги, в которой буквально на пальцах авторы объясняют чем старый high-availability подход отличается от нового подхода resilience к обеспечению надежности систем
- "Philosophy of Software Design" - отличная книга про то, как бороться со сложностью систем
- "503 Подкаст - System Design в разрезе надежности" - подкаст с Андреем Дмитриевым из JUG Ru Group, где я был гостем и мы обсуждали проектирование надежных систем
- "Architecting for Scale: High Availability for Your Growing Applications" - интересная книга Lee Atchison, где он обсуждает проектирование для масштабирования и затрагивает вопросы обеспечения availability. Книга пережила второе издание и это пошло ей на пользу.
- "Собеседование SRE: Troubleshooting и System Design" - моя статья про найм SRE инженеров в Tinkoff, и про тип интервью, в котором мы проверяем на практике работу инженеров в рамках инцидента
- "Публичное интервью по troubleshooting для SRE-инженеров на конференции Devoops" - публичное интервью с разбором инцидента
- Крутой доклад "Паттерны отказоустойчивой архитектуры" ребят из Яндекса про отказоустойчивые системы

#Software #Engineering #Architecture #SoftwareArchitecture #SystemDesign #DistributedSystems #SRE
2,795
Книжный куб

14 Oct, 12:00

Code of Leadership #21 "A Philosophy of Software Design" (Рубрика #Architecture)

Этот выпуск подкаста посвящен рассмотрению крутой книги Джона Остерхута "A Philosophy of Software Design". В разборе книги  помогает Григорий Скобелев, Java/Go techlead, чей основной профиль это highload приложения, также он является директором программного комитета Podlodka Techlead/Java Crew. А в свободное время он делает свой подкаст/книжный клуб - { между скобок }, LinkedIn

В этой серии рассмотрена первая половина книги, где получилось обсудить темы
- Знакомство с гостем
- История создания книги
- Общее содержание книги
- Философия борьбы со сложностью
- Управление техническим долгом
- Подходы к управлению процессом разработки
- Эволюция и технический долг
- Подходы к приоритизации
- Продуктовый подход и оценка импакта
- Виды сложности и метрики кода
- Когнитивная нагрузка и простота кода
- Принципы обучения и решения задач
- Автоматизация и тесты
- Причины когнитивной сложности
- Исследования в Google
- Стратегическое и тактическое программирование
- Примеры из практики
- Проблемы с накоплением технического долга
- Модуляризация и интерфейсы
- Проблемы с интеграцией через базу данных
- Скрытие информации и абстракции
- Проблемы с монолитными системами
- Генерализованные и специализированные модули
- Централизованное хранилище данных
- Уровни абстракции
- Декораторы и фасады
- Эволюция кода и опыт инженеров

Продолжение обзора книги будет в следующей серии

#Architecture #Processes #Management #Leadership #Software #SystemDesign
2,916
Книжный куб

14 Oct, 05:08

Operationalize a Scalable AI With LLMOps Principles and Best Practices (Рубрика #ML)

Я уже давно заметил, что модность темы можно отследить по наличию связки somethingOps, вот дошла очередь и до LLMOps, про что рассказывается в недавней статье от DZone. Раньше уже была на хайпе темы
- DevOps - тема уже давно на хайпе (подробнее в книге "Accelerate", про которую я рассказывал), сейчас больше говорят про Platform Engineering
- DevSecOps - горячая тема, подробнее в книге "Agile Application Security", про которую я рассказывал или недавней статье "Secure by Design at Google", который я разбирал отдельно
- DataOps - давняя и актуальная тема про выстроенные процессы работы с данными. Они нужна как пререквизиты для эффективной работы над ML-моделями
- MLOps - это очень актуальная тема, которая включает набор практик, которые объединяют ML, DevOps и инженерию данных, которые направлены на создание, деплой и эксплуатацию ML систем в проде надежно и эффеективно. Интересно, что эту тему мы разбирали в выпуске подкаста "MLOps в теории и на практике"
Подробнее про XOps подходы можно посмотреть в докладе "The Pipeline-Driven Organization", про который я уже рассказывал

В этой же статье речь идет про подмножество MLOps подходов, которые сфокусированы именно на LLM приложениях, которые сейчас являются горячей темой. В приведенной ниже статье сначала приводится определение LLMOps. Дальше разбирается разница между MLOps и LLMOps по критериям на чем основной фокус, как выглядит адаптация моделей, оценка качества моделей, управление моделями, включая версионирование и метаданные, как модели деплоятся и как мониторится их работа. Дальше автор разбирает базовые характеристики LLM
- Что они существуют в разных формах: проприетарные модели с платными API, pre-training models, fine-tuned models
- Что существует так называемый prompt engineering, так как многие LLM принимают в качестве входа текст на естественном языке
- Иногда можно добавлять контекст к запросам пользователей (context-based prompt engineering:), чтобы повысить их эффективность, для чего используются новые инструменты, навроде векторных баз данных (про которые был недавно интересный доклад)
- Они достаточно большие, иногда сотни гигабайт, а также им может требоваться GPU не только для тренировок, но и для обработки real-time запросов
- Оценивать их качество достаточно сложно, поэтому часто надо встроить человеческий фидбек прямо в MLOps процесс для оценки и тестирования моделей

Ключевыми моментами приложений с LLM сейчас являются следующие моменты
- Prompt engineering, про который мы говорили выше
- RAG (retrieval augmented generation), который полагается обычно на уже упоминавшиеся векторные базы для семантического поиска, а также на feature store, где хранятся признаки.
- Fine-tuning LLMs - это процесс адаптации предварительно обученной LLM к сравнительно небольшому набору данных, специфичному для отдельной области или задачи.
- Pre-training a model from scratch - это что-то на богатом про процесс обучения языковой модели на большом массиве данных (например, тексте, коде) без использования каких-либо предварительных знаний или весов из существующей модели:)

Дальше автор показывает референсные архитектуры LLM приложений с RAG от Databrics, а финализирует плюсами и минусами LLMOps

+ Minimal changes to base model - большинство LLM приложений можно запустить поверх базовых моделей с небольшими изменениями
+ Easy to model and deploy - LLMOps как раз упрощает использование моделей
+ Advanced language models - можно начинать использовать сложные модели через API, а потом перейти open source модели
- Human feedback - в случае LLM обратная связь от людей необходима, что добавляет сложностей
- Limitations and quotas - при использовании внешних API надо понимать их ограничения и стоимость использования
- Risky and complex integration - при использовании внешних API надо понимать какими данными вы делитесь и насколько это ок

#AI #ML #Software #Architecture #Future
2,311
Книжный куб

13 Oct, 08:44

Носки врозь! (Рубрика #ForKids)

Нашим детям подарили эту книгу-детектив Матюшкиной и Оковитовой про найденный и похищенный клад. Главными героями являются лучшие в мире сыщики кот Кис-Кис и пес Фу-Фу, которые приступают к поиску улик и подозреваемых среди других животных, живущих в лесу. В общем, книга очень забавная - в лесу много животных с яркими особенностями, интрига закручивается серьезная, а на место еще одного ссыщика претендует Кролик:) Отдельно отмечу, что в книге много забавных стихов, которые нравятся детишкам.

В общем, сама книга отлично подходит для чтения на ночь дошкольникам и школьникам начальных классов. Нашим детишкам книга понравилась и мы купили еще книг этих авторов.

#ForKids #ForParents
2,523
Книжный куб

12 Oct, 05:08

ЦЕХ 4 - Урок #20 "Social media marketing (SMM). Эксперт — Олеся Полянская" (Рубрика #Writing)

Очередной урок из курса книгописания и книгоиздания от МИФ вела Олеся Полянская, руководитель команды по социальным сетям в МИФ, которая поделилась опытом и знаниями в области SMM. Мне запомнились следующие тезисы из этой лекции:

1. Соцсети могут помочь в публикации книг и повышении узнаваемости автора и его книг
2. Их можно использовать для коммуникаций с аудиторией, получения обратной связи и монетизации
3. Сейчас уже существует множество блогов и каналов, но уникальность голоса и опыта автора всегда найдет свою аудиторию
4. Для ведения своего блога нужна понятная стратегия и планомерная работа
5. Важно понимать, зачем вы будете вести блог, чтобы не забросить дело на полпути. Цель должна быть вдохновляющей и значимой, а не просто меркантильной.
6. Важно правильно выбирать платформу для публикаций: разные соцсети, мессенджеры и так далее
7. Важно формулировать ключевые идеи и формировать свой стиль, через который виден личный опыт и уникальность
8. Можно делать тематические подборки и инструкции - они работают хорошо
9. Можно использовать бесплатное и платное продвижение для своих блогов, а можно давать рекламу в своем блоге
10. Важно понимать свою аудиторию и правильно формировать контент под своих читателей
11. Можно делегировать работу по развитию своего блога, оставив на себе только создание контента
12. Нужен контентный план публикаций и их ритмичность - иначе аудитория будет отваливаться, особенно, если автор будет пропадать надолго
13. Создание публикаций требует большого количества времени - это надо понимать, решая завести свой блог
14. Надо быть готовым к токсичным комментариям
15. Переводить аудиторию между разными соцсетями достаточно сложно, поэтому стоит диверсифицировать используемые платформы

Предыдущие посты про этот курс писательского мастерства доступны здесь
1. Увидеть свое имя на обложке может каждый
2. Целевая аудитория и ее потребности в создании книги
3. Жанры и стили. Как найти тему для нон-фикшн-книги
4. Как организовать работу
5. Как преодолеть писательские блоки. Практическое занятие
6. Жду музу, а она все не приходит
7. Книга по полочкам
8. MS Word для работы с большими и сложными текстами
9. Рассказываем истории: сторителлинг в книге
10. Саморедактура: работа с текстом, сокращения, фактчекинг
11. Правила сильной книги захватывающего текста
12. Авторская стилистика
13. Как превратить рукопись в сценарий
14. Рукопись готова. Что дальше?
15. Превращение рукописи в издание
16. Авторские права и договор с издательством
17. Дизайн книги.
18. Продвижение в самиздате.
19. Продвижение автора

#SelfDevelopment #PublicSpeaking #Storytelling #Writing
2,381
Книжный куб

11 Oct, 11:29

Беслатный онлайн-курс по математике для школьников 4-6 классов от Т-Образования (Рубрика #Math)

У нас уже больше года есть бесплатные курсы по математике для школьников в средних классах. Они помогут повысить интерес к математике у детей, так как в школах редко преподают математику круто. Кроме того, эти курсы могут помочь развить мышление и подготовить школьников к новым свершениям в старших классах.
В общем, подавайте заявку и изучайте математику!

P.S.
Я сам учился в ЗФТШ (заочной физико-технической школе при МФТИ), но это было уже в 10 и 11 классе и помогло мне в свое время поступить на Физтех. Но эта штука не очень масштабировалась, а наше обучение в рамках Тинькофф Поколения сможет охватить больше направлений и помочь большему количеству школьников получить актуальные и полезные знания и навыки. В общем, я считаю, что наши программы обучения - это топчик:)

#Math #Courses #SelfDevelopment #ForKids #Science
2,526

9,421

subscribers

2,071

photos

4

videos
Best Similar Channel
Т-Инвестиции Telegram Channel
Т-Инвестиции
602,089 subscribers
@tb_invest_official
Банкста Telegram Channel
Банкста
391,075 subscribers
@banksta
Т-Банк Telegram Channel
Т-Банк
313,010 subscribers
@tbank
Антонов такой Антонов Telegram Channel
Антонов такой Антонов
252,077 subscribers
@auantonov
Минцифры России Telegram Channel
Минцифры России
244,060 subscribers
@mintsifry
Книги для программистов Telegram Channel
Книги для программистов
160,051 subscribers
@progbook
Т—Ж Telegram Channel
Т—Ж
107,008 subscribers
@t_jrnl
RationalAnswer | Павел Комаровский Telegram Channel
RationalAnswer | Павел Комаровский
101,058 subscribers
@rationalanswer
Denis Sexy IT 🤖 Telegram Channel
Denis Sexy IT 🤖
89,547 subscribers
@denissexy
Библиотека программиста | программирование, кодинг, разработка Telegram Channel
Библиотека программиста | программирование, кодинг, разработка
86,209 subscribers
@proglibrary
Random Similar Channel
Senior Software Vlogger Telegram Channel
Senior Software Vlogger
18,564 subscribers
@seniorsoftwarevlogger
Team Lead Talks Подкаст Telegram Channel
Team Lead Talks Подкаст
3,230 subscribers
@teamleadtalks_com
StringConcat - разработка без боли и сожалений Telegram Channel
StringConcat - разработка без боли и сожалений
2,608 subscribers
@stringconcat
Купер.тех Telegram Channel
Купер.тех
8,771 subscribers
@tech_kuper
DDDevotion Telegram Channel
DDDevotion
4,458 subscribers
@dddevotion
Максим Дорофеев: джедайские техники и прокрастинация Telegram Channel
Максим Дорофеев: джедайские техники и прокрастинация
19,952 subscribers
@mnogosdelal
{ между скобок } анонсы 📣 Telegram Channel
{ между скобок } анонсы 📣
4,953 subscribers
@megdu_skobok
Ваня Замесин про продукт, психологию и картину мира Telegram Channel
Ваня Замесин про продукт, психологию и картину мира
41,353 subscribers
@zamesin
Инжиниринг Данных Telegram Channel
Инжиниринг Данных
22,311 subscribers
@rockyourdata
Event Storming Telegram Channel
Event Storming
1,625 subscribers
@event_storming

2025 All Right Reserved

Disclaimer: The content displayed on this website is solely provided by the respective Telegram channels. We hold no ownership or responsibility for the content shared by these channels.