Если кто еще не подписан на канал Андрея Кузнецова - настоятельно рекомендую. Грамотный спец. Не раз обсуждал с ним сложнейшие вопросы по безопасности.

FINDING SOFTWARE BOUNDARIES
FOR FAST FLOW
Team Topologies and Domain-Driven Design

О дихотомии функции и конструкции на примере шахмат.

В шахматах существует такой тактический прием, как связывание:
https://chessrussian.ru/materialy/beginners/svyazka-primenenie-svyazki/

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

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

Связанную фигуру можно так же рассматривать в качестве слоя трансляции - чтобы защитить свою доменную модель (самую дорогую часть ПО), мы создаем слой трансляции под названием Open Host Service:
this approach of inserting a translation layer for each external system avoids corruption of the models with a minimum of cost
http://ddd.fed.wiki.org/view/open-host-service

Т.е. чтобы предотвратить разрушение модели/конструкции. Все как и в шахматном связывании.

Этот тактический прием открывает также понимание еще и такого явления, как Coupling. Мы не можем изменить дислокацию фигуры (интерфейса), потому что она связана.

См. также.

Может кому-нибудь пригодится для реализации критериев выборки (фильтрации) Public-API по Style Guide AIP-160 by Google:
- https://github.com/einride/aip-go
- https://github.com/aip-dev/google.aip.dev/issues/684
- https://github.com/aip-dev/google.aip.dev/issues/738
- https://google.aip.dev/160
- https://github.com/google/cel-spec
Другие варианты смотрите здесь:
- https://dckms.github.io/system-architecture/emacsway/it/self-education/self-education-for-software-engineer.html#api-design

Только что обнаружил, что Greg Young тоже опубликовал 16 ноября пост на шахматную тематику.

[UPDATE]: И, кажется, он это делает систематически. Видимо, не я один заинтересовался шахматами на почве ИТ-архитектуры.

Физические Agile-доски до сих пор активно используются в крупных IT-компаниях, даже в таких, как Thoughtworks. Это никакой не исторический рудимент. Они используются даже для распределенных команд - в удаленном офисе на самом видном месте устанавливается большой монитор, на который проецируется изображение доски с главного офиса.

У меня в офисе такая доска была. Она состоит из поролоновых кубиков, количество которых пропорционально трудомощности команды разработки. Каждая сторя занимает площадь на столько кубиков, сколько составляет её трудоемкость. В Jira даже есть опция распечатать стори. Если в спринт нужно вставить другую сторю, то на доске сперва удаляется сторя эквивалентной площади.

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

Так вот, к чему это я. Некоторые мои в т.ч. широко известные коллеги используют бумажный ежедневник, чем неоднократно вводили меня в замешательство. Я считал это рудиментарными привычками. Но недавно у меня появилась хорошая перьевая ручка и мне захотелось купить себе бумажный ежедневник. После непродолжительных поисков мой выбор пал на блокнот fineplan формата A6 на кольцах из натуральной кожи коньячного цвета с тиснением под крокодила. Он у меня всегда раскрыт возле монитора и выполняет те же функции, что и физическая Agile-доска, - постоянно визуализирует образное представление моего личного распорядка перед глазами. Эстетичность блокнота и ручки вызывает желание ими пользоваться. За несколько дней заметил существенное улучшение моей личной сконцентрированности и организованности. И понял, что это никакой не исторический рудимент. Теперь я понимаю своих коллег с бумажными ежедневниками.

Хотя от электронных ежедневников я не отказался, и продолжаю пользоваться Open Source приложениями:

https://github.com/orgzly-revived/orgzly-android-revived (как заядлый емаксоид в прошлом)

и

https://github.com/tasks/tasks

Оба приложения доступны на F-Droid.

[UPDATE]: Тут подвернулось под руку еще одно неплохое Open Source приложение:
https://github.com/johannesjo/super-productivity/

Я, конечно, подозревал, что у Яндекса страдает морально-деловая сторона, но чтоб Яндекс.Такси было способно дважды чистосердечно признаться в том, что оно вытерает ноги о ст.10 ФЗ N 2300-1 о защите прав потребителей, я не предполагал. Не предполагал, потому что это происходит в стране, которая берет на себя смелость позиционировать себя как защитника правовых и высоконравственных ценностей на внешне-политической арене. Яндекс даже не пытается создать видимость уважения к Закону и к законным правам своих клиентов.

В чем суть. Саппорт Яндекса признал дважды, что Яндекс.Такси самовольно и беспричинно выставляет произвольную стоимость за уже фактически оказанную услугу, которая никак не коррелирует с той стоимостью, которая в соответствии со ст.10 ФЗ N 2300-1 была оглашена перед оказанием услуг, с целью обеспечения клиенту возможности правильного выбора. А чтобы окончательно запутать клиента, стоимость услуги отображается раздельно от стоимости ожидания лишь однократно при завершении заказа. В истории заказов стоимость услуги и ожидания раздельно уже не отображается, что усложняет клиенту возможность защиты своих прав. И именно этим пользуется саппорт, пытаясь ввести клиента в заблуждение о стоимости услуг ожидания.

По моему сугубо личному мнению, это даже не столько нарушение ст. 10 ФЗN 2300-1, сколько завладение чужими средствами обманным путем, что имеет признаки уголовного преступления, предусмотренного ст. 159 УК РФ.

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

В общем, будьте внимательны при использовании услуг Яндекса.

Многие думают, что конкуренция существет для достижения качества. Это не совсем так. Конкуренция существует для достижения разнообразия форм хозяйствования в условиях изменяемости рыночных условий. Где сейчас компания Кодак по производству фотоаппаратов на основе засветки серебра? А где был Гугл когда многие ходили с кнопочными телефонами Nokia?

Конкуренцию можно сравнить с разлётом дроби при стрельбе по утке из дробовика - какая-нибудь дробинка да попадет в цель. Но попадание определяется тем, где в текущий момент находится утка.

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

В силу ряда когнитивных искажений, они боятся нанимать сотрудников непохожих на них, потому что неопределенность всегда пугает. См.
- "Эффект неоднозначности"
- "Предпочтение нулевого риска"

Я уже не говорю про целый клубок сопутствующих эффектов, таких как:
- "Эффект Даннинга — Крюгера"
- "Склонность к подтверждению своей точки зрения"
- "Психологическая защита"
- "Закон иррационального усиления"
- "Систематическая ошибка выжившего"
- "Кривая забывания"
- "Кривая обучаемости"
- "Эффект края (память)"
- "Эффект недавнего"

Страх возникает от непонимания того, как управлять неопределенностью. Но как управляет неопределенностью сама природа? В архитектуре существует подход управления развитием системы, копирующий метод биологической эволюции, под названием Evolutionary Architecture. Такой метод не блокирует, а поощряет дивергентность технических решений с целью отбора наиболее соответствующего. Потому что в нем есть механизм обеспечения конвергентности технических решений, который копирует модель паспорта породы в собаководстве (которая, в свою очередь, копирует модель хищничества в условиях дикой природы). Такие компании не боятся сотрудников с новыми знаниями, не похожими на знания их старожилов, обеспечивая себе стратегическое превосходство в условиях скоротечно меняющейся рыночной обстановки.

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

Коллеги, хочу обратить внимание на приложение
https://github.com/johannesjo/super-productivity/ в качестве цифрового персонального ежедневника (если кому удобней цифровые).

1. Open Source
2. Работает и на Android (доступен в т.ч. на F-Droid), и на iPhone, и на Microsoft, и на Linux, и в брузере.
3. Можно использовать и как Task Manager, и как каледарь. Поддержка рекуррентных событий по RFC 5545.
4. Kanban board.
5. Матрица Эйзенхауэра.
6. Time Tracker.
7. Pomodoro
8. Интеграция с целой кучей систем управления проектами (Jira, Redmine, GitHub, GitLab, CalDAV, Open Project, Gitea etc.)
9. Интеграция с целой кучей календарей (Google Calendar, Outlook, iCal etc.)

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

Browser plugin for PERT estimates in JIRA:
https://github.com/aligent/pert-with-wings

Хорош тем, что не нужно просить администратора Jira устанавливать Jira plugin вроде этого:
https://marketplace.atlassian.com/apps/1218473/pert-calculator

Может кому-нибудь пригодится еще и online калькулятор:
https://goodcalculators.com/pert-calculator/

См. также
- https://www.tgoop.com/emacsway_log/916
- https://www.tgoop.com/emacsway_log/1101

Вдруг кому пригодится. На главной странице сайта org-mode https://orgmode.org/ перечислены решения, с помощью которых можно использовать org-mode на мобильных устройствах:
Android : Orgzly Revived, Orgro, Org Note
iOS : MobileOrg, Orgro
Web : Organice (progressive web app), Org Note

С какими трудностями я обычно сталкивался в своей практике при реализации Specification Pattern?

1. Расслоение, если мы хотим применять его как для фильтрации объектов в оперативной памяти, так и в БД. Обычно эта проблема решается через Expression Tree, но в Golang такой опции нет, что, правда, легко обходится самодельным синтаксическим деревом.

При этом возникает вопрос о том, должна ли логика предиката реализовываться в виде интерпретатора на основе Expression Tree или дублироваться хардкодно?

2. Когда агрегаты храняться в JSONB колонке БД, обычно проблем не возникает, и мы можем применить коробочные реализации JSONPath.

Трудности возникают когда сущности агрегата хранятся в отдельных табличках без использования JSONB.

В частности, структура таблиц и структура агрегата нередко отличаются. Например, агрегат часто использует композитные первичные ключи и композитные ValueObjects. Это означает, что синтаксическое дерево для предиката агрегата будет отличаться от синтаксического дерева для запроса в БД. Т.е. просто так "коробку" прикрутить не получится. И мне известны только единичные специалисты, обладающие достаточной квалификацией, чтобы написать код трансформации одного дерева в другое.

3. Большинство коробочных интерпретаторов для Expression Tree, которые можно приспособить для реализации Specification Pattern, умеют оперировать только примитивными типами данных, и без существенной доработки не умеют совершать операции над ValueObjects, особенно, если язык программирования не поддерживает перегрузку операторов.

4. Инкапсуляция агрегата. Это отдельный большой вопрос, который часто обсуждается в отрасли и уже не раз обсуждался мной. Чаще всего для извлечения защищенного состояния агрегата используются:
1. Общие области видимости (как в Golang) или дружественные классы (C++).
2. Mediator Pattern (описан в красной книге Vaughn Vernon).
3. Рефлексия (нередко используется в коробочных решениях, особенно в ORM).
4. Memento Pattern, хотя и часто называют, но ошибочно, если внимательно разобраться.

5. Самая любимая моя проблема - это предикаты к атрибутам коллекции сущностей агрегата с использованием Expression Tree.

Как выразить в Expression Tree следующее условие:
хотя бы одна из сущностей коллекции агрегата имеет значение "x" атрибута "a" и значение "y" атрибута "b", или хотя бы одна из сущностей той же коллекции имеет значение "j" атрибута "с"?

Ничего не получится, если напишем нечто подобное:
agg.ent[*].a == x && agg.ent[*].b == y && agg.ent[*].c == j

Кажется, такое ни одна коробка не умеет, за исключением операторов wildcard "*" и локального елемента "@" в JSONPath. Собственно, оттуда я и перенял решение:
agg.ent[*] ? (@.a == x && @.b == y) || agg.ent[*].c == j

Если скомпилировать это выражение в SQL запрос к обычным реляционным табличкам (без JSONB), то получится два JOIN.

Не знаю, можно ли выразить нечто подобное с помощью LINQ в C# (если да, то сообщите, пожалуйста, в комментарии).

Когда должно вернуть true следующее выражение:
agg.ent1[*].a == agg.ent2[*].a ?
Когда совпадает хотя бы один элемент в обоих подмножествах, или когда оба подмножества эквиваленты?

Нет ничего сложного в реализации Specification Patrern on Expression Tree, если обладать достаточным опытом и квалификацией. Реализация занимает всего несколько сотен строк кода.

Сложно найти/подготовить такого специалиста в команду.

Performance testing and antipatterns for cloud applications:
- https://learn.microsoft.com/en-us/azure/architecture/antipatterns/

TaskJuggler может создавать множество версий плана, что позволяет его использовать для 3 point estimates technique PERT:
https://github.com/taskjuggler/TaskJuggler/issues/127

См. по слову "scenario":
https://taskjuggler.org/manual/Tutorial.html

Docs:
https://taskjuggler.org/tj3/manual/scenario.html

Я использую такой макрос:

macro pert [
  optimistic:effort ${1}d
  nominal:effort ${2}d
  pessimistic:effort ${3}d
]

В отчете можно указать какие сценарии выводить:
https://taskjuggler.org/tj3/manual/scenarios.html

Это работает, хотя и не совсем так, как должно работать по PERT estimation.

Как вариант, можно сделать кастомное поле для StandardDeviation:
https://taskjuggler.org/tj3/manual/extend.html

И вносить в него данные из PERT-калькулятора:
https://www.tgoop.com/emacsway_log/1543

Для подсчета крайнего срока можно сделать csv-выгрузку и подсчитать в excel:
https://taskjuggler.org/tj3/manual/formats.html

Ну или добавить в страницу jQuery и подсчитать с помощью JavaScript:
https://taskjuggler.org/tj3/manual/rawhtmlhead.html

Потому что marco, к сожалению, математику не умеет делать.

Тем не менее, инструмент очень крутой, с высоким порогом вхождения. Наверное, лучшее из того, что я пробовал. Был разработан by Chris Schlaeger, Managing Director at Amazon Development Center Germany GmbH.

[UPDATE]: Как я уже говорил ранее, TaskJuggler можно интегрировать с различными системами управления задачами.

В предыдущем посте говорилось, что pessimistic scenario не совсем корректен в Taskjuggler. Картинка демонстрирует, как должны быть сложены две оценки. Мы видим, что оценки пересекаются. Вот почему мы должны сложить отдельно вероятностную оценку и среднеквадратичное отклонение. Но TaskJuggrer в пессимистическом сценарии сложил оценки так, что они не пересекаются. Т.е. степень его пессимизма превышает расчетную. Это та причина, по которой лучше учитывать раздельно вероятностную оценку и её среднеквадратичное отклонение, как я описал во второй части предыдущего поста.

На одном из реальных проектов прямое сложение пессимистических оценок дало превышение вероятностного срока на полтора месяца, в то время как 3-sigma составил не более 9 дней. Так что здесь нужно с осторожностью.

Кстати, это та же самая причина, по которой Story Points можно сложить только на краткосрочном горизонте (спринт-два).

- https://github.com/microsoft/ai-for-beginners

- https://github.com/microsoft/mcp-for-beginners

- https://github.com/microsoft/IoT-For-Beginners

Thanks to @vec650

Увидел в Авито объявление: "сдам в аренду собаку, гадит где попало, обои рвет, мебель грызет, на всех бросается, идеальный вариант чтоб отбить желание у родственников обзавестись питомцем, дорого".

Это... я что подумал... есть на примете программист, очень умный (реально), гений, победитель олимпиад, в совершенстве знает алгортмы (легко пройдет собес в любой бигтех), ненавидит DDD (даже этот персонаж нервно покуривает в сторонке), в одиночку решает сложнейшие задачи, замыкает все задачи на себя (Рик и близко не валялся), руководствуется принципом "вы никогда не сможете понять ничего из того, что я создал", "ФП - херня", "абстракции - вредны", "сеттеры удобны", "ООП - оверинжиниринг", "анемичные модели понятны", "монолиты распределенными не бывают", "люди вообще писали на ассемблере и ничего, выжили"...

Готов заключить с ним агентское соглашение и сдавать его в аренду. Дорого. Если кому нужно укрепить переговорную позицию перед бизнесом - обращайтесь. На руках носить потом будут.