Анализ производительности

Долго искал удобный инструмент для анализа и поддержки модели производительности.
Начинал с Excel. Потом открыл для себя язык R и R Studio.

Остановился на Jupyter Notebook (https://jupyter.org/).

Открытый, интерактивный, хорошо интегрируемый инструмент.
Пишу на любом удобном мне языке:R, Kotlin, Python.

В общем, рекомендую. )

Анализ производительности (пример)

Вдогонку к предыдущему посту небольшой пример на основе реальных данных
(Когда-то моделировал решение под СМЭВ.)
Пристегнул сам блокнот и экспорт результата в PDF

Примеры модели производительности

В личке попросили примеры по перформанс моделированию.
К сожалению, сразу не ответил и потерял чат (

Выложу сюда.
- atm_queue.ipynb
Пример использования simple simulation model (kalasim)
- Cache.ipynb
Расчёт эффективности кэша по пропускной способности (модель QNM)
- MG1.ipynb
Расчёт времени отклика для очереди M/G/1 (модель QNM)
- Scalability.ipynb
Определение масштабируемости системы по модели USL

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

Так как речь зашла о мат. моделировании производительности, хочу обозначить свою позицию.
- Даже самая продвинутая мат. модель даёт крайне не точное приближение к реальности. Огромное количество факторов влияющих на показатели производительности не учитываются моделью.
- Использую мат. модели (количество) исключительно для представления оптимистичного и пессимистичного сценария, то есть для определения возможных границ значений.
- Вариант, который в 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 процентов проектов завершаются либо провалом, либо превышением всех возможных бюджетов.
Неужели нечего показать?