Иллюстрация результатов опроса для исследования про успешность IT проектов. В этой диаграмме 7 считается полным успехом, 5 и 6 - это выше mid-level, а ниже 5 считается неудачей.
👍5❤2🔥1
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
Интересное выступление от 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
YouTube
Observability in an Asynchronous World • James Eastham • GOTO 2024
This presentation was recorded at GOTO EDA Day Warsaw 2024. #GOTOcon #GOTOeda
https://gotopia.tech
James Eastham - Serverless Developer Advocate at Datadog @serverlessjames
RESOURCES
https://twitter.com/plantpowerjames
https://www.linkedin.com/in/james…
https://gotopia.tech
James Eastham - Serverless Developer Advocate at Datadog @serverlessjames
RESOURCES
https://twitter.com/plantpowerjames
https://www.linkedin.com/in/james…
🔥7❤4👍4
Observability in an Asynchronous World • James Eastham • GOTO 2024 - Part II (Рубрика #Architecture)
Вторая часть поста про observability в асинхронных системах как раз говорит про observability, так как в первой мы успели обсудить только асинхронность:)
11) В асинхронных системах используются стандартные подходы к observability: logs, metriics, traces. Но это инструменты для обеспечения observability
12) А автор предлагает вернуться к вопросу, а зачем нам нужна наблюдаемость в нашей системе - по его мнению это
То есть, при возникновении проблем мы сможем разобраться в этом.
13) Асинхронные системы сложны с точки зрения наблюдаемости из-за множества движущихся частей. Essential complexity домена остается на месте, а accidental complexity в асинхронной системе высока.
14) Чтобы с ней бороться нам надо правильно использовать distributed tracing. Трассировка помогает понять влияние событий на систему.
15) Асинхронная архитектура упрощает эволюцию за счет добавления новых обработчиков событий, но надо следить за тем, как эволюционирует схема событий во времени - это может приводить к интересным проблемам. В качестве примера Джеймс приводит изменение для поддержки оплаты пиццы несколькими валютами. То есть важно учитывать влияние изменений на все системы, участвующие в обработке событий.
16) Дальше автор говорит про спецификацию событыий и ррассказывает про cloud events и про event catalog. Эти подходы определяют что включать в события, что помогает с идемпотентностью при обработке и с трассировкой.
17) Дальше автор рассказывает про подход API First Design и дальше говорит о том, что события в некотором роде тоже являются API, то есть нам нужно относиться к ним с уважением. И использовать каталог событий для документирования систем, управляемых событиями.
18) Автор говорит о том, что в нашей observability системе часто важно сохранять не содержание событий, а их схему. Это позволяет задавать вопросы о системе и улучшать распределенную трассировку
19) Вообще про observability и трассировки прикольно посмотреть в докладе "What Is This OpenTelemetry Thing?", про который я недавно рассказывал
20) Отдельно автор говорит про полезные метрики по событиям: глубина очереди, количество опубликованных и обработанных сообщений, возраст сообщений. Но вообще выбор метрик зависит от контекста и целей.
21) Observability платформа позволяет находить события, анализировать их структуру, а также отслеживать распространение событий и выявлять регрессии.
22) Мне понравился вопрос автора о том, а как понять что тот или иная часть кода работает на проде. По-факту, через те же логи, трейсы и метрики.
Для тех, кто хочет посмотреть как это работает на практике, Джеймс запилил код той систеемы для пиццерии, о которой он рассказывал. При желании можно изучить как это работает с использованием в качестве observability платформы Datadog.
#SRE #Architecture #DistributedSystems #Software
Вторая часть поста про observability в асинхронных системах как раз говорит про observability, так как в первой мы успели обсудить только асинхронность:)
11) В асинхронных системах используются стандартные подходы к observability: logs, metriics, traces. Но это инструменты для обеспечения observability
12) А автор предлагает вернуться к вопросу, а зачем нам нужна наблюдаемость в нашей системе - по его мнению это
The ability to ask questions of your system, you didn't know you'd need to ask from outside your system
То есть, при возникновении проблем мы сможем разобраться в этом.
13) Асинхронные системы сложны с точки зрения наблюдаемости из-за множества движущихся частей. Essential complexity домена остается на месте, а accidental complexity в асинхронной системе высока.
14) Чтобы с ней бороться нам надо правильно использовать distributed tracing. Трассировка помогает понять влияние событий на систему.
15) Асинхронная архитектура упрощает эволюцию за счет добавления новых обработчиков событий, но надо следить за тем, как эволюционирует схема событий во времени - это может приводить к интересным проблемам. В качестве примера Джеймс приводит изменение для поддержки оплаты пиццы несколькими валютами. То есть важно учитывать влияние изменений на все системы, участвующие в обработке событий.
16) Дальше автор говорит про спецификацию событыий и ррассказывает про cloud events и про event catalog. Эти подходы определяют что включать в события, что помогает с идемпотентностью при обработке и с трассировкой.
17) Дальше автор рассказывает про подход API First Design и дальше говорит о том, что события в некотором роде тоже являются API, то есть нам нужно относиться к ним с уважением. И использовать каталог событий для документирования систем, управляемых событиями.
18) Автор говорит о том, что в нашей observability системе часто важно сохранять не содержание событий, а их схему. Это позволяет задавать вопросы о системе и улучшать распределенную трассировку
19) Вообще про observability и трассировки прикольно посмотреть в докладе "What Is This OpenTelemetry Thing?", про который я недавно рассказывал
20) Отдельно автор говорит про полезные метрики по событиям: глубина очереди, количество опубликованных и обработанных сообщений, возраст сообщений. Но вообще выбор метрик зависит от контекста и целей.
21) Observability платформа позволяет находить события, анализировать их структуру, а также отслеживать распространение событий и выявлять регрессии.
22) Мне понравился вопрос автора о том, а как понять что тот или иная часть кода работает на проде. По-факту, через те же логи, трейсы и метрики.
Для тех, кто хочет посмотреть как это работает на практике, Джеймс запилил код той систеемы для пиццерии, о которой он рассказывал. При желании можно изучить как это работает с использованием в качестве observability платформы Datadog.
#SRE #Architecture #DistributedSystems #Software
Telegram
Книжный куб
Observability in an Asynchronous World • James Eastham • GOTO 2024 - Part I (Рубрика #Architecture)
Интересное выступление от James Eastham, Serverless Developer Advocate из Datadog, на тему событийно-ориентированной архитектуры и тому, как в ней обеспечивать…
Интересное выступление от James Eastham, Serverless Developer Advocate из Datadog, на тему событийно-ориентированной архитектуры и тому, как в ней обеспечивать…
❤8👍7🔥3
Вакансия партнера по работе с данными (Рубрика #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
В Т-Банке мы привыкли принимать решения на основе данных, а данных от 46+ млн клиентов и целой экосистемы продуктов у нас очень много. Для того, чтобы использовать более эффективно мы переносим ответственность за данные с централизованной дата платформы в сами домены. Мы считаем, что это позволит эффективнее работать с данными в каждом из направлений, за счет синка с продактами, аналитиками, разработчиками приложений. По-факту, в моей домен входят
- Клиентские интерфейсы: платформенные команды веба, мобилы и API
- Маркетинговые технологии: внешняя реклама, маркетинговая платформа
- Соц-медиа платформы: социальные сети, медиаплатформа, медиапроекты (ТЖ, Бизнес-секреты), игры
- Цифровые экосистемы: аутентификация/авторизация, биометрия, главная страница приложения, финздоровье
- Продуктовая аналитика и a/b платформа
В итоге, я ищу к себе человека, который поможет мне составить стратегию по работе с данными внутри этих доменов так, чтобы мы как компания получили дополнительный value. А дальше этот партнер по данным будет помогать реализовывать эту стратегию силами команд разработки внутри моего домена, используя инструменты дата платформы, которая сейчас уходит от стандартного DWH подхода в сторону data lake и lake house. Например, в этому году мы уже перенесли ответственность за отгрузку данных на сторону команд разработки, а также реализовали в новых инструментах (streaming data platform) возможность задавать контракты данных. Если выкинуть за скобки старые интеграции через базу (
Если приземляться на грешную землю, то успешному кандидату придется
- Выстраивать стратегию работы с данными, управления ими и эксплуатации в контексте домена
- Отвечать за 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
🔥17👍5❤3
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
Прочитал на этой неделе книгу Ким Скотт про радикальную прямоту, которая рассказывает об управлении людьми посредством честного и прямого общения. Автор представляет концепцию, которая является основой для предоставления обратной связи, сочетающей личную заботу о людях с прямым вызовом и жесткими требованиями. Этот подход направлен на улучшение коммуникации, построение доверия и повышение эффективности команды. Книга состоит из двух частей и восьми глав
Часть I - Новая философия менеджмента
1. Выстраивание радикально откровенных отношений. В этой главе описывается основная идея книги - важность сочетания личной заботы о сотрудниках с прямым вызовом. Автор объясняет, как это помогает улучшать рабочие отношения и повышать производительность команды.
2. Получать, отдавать и помогать. Эта глава посвящена методам установления доверительных отношений в команде, что является основой для успешного применения радикальной откровенности. Для этого автор описывает модель, которая визуализируется как двухмерный график. На графике вертикальная ось представляет "Личную заботу", а горизонтальная ось - "Прямой вызов". Цель состоит в том, чтобы работать в квадранте, где оба элемента высоки, создавая среду открытой и конструктивной обратной связи. Это и есть квадрант радикальной откровенности, а также есть разрушительное сочувствие, оскорбительная агрессивность и манипулятивная неискренность.
3. Что мотивирует каждого члена вашей команды. Здесь автор приводит свою модель суперзвезд и надежных сотрудников: фактически есть "суперзвезды", которые находятся на крутой траектории роста, и "надежные сотрудникы", которые предпочитают стабильность и устойчивую производительность. Признание этих различий помогает эффективно управлять ростом команды.
4. Добиться успеха вместе. В этой главе автор рассказывает про свою модель работы с людьми в команде "Выслушать" - "Объяснить" - "Обсудить" - "Решить" - "Убедить" - "Выполнить" - "Усвоить" и дальше опять "Выслушать". На протяжении всей главы автор рассказывает как должен работать этот цикл в компании.
Часть 2 - Инструменты и техники
5. Взаимоотношения. Эта глава посвящена построению и поддержанию эффективных отношений в команде. Автор подчеркивает важность доверия и открытого общения между коллегами. Она предлагает стратегии для улучшения взаимодействия, чтобы создать более сплоченную и продуктивную рабочую среду.
6. Наставничество. В этой главе рассматривается роль наставничества в развитии сотрудников. Автор объясняет, как руководители могут эффективно наставлять своих подчиненных, помогая им расти и развиваться в профессиональном плане. Она делится методами, которые позволяют вдохновлять и мотивировать сотрудников через личный пример и поддержку.
7. Команда. Глава фокусируется на создании эффективных команд. Автор обсуждает, как собрать команду, которая будет работать слаженно и продуктивно, а также как управлять различиями в характерах и навыках сотрудников. Автор подчеркивает важность разнообразия и инклюзивности для достижения лучших результатов.
8. Результаты. Заключительная глава посвящена достижению результатов через применение принципов радикальной откровенности. Автор делится инструментами и техниками, которые помогают руководителям не только устанавливать высокие стандарты, но и достигать их вместе с командой. Она акцентирует внимание на том, как измерять успех и корректировать подходы для постоянного улучшения.
Интересные факты о книге
- Ким Скотт активно использует свой опыт работы руководителем в bigtech компаниях, таких как Google и Apple.
- Она подчеркивает необходимость адаптации радикальной откровенности к различным культурным контекстам, чему она научилась в процессе работы с разнообразными командами по всему миру
- Книга не только теоретическая - она включает практические инструменты, такие как сценарии для сложных разговоров и основы для эффективных встреч.
#Engineering #Management #Leadership #Processes #SystemDesign #SystemThinking #SystemEngineering
🔥12👍6❤4😱1
Обложки для книг "Radical Candor: Be a Kick-Ass Boss Without Losing Your Humanity" и "Радикальная прямота"
🔥11❤4👍3
ЦЕХ 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
В очередном уроке разбирался пример личного продвижения автора. О своем пути рассказывала Лариса Парфентьева. Основные моменты, что я вынес из урока такие
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
Telegram
Книжный куб
ЦЕХ 4 - Урок #1 "Увидеть свое имя на обложке может каждый"
На прошлой неделе прошел первый вводный урок курса для начинающих авторов, что планируют написать и издать книгу:) Этот урок напоминал самосбывающее пророчество, которое должно было вдохновить участников…
На прошлой неделе прошел первый вводный урок курса для начинающих авторов, что планируют написать и издать книгу:) Этот урок напоминал самосбывающее пророчество, которое должно было вдохновить участников…
👍6❤4🔥3
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
Очередной выпуск подкаста с разбором 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
YouTube
Research Insights Made Simple #5 "DORA Metrics, SPACE, DevEx, Human Approach to Dev Productivity"
Очередной выпуск подкаста с разбором whitepapers посвящен разбору темы developer productivity, где мы говорим про DORA метрики, фреймворк SPACE, подход DevEx, а также про human approach от Google к теме developer productivity. Для обсуждения этих тем ко…
🔥6👍4❤3
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
Я наконец-то закончил этот курс с 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
❤27👍19🔥6⚡5
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
Я продолжаю рассказ про крутой курс с 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
Telegram
Книжный куб
System Design for Interviews and Beyond - Курс на Leetcode - Part I (Рубрика #Architecture)
Я наконец-то закончил этот курс с Leetcode, в котором доступно и понятно рассказывали о том, что такое system design interview и что он призван проверять у кандидатов.…
Я наконец-то закончил этот курс с Leetcode, в котором доступно и понятно рассказывали о том, что такое system design interview и что он призван проверять у кандидатов.…
🔥21👍10❤3
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
Заканчивая разбор курса о 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
👍10❤5🔥2👎1
System Design Interview by Groks King (Рубрика #Architecture)
На выходных прочитал очередную книгу по system design, которую как-то прикупил с Амазон еще пару лет назад. Меня часто упрекают, что я слишком добро обозреваю книги, но обычно я пытаюсь вытянуть из книг лучшее, но с этой книгой это сложно - в этой книге про system design
- Очень кратко даются теоретические основы и как-то обраывками, из которых не собирается общая картинка
- Нет ни одной схемы - автор предпочитает все описывать словами, поэтому формат взаимодействия компонентов между собой приходится наполовину угадывать
- Разборы практических задач состоят из отдельных частей, которые не всегда собираются в единое целое - например, в задачке про web crawling концовка посвщена защите робота от ловушек для спкам ботов, но рассказ не бьется с предыдущими частями
- В задачках бывают отсылки к векторным часам, CAP и PACELC, моделям консистентности, репликации, но ничего из этого автор не удосуживается не то, чтобы объяснить, а даже расшифровать:)
В общем, книга ужасна для тех, кто хочет подготовиться к интервью. А вот мне было интересно почитать и попробовать сложить из этой россыпи букв что-то осмысленное. Если бы книга не вышла в 2021 году, то я решил бы, что ее написал chatGPT первого поколения:)
P.S.
Если понравился формат и хочется еще отзывов с прожаркой книг, то напишите в комментах и поделитесь своими историями о книгах, что вас разочаровали:)
#Software #Architecture #DistributedSystems #SystemDesign #Engineering
На выходных прочитал очередную книгу по system design, которую как-то прикупил с Амазон еще пару лет назад. Меня часто упрекают, что я слишком добро обозреваю книги, но обычно я пытаюсь вытянуть из книг лучшее, но с этой книгой это сложно - в этой книге про system design
- Очень кратко даются теоретические основы и как-то обраывками, из которых не собирается общая картинка
- Нет ни одной схемы - автор предпочитает все описывать словами, поэтому формат взаимодействия компонентов между собой приходится наполовину угадывать
- Разборы практических задач состоят из отдельных частей, которые не всегда собираются в единое целое - например, в задачке про web crawling концовка посвщена защите робота от ловушек для спкам ботов, но рассказ не бьется с предыдущими частями
- В задачках бывают отсылки к векторным часам, CAP и PACELC, моделям консистентности, репликации, но ничего из этого автор не удосуживается не то, чтобы объяснить, а даже расшифровать:)
В общем, книга ужасна для тех, кто хочет подготовиться к интервью. А вот мне было интересно почитать и попробовать сложить из этой россыпи букв что-то осмысленное. Если бы книга не вышла в 2021 году, то я решил бы, что ее написал chatGPT первого поколения:)
P.S.
Если понравился формат и хочется еще отзывов с прожаркой книг, то напишите в комментах и поделитесь своими историями о книгах, что вас разочаровали:)
#Software #Architecture #DistributedSystems #SystemDesign #Engineering
👍26🔥14❤8😁2
Про 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
Сегодня я на конференции 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
www.piter.com
System Design. Подготовка к сложному интервью
Инсайдерская информация: что на самом деле нужно интервьюерам по System Design, 4-х шаговый подход к решению любой задачи, 16 вопросов из реальных интервью с подробными решениями, 188 диаграмм, наглядно объясняющих, как работают реальные системы
👍16❤7🔥6
Duolingo (Рубрика #SelfDevelopment)
Последние пару лет я ежедневно занимаюсь с этой зеленой совой. Когда-то я тренировал не только английский язык, но сейчас остался только он. Не факт, что duolingo помогает мне со всеми навыками английского языка, но как минимум он помогает мне со словарным запасом и их произношением, а также не дает забыть грамматику. Плюс, я могу заниматься в любой удобный для меня слот и зачастую короткими интервалами по 15 минут:)
#SelfDevelopment
Последние пару лет я ежедневно занимаюсь с этой зеленой совой. Когда-то я тренировал не только английский язык, но сейчас остался только он. Не факт, что duolingo помогает мне со всеми навыками английского языка, но как минимум он помогает мне со словарным запасом и их произношением, а также не дает забыть грамматику. Плюс, я могу заниматься в любой удобный для меня слот и зачастую короткими интервалами по 15 минут:)
#SelfDevelopment
👍23🔥18🤝7
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
Интересное интервью Дэниела Терхорст-Норта, которое он дал Джулиану Вуду в рамках конференции 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
1❤7👍4🔥1
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
В этом эпизоде подкаста я беру интервью у Константина Евтеева. Костя - директор департамента ИТ сервисов, поддержки и инфраструктуры 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
YouTube
Code of Leadership #24 - Interview with Konstantin Evteev
В этом эпизоде подкаста я беру интервью у Константина Евтеева. Костя - директор департамента ИТ сервисов, поддержки и инфраструктуры X5 Digital. В настоящий момент отвечает за инфраструктуру и развитие платформ для разработчиков. Прошел путь развития стартапа…
🔥11❤4👍4
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
Интересное выступление Дэниела Терхорст-Норта (презентация тоже доступна), в котором он поделился своими наблюдениями о том, что делает хорошего программиста отличным. Фактически он разбил все наблюдения на три категории
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
YouTube
The Best Programmer I Know • Daniel Terhorst-North • GOTO 2024
This presentation was recorded at GOTO Amsterdam 2024. #GOTOcon #GOTOams
https://gotoams.nl
Daniel Terhorst-North - Originator of Behavior Driven Development (BDD) & Principal at Dan North & Associates @daniel-terhorst-north
RESOURCES
https://bsky.app…
https://gotoams.nl
Daniel Terhorst-North - Originator of Behavior Driven Development (BDD) & Principal at Dan North & Associates @daniel-terhorst-north
RESOURCES
https://bsky.app…
❤18🔥8👍6🤔1
Откуда я беру интересные 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
Я люблю изучать научные статьи и уделяю этому много времени. Меня часто спрашивают где я их нахожу и я постоянно отвечают, что самые интересные статьи есть на сайтах 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
👍19❤9🔥5