Книжный куб

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

[1/4] Software Engineering at Google (Делай как в Google. Разработка программного обеспечения) (Рубрика #Engineering) Я читаю и перечитываю эту крутую книгу уже примерно пару лет, как раз с того момента, как она мне доехала с Amazon в 2022 году. Я никогда не читал ее в русском переводе от издательства "Питер", но перевод "Делай как в Google" по меньшей мере озадачивает меня, хотя я привык уже к играм разума российских издателей. Правда, я не читал перевод не из-за его качества, а потому что у меня была книга в оригинальном издании. Если говорить про саму книгу, то она была написана Титусом Уинтерсом, Томом Маншреком и Хайрумом Райтом, а также большим количеством других уважаемых людей из Google. Каждая глава в этой книге написана отдельным коллективом авторов, причем часто изначально в виде whitepaper для конференций разработке софта. Я отметил две особенности, что помешали лично мне проглотить ее быстро - Стиль изложения и динамика меняется от главы к главе - я не могу читать больше одной главы за один раз - Главы написаны академическим языком, а значит достаточно формальным и сложным Кстати: если вы хотите узнать про часть процессов разработки, связанных с continuous delivery, но изложенные простым языком, то рекомендую книгу "Grokking Continuous Delivery", которая тоже родилась в Google, но написана одним человеком и похожа по стилю на комикс. Кстати, я уже рассказывал про книгу "Grokking CD" раньше Если же возвращаться к изначальной книге, то основная цель авторов книги - поделиться своим опытом и уроками, что инженеры Google получили из управления огромной кодовой базой и сложнейшей инфраструктурой. Ребятам было важно не просто нашмалять код по быстрому, но спроектировать его так, чтобы системы можно было поддерживать и развивать с течением времени. Вообще, ключевые идеи такие - Programming over time (программирование с учетом эволюции): в книге подчеркивается, что хорошая программная инженерия — это не просто одноразовое программирование, а поддержка и развитие программного обеспечения в долгосрочной перспективе. - Processes and scale (процессы и масштаб): авторы рассказывают и объясняют смысл процессов и практик, используемых в Google, например, про code review, стратегии тестирования и управление гигантским монорепозиторием. Эти процессы адаптированы к тем нефукнциональным требования и огромным масштабам, которые характерны для Google. - Tools and infrastructure (инструменты и инфраструктура): авторы обсуждают, как специализированные внутренние инструменты и инфраструктура не только поддерживают, но и улучшают сотрудничество и эффективность среди инженеров (примерно про это идет речь в whitepaper "The issue of monorepo and polyrepo in large enterprises", про который я говорил раньше) - Culture and collaboration(культура и сотрудничество): хотя некоторые разделы очень специфичны для Google, книга также подчеркивает важность формирования культуры, которая поощряет эффективное межкомандное сотрудничество и обмен передовым опытом. Частично про это можно почитать в проекте "Google's Project Aristotle", где ребята изучали, а что делает команды продуктивными (я рассказывал про этот проект раньше) - Practical lessons (практические уроки): хотя многие практики уникальны для размера и ресурсов Google, книга содержит ценные сведения о проблемах создания и поддержки крупномасштабного софта В целом, книга рассказывает о принципах создания софта, которые работают на крупном масштабе, но многие из которых уже давно стали стандартом де-факто и которые можно и нужно применять в технологических компаниях независимо от их размера. Условно, когда я рассказываю о лучших инженерных практиках из этой книги и слышу в ответ фразу "Мы же не Google", то у меня возникает вопрос, а точно ли надо быть сотрудником Google, чтобы чистить зубы перед сном или мыть руки перед едой. В следующих постах я кратко расскажу о содержании книги по главам: часть про культуру #Engineering #Management #Software #Development #Processes #Leadership #SRE #DevOps

Giilker Intelligent Four Square Chess (Рубрика #Kids) Жена подарила мне эту игру на новый год. Мы немного поиграли в нее на новогодние праздники, а потом отложили. Но в последнюю неделю я каждый вечер играю со своим старшим сыном в эту игру и она нам очень нравится - у нее простые правила и она динамичная. По картинке видно, что игра представляет из себя поле 5x5, игроки ходят по очереди и должны выставить свои фишки четыре в ряд, побеждает тот, кто сделает это первым. Звучит все достаточно просто, но на самом деле поле состоит из 125 клеток (5*5*5), так как оно трехмерно и фишки можно ставить друг на друга. Поэтому победит тот, кто выставит четыре фишки в любом направлении: вертикальном, горизонтальном или диагональном. Сама игра позволяет играть вдвоем или соревноваться с компьютером - это очень удобно, так как можно потренироваться пока сына нет дома. P.S. Мне так понравилась игрушка, что я купил себе такую же на работу и она приедет ко мне через пару недель:) #ForKids #ForParents #SelfDevelopment #Brain

Analyzing The Impact of UML, BPMN, and ArchiMate Integration from User Perspective (Рубрика #Architecture) Забавный whitepaper про нотации моделирования, к которым я питаю особую любовь еще со времен своего обучения. Авторы решили объединить разные нотации моделирования во благо совместной работы внутри корпораций. Авторы исходят из предпосылок 1) В корпорациях есть много диаграмм разных уровней, созданных при помощи ArchiMate, BPMN и UML и эти диаграммы содеражат большой объем знаний 2) В корпорациях есть много людей, которые умеют использовать эти нотации для проектирования - BPMN для описания бизнес-логики и бизнес процессов - Archimate для описания нюансов корпоративной архитектуры - UML для описания различных приложений и их взаимодействий 3) В корпорациях можно получить значительный буст от объединения этих нотаций между собой Поэтому цель исследования оценить удовлетворение пользователей и удобство использования объединенной нотации. Моя мысль, что большая часть предусловий, на которых строились идеи авторов не выполняются 1) В компаниях нет большого количества актуальных диаграмм с этими нотациями и из них нельзя сформировать общую картину 2) В большинстве компаний нет людей, что легко используют эти нотации (если не считать касты корпоративных архитекторов, которая существует в некоторых больших корпорациях в виде сотен представителей департамента корпоративной архитектуры) 3) Предполагаемый буст достигается за счет использования преимуществ каждой нотации, но вот знающих все три нотации обычно не очень много - я представляю тут диграмму Эйлера-Венна с пересечением кружков-множеств и центральной маленькой частью, которая пренебрежимо мала Интересно, что у меня есть опыт из прошлого, который похож на описанное в статье - в своем магистерском дипломе я описывал реинжиниринг бизнес-процессов в одной организации, используя кастомную нотацию, которую меня попросили собрать. Там мы использовали микс eEPC и IDEF0 - меня попросил их скрестить мой тогдашний руководитель и использовать для моделирования изменений. В общем, кроме меня эту комбинированную нотацию не понимал почти никто, так как большая часть задействованных не знала ни eEPC, ни IDEF0, а также честно говоря им было по...й, так как их интересовали только результаты самих изменений в процессах. С тех пор я решил, что экспериментировать в нотациях моделирования - это не лучшая идея. В итоге, сама идея авторов статьи сомнительна, но ок ... пойдем к тому, а что и как они оценивали 1) Ребята взяли фреймворк FUEML (Framework for Usability Evaluation of Modeling Langueges) из книги "Usability evaluation of modeling languages: An empirical research study" 2) Из этого фреймворка они выбрали lernability, memorability, user satisfaction, по которым решили сравнивать отдельно диаграммы в Architmate и комбо-диаграммы с миксом из трех нотаций - Learnability - это оценка того, насколько просто научиться пользоваться новой нотацией и насколько быстро получается выполнять задачи, какой уровень ошибок, etc - Memorability - насколько устойчиво запоминается информация о нотации, синтаксисе и семантике - User satisfaction - это отзывы пользователей о том, насколько они довольны использованием языка, его полнотой, качеством и удобством 3) Авторы изучали - Насколько быстро респонденты разбирались с двумы диаграммами: базовой A и расширенной B (кстати, диаграмму с комбинацией нотаций у меня открыть не получилось - авторы, видимо, отменили права на шаринг) - Насколько быстро авторы выполняют задачи с использованием моделей - Насколько много ошибок в процессе обучения - Фидбек пользователей В итоге, авторы получили примерно следующее

Overall, respondents thought that the integration of BPMN, ArchiMate, and UML was ”easy”. Modeling complicated systems is another ”very useful” application of this combination.

Правда, их респонденты преимущественно знали все три нотации моделирования:) #Software #Architecture #Engineering #UML #SystemDesign #Whitepaper

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

Клубная встреча "Стратегия визионеров" от SouthHub (Рубрика #Management) В один из вечеров на этой неделе я был на клубной встрече SouthHub, где мы обсуждали вопросы миссии, видения, стратегии и того, как эти высокие материии влияют на компанию. Правда, у нас был и практический интерес - как распознать, что тебе про эту миссию, видение и стратегию рассказывает визионер, наподобие, Стива Джобса, Илона Маска, Билла Гейтса или мошенник, наподобие, Элизабет Холмс, Сэма Бэнкман-Фрида или Адама Ноймана. Для подготовки к обсуждению нас попросили перед встречей глянуть документальный фильм "The Inventor: Out for Blood in Silicon Valley" ("Изобретатель. Жажда крови в Силиконовой долине"), который рассказывает историю единорога Элизабет Холмс под названием "Theranos", который обещал изменить сферу медицинских анализов. Сам фильм отлично рассказывает историю в динамике, приводя кусочки публичных интервью с Элизабет, а также остальными ключевыми участниками событий, поэтому рекомендую его посмотреть, если еще не видели - больно история интересная вышла. Если же возвращаться к вопросу про отличия визионера от мошенника, то мы в ходе обсуждений пришли к выводу, что 1) Все высокие материи в виде миссии, видения, стратегии можно свести к высокоуровневым вопросам - Зачем мы что-то делаем? - Миссия - что конкретно мы делаем? - Видение - Как мы это делаем? - Стратегия 2) Визионеры из списка выше (Джобс, Маск, Гейтс) отличаются от мошенников из списка ниже (Холмс, Бэнкман-Фрид, Ноймана) только результатами. Если бы у последних трех все сошлось, то мы бы продолжали говорить о них, как о звездах мира бизнеса. По-факту, многие визионеры топят со своей стратегией до талого и у кого-то получается довести "fake it until make it" до состояния made, а у кто-то остается у разбитого корыта 3) Но результаты визионера - это слишком lagging indicator, то есть мы хотим понять раньше выйдет ли что-то из задумки очередного визионера. Для этого можно задать ряд вопросов к его стратегии и проверить насколько консистентно выглядят ответы. Например, можно посмотреть под разными углами, например, так - Четкое и реалистичное видение - Детальный план реализации - Участие заинтересованных сторон - Эмоциональная привлекательность vs. Манипуляция - Соответствие долгосрочным целям - Прозрачность и доверие - Реалистичность обещанных результатов В следующем посте я чуть подробнее раскрою эти пункты, но В итоге, сразу могу сказать, что по слишком многим из этих пунктов подход Элизабет Холмс к построению визионерской стратегии не выдерживает критики. Возможно, поэтому никто из профессиональных инвесторов и медицинских фондов не вкладывался в эту инициативу, а деньги и влияние привлекались от около-государственных структур и столпов политики. В общем, изначально это было сомнительно, но ок ... а потом стало совсем скамом. #Management #Leadership #Strategy

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

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

Adaptive Enterprise Architecture: Towards a model (Рубрика #Architecture) Недавно я решил почитать whitepapers по enterprise architecture и наткнулся на статью ученых из Морокко, где они пытаются скрестить ежа с ужом, а точнее корпоративную архитектуру со скрамом:) В начале статьи авторы отмечают, что текущие подходы к корпоративной архитектуре (TOGAF, Zachman) не обладают необходимой гибкостью для обработки быстрых, разноуровневых изменений, что характерны для модных ныне цифровых трансформаций. Они сосредоточены на реактивных процессах, ориентированных на заполнение кучи документов и с их помощью сложно управлять непредвиденными изменениями. Дальше авторы решают сформулировать набор критериев для адаптивной корпоративной архитектуры, куда входят такие вещи как 1) Support multi-level dynamics (поддержка многоуровневой динамики) - изменения бывают на разных уровнях и идут с разной скоростью, а значит архитектурный процесс должен уметь работать с каждым типом изменений. Авторы отмечают, что стандартный подход с архитектурой as-is и to-be уже не является статичным, а подвергается различным изменениям, что надо учитывать в архитектурных процессах 2) Sensing of change (ощущение изменений) - процесс должен поддерживать ощущение идущих вокруг изменений и позволять планировать свои инициативы для адаптации к изменениям 3) Process of adaptation (процесс адаптации под новые потребности) - это ключевая часть подхода авторов, что называется adaptive enterprise architecture 4) Complexity of change management (комплексность управления изменениями) - TOGAF и Zachman проваливают этот критерий, ребята хотят подход, который будет сильно проще с точки зрения управления изменениями 5) Handling of unforseen changes (обработка непредвиденных изменений) - это нужно для современных корпораций, что сталкиваются с высокими темпами непредвиденных изменений в своем бизнес окружении. 6) Explicit management of adaptability trade-offs - авторы отмечают важность явного управления компромиссами по адаптивности к изменениям. Сейчас это зачастую просто одно из нефункциональных требований или атрибутов качества решений, а в новом подходе им надо управлять явно 7) Evaluation of adaptation (эволюция адаптации) - для управления адаптацией ее надо уметь измерять, а занчит нам нужны метрики внутри процесса корпоративной архитектуры Дальше авторы сравнивают по этим критериям разные подходы к корпоративной архитектуре и оказывается, что все они не удовлетворяют критериям. Они объединяют подходы в группы 1) Approaches based on guidelines (Zachman, TOGAF, Koffi A.D, LEAP, DYA) 2) Integration oriented approaches (Shmidt R & al, Zimmerman A & al) 3) Co-evolution oriented approaches (DEEVA, ACEM, ...) И дальше авторы решают предложить свой подход, который удовлетворяет критериям и полагается на проверенные временем agile подходы, а точнее на Скрам. Дальше они рассказывают о том, какой Скрам замечательный, а потом натягивают его на архитектуру 1) У нас появляется роли architecture owner, business/IT owners. Первый отвечает за стратегический alignment, а вторые за оптимизацию бизнес-процессов и технического решения 2) Работа идет в циклах по 2-4 недели и используются скрам ритуалы: weekly cross-owner syncs, architecture reviews для обеспечения фидбека 3) Появляется архитектурный беклог, в котором приоритизируются изменения корп архитектуры, а также есть KPI и отслеживание движения As-Is / To-Be на графиках Все остальные ритуалы agile про связь бизнеса и IT остаются на месте, просто EA беклог и ритуалы адаптивной корпоративной архитектуры живут рядом. Для меня это whitepaper показался натягиванием совы на глобус без особых объяснений как это будет работать на практике, а не на бумаге:) #Architecture #Software #Management #Governance #Engineering

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

Hooked: How to Build Habit-Forming Products (На крючке) (Рубрика #Management) Эта уже классическая книга Нира Эяля рассказывает о том, как создавать продукты, которые захватывают пользователей и становятся неотъемлемой частью их повседневной жизни. В книге представлена модель крючка в виде процесса из четырех зацикленных шагов, что позволяют формировать привычки пользователей. В самой модели следующие четыре части 1) Trigger (триггер): запускает поведение пользователя через внешние сигналы (например, уведомления) или внутренние мотивации (эмоции или мысли). 2) Action (действие): поведение, выполняемое в ожидании вознаграждения, которое должно быть максимально простым для пользователя. 3) Variable reward (переменное вознаграждение): результат действия, который удерживает пользователей благодаря своей непредсказуемой природе. 4) Investment (инвестиция): вклад пользователя в виде времени, данных, усилий или денег, что повышает вероятность возвращения к продукту. Автор утверждает, что использование такой модели позволяет создавать продукты, что создают привычку у пользователей, что повышает лоялность клиентов, а уже это можно использовать монетизируя лояльность и зарабатывая больше. Отдельно автор разбирает этические вопросы и отмечает, что лучше делать продукты, формирующие привычки, которые действительно улучшают жизнь пользователей. Иначе можно скатиться к роли, аналогичной наркодиллеру, который полагается на привычку к продукту, что разрушает жизнь потребителей. Используя эту модель, можно разобрать подходы известных продуктов 1) Duolingo создал формирующий привычку опыт изучения языков: - Триггер: отправляет ежедневные уведомления о целях изучения языка. - Действие: предлагает геймифицированные, легко выполнимые уроки. - Переменное вознаграждение: предоставляет очки опыта и достижения за серии успехов. - Инвестиция: отслеживает прогресс и адаптирует пути обучения на основе результатов пользователя. Я сам пользуюсь duolingo и у меня нерпрерывный streak сейчас в 2 года 2) TikTok стал крайне привлекательным, используя модель hooked: - Триггер: внешние триггеры включают видео, которыми делятся друзья, в то время как внутренние триггеры обращаются к желанию развлечься. - Действие: предлагает простой процесс создания аккаунта и легкий просмотр видео. - Переменное вознаграждение: представляет постоянный поток разнообразных, персонализированных коротких видео. - Инвестиция: позволяет пользователям создавать и делиться своими собственными видео, увеличивая привязанность к платформе. 3) Slack стал популярной платформой для коммуникации на рабочем месте и она тоже применяет модель hooked: - Триггер: использует как внешние, так и внутренние триггеры для привлечения внимания пользователей. - Действие: предлагает удобный интерфейс для легкого обмена сообщениями и участия в каналах. - Переменное вознаграждение: доставляет вознаграждения в виде положительной обратной связи и уведомлений о выполнении задач. - Инвестиция: поощряет вклад пользователей через обсуждения и участие в проектах. Мы использовали Slack до того, как перешли на наш мессенджер Time. Но есть у модели и стандартные проблемы, которые могут уменьшать ее эффективность 1) Несоответствие потребностям пользователей - неспособность понять реальные проблемы пользователей или создание решений для несуществующих проблем. 2) Чрезмерное усложнение модели - слишком сложный UX или слишком много фичей могут оттолкнуть пользователей 3) Неэффективные системы вознаграждений - если вознаграждения слишком предсказуемы, то это плохо. Одновременно плохо, если они неконсистентны между собой и не поддерживают интерес и мотивацию пользователей. 4) Пренебрежение фазой инвестиций - слишком слабое или слишком сильное поощрение вклада пользователей в приложение приведет к тому, что они сорвутся с крючка 5) Этические проблемы - привычки должны приносить пользу клиентам иначе легко провалиться на темную сторону силы #Management #ProductManagement #Econimics #PopularScienceHooked: How to Build Habit-Forming Products (На крючке) (Рубрика #Management)

The issue of monorepo and polyrepo in large enterprises (Рубрика #Architecture) Недавно прочитал старенький whitepaper 2019 года от Nicolas Brousse из Adobe с анализом подходов к управлению репозиториями исходного кода в крупных компаниях. Собственно сравниваются подходы монорепозитория и полирепозитория (множества отдельных репозиториев). Монорепы используют такие компании как Google, Meta, Microsoft, а полирепозитории были в Amazon, Netflix, Lyft и так далее. Автор ссылается на исследование "Advantages and disadvantages of a monolithic repository: a case study at Google", в котором есть хорошее сравнение компромиссов монореп и полиреп и подсвечиватся плюс монорепы вида, что монорепы

Encourages consistent and high-quality code, and empowers engineers to study and learn from the institutional knowledge of their company, crystallized in the form of source code

Дальше автор рассматривает разницу через три призмы 1) Cultural Alignment (культурное соостветствие) Структура репозиториев отражает корпоративную культуру. Монорепы подходят для коллаборативных сред (например, Google с философией «открытого сотрудничества»), а полирепозитории — для культур, ориентированных на автономию (например, Netflix с принципом «свободы и ответственности»). Интересно, что у нас полирепозиторий в Т-Банке 2) Team Cognition (командное познание) Монорепозитории разрушают функциональные силосы, способствуя целостному пониманию задач за счёт видимости общего кода и снижения коммуникационных барьеров, что коррелирует с повышением качества софта. 3) Tradeoffs (компромиссы) Обе модели имеют технические сложности (например, масштабируемость монорепозиториев), но монорепы стимулируют культурные изменения, улучшающие конкурентоспособность через DevOps-практики и инновации без ограничений. В итоге, автор подчеркивает, что технические аспекты важны, но культурные преимущества монореп - Усиление коллаборации - Устранение разрозненности - Оптимизация процессов разработки особенно ценны для крупных компаний, ориентированных на гибкость и качество P.S. На тему различий рекомендую почитать сравнение от Carlos Arguelles, инженера, что долго проработал в Amazon на CI/CD инфрой, потом ушел в Google на несколько лет, а потом вернулся в Amazon. Я раньше уже разбирал его статью "How Amazon and Google view CI/CD in an entirely different way". #CI #SRE #Architecture #Software #Infra #QA

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

Deductive Software Architecture Recovery via Chain-of-thought Prompting - Part II (Рубрика #Architecture) Продолжая рассказ про дедуктивный процесс SAR (Software Architecture Recovery) при помощи LLMs, я расскажу своими словами про шаги этого процесса Phase 1. Reference architecture definition - собственно, именно эта фаза добавляется авторами и позволяет потом добавить использование LLMs 1) Select reference architecture - здесь авторы предлагают выбрать референсную архитектуру, упоминаются стандартные layered architectuure, MVC, но сходу можно припомнить и другие подходы вида MVVM, Onion Architecture, ... 2) Define architectural components - здесь авторы определяют компоненты архитектуры, именно они будут использоваться LLMs для дальнейшей классификации кода. Например, для типовой layered architecture выделяются следующие уровни: presentation, application service layer и так далее 3)Define component & interaction indicators - здесь авторы в текстовом виде описывают правила взаимодействия компонентов, что дальше используется для классификации. Например, в случае с layered architecture авторы описывают свойства presentation layer

Pr1 . . sets the attributes of UI components, e.g., sets the text of a TextView. Pr2 . . . notifies listeners about user events, such as button clicks or list item selections. Pr3 . . . transforms domain objects into visual representations

Phase 2. Code unit classification - эта фаза рекурсивная и направлена снизу-вверх. Авторы предлагают выбрать гранулярность, а потом запустить классификацию. Например, начать с методов классов, дальше аггрегировать это в классы, потом в неймспейсы и так далее 4) Evaluate code units against indicators - собственно, здесь немного prompt engineering + код с описаниями методов попадает в LLM (GPT-4) на оценку для классификации по компонентам из референсной архитектуры

In a layered software architecture, one of the layers is the (layer_name) layer, which (layer_responsibility). Consider the context of an Android Java project “(project_name)”: (project_domain_description) Here are some indicators that a Java method in the project may belong to a class in the (layer_name) layer: (layer_indicators) The class ‘(class_name)’ contains the method ‘(method_name)’: (method_source_code) Check whether this method satisfies each indicator above. Mention the specific line of code that supports your reason. At the very last line, write the boolean verdicts separated by a comma, e.g., ‘true, true, false, true’. If indeterminate, say ‘false’.

5) Aggregate classified code units - здесь мы агрегируем ответы с прошлого этапа и получаем классы, в которых были методы, а дальше запускаем их на предыдущий шаг для повторной классификации и так пока не доберемся до нужного нам уровня абстракции На выходе такого процесса у нас получается некоторая классификация программных компонент с учетом референсной архтитектуры нашего проекта. Авторы сделали PoC для Android приложения K9 Mail и сравнили ручную разметку экспертами с тем, что насчитала модель - precision и recall для классификации оказались 72% и 71% соответственно. В итоге, авторы отметили, что есть еще пространство для улучшений и сформулировали свой план дальнейших исследований, включающих в себя работу над референсными архитектурами, а также полевое исследование в компаниях с применением этого метода. #Architecture #Software #Metrics #LLM #AI #ML #Engineering #RnD

Deductive Software Architecture Recovery via Chain-of-thought Prompting - Part I (Рубрика #Architecture) Вчера перед сном прочитал интересный whitepaper про процесс SAR (Software Architecture Recovery) при помощи LLMs. Мне идея показалась интересной, чтобы кратко рассказать про нее. 1) Стандартный подход к Software Architecture Recovery обычно работал снизу-вверх (bottom-up). Условно, некоторый анализатор кода запускался строил архитектурные метрики, которые как-то характеризовали архитектуру проекта (что-то в духе кейсов из книги "Software Architecture Metrics: Case Studies to Improve the Quality of Your Architecture", про которую я уже рассказывал) 2) В этом paper исследователи решили пойти сверху-вниз (top-down) и начать с задания референсной архитектуры, а дальше уже классифицировать части кода как относящиеся к той или иной части этой референсной архитектуры. Это позволяет не просто собрать текущее состояние архитектуры как было в стандартном подходе, а оценить расхождение между референсной архитектурой проекта и тем, что у нас есть на самом деле:) 3) Авторы говорят о том, что этот подход больше похож на то, как работают software engineers, так как обычно инженеры знают какая базовая архитектура в проекте, поэтому могут использовать эти знания при изучении кода Дальнейшее описание процесса в следующем посте, а в приложении к этому основные иллюстрации с описанием процесса, описанием индикаторов компонентов архитектуры, а также промптом для LLM, который используется в классификации. #Architecture #Software #Metrics #LLM #AI #ML #Engineering #RnD

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

The Golden Passport: Global Mobility for Millionaires (Золотой паспорт: Глобальная мобильность для миллионеров) (Рубрика #Economics) Прочитал за последнюю неделю интересную книгу с подробным исследованием программ гражданства через инвестиции, которые часто называют еще "золотыми паспортами". Книгу написала Кристин Сурак, доцент политической социологии Лондонской школы экономики и политических наук. Для этого она много лет исследовала эти программы, посещала конференции, общалась с посредниками, представителями правительств карликовых государств, а также с самими покупателями. По итогу, у нее получилась глубокая и интересная книга, которая раскрывает как историю вопроса, так и текущее состояние дел в этой области, где состоятельные люди могут фактически купить гражданство в различных странах. Основные моменты книги включают: - Исследование трансформации продажи паспортов от сомнительной практики до процветающей индустрии, в которую вовлечено более десятка стран. Интересно, что формально и в России есть программа гражданства через инвестиции, а глобальным лидером сейчас является Турция, которая перехватила лидерство у Кипра. В Карибском бассейне еще есть старожилы рынка инвестиционных паспортов в виде Сент-Китса, Гренады, Доминики, Сент-Люсии, Антигуа и так далее - Анализ сложных причин этого явления, включая желание повысить глобальную мобильность, получить налоговые льготы и обеспечить страховку от политической нестабильности. - Масштаб рынка - порядка 50к человек, что ежегодно приобретают гражданство через эти программы, стоимость зависит от программы, но начинается все с нескольких сотен тысяч долларов и может доходить до миллионов - Исследование последствий этой практики для концепций гражданства, глобального неравенства и взаимосвязи между богатством и национальной принадлежностью. В общем, эта книга дает хорошее понимание современного ландшафта глобального гражданства, проливая свет на эту практику, которая имеет значительные последствия для международных отношений, экономики и социальной мобильности. Правда, книга была издана на английском в 2023 году, а это значит, что ландшафт глобального гражданства с тех пор много значительно поменяться:) P.S. Это книга издательства Fortis Press, которая публикует переводы недавних интересных книг на актуальные темы. О парочке книг этого издательства я уже рассказывал раньше - Woke, Inc. За фасадом корпоративной риторики о социальной справедливости (Woke, Inc.: Inside Corporate America's Social Justice Scam) - Taming Silicon Valley: How We Can Ensure That AI Works for Us #Economics #History

Книга-квест "Ам Ням. Жми" (Рубрика #ForKids) Вчера прочитал перед сном сыну эту книгу, в которой 20 небольших глав, а сегодня мы прошли все мини игры в дополненной реальности. Если кратко, то описание книги обещает раскрыть истинную историю появления Ам Няма, а потом Ам Ням спасет мир от супер-злодея из комптьютерной игры. Мне показалось, что это неплохая книга для дошкольников - весело и интересно, а родителям забавно читать про взаимоотношение Ам Няма и его "дамочки" сердца, Ам Няши, которую он спасает на протяжении всей книге. P.S. Книги от DEVAR нравятся нашим детям и у нас дома собрался из них полный комплект, а о некоторых я уже рассказывал: например, о "Живой раскраске Смешарики". #ForKids #ForParents #Tales

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

Teaching Software Architecture Design - Building Intuition - Part II (Рубрика #Architecture) Продолжая первый пост с разбором whtepaper про обучение архитектуре, здесь я расскажу про оставшуюся часть статьи Анализ гипотез по отношению к требованиям в итоге должен вести к - Развитию инженерного подхода к принятию дизайн решений - Повышению уверенности инжнеров, что предложенный ими диазайн удовлетворяет требованиям - Способствует дискуссии о компромиссах, которые принимаются при выборе того или иного варианта дизайна Для этого авторы предлагают использовать подход с опровержимой аргументацией (defeasible argumentation), в которой аргументы принимаются на текущий момент, если они звучат разумно и приняты на основе доказательств, что есть на текущий момент. Но эти аргументы могут быть пересмотрены при появлении новых данных. Этот подход очень напоминает то, как работают люди, что проектируют софт - Они опираются на текущие данные и принимают решения в этом контексте - При появлении новой информации они могут увидеть, что это противоречит предпосылкам, на которых был основан дизайн раньше - А это потребует принятия нового решения, что изменит старое Обычно такой процесс реализуется с использованием подходов RFC и ADR, где - RFC - это request for comments или подход коммитетов к принятию решения - ADR - это architecture decision record, что добавляется в список принятых архитектурных решений. В рамках SADM студенты учатся задавать критические вопросы по отношению к дизайн гипотезам, практикуясь в формулировании аргументации, а также в ее опровержении. Причем здесь есть 2 формата аргументов 1) Аргументы для анализа use cases Если предложенная гипотеза о декомпозиции помогает реализовать необходимое поведение для конкретного сценария, то студенты могут попробовать задать критические вопросы вида - Какие исключения из шагов в сценарии делают его вклад в вариант использования недействительным? - Есть ли какие-либо побочные эффекты предлагаемой архитектуры, которые отрицательно влияют на шаги или мешают им выполняться? - Вносит ли предлагаемая архитектура отрицательный вклад в другие требования системы (варианты использования или требования к атрибутам качества)? - Нарушаются ли какие-либо ограничения во время выполнения сценария или его исключений? 2) Аргументы для анализа атрибутов качества Эта часть посложнее, так как требует много лет опыта, чтобы приводить неотразимые аргументы. А у начинающих часто аргументы звучат в формате "так работает google/aws/netflix", а значит это масштабируется, что является очень слабым аргументом. Здесь авторы предлагают студентам делать отсылки к референсной архитектуре, а также общепринятым архитектурным паттернам. Например, во второй части книги "Software Architecture in Practice" есть примеры паттернов, что приведены в свзяи с теми атрибутами качества, которые они поддерживают. Для использования паттернов можно использовать следующий подход - Показать, как предлагаемая архитектура является примером задокументированного шаблона или эталонной архитектуры. - Показать, что шаблон или эталонная архитектура, как известно, удовлетворяют указанному атрибуту качества. Критические вопросы, которые студенты могут задавать по этим аргументам звучат примерно так - Включает ли предлагаемая архитектура другие паттерны, которые отрицательно влияют на атрибут качества? - Мешает ли предлагаемый шаблон/эталонная архитектура другому требованию к системе? Авторы давали студентам дизайнить решения из разных индустрий, что приводило к тому, что баланс между атрибутами качества каждый раз был разный. Это позволило студентам научиться анализировать требования, выдвигать дизайн-гипотезы, а также составлять аргументацию в поддержку своих гипотез. В общем, цель развития интуиции при принятии дизайн-решений была достигнута. P.S. Мне кажется, что здесь описан логичный и легкий процесс того, как можно подтянуть свои умения в дизайне сложных систем:) #Architecture #Software #Engineering #SelfDevelopment