emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.

Eще несколько решений, способных облегчить Out-of-process Component (Acceptance) Testing:
- https://schemathesis.readthedocs.io/
- https://hypothesis.readthedocs.io/
- https://github.com/python-jsonschema/hypothesis-jsonschema
- https://pypi.org/project/hypothesis-sqlalchemy/
- https://dredd.org/

Добавил поддержку Gherkin для реализации Fitness-Functions в Performance Framework. Теперь описание Fitness-Function выглядит примерно так:

  Scenario: Some object endpoint name
    Given SUT with 10000000 objects
    When 100 processes created 10000 objects each
    Then average RPS is greater than 1000
    And error rate is less than 5%

Реализация подобного сценария посредством behave с использованием Performance Framework занимает всего 40 строк кода (половина из которых - это пустые строки и переносы строк для форматирования). Все зависимые объекты в БД создаются автоматически с сохранением селективности индексов целевой системы (включая индексы внешних ключей зависимых объектов). Подробная статистика запросов накапливается на сервере статистики. В перспективе, при наличии благоприятной возможности, может быть добавлена поддержка декларирования вероятностной распределенности зависимых объектов и проиндексированных значений непосредственно в Gherkin-спецификации.

Материала по этой теме накопилось на полноценный доклад (если даже не на целую книгу). Подумаю об этом.

Может кому-нибудь пригодится для Out-of-process Component (Acceptance) Testing:
https://github.com/litestar-org/polyfactory

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

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

17 января совместно с командой закончил работу над созданием нагрузочного фреймворка для микросервисов, аналоги которого мне неизвестны (иначе я бы их применил).

Началось все с создания генератора объема фейковых данных (см. здесь и здесь) для микросервисов, который воспроизводил бы селективность индексов как в целевой системе.

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

Поддерживаются композитные ключи (первичные и внешние). Вероятностная распределенность поддерживается как для композитного ключа целиком, так и для составляющих его ключей.

Поддерживается логика многоступенчатого создания агрегата (black-box), когда агрегат возможно привести в необходимое состояние только серией запросов через public API.

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

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

Вскоре мы обнаружили, что полученный генератор данных можно использовать и для нагрузочных тестов. Адаптировали его для работы с публичным API (вместо прямого доступа к БД), сделали поддержку multiprocess.

Интегрировали его с нагрузочным движком molotov. Изначально рассчитывали на Locust, но обнаружили, что asyncio там не поддерживается и его поддержка пока не предвидится. Позже я узнал от @nkhitrov, что решение все-таки есть.

Потом мы обнаружили, что полученное решение можно без труда использовать для Out-of-process Component (Acceptance) Testing.

Таким образом, нам удалось сделать тестовый фреймворк (на Python), который позволяет одновременно и генерировать фэйковые объемы данных, включая автоматическое создание всех зависимых объектов, и создавать нагрузочные скрипты, и выполнять component out-of-process tests.

Теперь хотим завернуть его в Gherkin, чтобы fitness-functions в нем описывать. И добавить декларативное описание моделей посредством YAML-file.

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

Работаем!

Рассчитывал на Locust, но обнаружил, что asyncio там не поддерживается и его поддержка пока не предвидится.

Нашелся нагрузочный микро-движок, который выручил: https://molotov.readthedocs.io/

Мартин Фаулер, международный эксперт по программной инженерии, начал свою публичную просветительскую деятельность с книги Analysis Patterns 1997-го года.

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

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

Андрей Гордиенков решил исправить это досадное обстоятельство и подготовил собственную версию перевода.

https://habr.com/ru/articles/872598/

Вступление
1.1 Концептуальные модели
1.2 Мир шаблонов
1.3 Шаблоны в этой книге
1.4 Концептуальные модели и реинжиниринг бизнес-процессов
1.5 Шаблоны и фреймворки
1.6 Использование шаблонов

Часть 1. Аналитические шаблоны
2. Ответственность
3. Наблюдения и измерения
4. Наблюдения для корпоративных финансов
5. Обращение к объектам
6. Инвентаризация и учет
7. Использование моделей учета
8. Планирование
9. Торговля
10. Производные контракты
11. Торговые пакеты

Часть 2. Поддерживающие шаблоны
12. Слоёная архитектура для ИС
13. Фасады приложения
14. Подходы для моделирования типов
15. Шаблоны ассоциации
16. Послесловие

Часть 3. Приложения
А. Техники и обозначения
В. Таблица паттернов
C. Краткая справка по диаграммам

Как любил повторять один известный исторический деятель - «короче», «яснее». Вот это видео очень хорошо демонстрирует этот принцип:
https://vt.tiktok.com/ZS62A4GXs/

Примерно так же должен изъясняться и архитектор. Обратите внимание на отсыл к Закону Миллера в этом видео, и на акцент на визуализацию.

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

💬 „Всем известно, как тихи кладбища. Библиотека – самое веселое из них. Тут уж покойники в полном составе: они не сделали ничего плохого, лишь писали… От книги исходит аромат склепа. Вот тут начинается странный процесс, которую он называет чтением. С одной стороны, это обретение: он передает свое тело мертвым, чтобы они могли ожить. С другой – это общение с потусторонним миром.“ — Жан-Поль Сартр

Источник: https://ru.citaty.net/tsitaty/641057-zhan-pol-sartr-vsem-izvestno-kak-tikhi-kladbishcha-biblioteka-sam/

💬 "Как только мы почувствовали гнев во время спора, мы уже спорим не за истину, а за себя." -- Карлейль

Алина Богачёва @mialinist подготовила очередной раздел Systems.Wiki на тему

Generative AI for Analysis & Design

в раздел попали материалы:

1. Список нейросетей

2. Бизнес-анализ и требования
Анализ информации
— Обработка интервью
— Обработка анкет
— Анализ законов

3. Системный анализ и требования
Техническое задание
— Описание функциональных требований к системе
— Описание юскейсов
— Описание ограничений системы

4. Моделирование и диаграммы
Генерация схем
Генерация UML-диаграмм

5. Интеграции
Создание сценариев интеграции
Создание API-запросов
— REST API
— SOAP

https://systems-wiki.notion.site/Generative-AI-for-Analysis-Design-14b8db9e4167808eac30de6d5740dc03

Обсуждаем кейсы применения GenAI в группе @genai4AnD

С днем рождения меня, дорогой! 🍾🎂🥂🎇🎊🎉
https://t.me/emacsway/s/6

Очень интересна неоднозначная реакция на предыдущие посты. Хотя описанное явление известно под названием "Larman's Laws of Organizational Behavior".

Gregor Hohpe описывал это в статье "Reversing the disablement cycle: Everyone does the right thing, yet nothing much gets done. How to break self-reinforcing bad habits."

И есть очень качественный русскоязычный ресурс по этой теме: "Что такое сопротивление изменениям и как с ним работать?"

На эту тему у меня была заметка о том, как осуществлять изменения в коллективе.

Признаться, раньше не слышал про https://mockintosh.io/ . Многим он подойдет лучше, чем Mountebank или WireMock, учитывая, что тестировщикам ближе Python. Правда, давненько коммитов уже не было.

Что используете вы для изоляции тестовой среды сервиса?

Эксперт по DDD пытается помочь команде тонущего проекта 🙂)

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

Наткнулся на полезный репо — best-system-design-resources

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

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

➡️ @PortalToIT | #resourse

Мы подготовили очередной раздел базы ссылок по инженерии информационных систем http://Systems.Wiki

На этот раз раздел по Инженерии Требований.

В него попали подборки ссылок по темам:

Общие стандарты и своды знаний

Сертификации

Международные журналы

Международные сообщества

Международные конференции

Общие пособия по разработке требований

Инструменты разработки и управления требованиями

Критика инженерии требований

Инженерия требований в машиностроении

Инженерия требований в авиации

Формулирование требований

Разработка бизнес-требований

Требования к продукту

Требования уровня пользователей
— User Stories
— User Story Mapping
— Use Cases

Разработка системных требований

Разработка требований к информационным системам

Разработка требований к ПО

Обеспечение полноты требований к ПО

https://habr.com/ru/news/704392/

https://www.youtube.com/watch?v=AHlDDthxN58

Выступил вчера на AnalystDays'16. На этот раз постарался выдать максимум шаблонов и цепочек промптов, чтобы можно было сразу брать и применять. Держите презентацию!

Недавно обсуждалось такое же явление в одном из профильных чатов. Как видно, это вовсе не редкость. Личный кабинет ИП налоговой службы РФ, форма подачи отчета движения средств по зарубежным счетам. Последний день подачи отчета.

Увидимся на https://archdays.ru/ в эту пятницу.

3k подписчиков — спасибо!

У нас тут в группе задали хороший вопрос — какие документы создают БА, а какие — СА?

Мой заход в тему:

БА:
- диаграмма оргструктуры
- регламент бизнес-процесса
- модель бизнес-показателей
- карта процессов предприятия
- контекстная диаграмма процесса
- диаграмма потока создания ценности
- карта клиентского опыта
- модель бизнес-процессов
- модель предметной области
- отчет об обследовании
- аналитическая записка
- реестр бизнес-правил
- бизнес-требования
- требования заинтересованных лиц
- модель проблем и целей проекта
- бизнес-ограничения проекта
- концепция автоматизации
- технико-экономическое обоснование проекта / business case
- сценарии использования информационной системы уровня чёрного ящика
- техническое задание на выбор, заказ, разработку, построение информационной системы
- регламенты применения информационной системы
- макеты отчётов
- алгоритмы расчета бизнес-величин

СА (в автоматизации бизнеса и создании ИТ-продуктов):
- модель данных, словарь данных
- модели жизненного цикла объектов ИТ-системы
- функциональные требования к ИТ-системе
- карта пользовательских историй
- алгоритмы обработки данных
- атрибуты качества ИТ-системы
- расчеты количественных показателей эксплуатации ИТ-системы во времени
- модель надежности ИТ-системы
- технические ограничения ИТ-системы
- контекстная диаграмма ИТ-системы или подсистемы
- сценарии использования ит-системы уровня серого ящика
- предложения по функциональному и структурному разбиению ИТ-системы
- техническое задание на проектирование и разработку подсистемы
- структура БД
- сценарии интеграции системы
- спецификация API
- диаграмма навигации по экранам
- черновые макеты пользовательских интерфейсов
- технический проект на разработку ИТ-системы

Кстати, про архитектурные ката.
Еще один сборник ссылок описаний архитектуры решений победителей и призеров O'Reilly Software Architecture Katas можно посмотреть в ката-логе: https://github.com/TheKataLog

Презентация по одной хорошей книжке Влада Хононова (Vladikk).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Learning DDD

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

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

В IcePanel собрали пару ссылок на тексты из серии Modelling vs diagramming и дополнили их новыми словами и картинками. Но, на мой взгляд, не сделали главного, а именно не собрали в одну линию эскизы, модели, представления, исходники, работающее приложение, изменения. Обошли стороной вопросы когда и зачем нужны модели или диаграммы

В этом плане, даже матрица Захмана 1987 года, прокладывающая логику от набросков на салфетке до готовой системы, смотрится более целостной.

Ссылки:
[1] Comparison - C4 modelling vs diagramming
[2] Ardoq Compared to Drawing, Modeling, and Data Visualization Tools
[3] Modelling vs diagramming software architecture

💼 Добавил группу для всех причастных к ИТ-предпринимательству:
- https://t.me/rasa_business

Добавляйтесь)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мне видится эта тенденция положительной, т.к. она способна уменьшить проблему "лимонов и персиков" на рынке труда.

[UPDATE]: после регистрации требуется пройти спам-тест в главном топике https://t.me/archicases/1 за 60 сек.

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