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

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

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

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

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

#PopularScience #Physics #History

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

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

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

#ForKids #ForParents #Humor

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

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

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

#Architecture #DistributedSystems #SystemDesign #Engineering #Software

Introducing Domain-Oriented Microservice Architecture - Part I (Рубрика #Architecutre)

В 2020 году Adam Gluck написал интересный пост про редизайн микросервисной архитектуры Uber и переход на DOMA. А потом Адам уволился и пошел пилить свой стартап, но к делу это не относится:) Если вернуться к статье, то Адам описал стадии эволюции архитектуры

1) Монолитная архитектура (примерно 2012-2013), где было 2 больших сервиса и набор проблем: риски доступности, опасные деплои, poor separation of concerns, плохой execution изменений в бизнес-логике. Эти проблемы возникли при росте от десятков инженеров к сотням
2) При решении этих проблем ребята пошли в микросервисную архитектуру ради: общесистемной надежности, separation of concerns, ясной ответственности и владения (ownership), скорости разработки (developer velocity). Ребята на начальных этапах получили все запланированное, но при росте команды до тысяч инженеров возник распределенный монолит
3) С 2018 года шла работа над новой концепцией под названием DOMA (Domain-oriented microservice architecture), в которой ребята решили, что микросервисы - это просто i/o-bound библиотеки, а микросервисная архитектура - это большое распределенное приложение, то для его архитектуры можно использовать стандартные подходы
- Domain-driven design - про эту концепцию интереснее всего читать у Влада Хононова в книге "Learning DDD", на которую я написал 4 кратких обзора: общий обзор DDD, DDD и микросервисы, DDD и event-driven architecture, DDD и data mesh
- Clean architecture - лучше всего изучить книгу Книга "Clean Architecture" и ее часть про дизайн модулей - мое краткое саммари этой части здесь
- Service-oriented architecture - это предтеча микросервисной архитектуры:)
И на выходе получаться принципы для дизайна крупных распределенных систем в больших организациях.

Основные принципы DOMA такие

1) Вместо ориентации на отдельные микросервисы надо ориентироваться на их коллекции, что организованы вокруг доменов
2) На самом деле домены тоже объединяются в коллекции, которые называются уровнями. Уровни определяют то, какие зависимости могут быть у микросервисов внутри домена. Базовое правило - это то, что микросервисы из верхних уровней могут зависеть только от микросервисы с нижних уровней. Авторы называют это слоенным дизайном. Для меня он напоминает семиуровневую модель OSI (технологии часто развиваются по кругу)
3) Домены предоставляют чистые интерфейсы (clean interfaces), которые являются единой входной точкой в коллекцию. Такие входные точки называются gateways
4) Зависимостями между доменами быть не может - ни по коду, ни по моделям данных. Для того, чтобы сделать доступным включение логики из одного домена в другой (например, для кастомной валидации или мета контекста) авторы предоставляют точки расширения внутри доменов

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

1) Infrastructure layer. Provides functionality that any engineering organization could use. It’s Uber’s answer to the big engineering questions, such as storage or networking.
2) Business layer. Provides functionality that Uber as an organization could use, but that is not specific to a particular product category or line of business (LOB) such as Rides, Eats, or Freight.
3) Product layer. Provides functionality that relates to a particular product category or LOB, but is agnostic to the mobile application, such as the “request a ride” logic which is leveraged by multiple Rides facing applications (Rider, Rider “Lite”, m.uber.com, etc).
4) Presentation. Provide functionality that directly relates to features that exist within a consumer-facing application (mobile/web).
5) Edge Layer. Safely exposes Uber services to the outside world. This layer is also mobile application aware.

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

#DistributedSystems #Architecture #SystemDesign #Engineering #Software

Introducing Domain-Oriented Microservice Architecture - Part II (Рубрика #Architecutre)

Заканчивая рассказ про DOMA, начатый в первом посте, я хотел бы рассказать про оставшиеся компоненты архитектуры и получившиеся результаты.

Третьим архитектурным принципом является gateway. Он достаточно стандартен с точки зрения технической реализации, но на уровне домена он позволяет обеспечить за счет четкого котракта уменьшение сложности для взаимодействующих с доменом, а также более простые миграции внутри самого домена. Четвертый элемент - это точки расширения предлагают две возможности: расширение логики и расширение модели данных. Логические расширения реализованы через возможность подключения плагинов с интерфейсами определяемыми для каждого сервиса самостоятельно (приводится пример с кейсом, когда водитель выходит на линию и дополнительными проверками, что ему можно это делать). А данные можно расширять через добавление к core-модели данных произвольных опций. Также команды внутри доментов могут придумывать и другие точки расширения.

На выходе авторы получили
1) Снижение сложности: благодаря объединению 2200 микросервисов в 70 доменов DOMA упрощает управление зависимостями и обслуживание системы (за счет доменов и слоев)
2) Улучшенная масштабируемость и гибкость: архитектура позволяет осуществлять независимую разработку и развертывание доменов, сохраняя гибкость для будущих миграций (за счет gateways)
3) Улучшенный опыт разработчиков: структурированный подход снижает когнитивную нагрузку на разработчиков, позволяя быстрее разрабатывать функции и упрощать устранение неполадок (за счет понятных API и точек расширения)
4) DOMA доказала свою эффективность в управлении крупномасштабными operations в Uber

Напоследок автор рекомендует использовать стартапам монолиты, средним по размеру организациям микросервисы, а большим идти в сторону дома (DOMA)

Итого, это интересная статья от ребят из Uber из 2020 года. Если сейчас поискать дополнительную информацию, то кажется, что этот подход до сих пор используется Uber. Ради интереса я поискал whitepapers от Uber на тему DOMA и не нашел ни одной - Uber не Google, чтобы писать научные статьи:)

#DistributedSystems #Architecture #SystemDesign #Engineering #Software

ЦЕХ 4 - Урок #24 "Продающие тексты. Эксперт — Алена Лепилина" (Рубрика #Writing)

В очередном уроке разбирался пример создания продающих текстов:) Я сразу вспомнил книгу "Пиши, сокращай", о которой я рассказывал раньше. Экспертом урока была Алёна, что работает с текстами более 16 лет, руководит командой контента и редактирует курсы. Алёна рассказывает о важности текстов и их влиянии на аудиторию. Основные тезисы урока
1) Пирамида аудитории - про это рассказывали подробно во втором уроке
2) Для написания своей книги:
- Выделите свои смыслы и идеи, которые лежат на поверхности.
- Работайте над книгой, пока не найдете новые идеи.
- Продвигайте книгу, показывая её любой аудитории.
3) Для книги стоит составить контент план и дальше использовать разные площадки, правильно подбирая tone of voice в зависимости от площадки
4) В продающих текстах важно выстроить отношения с читателем, а не просто втюхать книгу. Для этого лучше не обещать больше того, что есть в книге:)
5) Можно писать про книги посты, подборки или гайды. Также можно писать трейлеры к книгам (внезапно по аналогии с трейлерами к фильмам)
6) Важно, чтобы текст к книге выщывал эмоции у читаталей, но не надо ими манипулировать и учитывать жанровую специфику
- Нон-фикшн: упор на пользу и практичность.
- Художественная литература: создание атмосферы и избегание спойлеров.
- Детская литература: учет формата и возраста читателя.
7) При написании текстов важен ритм и ясность. Длину предложений стоит чередовать, а также не надо перегружать читателя деталями, надо быть кратким и понятным
😍 Истории лучше сопровождать иллюстрациями
9) Тексты должны быть уникальными и интересными.Важно удивлять аудиторию и вдохновлять её. Важно писать нестандартно и оригинально.
10) Можно проявлять креативность в текстах, но не надо забывать проверять факты (делать фактчекинг)
11) Редактировать тексты стоит безжалостно - надо дорабатывать текст до момента, пока он не станет интересным и полезным. Можно привлекать внешнего редактора (так каксамому часто сложно резать написанный текст)
12) Чтобы писать хорошие тексты, надо много читать других авторов и профессионально развиваться в этой области
13) Полезно иметь сильный личный бренд - это помогает продвигать книгу
14) Стоит использовать аналитику для оценки эффективности текстов

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

#SelfDevelopment #PublicSpeaking #Storytelling #Writing

Коллеги из AI Центра продолжают радовать большими языковыми моделями на русском языке - теперь вышла T-Pro, которая по бенчмаркам хороша. Отдельно стоит отметить, что новая модель T-Pro выложена в opensource как и T-Lite и обе можно скачать с Hugging Face.

Запустили open-source модели на 7 и 32 миллиарда параметров

Сегодня мы выложили в открытый доступ две большие языковые модели на русском языке: T-Pro на 32 млрд параметров и обновленную T-Lite на 7 млрд параметров. Они построены на базе моделей Qwen 2.5 и дообучены на русский язык.

T-Pro заняла второе место по бенчмарку MERA среди всех моделей, включая проприетарные, и первое место среди открытых. А T-Lite стала лучшей русскоязычной open-source моделью в классе «до 10 миллиардов параметров» по ряду индустриальных бенчмарков.

🎄Скачать модели можно с huggingface.

Больше подробностей — совсем скоро ;)

Research Insights Made Simple #6 - Interview with Nikolay Golov about data platforms (Рубрика #Data)

И, продолжая тему систем хранения данных, я решил сегодня поделиться новым выпуском подкаста про инсайты. В этот раз ко мне в гости пришел Николай Голов для того, чтобы обсудить то, как строить дата платформы в 2025 году:) Коля исполняет роль head of data engineering at ManyChat, а до этого он был head of data platform в Авито. Коля знает все о том как построить OLAP и OLTP системы, интенсивно работающие с данными. Выпуск доступен в виде подкаста на Ya Music и Podster.fm

За время подкаста мы обсудили темы
- Как развивалась карьера Коли в разных компаниях и как он стал преподавать базы данных параллельно с основной работой
- Как можно строить платформы данных (централизованно, гибридно и децентрализованно)
- Как выглядят принципы федерализации данных (аля data mesh) в теории
- Во что этот подход превращается на практике
- Как строить дата платформы в стартапах, средних, а также крупных компаниях в 2025 году
- Что не так с классическими базами данных (Postgres и иже с ним)
- Что не так с MPP базами данных (Vertica, Greenplum, ClickHouse, ...)
- Как data mesh превращается в data mash и как цепочки дата продуктов работают на практике
- Как выделять базовый домен данных, чтобы уменьшить длину цепочек дата продуктов
- Почему облачные аналитические базы так быстры: колоночное хранение + разделение storage и compute
- Что такое medalion architecture
- Куда дальше будут развиваться технологии обработки данных и почему нельзя полагаться на старые подходы и ограничения

Дополнительные материалы
- Статьи из периода работы в Avito "Vertica+Anchor Modeling = запусти рост своей грибницы"
- Статья из периода работы в Manychat: 1 и 2
- Запись "Data Modeling Meetup Munich: From Data Vault to Anchor Modeling with Nikolai Golov"
- Запись "DataVault / Anchor Modeling / Николай Голов"
- Научная статья "Golov N., Ronnback L., Big Data Normalization for Massively Parallel Processing Databases" //Computer Standards & Interfaces, 09-May-2017, https://doi.org/10.1016/j.csi.2017.01.009
- Научная статья "Golov N., Filatov A., Bruskin S.,Efficient Exact Algorithm for Count Distinct Problem", Computer Algebra in Scientific Computing, July 2019

#Data #Datamesh #Processes #Management #Architecture

Big Data is Dead (Рубрика #Data)

Этот пост Jordan Tigani вышел почти два года назад в блоге компании MotherDuck, которая является материнской для DuckDB. Сам Jordan был одним из инженеров, что стояли у основ Google BigQuery, а потом он отвечал за ее продуктовое развитие, а значит знает о чем говорит. Ну а компания MotherDuck пытается сделать облачную версию DuckDB, интересную аналитическую in-process базу данных, про которую рассказывали в докладе "DuckDB: Crunching Data Anywhere, From Laptops to Servers • Gabor Szarnyas • GOTO 2024 ", который я уже разбирал. Но если возвращаться к самой статье, то основной посыл Джордана в том, что эпоха «больших данных» как доминирующей концепции завершилась. Суть в том, что большинство организаций на самом деле не работают с огромными объемами данных, и акцент должен сместиться с размера данных на получение практических инсайтов. Ключевыми идеями статьи являются

1) Рассмотрение хайпа больших данных через призму реальности: нарратив о том, что компании перегружены огромными объемами данных, не оправдался для большинства организаций. Хотя объемы данных растут, развитие аппаратного обеспечения и технологий баз данных опережает эти темпы, делая традиционные системы достаточными для многих задач.
2) У большинства компаний умеренный объем данных: анализ клиентских данных Google BigQuery показывает, что большинство организаций управляют относительно небольшими наборами данных, часто менее 1 терабайта. Даже крупные предприятия редко генерируют или обрабатывают действительно огромные массивы данных, а типичные рабочие нагрузки затрагивают лишь небольшую часть хранимой информации.
3) Разделение compute и storage: современные облачные архитектуры разделяют хранение и вычислительные ресурсы, позволяя масштабировать их независимо. Это привело к росту объема хранилищ при тех же вычислительных потребностях, так как аналитика чаще сосредоточена на актуальных или агрегированных данных, а не на исторических архивах.
4) Экономические и практические ограничения: обработка больших объемов данных дорогостоящая и зачастую избыточная. Такие технологии, как колоночное хранилище, отсечение разделов и сжатие данных, сокращают объем обрабатываемой информации, что соответствует экономическим стимулам минимизировать затраты.
5) Данные как источник риска: хранение большого количества неиспользуемых данных может создавать риски, включая проблемы с соблюдением нормативных требований (например, GDPR), юридическую ответственность и операционные сложности из-за «старения» старых наборов данных.
6) Спад популярности систем для больших данных: традиционные монолитные базы данных (например, MySQL и Postgres) демонстрируют рост популярности, тогда как масштабируемые системы вроде NoSQL стагнируют. Количество рабочих нагрузок, требующих распределенных систем, сократилось благодаря значительному увеличению возможностей одиночных машин.

Напоследок Джордан предлагает компаниям оценивать свои реальные потребности в работе с данными вместо того, чтобы следовать маркетинговым нарративам о «больших данных». Большинство организаций могут извлечь выгоду из инструментов для управления данными меньшего масштаба вместо инвестиций в системы для гипотетически огромных массивов информации. Кстати, одним из таких инструментов может быть и DuckDB (это читается между строк).

P.S.
В продолжении темы можно изучить
1) Статью "What Goes Around Comes Around... And Around..." Майкла Стоунбрейкера, создателя Postgres, и Эндрю Павло, исследователя баз данных, про развитие СУБД за последние 20 лет. У меня есть краткий обзор в трех частях: 1, 2 и 3
2) Выступление от создателя DuckDB "A Short Summary of the Last Decades of Data Management • Hannes Mühleisen • GOTO 2024" и мое краткое саммари
2) Подкаст "Research Insights #6 с Колей Головым про дата платформы"
3) Подкаст "Code of leadership #22 с Димой Аношиным про data engineering"

#Database #Architecure #Software #Data #SystemDesign #Engineering

Quantum Computing Inches Closer to Reality After Another Google Breakthrough (Рубрика #Physics)

Интересная статья вышла на этой неделе в New York Times, в которой рассказывается про последние достижения Google в области квантовых вычислений. Суть в том, что Google заявляет о достижении "квантового превосходства", так как их квантовый компьютер на чипах Willow решил синтетическую задачу за минуты, а классическим суперкомпьютерам на архитектуре фон Неймана потребовались бы септиллион лет (10^24 лет). Звучит конечно круто, но так как задача синтетическая, то пользы от нее можно не ждать, но при этом достижении ребята из Google смогли преодолеть проблему коррекции ошибок. Суть в том, что квантовые компьютеры состоят из квантовых битов или кубитов, которые изолированы от окружающей среды и заморожены до сверхнизких температур. Вычисление представляет собой последовательное измерение функции Шредингера для системы из всех кубитов, чтобы в конце прийти к состоянию, где наиболее вероятным состоянием при измерении будет то, что дает правильный ответ. Вся эта машинерия может очень интересно сбоить, поэтому в процесс надо встраивать коррекцию ошибок, которая в этом компьютере ребят преодолела некоторый порог, который приближает всю эту конструкцию к практическому применению. В общем, по всем характеристикам это крутое событие, что усилит конкуренцию между технологическими гигантами, каждый из которых делает свои квантовые компьютеры. В интересное время мы живем.

P.S.
Рекомендую почитать книгу Алексея Семихатова "Сто лет недосказанности: Квантовая механика для всех в 25 эссе", про которую я рассказывал недавно.

#PopularScience #Physics #Software #Architecture #Engineering

TDR — процесс технического дизайн-ревью / Павел Лакосников (Авито) (Рубрика #Architecture)

Интересный доклад Паши Лакосникова из Авито про принятие качественных технических решений в большой компании. Основные тезисы примерно следующие
1) Сам Паша давно работает в Авито и сейчас занимается выстраиванием architecture governance
2) По мере роста компании все сложнее принимать качественные решение из-за роста чимсла команд и усложнения иерархии
3) Компании часто вводят роли техлидов и архитекторов для решения этих проблем
4) Это приводит к тому, что инженеров отстраняют от принятия решения и они теряют мотивацию и ответственность за принятые без них решения
5) Дальше появляется архитектурные комитеты и архревью, где рассматриваются архитектурные артефакты и принимаются решения
6) Если все решения прогонять через архкомитет, то он становится бутылочным горлышком и замедляет работу, а также стоит много-много денег
7) Следующий шаг - это дизайн ревью решений в асинхронном формате
😍 Для этого нужны шаблоны документов для описания технических решений + автоматическая валидация их заполнения. В документе должны быть: автор, команда, юнит, дата создания, уровень влияния (низкий, средний, высокий), сроки ревью.
9) Дальше появляется реестр таких документов и возможность поиска и анализа решений
10) Инициативы делятся на разные уровни, которые требуют ревью разной строгости и формата
11) Уровни влияния помогают разным стейкхолдерам отслеживать только нужные им инициативы, например, техдиры могут отслеживать самые крупные изменения
12) У технических инициатив есть связь с продуктовыми, что позволяет лучше понять для чего мы делаем изменения и насколько они оправданы
13) У инициатив есть жизненный цикл: прототип, эксперимент, масштабирование. Каждый этап имеет свою детальность проработки. А также можно фиксировать зависимости между командами и компонентами для предотвращения ошибок.
14) Так как в инициативах указываются затронутые компоненты, то их владельцы получают уведомления и могут прийти поревьювить инициативу, в которой они упоминаются
15) Наличие реестра обеспечивает историчность принятия решений + позволяет настроить валидацию принятия решений, чем отдельные роли: авторы, контрибьюторы, FIY и owners
16) Реестр можно связать с техническим радаром, который должен быть входной точкой в жизненный цикл технологий.
17) Все это обеспечивает прозрачность появления и развития технологий, а также их depracation и миграции с EOL (end of life)
18) По всей этой машиенрии можно собирать метрики: количество decision records, время их прохожджения, доля успешно доведенных до конца и так далее
19) Внедренный процесс помогает решить проблему с архитектурными комитетами, а также повысить вовлеченность инженеров

P.S.
Про то, как это устроено у нас было в постах
- Серия подкаста "Code of Leadership" - Interview with Anton Kosterin about Architecture Governance
- Мое выступление на ArchDays 2024 - "Архитектура в Т-Банке: вчера, сегодня, завтра"
- Серия подкаста Research Insights Made Simple про "API Governance at Scale", где мы с Даниилом Кулешовым разбирали whitepaper о том, как это устроено в Google, а также говорили про governance у нас в компании

#Architecture #Software #DistributedSystems #SystemDesign #SystemEngineering #API #Governance

Enabling efficient analysis of biobank-scale data with genotype representation graphs (Рубрика #Data)

Наткнулся тут в рассылке от ACM (Association of Computing Machinery) на новость, что отлично демонстрирует то, что большие данные уже не такие большие:) Собственно, в генетике данных было всегда много после того, как ученые научились расшифровывать геном. Но эти данные надо было уметь где-то хранить и быстро лопатить для того, чтобы извлекать инсайты. И теперь ученые-исследователи из Корнелла разработали новый метод сжатия данных, который позволяет хранить большие геномные наборы данных на локальных компьютерах. Раньше эти данные весили сотни террабайт, а теперь они жмутся в гигабайты. Этот метод, названный Genotype Representation Graph (GRG), описан в статье, опубликованной 5 декабря 2024 года в Nature Computational Science. GRG использует графы для представления генотипов, что позволяет компактно и интуитивно кодировать информацию о геномах, а также выполнять вычисления без необходимости разжатия данных. Это делает анализ биобанковских данных более эффективным и менее затратным. В отличие от традиционных матричных представлений, GRG фиксирует связи между индивидами через общие мутации в их геномах. Метод был разработан для решения проблемы роста объема данных, который теперь может достигать петабайтов из-за увеличения доступности полногеномных последовательностей. GRG обеспечивает масштабируемость и точное представление данных, позволяя проводить сложные анализы, которые ранее были недоступны из-за высокой вычислительной стоимости.

Исследование уже привлекло внимание научного сообщества, и другие ученые начали тестировать метод на различных наборах данных. Работа поддержана грантом Национального института здравоохранения США.

#Data #Math #Software #Whitepaper

Evolution of software architecture with the co-creator of UML (Grady Booch) (Рубрика #Architecture)

Интересная серия подкаста с Гради Бучем, на книгах которого я учился в самом начале карьеры:) Гради придумал объектно-ориентированное проектирование и "метод Буча", который был предтечей UML. Дальше он вместе с Rumbaugh и Jacobson стал создателем языка UML (Unified Modeling Language), а также основал компанию Rational Rose, которую 20 лет назад купил IBM. Сразу после покупки Rational Гради стал Fellow внутри IBM и, судя по разговору в подкасте, именно это ни один раз его спасало от увольнения (как я понял Fellow нельзя так просто взять и уволить). В следующем году Гради исполнится уже 70 лет, но он бодр и полон сил.
Сам подкаст затрагивает следующие основные темы
1) Эволюция разработки ПО: разработка программного обеспечения - это история повышения уровня абстракции, где современные фреймворки и облачные сервисы стали ключевыми архитектурными решениями.
2) Роль архитектора изменилась: теперь архитектор решает системные проблемы и управляет более абстрактными уровнями системы.
3) Гради Буч примерно 20 лет назад получил предложение от Билла Гейтса стать Chief Architect всего Microsoft, но он отказался и сосредоточился на работе в IBM, в частности, в области искусственного интеллекта (помогал делать IBM Watson).
4) UML был создан для описания систем на разных уровнях абстракции и впоследствии стал стандартом. Несмотря на это, со временем его использование уменьшилось из-за сложности, которая появилась в версии 2+. Кстати, я действительно помню, как сложность скачком увеличилась и UML начали двигать от визуализации архитектуры в сторону языка прогаммирования, из которого можно генерить код на обычных языках
5) Среди современных вызовов есть следующие
- В bigtech компаниях иногда используют формальные методы для описания алгоритмов распределенных систем - это нужно для сложных случаев
- AI и LLM сейчас на коне, но Гради отмечает их потенциальные ограничения и опасности.
6) Эволюция архитектуры произошла из-за распределенных систем, которые потребовали новых методов обмена сообщениями между частями системы. А современные архитектурные решения часто зависят от предварительно созданных компонентов и API, что снижает риски и затраты на создание систем.
7) Напоследок Гради дает совет, что начинающим инженерам-программистам не стоит бояться экспериментировать и учиться новому.

#DistributedSystems #Architecture #Software #SystemDesign

CMMI (Capability Maturity Model Integration) (Рубрика #Management)

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

Изначальную версию CMM (Capability Maturity Model) разработал SEI (Software Engineering Institute) внутри Carnegie Mellon University в конце 1980х годов для Department of Defense. Цель была в том, чтобы улучшить практики разработки софта в этом ведомстве. К 2000 году CMM объединило в себе разные модели зрелости и расширилось на еще одно слово Integration, чтобы выйти в свет в виде модели CMMI и увеличить границы применимости.

Фреймворк строился вокруг концепций возможностей и зрелости
- Возможности относились к способностям организации достигнуть бизнес-цели через хорошо выстроенные процессы
- Зрелость отображала концепцию эволюции процессов во времени от ad-hoc до файнтюна и вылизывания выстроенных процессов:)

Фокус был на определении, имплементации и непрерывном улучшении процессов для обеспечения консистентности и эффективности. Фреймворк включал цели и лучшие практики для помощи в движении к лучшим процессам. В нем были следующие уровни зрелости
1) Initial: непредсказуемые и реактивные процессы (условно реакция по факту произошедшего события)
2) Managed: процессы планируются и выполняются с учетом политик
3) Defined: процессы хорошо описаны и стандартизированы
4) Quantitatively Managed: процессы измеримы и контролируются с учетом статистических методов
5) Optimizing: фокус на улучшении процессов через инновации

Адепты этого подхода упирали на плюсы фреймворка
1) Increased efficiency and productivity - это достигалось за счет стандартизации и оптимизации, что приводило к выравниванию workflow и лучшему распределению ресурсов
2) Quality improvement - предполагалось выравнивание процессов на требования заказчиков для повышения качества продуктов и удовлетворенности клиентов
3) Competitive advantage - достижение высоких уровней зрелости выделяло компании на рынке, что показывало их приверженность лучшим практикам (особенно актульно для сервисных компаний, что делают проекты на заказ)
4) Scalability - фреймворк позволял организациям масштабироваться по мере роста и наработки какой-то специфики

А среди недостатков выделяли
1) Complexity and cost - имплементаци CMMI была комплексной, требовала кучу времени и была дорогой из-за выделения значительных ресурсов, тренировок и документации
2) Rigidity - модель была негибкой, а также предотвращала внедрение новых практик и технология, что появлялись после ее внедрения
3) Bureaucracy - модель требовала значительного количества документов, что повышало уровень бюрократии и снижало гибкость и креативность (ака без бумажки ты букашка)
4) Lack of customizability - эта общая модель не всегда хорошо натягивалась на любую организацию (например, на bigtech компании, что взлетали в начале 2000-х), что ограничивало такие организации, если они пытались внедрить CMMI

В итоге, я видел внедрения CMMI в начале 2000х в сервисных компаниях (галерах), которые работали на рынке заказной разработки, но не слышал ни про одну bigtech компанию, принявшую эту модель. Я думаю, что причина в том, что на вопрос "А какую проблему мы решаем" эта модель CMMI не дает никакого ответа внутри продуктовой компании.

Я думаю, что надо фокусироваться на конкретных практиках, что решают конкретные проблемы, например,
- Процесс написания RFC и фиксация арх решений в ADR
- Ведение техрадара в организации
- Как работать с надежностью систем: observability, SLI/SLO/SLA, бюджет ошибок
- и так далее

Но вот в упор не могу понять на...я выбивать уровень 5 CMMI кроме как порадовать своего внутреннего бюрократа.

#Processes #Management #Metrics #Leadership #Software

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

В очередном уроке Игорь Манн рассказывает про построение личного бренда. А уж он знает в этом толк:) Из этого урока я вынес следующие основные идеи

1) Личный маркетинг (что равно личному бренду) начинается с постановки цели и аудита самого себя. А еще он должен быть системным
2) Для этого можно задать себе четыре главных вопроса: кто вы, что вы делаете, как вы это делаете и как об этом узнают.
3) Личный бренд помогает целевой аудитории запомнить вас и выбрать ваши выступления, статьи и книги.
4) К этому вопросу надо подходить системно и работать параллельно над качеством и узнаваемостью
5) Вообще, это про инвестиции в себя, в образование, книги, внешний вид, благоприятные условия для жизни, работы и новых впечатлений
6) Игорь советует начать заниматься личным брендом сразу, а не тогда, когда вы набьете 10к часов в своей области и станете экспертом
7) В личном бренде важно постоянство - нельзя делать это иногда или по настроению
😍 Игорь говорит, что важно быть хорошим профессионалом, а уже затем хорошим человеком (это из серии, что хороший человек - это не профессия)
9) Автор отмечает необходимые навыки, которые нужны человеку доверие, коммуникабельность, умение общаться с ИИ, инициативность, тайм-менеджмент, личную эффективность, умение продавать и стрессоустойчивость, умение доводить дела до конца и проявлять упорство.
10) А дальше можно оценить свои навыки и понять, что требуется просто поддерживать, а над чем надо поработать
11) Игорь говорит о важности самопрезентации и предлагает упражнение "100 слов о себе", а потом экстремальные "3 слова о себе"
12) Для личностного роста нужны вызовы, которые делают тебя сильнее (прямо как по Ницше)
13) Секрет профессионального долголетия Игоря в том, что он постоянно занимался самообразованием и стремился стать номером один в своей области.
14) Важно иметь хорошие отношения в семье и уделять ей достаточно времени, а также окружать себя интересными людьми и работать над своим нетворкингомЁ
15) Можно сделать SWOT анализ самого себя и понять сильные и слабые стороны, а также расписать возможности и угрозы
16) Важно правильно работать с самооценкой и уметь преодолевать синдром самозванца
17) В этом могут помочь сравнения с более ранней версией самого себя или крутыми конкурентами
18) Также полезны профессиональные достижения и признание людей
19) Но для всего этого надо работать много, системно и по приоритетам
20) Для того, чтобы это сделать нужно уметь отвечать на вопрос "А зачем мне это нужно":)

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

#SelfDevelopment #PublicSpeaking #Storytelling #Writing