О Теории Игр на пальцах:

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

Архитектора от статиста отличает влияние. Теория Игр - это наука о влиянии.

В повседневной деятельности у архитектора две ключевые задачи:

1. Найти правильное решение.
2. Сделать это решение жизнеспособным. Т.е. сделать так, чтоб равновесие Нэша наступило через реализацию решения. Что превращает архитектора в политика.

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

📝 "Закон Вайнберга-Брукса: От действий менеджеров, основанных на неправильных моделях системы, пострадало больше проектов, чем от всех остальных причин вместе взятых.

Weinberg-Brooks' Law: More software projects have gone awry from management's taking action based on incorrect system models than for all other causes combined."

Три самые важные политические опоры архитектора:
1. Системное мышление.
2. Теория Игр.
3. Диалектическая философия (раз, два, три, четыре, пять, шесть).
И шахматы, чтоб все это практиковать и развивать.

И тогда архитектор сможет эффектно реализовывать блистательные решения, а не "голосовать ногами" от безысходности.

Вы знали, что ИИ старше ЯП Lisp? Более того, сам Lisp появился в попытке создать ИИ.

Термин “искусственный интеллект” впервые появился в заявке на проведение семинара в Дартмутском колледже в Хановере (штат Нью-Гэмпшир). Семинар состоялся в 1956 году.

Мак-Каллок и Питтс доказали, что нейронная сеть может выполнять числовые и логические операции. Кроме того, они предположили, что сети с особенной архитектурой способны обучаться. В 1943 году учёные опубликовали свои результаты в статье “Логическое исчисление идей, присущих нервной деятельности” (A Logical Calculus of Ideas Immanent in Nervous Activity).

В 1957 году Фрэнк Розенблатт смоделировал работу нейронной сети в виде программы для универсального компьютера IBM 704. Годом позже учёный сконструировал первый нейрокомпьютер под названием Mark I Perceptron. Mark I представлял собой однослойную нейронную сеть. Она работала по тому же принципу, что и отдельный перцептрон. Компьютер состоял только из аналоговых компонентов. Входное изображение поступало на матрицу из фотодетекторов размером 20x20. Сигналы с неё передавались на электромеханические устройства, которые моделировали отдельные нейроны. Чтобы регулировать веса входных сигналов, применялись потенциометры. В процессе обучения их настройки менялись автоматически с помощью электромоторов.

В системе Advice Taker знания и механизм рассуждений чётко разделялись. Знания хранились в виде правил на некотором формальном языке. Эти правила помещались в списки. В результате их стало проще редактировать. Теперь с этой задачей мог справиться оператор без навыков программирования.

Для логического вывода Advice Taker выполнял поиск по спискам. Джон Маккарти искал способ вынести алгоритм поиска из кода самой системы. Учёный решил сделать поиск одним из механизмов языка программирования. Тогда на таком языке стало бы значительно проще и быстрее создавать новые специализированные интеллектуальные системы.

Джон Маккарти начал работать над новым языком программирования. Он рассматривал это как первый шаг для реализации Advice Taker. Так появился язык LISt Processing более известный как Lisp. Учёный описал Lisp в статье для журнала Communications of the ACM в 1960 году. Первый работающий интерпретатор языка появился в 1958 году для компьютера IBM 704.

Некоторые идеи языка Lisp Джон Маккарти высказал ещё в статье “Программы со здравым смыслом”. В ней учёный рассуждал над преимуществами декларативных и императивных инструкций. Декларативные инструкции описывают свойства результата, который должна выдать программа. Императивные инструкции — задают чёткий алгоритм вычисления результата.
Джон Маккарти утверждал, что декларативные инструкции лучше подходят для разработки интеллектуальных систем и упрощают работу с логическими правилами.

Главный механизм Lisp — это операции над списками. В отличие от других языков Lisp не различает данные и код программы. Вся программа записывается в виде списков, заключенных в круглые скобки.
Такие структуры в терминологии языка называются S-выражениями (s-expressions).

Изначально Джон Маккарти задумывал Lisp как чисто декларативный язык. Но в процессе реализации учёный добавил такие конструкции императивного языка как циклы и переменные. Благодаря им, Lisp стал универсальным языком. Он подходит для широкого круга задач, которые не относятся к ИИ. Сегодня его продолжают применять в разных прикладных областях.

Система Advice Taker так никогда и не была реализована. Когда Джон Маккарти довел язык Lisp до стабильного состояния, она уже потеряла актуальность. Тем не менее Advice Taker оказалась полезна как модель типичной интеллектуальной системы.
Она помогла учёному лучше понять нужды разработчиков. Благодаря этому, Джон Маккарти создал язык, который стал основным инструментом для исследователей ИИ на протяжении десятилетий.

"Искусственный интеллект в стратегических играх" Илья Шпигорь
https://leanpub.com/ai-in-strategy-games

О роли таланта в мастерстве (научное исследование):

В начале 1990-х годов шведский психолог Андерс Эрикссон и его коллеги изучали роль практики в получении экспертных навыков. В 1993 году они изложили результаты своей работы в статье “Роль целенаправленной практики для достижения уровня эксперта” (The Role of Deliberate Practice in the Acquisition of Expert Performance).

Учёные проверяли распространённое мнение о роли таланта в профессиональной деятельности. Для этого они провели исследование с участием студентов скрипачей из Академии музыки в Берлине.
Уровень студентов различался. В зависимости от успеваемости, учащихся разделили на три группы:

1. Потенциальные звёзды мирового класса.
2. Перспективные исполнители.
3. Посредственные исполнители.

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

Андерс Эрикссон и его коллеги выяснили, что к 20 годам музыканты из первой группы потратили в сумме около 10000 часов на занятия музыкой.
Студенты из второй группы за тот же период времени занимались порядка 7500 часов, а в третьей группе—только 5000 часов. Из этих наблюдений учёные сделали вывод, что регулярная практика имеет решающее значение для приобретения экспертных навыков. Именно она определяет успешность исполнителя, а не врождённый талант или ранний возраст начала обучения. В то же время Андерс Эрикссон признаёт, что индивидуальные когнитивные и физиологические различия влияют на эффективность практики.

В 2008 году канадский журналист Малкольм Гладуэлл популяризовал выводы Андерса Эрикссона в книге “Гении и аутсайдеры” (Outliers: The Story of Success). Автор книги утверждает, что для достижения мастерства в какой-либо области нужно около 10000 часов практики. Это примерно 6 лет упражнений по 5 часов в день. Закономерность получила широкую известность как правило 10000 часов. К сожалению, это правило упускает некоторые важные тонкости первоначального научного исследования.

В статье Андерс Эрикссон утверждает, что для практики важно не количество, а качество.
Чтобы подчеркнуть эту мысль, учёный ввёл специальный термин. Преднамеренная практика (deliberate practice) — это целенаправленная и систематическая работа эксперта, направленная на улучшение своей производительности.
У преднамеренной практики есть ряд особенностей.

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

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

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

-- "Искусственный интеллект в стратегических играх" Илья Шпигорь
https://leanpub.com/ai-in-strategy-games

"В успехе только 5% таланта, а остальное - это пот и трудолюбие. Поэтому нужно захотеть стать чемпионом и не бояться преодолевать трудности. Самое главное - сделать первый шаг, не бояться наступать на леность, трусость и самовосприятие. Нужно встать с дивана, поднять сначала свою "тушу", а потом тело соперника на ковре..."
—Александр Карелин



Архитектурные руководства по Multitenant:

- https://learning.oreilly.com/library/view/building-multi-tenant-saas/9781098140632/

MS:
https://learn.microsoft.com/en-us/azure/architecture/guide/multitenant/overview

- https://docs.microsoft.com/en-us/azure/architecture/guide/multitenant/related-resources

AWS:
- https://aws.amazon.com/solutions/guidance/multi-tenant-architectures-on-aws/

- https://d1.awsstatic.com/whitepapers/saas-tenant-isolation-strategies.pdf

- https://aws.amazon.com/blogs/apn/building-a-multi-tenant-saas-solution-using-aws-serverless-services/

- https://aws.amazon.com/blogs/security/security-practices-in-aws-multi-tenant-saas-environments/

RLS:
- https://aws.amazon.com/blogs/database/multi-tenant-data-isolation-with-postgresql-row-level-security/

Коллеги, интересно ваше мнение. Насколько востребованным был бы для вас сервис, который извлекал бы данные из вашей системы управления задачами и строил высокодетализированный план в виде диаграмм Ганта, с учетом реального распределения ресурсов (команд разработки или исполнителей/разработчиков), с учетом их доступности, фокус-фактора, к-та эффективности, календаря праздничных и отпускных дней. Визуализировал бы загрузку ресурсов по сторям, эпикам, спринтам, календарному периоду. Визуализировал бы распределение задач по ресурсам. Позволял бы сравнивать фактический график по окончании спринта с запланированным. Позволял бы прогнозировать сроки завершения работ по законтрактованному инкременту. Вычислял бы среднеквадратичное отклонение оценки для заданного объема задач. Т.е. делал бы все то, чего нет в диаграммах Ганта популярных систем управления задачами, суть которых зачастую сводится к обычному рисованию полосочек без учета реального распределения ресурсов.

Могла бы быть актуальной эта тема для тех, кто работает в заказной разработке или по методологии гибридной SDLC модели (сочетающей в себе как продуктовые, так и проектные практики)?

👍 - да, востребовано
😐 - не знаю
👎 - нет, не востребовано

Спасибо за участие)

For example, it’s not sufficient to be a good communicator and a good technologist. You have to be a good technical communicator, making complex topics approachable without dumbing them down. You have to remain engaging without drifting completely into storytelling–your job is to highlight critical technical decisions and trade-offs.

Good technical leaders are role models, understand and value their team’s skills, or find ways to simplify designs (naturally, without micromanaging). If managers are accountable for performance evaluations and can’t judge technical skills, teams will quickly learn that they can get by with sounding smart instead of actually knowing their stuff.

A good technical leader is a force multiplier for the teams: it makes them more productive, better decision makers, and happier. And you need to have some idea what you are managing.

"Being an architect isn’t the sum of skills. It’s the product. It’s not just about tech. But also not just about non-tech." by Gregor Hohpe
https://architectelevator.com/architecture/architect-skills-product/

а когда я всмотрелась в него утром, то это был не мой сын, которого я родила. И сказала другая женщина: нет, мой сын живой, а твой сын мертвый. А та говорила ей: нет, твой сын мертвый, а мой живой. И говорили они так пред царем. И сказал царь: эта говорит: мой сын живой, а твой сын мертвый; а та говорит: нет, твой сын мертвый, а мой сын живой. И сказал царь: подайте мне меч. И принесли меч к царю. И сказал царь: рассеките живое дитя надвое и отдайте половину одной и половину другой. И отвечала та женщина, которой сын был живой, царю, ибо взволновалась вся внутренность ее от жалости к сыну своему: о, господин мой! отдайте ей этого ребенка живого и не умерщвляйте его. А другая говорила: пусть же не будет ни мне, ни тебе, рубите. И отвечал царь и сказал: отдайте этой живое дитя, и не умерщвляйте его: она — его мать.
Третья книга Царств 3:16-27 СИНОД

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

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

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

Это еще один из примеров применения теории игр на практике. Я даже коллекционирую такие примеры.

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

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

В наше время развелось куча курсов, которые учат первому.

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

Лидерство держится на двух столпах:

1. Горизонт видения. Они видят дальше других. Потому что, As Issac Newton said: "If I have seen further, it is by standing on the shoulders of giants." Это важно, потому что истинный авторитет и истинное лидерство невозможны без хардов.

2. Способность внушать спокойствие. Люди объединяются вокруг тех, кто помогает им обрести спокойствие и уверенность.

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

Происходит это потому, что они испытывают страх за то, что занимаемое ими место в социальной иерархии не соответствует их уровню квалификации. Что означает, лидерство невозможно без смелости перед собственными страхами. Именно об этом говорил Лао Цзы, что море величественней реки, потому что оно ниже реки.

В продолжение темы. Прилагаю файлы, которые реализуют этот принцип и компилируют jsonpath-выражение в SQL-запрос к реляционным данным (не JSQNB). Готовый Specification Pattern. Работает как с объектами в памяти, так и с данными в БД. Код сгенерирован by Claude.
См. также:
- https://xn--r1a.website/emacsway_log/1508
- https://xn--r1a.website/emacsway_log/1545
- https://xn--r1a.website/emacsway_log/1564

[UPDATE]: Может быть применён в "OpenAPIs" для передачи критериев выборки с клиента на сервер в GET-параметре запроса.

#Python #DDD #SpecificationPattern

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

- Golang
https://github.com/sqlc-dev/sqlc

- Python
https://github.com/sqlc-dev/sqlc-gen-python

- Typescript
https://github.com/sqlc-dev/sqlc-gen-typescript

- Kotlin
https://github.com/sqlc-dev/sqlc-gen-kotlin

Тот же Martin Fowler, создавший моду на ORM, писал:

Generated code is more explicit so you can see what's going on in the debugger; as a result I usually prefer generation to reflection, and I think it's usually easier for less sophisticated developers (which I guess makes me unsophisticated).
—"Patterns of Enterprise Application Architecture" by Martin Fowler, David Rice, Matthew Foemmel, Edward Hieatt, Robert Mee, Randy Stafford

Глава "Metadata Mapping" книги "Patterns of Enterprise Application Architecture": "reflective program" и "code generation".

Кстати, про CQRS в качестве альтернативы ORM тоже говорил он:

ORMs are complex because they have to handle a bi-directional mapping. A uni-directional problem is much easier to work with, particularly if your needs aren't too complex and you are comfortable with SQL. This is one of the arguments for CQRS.
https://martinfowler.com/bliki/OrmHate.html

А это, наверное, самый приятный пример Anemic Domain Model на Golang, который я встречал:
- https://github.com/techschool/simplebank

Сопроводительная статья:
"A clean way to implement database transaction in Golang"
- https://dev.to/techschoolguru/a-clean-way-to-implement-database-transaction-in-golang-2ba

Ни к чему не призываю. Я сторонник качественных полноценных доменных моделей, будь то OOP или FP. Анемичные доменные модели не относятся ни к первому, ни ко второму.

#Golang #Python #TypeScript #Kotlin

Да, https://notebooklm.google.com/ - это бомба! Согласен. Экономит тонны человеко-часов.

Обзавелся небольшим собственным проектом, и мне в наследство достался Tortoise ORM. И стал я думать, что мне с ним делать, оставлять или выпиливать.

Вначале думал - оставлю, т.к. важнее нарастить функциональность, а на ORM это делать вроде как бы быстрее. И стали возникать вопросы: как сделать поддержку композитного объекта (например, Money multi-currency), как сделать поддержку мультиязычности, как захватить коннект из пулла без старта транзакции, как сделать поддержку композитного FK, как сделать запрос, который не вписывается в возможности этого ORM, и т.д.

И полез я, значит, смотреть потроха этого ORM. И весело так смотрю, под музыку, а в глазах - печаль. И я понимаю, что не хочу его в новых компонентах.

Это я к чему. Стал я, значит, думать, может затащить другой ORM? Смотрю я значит, потроха и так хорошо знакомого мне SQLAlchemy. Испытываю восторг. Одна беда - по объёму его кодовой базы это не я его добавил бы в проект, а проект прилепил бы к нему.

И обратил я свой взор на мой самый любимый Storm ORM. Песня! Красивый, маленький, быстрый, с хорошей функциональностью, элегантный... - мечта! Одна беда, он не поддерживает async.

Ну, думаю, сейчас я на него натравлю Claude, и он мне быстренько реализует этот async... Ага... щас... четвёртый день подряд многократно расходую все лимиты токенов. Весело смотрю как Claude под музыку пускает в разнос процессор ноутбука, пытаясь отладить свои изменения. Вначале радовался. Потом понял, что без личного участия обойтись не получится.

Ну, думаю, токены для другого дела нужны... не гоже так... Думаю, может все-таки SQLAlchemy? И думаю, кто такой этот Michael Bayer на фоне Canonical's CTO Gustavo Niemeyer? Уж если у Gustavo Niemeyer Storm ORM зачах, то где гарантия, что этого не случится с SQLAlchemy, автор которого пишет о себе в LinkenIn: "I am old, tired, extremely busy"? И если собственноручное сопровождение Storm ORM я еще могу вообразить, то меня пугает даже мысль про сопровождение объемов кода SQLAlchemy.

И тут я решил попробовать сделать новый компонент по классике DDD, все по книжному: Pure Domain Model & Raw SQL Repository. И заметил я одну особенность. Claude, видимо, очень начитанный парень, и прекрасно понимает и пишет "книжный" код. С первого раза!

Он прекрасно пишет SQL запросы любой сложности. Но спотыкается даже о тривиальный запрос на Tortoise ORM и требует на порядок больше промптов. За ним нужен глаз да глаз, иначе не успеешь моргнуть, как он вытащит половину БД в память, чтоб посчитать Count().

И, значит, решил я тогда вообще никакой ORM не использовать. Ведь не даром же автор моды на ORM говорил, что персонально он предпочитает генерацию кода рефлексии. А с генерацией кода по книжному Claude справляется на отлично!