Архитектура Дома Наркомфина вчера и сегодня - Part II (Рубрика #Architecture)

Продолжая первый пост про Дом Наркомфина, здесь я закончу рассказ про оставшуюся часть книги
- Дом Наркомфина. Цветовые решения - цветовые решения в доме сильно отличались от дефолтных и учитывали разную этажность и назначение помещений
- Другие участники строительства Дома. Николай Милютин и Сергей Прохоров - Николай Милютин был наркомом по финансам и главным стейкхолдером при строительстве дома. Без его помощи такой эксперимент бы не состоялся. Сергей Прохоров - был главным инженером стройки, без которого дом бы не удалось построить в нужные сроки, с нужным бюджетом и качеством
- Вторая очередь проекта Дома - у дома предполагалась вторая очередь, но она не случилась
- Довоенная жизнь Дома - до 2 мировой войны дом жил по задуманному плану, но во время войны многие уехали, а потом уже не вернулись. После войны его уже заселили по другому и многие решения переиграли
- "Соцгород" Николая Милютина - авторы рассказывают про вышедшую в 1930 году книгу Милютина «Соцгород», в которой он выдвинул собственную архитектурную концепцию градостроительства в соответствии с марксистской идеологией. В этой книге он обращался к западной практике, а также призывал к деурбанизации, то есть децентрализации городов, что противоречило общепринятой концепции развития городов в СССР. Плюс саму книгу он посвятил вскоре репрессированному коллеге, поэтому книгу запретили спустя год после публикации.
- Аналоги и "двоюродные братья" Дома - здесь авторы приводят примеры других домов, что использовали ячейки Стройкома, в котором когда-то работал Гинзбург. Похожие дома есть в Саратове, Нижнем Новгороде, Екатеринбурге, Ростове-на-Дону и других городах. Редко какие дома настолько ярки как Дом Наркомфина, но в них определенно прослеживается похожая логика и влияние конструктивистов
- Наследие Дома в послевоенной архитектуре - после войны идеи двухэтажных квартир и обобществления быта не особо котировались, но часть домов в 70-е и 80-е годы с похожими идеями было создано
- Послевоенная жизнь и реставрация Дома - к 2000м годам дом постепенно пришел в упадок и появилась идея о его реконструкции, но это потребовало расселения жильцов и выкупа квартир, что шло медленно. Но в 2016-2020 году удалось провести реставрацию этого культого места и теперь Дом Наркомфина - это институциональный и исследовательский проект Музея современного искусства «Гараж».

#Architecture #Design #Culture

Экстремальное программирование: постановка процесса (Extreme Programming Applied: Playing to Win) - Part I

Сегодня я решил вспомнить книгу про экстремальное программирование (XP) из времен старта моей карьеры (на русском она появилась 20 лет назад, а на английском за пару лет до этого). В этой книге авторы разбирают что такое XP и главное, как его применить на практике. Интересно, что большая часть практик XP стала стандартом де-факто и сейчас их даже не надо продавать, так как они считаются некоторым baseline для инженерных практик. Но в начале 2000х XP проиграла маркетинговую войну другим Agile подходам навроде Scrum и его вариаций - инженеры не так красиво пели, как любители поговорить за процессы и ритуалы, поэтому скрам был сильно известнее XP:)

Ну а теперь перейдем к самой книге.

Введение: играть, чтобы выиграть - здесь авторы говорят о том, что софт - это изменчивая сущность и нам надо быть готовым к модификациям нашей системы, а для этого надо учитывать стоимость изменений. И старые подходы (аля waterfall и тяжеловесное планирование, проектирование и т.д.) приводили к тому, что стоимость изменений в процессе создания системы экспоненциально росла, поэтому изменений старались избегать. Но в XP все сделано так, чтобы сгладить стоимость изменений. Именно это авторы и предлагали использовать в качестве главного аргумента.
XP в кратком изложении - здесь авторы рассказывают про ключевые ценности XP и основные принципы, которые раскрываются дальше на страницах книги и объясняется как их практически применять, а также продавать коллегам для внедрения изменений. Основные ценности XP такие
1) Коммуникация (Communication) - работая в стиле XP невозможно избежать общения
2) Простота (Simplicity) - XP всегда предлагает решать проблему самым простым способом
3) Обратная связь (Feedback) - частый и качественный feedback позволит оставаться продукту/проекту на правильной траектории
4) Храбрость (Courage) - для движения с максимальной скоростью нужна храбрость. Плюс надо уметь побеждать sunk cost fallacy

Дальше авторы вспоминают про основные практики, которых всего 12 штук, но в дальше в самой книге они делят их на шесть стартовых и остальные, что надо внедрять во вторую очередь, поэтому я тут начну с первых 6
1) Игра в планирование - здесь авторы рассказывают про планирование и оценку трудозатрат. Фактически, предлагается следующая частотность Release planning (quaterly) -> Iteration planning (2 weeks) -> Standup meetings (everyday). Авторы отмечают важность оценивания трудозатрат для того, чтобы дискутировать с заказчиком на уровне приоритетов задач и стоимости их реализации. Это похоже на общепринятую сейчас практику
2) Частые релизы (Small releases) - частотность релизов и их небольшой размер очень хорошо укладываются в lean практики и позволяют инкрементально получать ценность. А с точки зрения инженерии это позволяет поддерживать нужный темп и не слишком рисковать во время каждого релиза - подробнее рекомендую почитать книгу "Accelerate" (см. мой пост) и про DORA метрики. Это уже стандарт де-факто
3) Тестирование - фактически, авторы рассказывают про TDD и объясняют зачем нам нужны тесты в сложных системах. Это уже стандарт де-факто.
4) Парное программирование - тут речь про работу в паре за одним компьютером при реализации одной задачи. Эта практика так и не стала общепринятой, но вместо нее принято делать design review до реализации задачи, а также code review уже после ее реализации
5) Рефакторинг - здесь авторы вспоминают Мартина Фаулера и его классическую книгу "Рефакторинг", а сам подход сейчас является стандартом де-факто в индустрии
6) Continuous integration - авторы продают важность интеграции проекта и прогона тестов как можно чаще, например, несколько раз в день. С тех пор тулинг вокруг CI сильно улучшился и мы собираем приложения и гоняем тесты на каждый коммит. Плюс теперь принято использовать TBD (trunk based development), который доводит идею continuous integration до логического финала

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

#Management #Software #Engineering #SoftwareDevelopment #Processes #Devops #SRE

Экстремальное программирование: постановка процесса - Part II (Extreme Programming Applied: Playing to Win)

Этот пост заканчивает разбор книги из начала 2000х, рассказ про которую я начал в предыдущем посте. Здесь я планировал рассказать про шесть оставшихся практик второй очереди, а также дать материалы для дальнейшего изучения. Ну поехали
1) Простой дизайн (Simple Design) - здесь суть в том, чтобы не делать большую архитектуру перед стартом проекта, а проектировать по мере поступления новой информации и требований. Звучит хорошо, но у неопытных ребят это превращается в big ball of mud. В итоге, тут до сих пор есть вопросики о том, а как же правильно проектировать комплексные системы
2) Коллективное владение кодом (Collective code ownership) - коллективное владение кодом внутри команд является стандартом де-факто, а вот контрибьютинг в код соседних команд до сих пор не так тривиален - есть такое направление как innersourcing, про которое упоминают при желании уменьшить ожидания и зависимости от других команд. Основная суть как раз в том, чтобы не ждать соседнюю команду, а самому набацать им кода и влить через процедуру merge request. На этом пути есть ряд организаионно-технических проблем, но bigtech компании как-то справляются с ними:)
3) Приемочные тесты (Acceptance tessting) - суть в том, чтобы фиксировать ожидания заказчика и писать приемочные тесты, которые выступают как фиксация критериев приема задач со стороны заказчика. Сейчас этот подход чуток расширился до критериев готовности по задачам (definition of done), которые должны быть выполнены прежде, чем элемент бэклога (пользовательская история) будет считаться завершенным.
4) Стандарты кодирования (Coding standards) - авторы говорили про стандарты кодирования, которые сейчас автоматизируются на уровне linters. Но если пойти чуть дальше, то стандарты помогают и на уровне использования общих библиотек или стандартизации подходов к проектированию API
5) Метафора системы (metaphor) - интересная концепция про использование метафор внутри системы и общего языка для общения технарей и бизнес-заказчиков. Лет через 5 после выпуска этой книги вышла книга "Domain-Driven Design: Tackling Complexity in the Heart of Software", в которой Эрик Эванс представил концепцию DDD и ввел термин ubiquitous language
6) Сорокочасовая рабочая неделя (40-hour week) - здесь авторы говорят про отсутствие переработок и нормальный work/life balance. Интересно, что уже тогда эта тема была важна и вошла в набор принципов.

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

P.S.
Если этот обзор понравился, то рекомендую почитать книги
- Modern software engineering - это недавняя книга Дейва Фарли, про которую я уже писал. В этой книге Дейв рассказывает примерно про эти же практики, но в приложении к текущему уровню индустрии
- Accelerate - это книга 2017 года от Nicole Forsgreen, Jez Humble и Gene Kim, про которую я уже писал. В этой книге авторы рассказывают результаты DevOps Reports за 5 лет и показывают как инженерные практики помогают бизнесу двигаться быстрее
- Tidy First?: A Personal Exercise in Empirical Software Design (Чистый дизайн. Практика эмпирического проектирования ПО) - недавняя книга Кента Бека, создателя eXtreme Programming, про которую я уже рассказывал. В этой книге Кент подробнее ракрывает суть принципа Simple Design:)
- A philosophy of software design - книга Джона Остерхута, создателя алгоритма консенсуса Raft, про которую я уже рассказывал. В этой книге Джон круто раскрывает про свой подход к дизайну софта и важности инженерных практик

#Management #Software #Engineering #SoftwareDevelopment #Processes #Devops #SRE

Super Pumped: The Battle for Uber (Битва за Uber) (Рубрика #Management)

Прочитал очередную книгу во время отпуска - на этот раз про историю Uber. Эта компания продемонстрировала силу подрывных инноваций, буквально разрушив стандартный мир таксистов и диспетчеров и построив на осколках новый красивый и удобный мир для пассажиров. Этой революцией руководил Трэвис Каланик, который ценил результаты превыше всего и игнорировал законы, выкручивая руки властям. Эта книга читается как боевик и рассказывает историю удивительно детально, так как Майк Айзек был штатным журналистом в New York Times и писал о технологических компаниях и очень много про Uber, который гремел в 2010х. Пока я читал книгу, то ловил себя на мысли, что это почти готовый сценарий - оказалось, что так думал не только я, но и ребята из Showtime, которые в 2022 году выпустили одноименный сериал. Пересказывать все перипетии книги мне кажется лишним, но вот посмотреть на список ценностей, который сформулировал Тревис, мне кажется интересным. Это позволяет сравнить Uber с другими технологическими гигантами (у Тревиса было 14 принципов как и у Amazon изначально, подробнее про Amazon и его культуру можно почитать в книге "Working Backwards", про которую я рассказывал раньше)

1) Always be hustlin’ (Get more done with less, working longer, harder, and smarter, not just two out of three)
2) Be an owner, not a renter (Revolutions are won by true believers)
3) Big bold bets (Take risks and plant seeds that are five to ten years out)
4) Celebrate cities (Everything we do is to make cities better)
5) Customer obsession (Start with what is best for the customer)
6) Inside out (Find the gap between popular perception and reality)
7) Let builders build (People must be empowered to build things)
8) Make magic (Seek breakthroughs that will stand the test of time.)
9) Meritocracy and toe-stepping (The best idea always wins. Don’t sacrifice truth for social cohesion and don’t hesitate to challenge the boss)
10) Optimistic leadership (Be inspiring)
11) Principled confrontation (Sometimes the world and institutions need to change in order for the future to be ushered in)
12) Superpumped (Ryan Graves’s original Twitter proclamation after Kalanick replaced him as CEO; the world is a puzzle to be solved with enthusiasm)
13) Champion’s mind-set (Put everything you have on the field to overcome adversity and get Uber over the finish line)
14) Be yourself (Each of us should be authentic)

А после низвержения Каланика в 2017 году принципы переписали и их осталось всего 8 (подробнее можно почитать в статье 2017 года).

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

Автор завершает книгу предостережением относительно харизматичных основателей технологических компаний навроде Тревиса Каланика (Uber), Адама Неймана (WeWork), Элизабет Холмс (Theranos) или Сэма Бенкман-Фрида (FTX). Эти лидеры умеют продавать видение будущего инвесторам так, что на них находит затмение относительно самой идеи или ее реализации, когда основатель проповедует иезуитское "Цель оправдывает средство".

#Management #Leadership #Bigtech #Processes #BusinessStory

How we use GenAI in SRE (Рубрика #SRE)

Я периодически почитываю статьи Google на тему "Distributed Systems and Parallel Computing" на их сайте research.google. Именно там я нашел статью "How we use GenAI in SRE" с абстрактом вида

Службы Google работают на крупнейшей в мире сети компьютеров. Инженеры по надежности сайтов (SRE) следят за тем, чтобы весь стек был в порядке: центры обработки данных были безопасными, хорошо подготовленными; у нас были резервные механизмы и целостность данных; чтобы убедиться, что мы правильно проектируем наш стек, используя правильные компромиссы в области хранения, репликации и программного обеспечения. Генеративный ИИ — отличный инструмент, который сделает нас сверхэффективными: имея доступ к инструментам для создания наших самых сложных конфигураций, для классификации рисков и событий, для управления большими массивами машин с помощью агентов или для дешевой автоматизации сложных рабочих процессов. В этом докладе будет рассмотрен путь, который SRE начал много лет назад, чтобы стать по-настоящему дисциплиной AI-First, и последние достижения в области инструментов, практик и рабочих процессов.

Эта статья оказалась не статьей, а простенькой презентацией от 20 апреля 2024 года (сама презентация доступна здесь). Из этой презентации можно вытащить не так много нового

1) Тезис про то, как SRE связан с работой AI систем

SRE is crucial component to operate at scale AI systems that are trustworthy, safe and efficient

2) Как SRE помогает AI
- Дизайн распределенных систем - системы, у которых основа завязана на AI, тоже должны хорошо масштабироваться и быть надежными
- Ускорить деплой - новые железные компоненты (GPU, TPU, ...) должны поступать в датацентры и эффективно шедулиться
- Trust & safety - результаты работы систем, основывающихся на AI моделях, должны быть выровнены относительно человеческих стандартов
- Эксплуатация и автоматизация - тренировка моделей и пайлайны для fine-tuning, релизов, откатов и так далее (вообще это можно называть MLOps)

3) Как AI помогает SRE
- Генеративный AI для документации и постмортемов - сохранение документации чистой и актуальной, создание изначальных постмортемов (видимо, рыба с автозаполнением части инфы)
- Автоматизация workflow - агентские процессы служат как workflow runners и выполняют часть функций на проде
- Оценка риска - еще до возникновения инцидента модели могут детектировать проблемы и исправлять часть из них
- Эффективность ресурсов - начиная с температур в датацентрам и до размещения сервисов по доступным машинкам ML модели помогают проду быть более здоровым и эффективным

В итоге, это доклад на хайповую тему, но вот содержание не уходит дальше рассказов о том, что SRE в Google теперь на AI-стероидах и применяется к AI системам:))

#SRE #Management #ML #AI #Processes #SystemDesign #DistributedSystems

Как я решаю сложные задачи или Как от решений в уме я пришел к письменной культуре (Рубрика #SelfDevelopment)

За свои 38 лет я прошел большой путь в этом вопросе. В детстве мне многое давалось легко, еще до школы я начал играть в шахматы, а в первом классе уже побеждал отца. Так я оказался в шахматной секции ДЮСШ, куда я ходил до конца седьмого класса. Там я научился отличию тактики от стратегии, расчету вариантов, а также позиционной игре (тут, кстати, были самые большие проблемы). Шахматы очень структурировали мое мышление и дали следующие перки
- Оценка позиции и проработка стратегии
- Учет конкретных деталей текущей позиции и расчет вариантов
- Умение взглянуть на позицию с позиции оппонента, задача которого не дать тебе реализовать свой план
И все бы хорошо, но я был слишком самоуверенным и ленивым - так я пришел к выводу, что все задачи мне стоит решать в голове. В школе это приводило к тому, что я часто вместо решения уравнения просто писал сразу ответ, при решении стереометрических задач представлял их в голове и тоже писал ответ:) Базовые задачки по физике я решал примерно также. Это привело к тому, что к старшим классам я не мог решать действительно сложные олимпиадные задачи, так как навыка записывать промежуточные шаги у меня не было. В десятом классе я начал учиться в ЗФТШ (заочной физико-технической школе при МФТИ). Это обучение навело меня на мысль, что надо что-то менять. За последние два класса школы я научился писать свои решения ручкой в тетради, а не оставлять в голове - это помогло мне поступить в МФТИ, где я уже строчил лекции и семинары на потоке:)
На третьем курсе университета я начал работать и я продолжать много писать и размышлять о решаемых задачах, но по-настоящему парадигма сдвинулась только тогда, когда я стал руководить людьми. Тогда я понял, что важно не просто описать решение задачи, целевой процесс или нашу стратегию развития приложения, а важно сделать так, чтобы твои коллеги это поняли:) Я начал тренировать эти навыки, но расцвели они уже после прихода в Т-Банк (тогда еще в Тинькофф). Здесь у меня команда и зона ответственности росла быстро и неотвратимо. В какой-то момент я понял, что без выстроенной письменной культуры я быстро закончусь и начал ее практиковать еще активнее - я писал RFC, ADR, планы развития, инструкции, делал автоматизации на базе wiki и макро-репортов:) Суть была в том, чтобы построить систему, в которой информация не замыкается на одном человеке, а доступна всем заинтересованным. Где-то в 2018 году я начал выступать на конференциях и завел блог на Medium, а в 2022 году - в telegram. Сейчас я здесь и пытаюсь по вечерам и выходным писать книгу, которая будет состоять из компиляции моих постов, выстроенных в нужном порядке. Идет это туговато, но если бы у меня не было письменных артефактов из прошлого, то это было бы попросту невозможно:)

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

#SelfDevelopment #Writing #Leadership #Management

Летняя распродажа в издательстве Питер (Рубрика #Sales)

В издательстве Питер очередная распродажа с 12 по 18 августа со скидками в 40%. Для получения этой скидки надо использовать промокод "Лето" при оформлении заказа.

В прошлую расродажу я купил себе 5 книг и одну из них уже прочитал
- Data mesh в действии - тема очень интересна в контексте ухода от стандартного DWH в сторону Data Mesh и Lake House. До этого я читал частями книгу "Data Mesh: Delivering Data-Driven Value at Scale" и поэтому решил почитать другую книгу:)
- Грокаем алгоритмы искусcтвенного интеллекта - просто тема интересная для меня:) Хотя я эти базовые алгоритмы уже много раз изучал в разных вариациях, но решил, что книга из серии "Грокаем ..." сможет мне объяснить эти алгоритмы еще доступнее:)
- Компьютерные сети. Принципы, технологии, протоколы: Юбилейное издание, дополненное и исправленное - я уже как-то читал книгу Олиферов, но это было много лет назад. Решил посмотреть что авторы добавили по прошествии времени
- Настоящий CTO: думай как технический директор - тут я решил сравнить насколько я думаю как настоящий технический директор, а то вдруг я думаю как-то не так:)
- Разработка приложений на базе GPT-4 и ChatGPT - базовая книга про chatGPT и GPT-4, я ее уже прочел и даже рассказывал в отдельном посте.

#Sales