Математическое моделирование производительности

Так как речь зашла о мат. моделировании производительности, хочу обозначить свою позицию.
- Даже самая продвинутая мат. модель даёт крайне не точное приближение к реальности. Огромное количество факторов влияющих на показатели производительности не учитываются моделью.
- Использую мат. модели (количество) исключительно для представления оптимистичного и пессимистичного сценария, то есть для определения возможных границ значений.
- Вариант, который в SPE (QNM) называют реалистичным, рассматриваю как (крайне) оптимистичный.
- Использую мат. модели (качество) для определения зависимостей нужных качеств. От зависимостей строю тактики улучшения качества.

И небольшой пример реального распределения времени обслуживания для функции выполняющей delay(20) (рисунок).

Вместо красивой линии на 20ms имеем 4 моды из которых я могу объяснить только три )

Онтология в программной архитектуре

К сожалению, тема звучит как насмешка.

Программную архитектуру поддерживают специалисты с инженерным мышлением.
Основной инструмент - эвристика.
"Уха помогает от простуды плотнику, но не помогает слесарю ..."

Термины в нашей области используются, без оглядки на их смысл в других контекстах.
Есть нечто, что надо назвать?
Выдернем первый подходящий понравившийся термин из смежных областей знаний.
И появляются на свет такие оксюмороны как изменяемые сущности (Entity в DDD).

Особое спасибо хочется предъявить Эрику Эвансу за домены и поддомены.

Изначально домен — это просто набор чего-либо встроенный в иерархическую (доменную) структуру.
С легкой руки аналитиков домен (domain) напрочь завязан на понятие предметной области (Subject Area).

Эванс подхватил это имя и притянул еще одно ограничение, связав домен с пространством проблем.
"Домены — это пространства проблем, которые вы хотите устранить."

Теперь опускаемся вниз по доменной структуре, выделяя в пространстве проблем подобласть.
В частности подобласть с единым языком. Как же ее назвать? Естественно поддомен!

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

Не судьба была назвать любую предметную область доменом и выделить в иерархии две их разновидности:
- "проблемную область" (сверху),
- "область общего языка" (снизу)?

Или подход как у Microsoft:
Чем больше путаницы в терминах, тем больше заработаем на обучении?

____

P. S. Написал после очередных объяснялок.
Если кого задел, прошу прощения, накипело)

#ворчалка

Анaлитические шаблоны | Analysis Patterns
https://violettape.github.io/ap_book/cover.html

☝️ Долгожданный перевод первой работы М. Фаулера "Аналитические паттерны".

Ждал с 1997 )

ИМХО одна из лучших работ автора, во многом предвосхитившая идеи DDD.

Качества архитектуры

В чате канала мне подсказали интересную мысль:
"В книге Righting Software Джувел Лёве определяет еще одно качество, которое, вероятно, можно отнести к красоте - это симметричность."

Добавляю в список метрик красоты:
- лаконичность,
- симметричность.

Если есть еще накидывайте в коменты.
Буду очень благодарен )

Вопрос наименования

Как назвать специалиста, формирующего множество моделей системы с целью предсказывать/объяснять её поведение?
Я бы назвал моделистом, но почему-то все называют архитектором. )

👆Так как сейчас повсюду режут косты и с подозрением посматривают на всяких непонятных архитекторов,
многим приходится объяснять зачем эти архитектора нужны. К сожалению, название должности не говорит само за себя (

Реальная угроза

1. ИМХО, основным путём разработчика в архитекторы был путь перехвата управления:
Амбициозный разработчик навязывался в помощники опытному, но ленивому коллеге, брал на себя все рутинные задачи и со временем "отжимал" проект (see "strangler pattern").
2. Теперь же рутиной занимаются синий кит и ко. У молодых разработчиков больше нет шанса (

#доля_шутки

AI как кодер

Как-то искал подходящую утилиту для автоматизации надоевшей рутины.
Спросил у AI и он предложил неплохой выбор, но предупредил, что сам на питоне может написать намного лучше.
И я повелся )
Я по очереди использовал разные популярные модели и в итоге
утилиту мы почти дописали,)
За одно обратил внимание на пару нюансов:
1. Разжевывать надо тщательнее, чем даже джуну. К сожалению, то что кажется очевидным, неочевидно ИИ. У него другая "культурная" среда.
Например, при выводе списка файлов лучше показывать пути а не inodes
2. Короткая память требует постоянного повторения того, что уже проговаривали.
В противном случае классическая ситуация "нос-хвост".
Примерно так: исправь этот дефект, но не воспроизведи тот, что мы исправили на предыдущем шаге.
3. Кинуть задачу и забыть - это не про ИИ. С ним надо сидеть в паре. И конечно же разбираться в том, что он творит.
4. Если ИИ чего то не знает - он придумает. Например, название несуществующей функции несуществующей библиотеки. И даже подкрепит это цитатой из несуществующей доки. Можете умолять его не делать этого. Он с удовольствием проигнорит самый конкретный промпт.
5. Через некоторое время свое творение он начнет называть "вашим кодом", и указывать вам на многочисленные ошибки. Это конструктивно, но раздражает.
6. Явного лидера среди моделей не выявил. Но если результат работы одной давать на растерзание другой, получается лучше, чем если все время пытать одного из них.

Коллективный архитектор

Идея коллективного архитектора не покидает головы менеджеров.

Идея интересная и у меня есть пара любопытных патернов миграции:
1. Лоботомия.
Превратит любого обычного архитектора в коллективного.
2. Разделение знания.
Разрезаем диаграграмы оставленные обычным архитектором и раздаем их разработчикам. Пусть выучат.

#сарказм

ИТ конференции

Что-то не то показывают на наших конференциях.
Обычно нам радостно демонстрируют истории успеха. При этом не всегда понятно, что является его причиной. То ли новый инструмент, то ли мастерство команды, то ли звёзды так сложились.

Мы же все учимся не на успешных кейсах, а на ошибках. И умные, и дураки признают, что опыт сын ошибок.

Хочется видеть истории провалов. Хочется получить демонстрацию всевозможных граблей.

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

Cloud Native Data Security with OAuth: A Scalable Zero Trust Architecture
https://curity.io/cloud-native-data-security-oauth/

👆Cloud Native Data Security with OAuth: A Scalable Zero Trust Architecture

Если вас интересует аспект безопасности при проектировании, советую обратить внимание на эту книжку.

Тем более, что на сайте авторов её можно получить бесплатно 😊

Правильные (М/м)икросервисы

Типичный разговор разработчиков:
- Я пишу микросервисы, могу ли я связать их через общую базу?
- Конечно нет. Левис и Фаулер запрещают (https://martinfowler.com/articles/microservices.html).
- А кто такие эти Левис и Фаулер?
- Гм. Ну вообще-то создатели термина "Микросервис".
- А у меня своё понимание термина "микросервис". И мои микросервисы будут общаться через общую базу!
____
Кто из двух разработчиков прав?
Очевидно оба )

Обычно "говорящие словами" не заморачиваются и не вспоминают тот факт, что слово может быть либо концептом, либо термином.
Концепт — это слово, за которым в нашем сознании стоит целое представление со всеми его ассоциативными связями.
Термин — это слово, за которым стоит определение, чётко ограниченное понятие пригодное для научного моделирования.

Микросервис, как термин, ограничивает небольшое подмножество во множестве микросервисов (концепт).

Тот, кто мыслит терминами, сталкиваясь с тем, кто мыслит концептами, морщится от нечёткости и нелогичности произносимого.
Тот, кто мыслит концептами, считает первого душнилой.

Онтологически обоснованный подход заключается в следующем:
1. Вне контекста размышляем, используя концепты (широко).
2. В контексте домена (предметной области) концепты должны стать терминами (определиться).
3. Современная онтология предполагает, что в разных доменах конкретный концепт может получить отличное определение продиктованное условиями задачи и банальным прагматизмом.

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

Закон Фолкленда

Если нет необходимости принимать решение - не принимай его.

ИИнтуиция

Интуиция — это способность подсознания соединять разрозненные сигналы и опыт в целостное решение.

Сила:
учитывает то, что разум не замечает, и быстро схватывает целое.

Человек чувствует, что собеседник врёт, хотя «логических доказательств» нет — сработали микродвижения и интонация.

Слабость:
может ошибаться, делая выводы по верхам.

Игрок в покер «чует победу» и делает ставку, хотя шансы (по теории вероятности) минимальны.

ИИ — это скорее искусственная интуиция: блестяще решает сложное, но может тупить на простом.
Найдет патологию по флюрографиям, но ошибётся в подсчёте лап у котика.

Может ли ИИ заменить разработчика/архитектора?

Оставлю вопрос открытым )

Простая мысль, которую очень сложно донести

"Делать правильно" зачастую неправильно