📝 Способы разрешения системных (технических) противоречий
http://www.triz.natm.ru/instrum/11priem.htm

💬 14:45. Звонит мой приятель, очень успешный художник. Он приглашает меня на открытие своей выставки. Я нахожу большое удовольствие в общении с этим парнем. В отличие от многих других деятелей искусства, он совершенно чужд тщеславия.

Как-то раз, несколько месяцев назад, он пригласил меня в свою студию. Мы стояли и беседовали в окружении холстов и красок, как вдруг он говорит: «Хочешь посмотреть, как я заработаю 25 тысяч долларов прямо сейчас, до ланча?» – «А как же», – ответил я, слабо представляя себе, что он имеет в виду. И тут он берет открытое ведерко с краской и выплескивает некоторое ее количество на расстеленный на полу холст. Затем берет ведерко с другой краской и снова выплескивает немного на холст. И так четыре раза подряд. На все это у него ушло не более двух минут. Затем, повернувшись ко мне, он говорит: «Ну вот, теперь хватит, готово, можно и обедать!»

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

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

-- Д.Трамп, "Искусство заключать сделки"

P.S.: Ничего не напоминает?

Коллеги, хочу обратить внимание на канал Геннадия Круглова о системной инженерии в архитектуре программного обеспечения:
https://www.tgoop.com/IndustrialSoftwareArchitecture

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

Такого уровня качество исследования, как в нашем обсуждении по SAGA, я больше не встречал нигде.

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

Публикации Гены затрагивают чрезвычайно острую проблему в разработке программного обеспечения, о важности которой вы можете судить из статьи Craig Larman "Системное мышление".

В канале излагается информация, проверенная практикой в одном из крупных архитектурных подразделнний Сбера.

В общем, я подписался на его канал.

Интересный цикл постов про асинхронщину и параллелизм от @ea_kozlov . У парня определенно есть талант излагать сложное просто.

Трушный гик! Один из самых начитанных и грамотных специалистов, которого я когда-либо знал! Говорите, некогда читать? У него как-то находится время еще и писать книги со статьями. Титан!
https://www.instagram.com/coderatworkout

Learning DDD

Наткнулся на канал, достойный внимания. Не могу дать оценку всему контенту за отсутствием времени на изучение, но несколько просмотренных мною постов на крайне сложную тематику там освещены достаточно грамотно, с глубокой проработкой теоретической части. Специалистов с таким бэкграундом я за всю свою практику встречал лишь единицы.
https://www.tgoop.com/rect_arrow

Довольно актуальный канал для людей нашей профессии:
https://www.tgoop.com/osankanaiznanku

Фитнесс, осанка, спортивная медицина, массажи и т.п.

Даже архитектура есть 🙂)

Доводилось ли вам чувствовать себя обесцененным на работе?

Источник:
https://vk.com/clip-214451788_456245390?c=1

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

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

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

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

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

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

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

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

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

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

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

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

Почему так произошло? Потому что разные модели в голове у специалиста и клиента.

Как мог поступить специалист? Представить конструкторские расчеты предельно-допустимых износов и сопоставить их с реальными замерами. До тех пор, пока замеров нет, проблема не очевидна.

В голове роится: а вдруг разводят, а вдруг не справятся, ну ведь работает же...? Эти мысли не покидают его, даже если он согласился: а вдруг обманул, а может заменить его...?

Нагрузочное тестирование делает проблемы видимыми.

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

[UPDATE]: Говорят, что начинать проект с нагрузочного тестирования хорошо еще и тем, что можно хорошо погрузиться в структуру БД и публичных API сервисов.

Какая основная решаемая задача при создании фейкера объема данных?

На мой взгляд, это обеспечение планов запросов к БД, близких к реальным. И здесь основную роль играет воспроизводение селективности индексов.

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

Хорошо то, что в Python существует изобилие библиотек для работы со статистикой и с вероятностной распределенностью: numpy, pandas, scipy, statistics, да и стандартная библиотека random в Python поддерживают ряд актуальных функций.

Задача решается с помощью численных методов, используя «Аппроксимацию» и «Интерполяцию».

Допустим, у нас в таблице есть FK. Несложно получить список количества вхождений каждого значения, взять из этого списка несколько точек, вывести по ним функцию, которая будет использоваться для генерации данных. Впрочем, саму функцию можно не выводить, а ограничиться интерполяцией при генерации данных. Тогда вообще можно ограничиться стандартной функцией random.choices(...).

Поскольку это узкопрофильная область знаний, на которой я не специализируюсь, я прибегнул к помощи Евгения Козлова ( @ea_kozlov ), автора канала https://www.tgoop.com/careerunderhood

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

Если у вас имеется опыт или есть идеи по теме поста, с удовольствием выслушаю.

О спорах в профессиональных пабликах о том, существут ли деление на События/Команды, или между ними нет разницы, т.к. и то и другое - сообщение.

Даже условные операторы состоят из утверждений when и then.

Если говорить метафорически, то существует мнение, что нет никаких when и then, потому что они образуют единый условный оператор. Then не имеет смысла без When, а When - без Then.

Логично. Но все-таки, один и тот же Then может быть выполнен при различных When, что делает их различными. А при одном и том же When может быть выполнено несколько Then.

When/Then может быть на стороне сервиса-провайдера, и тогда сообщение несет Then, т.е. Команду. Может быть на стороне сервиса-потребителя, и тогда сообщение несет When, т.е. Событие (хореография, когда каждый сервис сам определяет свою роль в бизнес-процессе). А может быть между ними, т.е. ProcessManager.

Возвращаясь к вопросу о Командах/Событиях.

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

Возникает вопрос - а где размещается логика, отвечающая за то, чтобы в ответ на Событие была инициирована необходимая Команда?

Ответ зависит от типа Relationship между Bounded Context (BC).

Допустим, заказ укомплектован и его нужно передать в доставку, т.е. доставить. Доставить груз/посылку. Обратите внимание на использование другого термина, которым утрачена избыточная определенность об оригинале, т.е. найдена новая абстракция, а значит, найдена новая модель с другим ubiquitous language.

Событие происходит в одной модели, а команда исполняется в другой модели. Между моделями происходит трансляция языка. Допустим, что каждый BC выражен отдельным сервисом. В каком сервисе разместить эту трансляцию?

Предположим, трансляция осуществляется в сервисе логистики, который подписан на Событие склада. Тогда это Anti-corruption Layer.

Или же она осуществляется в сервисе склада, т.е. в паблишере события. И в шину отправляется уже Команда, а не Событие. Тогда это Open Host Service, обычно с Published Language.

Реализуется слой трансляции, как правило, в виде адаптеров хексагональной архитектуры.

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

Обычно domain specific сервис осведомлен о generic сервисах. Но тут есть нюанс, который раскрывается в этой статье Nick Tune.

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

У него есть канал, где он рассказывает про устройство VM Питона: https://www.tgoop.com/opensource_findings