Про велосипеды, продолжение.

Чем зацепила статья из поста выше? Конечно же, формулировки смешные ("про Кубу и Министерство обороны США") и тезисы броские ("отрыв коммерческих инноваций от производства", "зацикленность монополии на затратах, контроле и муторном регулировании"). Но самое главное – это абсолютно понятный любому айтишнику разговор о среде, которая генерирует и поддерживает инновации.

Анализ, проведенный Шьямом Санкаром, удивительно подтверждает выводы, сделанные двадцать пять лет назад Эриком Реймондом в его знаменитой статье «Собор и базар» о модели разработки операционной системы Linux. (Если кто-то вдруг не читал, вот ссылка на перевод)

Когда одни выпускают кукурузные хлопья и системы наведения, другие – алюминиевые банки и первые ступени ракет, и так далее, это типичный «базар». Его реорганизовали в строгий «собор» из пяти крупных компаний с долгосрочным финансированием и "выстроенными" процессами. «Собор», казалось бы, должен был обыграть «базар» в одну калитку, однако, если верить автору статьи, получилось ровно наоборот ( "консолидация породила конформизм").

А при чем здесь "велосипеды" спросите вы? "Велосипеды" это и есть инновации. Нет никаких формальных критериев, позволяющих на ранних этапах отличить «велосипед» от перспективной инновации. На старте они выглядят совершенно одинаково – как "велосипед". Решающий фактор отбора перспективных решений – количество попыток, предпринятых независимыми экспериментаторами.

#велосипеды

Чуть флуда на этом серьёзном канале.

Сегодня исполняется 30 лет с момента выхода мажорной версии JDK 1.0.

У меня в связи с этим своё воспоминание: где-то в 1998 году я пришёл к нашему зам. директору Владимиру Александровичу, светлая ему память, и говорю: «Технология перспективная, надо переходить». (Всё, что у нас было в тот момент, работало на SCO Unix и на C/C++.) Долго я его этим вопросом доставал. Собрали какое-то совещание, все послушали про "write once, run anywhere" и сказали: «На фиг-на фиг». Я, конечно, расстроился слегка.

Уже после совещания он меня спрашивает:
— Сколько этой твоей Java ресурсов то надо?
— 4 Мб памяти минимум.
— Ну вот видишь, а у нас, у нас во всех филиалах на рабочих местах 640 Кб.

Да путь к инновациям никогда не бывает легким.
Всем, кто продолжает сегодня писать на Java, физкульт-привет!

Про велосипеды. Окончание

Никак не мог дописать про велосипеды. Крутится в голове разное: велосипеды, Калашников, реформа американского ВПК, Айзек Азимов, князь Кропоткин, анархисты... Поэтому дальше будет набор несвязных мыслей.

"Велосипедом" принято называть попытку сделать уже сделанное по следующим причинам:
- не смогли нагуглить;
- нагуглили, но было лень дальше читать;
- чтобы чтобы упростить сложную реализацию;
- чтобы приспособить старую реализацию к изменившимся условиям.

И выглядит это, как правило, совершенно нерационально. Зачем «изобретать велосипед», когда нужно правильно пользоваться проверенными решениями? И вроде действительно так, но есть несколько «но». Первое — упрощение, это самый главный инженерный навык. Великий Михаил Калашников, в начале своей карьеры, услышал от другого великого конструктора Георгия Шпагина* присказку, которую повторял всю жизнь: «Самое сложное — это сделать просто». Второе — а откуда, собственно, берутся проверенные надёжные решения? Из требований пользователей? Ну, если вы никогда не слышали про Айфон, вы вряд ли знаете, что он вам нужен. Они берутся из попыток сделать что-то по другому, иногда из наивных, как правило нерациональных, иногда рискованных, и всегда интересно понять, почему они вдруг делаются и как выживают, превращаясь в зрелые проверенные решения.
*(на всякий случай, Г. С. Шпагин — это конструктор автомата Победы, ППШ, такого с круглым магазином, и один из конструкторов пулемёта ДШК)

У Айзека Азимова был рассказ «День знаний», в котором цивилизация достигла такого прогресса, что все нужные знания прошиваются обучающимся прямо в мозг, а вся специализация, карьера, весь жизненный трек человека определяются на основании тестирования подростка машиной. И в этом обществе был очень небольшой процент «бракованных» персонажей, непригодных ни к какой прошивке; единственное, чем они были полезны, — они могли создавать новые знания, те самые обучающие программы, которые прошивали всем остальным. Те из них, из кого учёных в результате не получилось, становились коучами и психологами. Возможно что «изобретатели велосипедов» из тех самых, из «бракованных».

#велосипеды

Про велосипеды. Окончание.

Что еще зацепило в статье Шьяма Санкара? Эта статья — программный манифест одного из кандидатов на должность заместителя министра обороны США, и основной её тезис — «Развитие не может быть регламентированным, развитие всегда хаотично».

Это пишет представитель культуры, которая вся про «how much», про измерение всего и рациональное управление. И шутки про Министерство обороны США и Кубу, про проигрыш великих американских автоконцернов в конкурентной борьбе японцам, они приведены как обоснование идеи, что «научное и рациональное» управление развитием не работает, и придётся выбирать.

Можно спросить: «А нам-то зачем всё это читать?» Мы ведь живём в другой экономической реальности и вообще люди другой культуры. И тут вот что интересно: одно из направлений общечеловеческой мысли, в которое русские внесли наибольший вклад, — это анархизм. Явление, бывшее очень популярным в России в конце XIX — начале XX века, яркое, сложное, сейчас почти забытое, упрощенное до нескольких клише: революционные матросы, Нестор Махно и лозунг «Анархия — мать порядка» (лозунг, кстати, принадлежит французу Пьеру-Жозефу Прудону).

И тут что интересно, на этом обычно не делают акцент, но программное обеспечение с открытым исходным кодом — это просто образцовая реализация идей князя Кропоткина. Наш любимый Agile тоже, анархисты называли команды артелями, на роли скрам-мастеров акцентов не делали, но на этом сущностные различия заканчиваются. В основе Agile лежат идеи анархистов, примененные к специфической технической отрасли, где основой производства являются не ресурсы, машины и механизмы, а обмен информацией и идеями между людьми.

Заканчивая этот поток путаных мыслей… Обычно фразу «Анархия — мать порядка» произносят с такой же коннотацией, как и «Изобрести велосипед», мол, хотите внести беспорядок и дезорганизацию в наши дела. Я, собственно, всегда так её и понимал и использовал, но статья Шьяма Санкара заставила ещё раз задуматься. Она написана по «очень серьёзному поводу» и для «очень серьёзных людей», но написан в ней буквально тот же лозунг, ну или я это так прочитал.

#велосипеды

Про нестареющую классику

В середине 90-х идея «Шаблонов» захватила информационное пространство, почти так же, как сегодня LLM-модели. Самой известной книгой той эпохи является, конечно, труд Эрика Гаммы и соавторов «Design Patterns». Однако были и другие работы: серия «Pattern-Oriented Software Architecture» Франка Бушмана, «Enterprise Integration Patterns» Грегори Хопа, «Patterns of Enterprise Application Architecture» Мартина Фаулера.

Самая первая книга Мартина Фаулера немного выбивалась из общего ряда — она называлась «Analysis Patterns» и была посвящена шаблонам анализа. К сожалению, эта работа на русский язык никогда не переводилась. Но вот недавно некий добрый человек выложил в открытый доступ свой перевод этой книги. Несмотря на то, что прошло почти 30 лет, описанные в ней подходы по-прежнему актуальны не только при разработке структуры классов, но и при проектировании микросервисных архитектур.

Статья: habr.com/ru/articles/872598
Перевод: violettape.github.io/ap_book/cover.html

P.S. Новость нашел на канале Кати Лысенко

Следим за успехами Архитектура как Код

Сегодня сложно себе представить платформу по работе с кодом без ИИ АССИСТЕНТА. DocHub не отстаёт. На примере Романа co-pilot помогает в написании документации и предлагает варианты заполнения архрешения. Думаю качество решений будет только расти. Пользуйтесь!
#aaac

AI теперь в DocHub официально!

Долгий был путь к разработке внятной интеграции AI ассистентов в DocHub. Но, наконец, инфраструктурные метания завершены. Ассистент встроен и совместно со мной проходит тесты наполняя документацией новый портал DocHub!

Впереди еще большая работа по его улучшениям. Но в целом, уже сейчас он реально облегчает мне задачу документирования.

Шаблоны проектирования

Совсем недавно вспоминали прошлый век и "Analysis Patterns", а сегодня прочитал у коллеги на канале про AI шаблоны.

P.S. Канал кстати хороший, я читаю.
Ну и к Мартину Фаулеру на сайт надо заглянуть обязательно. У меня ощущение, я не знаю почему, что эти технологии: микросервисы, архитектура как код, и AI помощники где-то должны встретиться и дополнить друг друга. Как конкретно, я пока не понимаю, но ощущение есть и давно что встретиться должны на нашей платформе.

https://t.me/javaKotlinDevOps/387

Микросервисы

Куда сейчас без них? Мы привыкли слышать про микросервисы в интеграционных приложениях или в высоко нагруженных бэкофисах. Но только этими областями применение микросервисов не ограничивается.

Сегодня в 13.00 коллеги расскажут про микросервисы в моделировании процессов нефтегазохимической промышленности. Интересно будет сравнить с собственным опытом. Заходите послушать.

https://t.me/fielddev/471

Классика

UML, если кто вдруг не помнит, родился как объединение трех нотаций. Одна из них называлась нотацией Якобсона.
Ивар Якобсон это тот самый человек который ввел в широкое использование понятие Use Case Diagram.

Очень старая (2017) но интересная лекция Ивара Якобсона

https://2017.secrus.org/program/submitted-presentations/kill-all-methods-free-the-practices

Еще про цифровые двойники. Нашел интересный референс в НефтеГазовой индустрии. Идея похожа на то что предлагалось для микросервисного проекта https://t.me/SynapseDevCommunity/50.

Каждая единица оборудования (в нашем случае это микросервис) описывается набором уравнений. Оборудование собирается в проект (в нашем случае цифровая архитектура) и получается цифровой двойник промышленного объекта.

Преимущество этого решения в том что на самом промышленном объекте не нужно организовывать хранение большого объема данных. Для запуска цифрового двойника достаточно локального компьютера. При необходимости цифровой двойник можно откалибровать под конкретный пром.объект.

Полная запись вебинара по ссылке

#DigitalTwin

Ролик про разработчика который пришел к архитектору выбирать себе платформу

На прошлой неделе прошла 10-я, юбилейная DevOpsConf "Профессиональная конференция по интеграции процессов разработки, тестирования и эксплуатации".

Честно говоря мне она кажется даже интересней чем более "престижный" ХайЛоад. В этом году четко заметен тренд на создание внутренних платформ. Тренд видимо был давно, те кто вышли в этом году с докладами, начали работы 4-5 лет назад. В этом году заметны уже результаты тренда.

Может это мой личный вкус, но самый интересный доклад был тот где прямо начали с вопроса - а кто клиент внутренней платформы?
И на следующем слайде ответили на вопрос, что основной клиент внутренней платформы - это разработчик.
Получился прямо классический рассказ про "Customer jorney map".
Возможно следующим этапом развития станет унификация и появления коммерческих developers platforms, будем следить.
Я надеюсь частью докладов, с разрешения авторов получится поделиться.

P.S. На фото вместе с Максом и Всеславом смотрим в прекрасное платформенное будущее с оптимизмом

И чтобы "два раза не вставать" еще про внутренние платформы, поделюсь свежим постом в котором хорошо и подробно разобрали плюсы и минусы
https://t.me/cto_govorit/95

Бывает такое, что давно уже перешли в Кубер, и вдруг хочется об этом ещё раз поговорить? Вот и с нами случилось.

Во-первых — вы уже перешли;
во-вторых — давно;
в-третьих — а вдруг кто-то переходил иначе?
в-четвёртых — а кто-то ещё и вовсе не перешёл?

Так у нас для него столько разных полезных советов есть! Чего ж они у нас просто так лежат? Советы эти. Тем более мы давно перешли.

24.04 заходите послушать митап и чего-нибудь спросить.
Попробуем рассказать про все вместе, но по порядку - Platform V DropApp (K8s), Platform V Synapse Service Mesh и Platform V SberLinux OS Server

Ссылка

Привет всем.

Организаторы DevOpsConf 2025 уже поделились с докладчиками видео их выступлений и есть возможность, в свою очередь, тоже поделиться.

Про то как организовать команды в большой девопс платформе.

Доклад Рашида Галиева "От DevOps инженеров к сервисным DevOps командам"

https://www.youtube.com/watch?v=ZhcSovOZjJ8

Смотрите, комментируйте.

#доклады

В следующем докладе подробный рассказ об общих принципах организации ИТ инфраструктуры и немного цифр вызывающих уважение пополам с восхищением.

Доклад Антона Саросека "Как мы создаем и обслуживаем тысячи кластеров Kubernetes в Сбере".

https://youtu.be/Epbn3WDrtHA

#доклады

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

Доклад Александра Козлова "Система без теней: полный цикл наблюдаемости в современных приложениях".

https://youtu.be/z3MKgUFCaCg

#доклады

Доклад про технологию с которой вроде все понятно, но на самом деле все сложно.

"Как управлять горизонтальным масштабированием в больших проектах".

https://youtu.be/GWJ9rDrsBdQ?si=dx-VHMlIIYKo2g4q

#доклады #DigitalTwin

Заметки с DevOpsConf

С интересом послушал про практику работы SRE инженеров. Но вот чего подумалось.

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

И нас всегда за эту практику ругали - мол, вот вы, гоблины сиволапые, ничего нормально разработать не можете, так чтобы все было штатно, благообразно, по процессам, без этой вашей чрезвычайщины.
Мы конечно смотрели в пол, пожимали плечами: "Простите, извините, так вот как-то получилось". Доступ все время усложняли, урезали права и через какое-то время доступ пропал совсем.

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

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

"За одно и то же, т. е. за один способ поведения, известную группу металлов называют благородными, а газы — инертными" заметил как-то Венедикт Ерофеев

Доклад про IDP (Internal Development Platform).

Буквально на третьем слайде, после тезиса "Платформы создаются для разработчиков" я решил что доклад мне очень нравится и это чувство не покидало меня до конца доклада.

Прекрасное изложение темы, логичная, убедительная аргументация.

Максим Скоморохов из ТуТу "Как построить IT-платформу с нуля".

https://www.youtube.com/watch?v=UDYKx7HISAA

#доклады