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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

? "Дисциплина - это действие сдерживающих начал в действии личности" -- А.С. Макаренко "О воспитательной системе" Великолепное определение, хорошо понятное мне исходя из принципов разрешения противоречий в архитектуре. Вообще говоря, грань между архитектурой…

Telegram

Системный сдвиг

На конфе "Анализ & Управление в ИТ-проектах" от Infostart мне очень понравился мастер-класс по ТРИЗ. ТРИЗ часто вспоминают в связи с ИТ, но толком мало кто может рассказать, как его системно применять. Тут тоже не было особо сильной привязки к ИТ, но зато…

Исправление - это комплекс мер. Тут надо смотреть, где идет затор, сверху или снизу. Я обычно делаю так (но я не советую за мной повторять из-за высоких рисков, просто у меня с моим польским характером по другому не получается): 1. На работу выхожу, когда…

Ну и остальное на https://triz-guide.com/books можно поглядеть :)

Triz-Guide

Библиотека изобретателя | Институт Инновационного Проектирования

В Обзоре судебной практики по делам, связанным с защитой прав потребителей финансовых услуг, утв. Президиумом ВС РФ 27 сентября 2017 г., отмечена позиция, что адрес проживания и номер телефона относятся к персональным данным (+ определение Судебной коллегии по гражданским делам Верховного Суда РФ от 01.08.2017 N 78-КГ17-45).

Плюс - скан с сайта РКН со страницы заполнения Уведомления о намерении обработки ПДн.

Не всё так сложно, как однозначно кажется))

Подборка постов, которая заменит вам прочтение пары книжек по конфликтам
За 9 лет работы мы проанализировали несколько тысяч конфликтных кейсов. На их основе получился фреймворк для работы с конфликтами, который позволяет легко анализировать любую ситуацию и быстро выбирать оптимальную стратегию коммуникации. Мы душнейшие душнилы с точки зрения системности :)

Наша система теории работает повсеместно: в огромных корпорациях и малых бизнесах, технологичных стартапах и госкомпаниях, на кассе в магазине и семейных отношениях.

Основа этой системы — «лестница», которая делит решение конфликта на 4 этапа. Давайте расскажем, какие посты помогут вам ее освоить и чувствовать себя уверенне в коммуникации??

1️⃣ Начните с поста про лестницу решения конфликта.

2️⃣ Чтобы освоить приемы для работы с эмоциями, читайте этот пост. Дали в нем 3 универсальных способа, как снять напряжение в разговоре и отрезвить собеседника.

3️⃣ Чтобы научиться уверенно доносить свои потребности и недовольство без агрессии и манипуляций, прочитайте следующие материалы. В них мы разбираем обозначение личных границ на разных кейсах и примерах:

1. Статья на VC про универсальную формулу обозначения личных границ2. Как перестать закрывать глаза на нарушение границ

3. Почему не стоит быть «удобным» и как показывать границы на работе

4. Кейс подписчицы про смещение авторитета и критику на работе

4️⃣ Если человек нарушает ваши границы осознанно, пора их защищать. Выбирайте, каким приемом будете противодействовать манипулятору: декодирование, гиперболизация, ломание причинно-следственных связей.

5️⃣ Про финальный этап решения конфликта — сепарацию, наш тренер Михаил Ромашов рассказал в статье на VC. Читайте, чтобы научиться грамотно расставаться с людьми.

? Фух, ну вроде все! Изучайте и приходите практиковаться на наши открытые воркшопы 28 и 30 мая. Будем разыгрывать кейсы и обсуждать риски и возможности различных стратегий поведения.