Руслан Сафин ♟️

Твит для закрепа. Несмотря на то, что мой курс по проектированию микросервисной архитектуре теперь можно купить отдельно (t.me/rsa_enc/330), почти все теоретические материалы есть и будут в открытом доступе. Ссылки в треде:

@tatarmagister У меня тоже 2 из 3 заграниц в этом году – нерабочие )

@razonrus Выезды за границей только во время отдыха.

Горы 2024. Питер → Стамбул → Питер → Челябинск → Питер → Москва → Питер → Сколково → Питер → Москва → Питер → Казань → Иннополис → Казань → Питер → Новосибирск → Екатеринбург → Питер → Челябинск → Питер → Москва → Питер → Терскол (Эльбрус) → Питер → Выборг → Питер → Тбилиси → Питер → Москва → Питер → Челябинск (Таганай) → Питер → Москва → Питер → Алматы → Питер → Сколково → Питер → Пермь → Питер → Челябинск (Тургояк) → Питер перелетов: 25 поездов: 12 А следующий перелёт уже послезавтра 🛫 – и снова горы

Спасибо вам! За все сердечки и огонёчки и слова 🥰 Это меня драйвит и заряжает энергией двигаться дальше! 💙

Поздравление Сергея Борисовича Переслегина с новым годом. Вдвойне приятно, что я лично присутствовал на упоминаемой деньрожденческой лекции "Россия. Предрассветные годы" youtu.be/uSH61pmk1xM Рутуб: rutube.ru/video/private/…

Подвёл (😉) итоги года! 🥂 vc.ru/dev/1729640-20…

Всех с наступающим! Всех жду 31 мая в Новосибе! Мы готовим нечто воистину особенное! 🚀 #codefest

@sharslammer хахах, получается надо сюда перестать публиковать то же самое, что и в канал, чтобы там нарастить подписчиков? )))

@razonrus я пока не подпищик, потому что не читатель телеграма, мне тут удобнее по ссылкам переходить

Разбор моего телеграм-канала "Архитектура распределённых систем" (t.me/rsa_enc) от Дениса Бескова: t.me/denis_beskov/3… ❤️

@gaxeliy Просто дублирую туда некоторые записи из канала про ит-архитектуру и некоторые твиты ))

Коллеги, пишете что-нибудь на linkedin? Интересно просто, как люди живут в этой соцсети. Мне она кажется чудовищно скучной, но кажется, что забивать на нее - плохая идея.

@gaxeliy ахах, я выбрал самый непопулярный вариант ))

Выберете единственный верный путь!

В Питер пришел снег

Как бы мы не были завалены работой, мы всегда сможем её развалить

Отчётный ролик CodeTalks 2024: youtu.be/l0jXvHJPGPM?si…

А теперь и в виде статьи на Хабре: habr.com/ru/articles/86… ➕'аните, если считаете полезным/интересным 😊

Про документацию, неоднозначность термина "as Code" или вопросы от подписчиков. > Руслан, привет!) а подскажи пож-та, может есть у тебя ссылочки на шаблоны/примеры/лучшие практики по документированию архитектуры и инфраструктуры системы Вопросы документирования и особенно актуальности документации — на мой взгляд, одни из самых больных в нашей с вами айтишечке. Но, если дело касается сущностей, которые мы можем описать кодом (или как код) — всё становится сильно проще. 1️⃣ Лучшая документация — это всегда актуальная документация. Такой вариант возможен только в двух случаях: 🌹 при автоматической генерации документации (описания) из реального положения дел (для исполняемого кода API таким примером будет Swagger) 🌹 или же наоборот — генерации "реальности" из описания (в случае Infrastructure as Code примером может быть разворачивание инфраструктуры из её описания в yaml-формате). 2️⃣ Если лучший вариант нам недоступен, то хорошо бы нам хотя бы иметь автоматический сигнал о том, что наша документация разъехалась с реальностью (или наоборот). 🚨 Источником такого сигнала должны стать тесты — мы их можем и будем запускать при любом изменении и системы (реальности), и её описания. И в случае расхождения тесты должны падать (блокируя тем самым дальнейшее попадание порождающих несоответствие изменений в основную ветку/новый релиз и т.д.). Базовое свойство тестов — они должны быть воспроизводимы и независимы от внешних условий. Именно поэтому ручные проверки не попадают в эту категорию (регламентированная ручная проверка на актуальность документации при каждом тестировании не работает, т.к. имеет в основе своей человеческий фактор). 3️⃣ а вот третьего, на мой взгляд, не дано. Либо у вас есть автодокументация, либо есть автоматизированные тесты, проверяющие актуальность. В противном случае — всё, ваша документация рано или поздно в бо́льшей или меньшей степени, но станет неактуальной. Без вариантов. И никакими оффлайн-процессами или регламентами это не решить. Есть, конечно, ещё один граничный случай — это когда в проект никаких изменений не вносится.. Но это означает, что проект мёртв, и этот случай нам неинтересен ⚰️ Итак, возвращаясь к архитектуре и инфраструктуре. 🌺 Начнём с инфры. Если у вас реализован подход Infrastructure as Code (IaC) и всё разворачивается из кода (описания) инфры — то уже всё хорошо. По сути ваши yaml или другие файлы и являются документацией (сюда попадает не только статичная инфра, но и различная инфраструктурная логика: мониторинг и правила алертинга, например). А если хочется иметь документацию по инфраструктуре в более удобном и наглядном виде — всегда можно написать различные генерилки/визуализаторы из yaml и json в красивый текст и схемки (или даже интерактивный, как у Swagger). А возможно, такие инструменты уже и существуют (накидайте, плиз, если да). 🌺 С архитектурой всё чуть сложнее. Подход Architecture as Code (AaC) в отличие от IaC не предполагает, что по описанной в коде архитектуре всё будет разворачиваться и работать согласно ей. В большинстве случаев предполагается лишь описание архитектурных схем кодом из которого генерируется картинка, а не просто картинкой. В таком случае Architecture as Code на самом деле всего-то навсего Architecture Scheme as Code ☹️. Т.е. не сама ИТ-архитектура, а лишь опять же её документация в виде схемки или нескольких. Тут некоторые читатели могут задаться вопросом — а что же такое ИТ-архитектура, если не просто схемка или набор схемок? Готовясь к одному из своих докладов, я гуглил разные определения ИТ-архитектуры. И к своему удивлению нашел одно из лучших, на мой взгляд, в стандарте (ANSI/IEEE Std 1471-2000): «Фундаментальная организация системы, реализованная в её компонентах, их взаимоотношениях друг с другом и средой и принципах, определяющих её конструкцию и развитие» Т.е. архитектура — это даже больше чем просто "описание реальности" как IaC, но и принципы, определяющие в том числе и её развитие (т.е. будущее). Но сейчас не об этом... Про то, что такое архитектура надо будет как-нибудь отдельный пост написать 🙂 (и это на 4й-то год существования моего тг-канала (t.me/rsa_enc) со словом "архитектура" в названии 😅😆 ). Скрепя сердце приравняв архитектуру к документации, вернемся к вопросу актуальности этой документации. Описав архитектурные схемки кодом (т.е. применив AaC) мы можем пойти описанными выше путями в плане автодокументации или тестов на актуальность, но для этого нужны ещё инструменты над AaC (см. ниже). Т.е. всё-таки as Code нам помогает, хоть и в меньшей степени, чем в IaC, где as Code уже гарантирует соответствие реальности и описанию (коду). Вот так, размышляя о документации, мы пришли к выводу о различии подходов, называемых as Code в инфраструктуре и архитектуре 🥲. А теперь обещанные ссылки на мои инструменты, если кто ещё не видел. Разделы Open-Source репозитория (github.com/Byndyusoft/aact) с инструментами и примерами: - автогенерация архитектуры: github.com/byndyusoft/aac… - тесты на актуальность архитектуры: github.com/byndyusoft/aac… Статья про покрытие тестами: habr.com/ru/articles/80… Общий доклад про все инструменты: rutube.ru/video/8ed42e50… Оффтоп. И всё-таки, согласно в том числе и определению из стандарта, архитектура — это в том числе и принципы на которых она построена, а один из способов описания таких принципов (ещё и сразу же автоматизирующий проверку их выполнения) — это тесты на соблюдение архитектурных принципов: github.com/byndyusoft/aac… Всё. Теперь точно всё ) ❤️

ахахах )

@oldValkyrie А в один твит при купленном премиуме влезло! 😂 x.com/razonrus/statu…

@oldValkyrie хахах, это не я )) хотя как раз в итоге вчера этот пост в дзен и засунул 😅 dzen.ru/a/Z1deq4C9ZzIw…

Мне тут прислали на вычитку статью-интеграцию для Дзен. 18 страниц в ворде. Кто ж такое вообще прочитает? (думаю, никто)

о, у меня про это есть на одном из слайдов из доклада выше. Сейчас замыслы описываю в ADR, и если удается — в виде теста. И в посте годичной давности: > ...Суть в первичности инженерного решения, а не в его проверке на последнем этапе зацикливания обратной связи. Суть в автоматической генерации реализации принятого решения, уничтожения самой возможности совершить ошибку, т.е. хрупкости, а не в проверке на хрупкость путём краштеста с находящимся за лобовым стеклом манекеном из времени разработчика и денег заказчика. t.me/rsa_enc/171

@razonrus И поэтому у меня вопрос тот же что и к Пионтику: мы идём от замысла. А где он? За нашим замыслом уже идут разрабы и аналитики