Книжный куб

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

Архитектурные материалы для изучения от облачных провайдеров (Рубрика #Architecture) Как-то раньше я не писал о том, что помимо книг есть большое количество архитектурных материалов у главной тройки cloud провайдеров. 1) У AWS это называется AWS Well-Architected Framework, у него 6 ключевых столпов - Operational excellence (операционная эффективность): Фокус на управлении и мониторинге систем для обеспечения бизнес-ценности и постоянного улучшения процессов. - Security (безопасность): Защита информации и систем с помощью надежного управления идентификацией, защиты данных и обнаружения инцидентов. - Reliability (надежность): Обеспечение того, что рабочие нагрузки выполняются в соответствии с ожиданиями и быстро восстанавливаются после сбоев. - Performance efficiency (эффективность): Оптимальное использование ресурсов для удовлетворения требований системы. - Cost optimization (оптимизация затрат): Помощь в отсутствии ненужных расходов при сохранении производительности. - Sustainability (устойчивость): Фокус на минимизации воздействия на окружающую среду за счет оптимизации энергопотребления. 2) У Microsoft это называется Azure Well-Architected Framework. Он имеет схожие цели и структуру с AWS фреймворком, в нем даже то же самое название, но столпов всего 5 (выпала часть про sustainability) - Cost optimization (оптимизация затрат): Максимизация ценности при минимизации расходов. - Operational excellence (операционная эффективность): Эффективное управление операциями и автоматизация процессов. - Performance efficiency (эффективность): Обеспечение производительности и масштабируемости приложений. - Reliability (надежность): Построение отказоустойчивых архитектур, способных восстанавливаться после сбоев. - Security (безопасность): Защита данных и систем через надежные методы безопасности. 3) У Google это называется Cloud Architecture Framework. Он имеет немного другую структуру, но также фокусируется на ключевых принципах построения облачных решений. У него пять столпов: - Operational excellence (операционная эффективность): Эффективное развертывание, эксплуатация, мониторинг и управление рабочими нагрузками. - Security, privacy, and compliance (Безопасность, конфиденциальность и соответствие требованиям): Обеспечение безопасности данных, их конфиденциальности и соблюдения нормативных требований. - Reliability (надежность): Построение отказоустойчивых систем, способных выдерживать сбои. - Cost optimization (оптимизация затрат): Максимизация бизнес-ценности за счет оптимизации использования ресурсов. - Performance optimization (оптимизация производительности): Настройка ресурсов для достижения оптимальной производительности. Из этого краткого описания фреймворков видно, что у них похожие фокусы на оптимизацию затрат, безопасность, оптимизацию производительности, надежность. В общем, на вопросы, которые важны для клиентов, что планируют заезжать в облака (но важны также и при разворачивании on-prem). Эти фреймворки направлены на то, чтобы помочь организациям постоянно оценивать и улучшать свои облачные архитектуры на основе лучших практик, предоставляемых соответствующими облачными провайдерами. Хотя конкретные детали реализации могут различаться между провайдерами, основные принципы остаются схожими на всех платформах. Кстати, часть научных статей ребят превращаются в мануалы внутри этих фреймворков. Например, раздел "Deployment archetypes" из документации Google изложен в научной статье "Deployment Archetypes for Cloud Applications", которую я разбирал больше года назад в своем блоге. #DistributedSystems #ExternalReview #SoftwareDevelopment #SoftwareArchitecture #Architecture #SystemDesign #SystemEngineering #Cloud

Корпоративный мессенджер Time Около полугода назад я уже рассказывал про наш корпоративный мессенджер Time, на который мы оперативно переехали, когда Slack отказался работать с русскими компаниями. За эти пару лет само решение прошло испытание огнем, водой и медными трубами и показало то, что этот мессенджер можно использовать для общения в компании с десятками тысяч сотрудников. Также поверх него можно строить бизнес-процессы и автоматизации (аля chat-ops). Какое-то время назад мы начали продавать это решение разным заказчикам сначала в on-prem варианте, а за последние полгода добавился SaaS вариант, а также mvp для видео-конференц связи. С учетом такого большого количества изменений коллеги решили провести вебинар с продактом и парой клиентов (Атом и Юрент), чтобы рассказать про плюсы и минусы продукта, а также поделится опытом переезда в Time и тем, как они выбирали из доступных на рынке решений. В общем, если для вас актуален выбор, то регистрируйтесь на этот вебинар и дальше не стесняйтесь задавать вопросы. P.S. Кстати, сайт сильно обновился и стал содержать больше полезной информации навроде базового описания стека решений и интеграций - Time - это cloud-native решение, которое у нас развернуто в наших целевых runtime окружениях (kubernetes кластерах) - TIme можно развернуть в геораспределенном режиме (у нас, например, он развернут на 2 геораспределенных дата центра) - Под капотом используются стандартные стек: Postgres, Kafka, Redis, Open search / Elastic search - Есть разные виды авторизаций (SAML, AD/LDAP, openID) - Есть возможность мигрировать с других мессенджеров (Slack, MM, RocketChat) А также есть чиселки для технарей про один из наших инстансов Time - 45 тысяч пользователей на инстансе в день - 2 миллиона cообщений в день - 80 тыс пользователей - 5,4 миллиона диалогов создали пользователи - 186 тысяч каналов создано этими пользователями - более 1200 ботов создано пользователями благодаря удобной документации - 99,9% - SLA на доступность #Software

Экскурсия по стадиону ЦСКА Были сегодня на часовой экскурсии по стадиону и она нам понравилась: - На экскурсию пришло человек 30-40, половина из них детей - Экскурсовод был с хорошим чувством юмора и не просто рассказывал истории, но и делился анекдотами и байками - Мы прошли через вход, куда заходят футболисты, дошли до раздевалки, прошли к выходу на поле и походили около скамеек команд, сделав ряд снимков, а дальше прошли в комнату для пресс-конференций каа обычно и бывает после окончания матчей В общем, мы смогли посмотреть те места, куда обычно болельщикам не попасть во время матчей ... и нам все понравилось #Family #ForKids

ЦЕХ 4 - Урок #21 "Ведение блога и его продвижение в Телеграме. Эксперт — Олеся Полянская" (Рубрика #Writing) Очередной урок из курса книгописания и книгоиздания от МИФ вела Олеся Полянская, руководитель команды по социальным сетям в МИФ, которая поделилась опытом и знаниями в области ведения блога в telegram. Интересно было послушать этот урок и сравнить со своим опытом:) Мне запомнились следующие тезисы из этой лекции: 1) Telegram по разному используют люди разных возрастов - молодые люди больше общаются, а люди постарше читают каналы 2) После бана части других соцсетей пользователей в tg в последнее стало больше 3) Часть каналов в tg фокусируются на новостях, а другие говорят про "вечные темы" 4) Часто важна не сама информация, а ее интерпретация автором канала, у которого есть свой голос и мнение 5) В tg не очень много алгоритмов, которые рекомендуют контент - это отличает tg от других соцсетей. Поэтому авторам важно сарафанное радио и/или стратегия промотирования через рекламу 6) Важно понимать зачем создаешь канал, какая у него будет аудитория и сколько времени получится на него уделять 7) Логотип канала очень важен, также важны контакты автора, а также способ форматирования текста для его удоства 😍 Теперь есть истории и видео-кружочки, их надо использовать с умом, учитывая ожидания аудитории. В tg также можно вести прямые эфиры 9) Важно писать о том, что интересно автору, а также писать регулярно, чтобы поддерживать доверие и интерес аудитории 10) Каналы в tg можно монетизировать через рекламу в них, но скорее всего и самому придется потратиться на рекламу канала 11) Зарабатывать можно не только на рекламе, но и на консультациях, продаже своих книг и всему остальному - популярный канал поможет этому Предыдущие посты про этот курс писательского мастерства доступны здесь 1. Увидеть свое имя на обложке может каждый 2. Целевая аудитория и ее потребности в создании книги 3. Жанры и стили. Как найти тему для нон-фикшн-книги 4. Как организовать работу 5. Как преодолеть писательские блоки. Практическое занятие 6. Жду музу, а она все не приходит 7. Книга по полочкам 8. MS Word для работы с большими и сложными текстами 9. Рассказываем истории: сторителлинг в книге 10. Саморедактура: работа с текстом, сокращения, фактчекинг 11. Правила сильной книги захватывающего текста 12. Авторская стилистика 13. Как превратить рукопись в сценарий 14. Рукопись готова. Что дальше? 15. Превращение рукописи в издание 16. Авторские права и договор с издательством 17. Дизайн книги. 18. Продвижение в самиздате. 19. Продвижение автора 20. Social media marketing (SMM) #SelfDevelopment #PublicSpeaking #Storytelling #Writing

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

The Engineering Executive's Primer - Part III (Рубрика #Management) Продолжая первые посты об этой крутой книге (0, 1, 2) с обзором книги, я хотел бы рассказать про следующие главы. 7) Participating in Mergers and Acquisitions В этой главе автор говорит про участие ИТ топ-менеджеров в merge & acquisitions процессах. Для начала автор разбирает про сложные мотивы для m&a действий - условно цели команды, что ведет сделки, отличаются от целей инженерных команд. В общем, важен общий взгляд на процесс и понимание бизнес-стратегии, чтобы оценить соответствует ли поглощение целям компании и выявить потенциальные риски. Отдельно автор описывает структурированный подход к оценке поглощений с инженерной точки зрения, куда входит создание шаблонов для оценки сложности внедрения, проблем интеграции, масштабируемости, безопасности, соответствия требованиям, затрат и инженерной культуры. Важно также запланировать интеграции между объединяемыми компаниями - важен четкий план интеграции для эффективного управления переходом после поглощения. Это включает решения по интеграции технологий, реструктуризации команд и роли лидерства. А дальше надо управлять этим процессом. 😍 Developing Leadership Styles Автор предлагает модель из трех подходов к управлению - Leading with policy - для повторяемых решений, которы надо делать консистентно разными людьми внутри организации - Leading from consensus - для нечастых решений с контекстом, который распределен между несколькими заинтересованными сторонами. - Leading with conviction - для решений без четкого предложения, когда вовлеченные лица сильно расходятся во мнениях или когда решение оказывает значительное долгосрочное влияние на вашу организацию В этой главе автор приводит примеры из своего опыта в разных компаниях (Digg, Uber, Stripe, Calm). А дальше говорит о том, что надо уметь работать над прокачкой тех стилей лидерства, что несвойственны вам. Это позволит вам стать более универсальным руководителем:) 9) Managing Your Priorities and Energy В этой главе автор рассказывает про свою стратегию к решению задач вида "Компания - Команда - Я". Изначально автор рекомендовал принимать решения, основываясь на иерархии: сначала компания, затем команда, и в последнюю очередь — личные интересы. Этот подход использовался для обеспечения соответствия решений целям компании, а не личным или командным предпочтениям. Однако позже автор осознал, что такая жесткая структура может привести к выгоранию и потере мотивации среди сотрудников. Но дальше автор подчеркивается важность управления энергией как процесса с положительной суммой. Предполагается, что предоставление людям возможности заниматься работой, которая их вдохновляет, даже если она не соответствует непосредственным приоритетам, может повысить общую продуктивность и удовлетворенность работой. В итоге, концепт "Company, Team, Self" изменяется на подход "Eventual Quid Pro Quo", которая балансирует приоритеты компании с личными потребностями в энергии. Этот подход поощряет приоритизацию вдохновляющей работы при необходимости для поддержания долгосрочной вовлеченности и эффективности. Автор подчеркивает необходимость гибкости в применении стратегий. Утверждается, что хотя следование правильным приоритетам важно, это не должно происходить за счет личной энергии и мотивации. Лидеры должны адаптировать свои подходы в зависимости от личных нужд и контекста их ролей. Продолжение будет в следующем посте. #Engineering #Management #Leadership #Processes #SystemDesign #SystemThinking #SystemEngineering

Кем может стать системный аналитик - подкаст InSAйт (Рубрика #Career) Недавно сходил в гости к своим коллегам на подкаст InSAйт, который ведут Павел Каравашкин, руководитель группы разработки T-API, и Есения Киселева, старший системный аналитик, управление разработки продуктов эквайринга в Т-Банке. Темой разговора было карьерное развитие системных аналитиков, о котором я когда-то размышлял на конференции Flow. В итоге, мы обсудили темы - Почему я когда-то не захотел быть системным аналитиком, а Паша – системным архитектором; - Можно ли одновременно сохранять фокус на менеджерских и технических скиллах; - Кем может стать системный аналитик и какие навыки ему важно качать; - Что такое white paper и чем этот формат может быть полезнее книг; - Как сделать доменные области более понятными для разработчика. У этого подкаста есть свой канал в tg (@insight_t_bank), подписавшись на который можно узнавать о новых выпусках. #Analyst #SoftwareDevelopment #Career #Podcast #SystemDesign #SystemThinking

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

Масштабирование комплаенс-контроля надежности на сотни сервисов - Салих Фахрутдинов, Т-Банк Интересный доклад моего коллеги, Салиха, который Staff SRE инженер в Origination Business Platform. В этом докладе Салих рассказал о том, как можно обеспечивать надежность сотен разных сервисов за счет контроля инвариантов, который реализован через стороннее приложение. В этом приложении настраиваются различные правила для проверок, например, использование разных портов для проб (liveness, readiness, startup), настроек java приложений (падение от OOM), параметров СУБД, наличие алертов на критические SLA и так далее. Дальше эти правила можно пополнять реактивно (после инцидентов) или проактивно по результатам исследований на улучшение надежности приложений. Само это приложение собирает информацию о соблюдении правил и позволяет сформировать отчет в виде leaderboard. Те руководители, чьи сервисы оказываются внизу лидерборда, обычно имеют нехилую мотивацию на устранение найденных проблем. В принципе, другой вариант реализации этой логики проверок - это реализация внутри пайплайна поставки, примерно так работает наш Quality Gate, который проверяет уровень автоматизации тестирования. Но ребята решили пойти другим путем, чтобы иметь возможность проверить проиложения не только перед деплоем или вовремя деплоя, но и дальше по мере их работы в продакшене. P.S. В software architecture такие проверки предлагается делать через fitness functions, которые предлагались в книге "Building evolutionary architecture". Вот эпизод подкаста "Code of Architecture", в котором мы говорили об этом концепте. #Architecture #Management #Leadership #SRE #Engineering #Software

Research Insights Made Simple #3 - Обсуждение paper "Security by Design at Google" (Рубрика #Security) В третьем эпизоде подкаста мы обсуждаем интересный whitepaper "Secure by Design at Google" от Chirstoph Kern на тему security с человеческим лицом от Google, где рассказывалось о том, как создавать безопасный софт на большом масштабе. В разборе мне помогает крутой гость - Артем Мерец, мой коллега. Артем был разработчиком и 10 лет назад перешел в информационную безопасность. Он активно строил AppSec, когда он начал зарождаться в РФ как стрим, а затем увлекся атаками и несколько лет ломал инфраструктуру и приложения разных компаний в РФ и за пределами. И с 2021 помогаю выстраивать защиту Т-Банка в роли архитектора. Сама научная статья доступна на сайте Google, а в моем блоге есть разбор В этом выпуске мы обсудили следующие темы - Общие впечатления от статьи - Логические уязвимости и подходы Google - Сложности безопасной разработки - Концепция Security by Design - Примеры безопасности из автомобильной индустрии - Проблемы аудита кода - Принципы безопасного дизайна - Проблемы с инвариантами - Автоматизация и категоризация инвариантов - Применение инвариантов - Проблемы безопасности в системах - Примеры защиты от злонамеренных действий - Дизайн для безопасности - Shift left everything в разработке - Проблемы и решения в безопасности - Проект Yaga в Т-Банке - Логические уязвимости - Безопасная экосистема разработки - Проблемы с памятью и микросервисной архитектурой - Проблемы с безопасностью и инфраструктурой - История о стажере-саботажнике в ByteDance - Контроль артефактов и безопасность - Экосистема для разработчиков #Architecture #Security #CI #CD #Devops #Software #Management #Leadership #Engineering #Podcast

Обзор paper "Build Latency, Predictability, and Developer Productivity" (Рубрика #Management) Я продолжаю читать и писать о статьях из серии developer productivity от исследователей из Google. В четвертом whitepaper с заголовком "Build Latency, Predictability, and Developer Productivity" речь идет про скорость сборок и как она влияет на продуктивность разработчиков (вот мой обзор). Эта связь кажется довольно очевидной, но авторы находят очень элегантный способ для измерений. Вообще, авторы в своей статье дают ответ на следующие вопрос

- How fast do builds need to be for developers to stay productive? - Are there changes we can make to build systems besides just “make builds faster” to improve productivity? - And how much of a productivity improvement can we reasonably expect by improving build latency, anyway?

P.S. Вот список статей из этой колонки "Developer Productivity for Humans", большую половину из которых я уже разобрал раньше 1) A Human-Centered Approach to Developer Productivity - разбор у меня в блоге 2) Hybrid Productivity - разбор у меня я в блоге 3) Defining, Measuring, and Managing Technical Debt - разбор у меня в блоге 4) Build Latency, Predictability, and Developer Productivity - это сегоднящняя статья 5) Onboarding and Ramp-Up 6) Measuring Flow, Focus, and Friction for Developers 7) Software Quality - разбор у меня в блоге 😍 Creativity in Software Engineering #Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes

Обложки книг "Ухожу в Stand Up!" и "Mastering Stand-Up"

Ухожу в Stand Up! (Mastering Stand-Up) (Рубрика #Humor) Это не утверждение, а название очередной книги, которую я дочитал буквально этой ночью. Книга попала ко мне интересным образом - пару месяцев назад меня позвали выступить на внутреннее мероприятие на всю компанию в формате стендапа. Я немного подумал над темами и выбрал одну из двух, про которые я обычно рассказываю - это была тема "Архитектуры", потому что про менеджмент шутили два других спикера. Как обычно, когда я сталкиваюсь с новой темой, то покупаю книги по ней - кажется, что еще с детства у меня пошла история о том, что получение книги == получению знаний из книги. В итоге, выступление на стендап я подготовил, но книгу прочитать не успел. Хорошо, что я заявился с этой же темой "Архитектура в Т-Банке: вчера, сегодня, завтра" на ArchDays и взял книгу в проработку. На прошлой неделе я рассказал этот доклад, а ночью дочитал последние страницы книги. Конечно, конференция по архитектуре - это не стендап-шоу, поэтому пришлось разбавлять шутки занудной теорией до гомеопатического состояния, но часть пользователей в отзывах к докладу отметила чувство юмора (ладно, это заметил один человек). Если говорить о самой книге, то ее написал Стивен Розенфилд, основатель Американской школы комедии, который поставил обучение комиков на поток и в этой трехсотстраничной книге поделился своими рецептами становления хорошим стендапером. В книге 5 частей 1) Начинаем сотрудничать - в этой части автор подбадривает читателя и рассказывает о пути, который ему предстоит пройти, чтобы стать успешным: выясни в чем, твоя оригинальность, научись писать тексты для стендапа, отточи мастерство выступлений, придумай сценического персонажа, постоянно выступай и так далее 2) Виды стендап-комедии - здесь автор перечисляет виды, показывает примеры и объясняет разницу между ними. Например, он говорит о комедии наблюдений, сторителлинге, стендап-скетчах, акт-аутах, унижениях знаменитостей или людей из своего окружения, самоиронию, юмор на грани фола и так далее 3) Руководство по созданию материала для стендап-комедии - здесь автор рассказывает что делать до того как сесть за черновик, дальше как работать с черновиком, как обкатывать материал из него, как дорабатывать шутки формата сетап - панчлайн через фидбек аудитории на выступлениях (тут используется принцип working backwards для шлифовки и усиления шуток) 4) Руководство по выступлению со стендап-комедией - автор описывает что делать с волнением перед выступлением, как вести себя на сцене, как уложиться в регламент и что делать если шутка не зашла:) 5) Как добиваться непревзойденного мастерства - здесь автор рассказывает про классификацию шуток "A", "B", "C" и описывает как составить сет из шуток класса "А". Как создать удачный сценический образ, который должен быть оригинальным, правдоподобным, ярким, вызывать симпатию, иметь сценическое обаяние и смешную суть. Прикольно, что автор дает список причин почему шутка, которая раньше разрывала зал, стала уходить в тишину - а дальше он дает рекомендации как это можно исправить. Финалит последнюю часть автор рассказом про то, как быть ведущим и как победить свой внутренний голос, который мешает достигать своих целей (в данном случае быть смешным). В общем, книга мне показалось интересной и полезной, даже с учетом того, что я не ухожу в StandUp! #Humor #PublicSpeaking #Leadership #SelfDevelopment

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

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

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

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

CPU, Memory Models, Concurrency, Multiprocess, Multithreading и Async (Рубрика #ComputerScience) Я часто рассказываю про то, что надо знать базу для того, чтобы развиваться в software engineering. Но обычно сложно описать, а что же входит в это определение "база" и является джентельменским набором хорошего инженера. Но тут мой коллега, Женя Козлов, крутой инженер написал серию статей про процессоры, модели памяти, многозадачность и конкурентность. В этой серии разбираются моменты, которые полезны инженерам, что делают высоконагруженные системы, которые плотно работают с данными. Собственно, сам Женя у нас лидит команду, что занимается Statist - это наша система продуктовой аналитики, которая давно заменила нам Amplitude и по всем характеристикам тянет на data intensive application. В общем, я очень рекомендую вам эту серию статей от Жени, если вам интересно понять как компьютер обрабатывает под капотом те программы, что вы пишите на своем любимом языке программирования. 1) Начальный пост про многозадачность в OS 2) Про развитие процессоров и взаимодействие OS с ними 3) Про Hyper Threading 4) Процессы. Начало 5) Процессы в Linux 6) Потоки. Начало 7) Потоки в Linux 😍 Модели ввода-вывода. Универсальная(блокирующая) модель ввода-вывода 9) Multiplexed IO 10) Asynchronous IO #Software #ComputerScience #Engineering #SRE #Architecture

What Is Your Definition of Software Architecture (Рубрика #Architecture) Пока готовился к своему выступлению на ArchDays в пятницу, наткнулся на paper почти 15-летней давности от Software Engineering Institute с названием "What Is Your Definition of Software Architecture". В нем авторы сделали подборку определений архитектуры программного обеспечения с начала времен по 2010 год. Среди определений встречаются примечательные

1) Из книги "Documenting Software Architectures: Views and Beyond (2nd Edition)", Clements et al, AddisonWesley, 2010: The set of structures needed to reason about the system, which comprises software elements, relations among them, and properties of both. 2) Из книги " Software Architecture in Practice (2nd edition)", Bass, Clements, Kazman; AddisonWesley 2003, которую я перечитывал пару раз The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them. 3) Из стандарта ANSI/IEEE Std 1471-2000, Recommended Practice for Architectural Description of Software Intensive Systems Architecture is defined by the recommended practice as the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution. 4) Из RUP (Rational Unified Process) An architecture is the set of significant decisions about the organization of a software system, the selection of the structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaborations among those elements, the composition of these structural and behavioral elements into progressively larger subsystems, and the architectural style that guides this organization---these elements and their interfaces, their collaborations, and their composition

В итоге, можно выделить следующие взгляды на программную архитектуру - Высокоуровневая структура - организация системы, структурных элементов и их интерфейсов. Фокус на взаимодействии элементов - Абстракция и композиция - архитектура представляет собой абстракцию, что скрывает реализацию. Такие абстракции позволяют проще думать о взаимодействиях компонентов. Эта тема была отлично раскрыта John Osterhout в книге "A Philosophy of Software Design", что я рассматривалась в 21 выпуске подкаста "Code of Leadership" - Набор структур - этот набор позволяют комплексно размышлять о программной системе, в этот набор обычно включают элементы, их взаимосвязи и свойства - Руководящие принципы - это история про governance:) Суть в том, что архитектура - это про принципы, политики, модели, стандарты. В общем, тут фокус на стратегическом роли архитектуры. Недавно я вспоминал книгу про "Continuous API Management", где тема governance была отлично раскрыта - Компромиссы и принятие решений - это история про принятие фундаментальных структурных решений, что стоят дорого для будущего. Фокус на поиске компромиссов между функциональными и нефункциональными требованиями - Архитектурные стили и паттерны - это практический подход, который фокусируется на выделении повторно используемых подходов к построению архитектуры. Недавно вспоминал про книгу "API Design Patterns" - Коммуникация со заинтересованными сторонами - здесь фокус на том, что нам надо обсуждать и согласовывать архитектурные решения со стейкхолдерами для принятия дорогих решений. В итоге, определений много и перефразируя Джорджа Бокса, все они неправильные, но некоторые полезны:) Главное понимать их границы применимости и использовать по назначению. У меня вроде картинка за 20 лет работы в IT сложилась:) #Architecture #Software #DistributedSystems #SystemDesign #SystemEngineering #API #Governance