О спорах про технологии.
🇨🇳 Какой язык программирования самый лучший? Я вот думаю, что китайский. Ладно, это шутка-минутка. Не могу без них, простите.

Кажется, что все понимают холиварность этого вопроса, итогом которого будет ответ "дело вкуса". Но почему-то, когда вопрос касается библиотек, то тут уже не так очевидно.

Я вот недавно узнал, что мой любимый MediatR некоторые люди считают говном! (Кстати, он скоро станет частью BCL, с чем я его и поздравляю! Точнее старину Джимми Боггарта) Мол, он усложняет чтение кода, а нормального CQRS не дает.

🤬 Сначала хотелось возразить, что это все жуткая неправда, и вы все не понимаете! Вот же есть классные репозитории, у которых не зря в названии стоит CleanArchitecture и там используется MediatR! https://github.com/jasontaylordev/CleanArchitecture

Ну я собственно и возразил! Потому что, йопт, я человек или где?!

Мне в ответ кинули этой статьей https://cezarypiatek.github.io/post/why-i-dont-use-mediatr-for-cqrs/

Разумеется я поступил с материалом, как и положено порядочному оппоненту в споре – положил на нее С ПРИБОРОМ и написал в чат, что ОБЯЗАТЕЛЬНО ознакомлюсь.

🤔 Но все же я задумался. А ведь и правда, человеку стороннему, все эти хэндлеры с запросами и прочими бихейвиорами покажутся прям дремучим лесом. В тысячу раз понятнее как прочитать вот это

var result = await _smsService.Send(message, ct)

чем вот это

var result = await _mediatr.Send(message, ct);
 
Конечно, уверенный пользователь медиатра не напишет такого кода. Но у нас есть новички, которые могут всякое. Могут и не так понять, как использовать. Это как в трудностях перевода – по формке все правильно, а по факту нет.

Вот тут меня и осенило. Это сейчас будет не новая мысль, но все же. Библиотеки – это расширения для языка. А значит, люди, пользующиеся разными библиотеками, по сути говорят немного на разных языках.
 
Ну точнее не совсем на разных языках, но на разных диалектах. Поэтому код, понятный одному, написанный по всем принципам SOLID может быть непонятен другому. И это вполне нормально! А значит польза или бесполезность библиотек – это дело вкуса, как и в случае с языками программирования.
 
Я вот не люблю AutoMapper (кстати, тоже въехал в BCL). Мне кажется, что в нем есть смысл только тогда, когда названия свойств в моделях одинаковые. Если же есть хоть одно отличие, то вот эти все правила маппинга, которые ты потом еще и хрен найдешь, усложняют модификацию кода. Охренеть причем как!
 
Но при этом я видел людей, которые легко находили эти правила, и придумывали понятные DSL'ки для поиска. То есть для них понятные, для остальных это все еще был пиздец.

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

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

⛽️Кодовый газлайтинг.
Нет ничего страшнее, как мне кажется, чем кодовый газлайтинг.

Это когда ты тратишь время на проверки, выкатываешь код на прод, а потом кто-то приходит к тебе и спрашивает: "Ну как там, раскатил изменения? А то что-то ничего не поменялось."

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

А на проде кнопки нет! Сидишь в замешательстве (да в каком замешательстве!? ты в чистом ахуе!), думаешь на себя, что ты чертов растяпа, не проверил что-то. Вспоминаешь, как перед выкаткой позволил себе слабость – не проверил какую-то там запятую. И понимаешь, что вот ты безответственный мудак! А потом – БАЦ!

И оказывается, что просто кто-то накатил что-то поверх и просто затер случайно твою фичу... Я так пару раз чуть кукухой не поехал. 🐦

План – не стратегия!
Я уже говорил, что обожаю Harward Business Review. Так вот теперь я их обожаю еще и в своем любимом видеоформате! И не могу не поделиться видосом про отличие стратегии от плана, которые все часто путают. А разница просто жесть какая!

Ключевые мысли видоса:
1️⃣ Стратегия – это связанный набор решений, который позволяет вам разместиться на игровом поле в положении, из которого вы можете выиграть.

2️⃣ Стратегия – это теория! Как и всякая теория она должна быть непротиворечивой и согласованной. Отвечать на вопрос, почему мы делаем что-то на этом игровом поле (читай рынке), а не на другом? И как мы будем приносить здесь большую пользу, чем конкуренты?

3️⃣ Планирование – не имеет никакой согласованности. Это просто набор действий.

4️⃣ Лидеры чаще выбирают планирование, просто потому что это проще.

🅰️ Смотреть здесь:
https://www.youtube.com/watch?v=iuYlGRnC7J8&ab_channel=HarvardBusinessReview

P.S.: А еще там важная мысль, о том, что словосочетание Стратегическое Планирование – это вообще бессмысленная хуета.

Если прикладывать чисто к программистским потребностям. Допустим, у вас есть план обучения:
1) Сначала выучу алгоритмы,
2) Потом базы данных,
3) Потом еще какое-то говно.

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

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

Выбирайте стратегию! Это сложно, но окупается.

🍚 Как сделать так чтобы RICE заработал?
Я тут прохожу курс для product ownerов https://productmindset.net, и там у них есть таблица скиллов по грейдам, где один из инструментов приоритезации, которым должен уметь пользоваться крутой PO – RICE.

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

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

И я долго рефлексировал, что же с этим всем не так?

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

🅰️Если оценивать задачи по RICE внутри одного контекста, то получится гораздо лучше!

P.S. Мне вообще в последнее время кажется, что внятная стратегия для команды разработки это что-то вроде коллективного здравого смысла. Если она есть, то вам скорее всего не понадобится никакой RICE. Ну и наоборот, если вы не можете сформулировать стратегию, то никакой ветер не будет вам попутным.

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

Вот этот ретрай не заработает. Вопрос: как думаете, почему?

[HttpGet]
public async Task<string> Get()
{
var policy = GetPolicy();
var url = new Uri(@"http://localhost:5000/someurl");
var msg = new HttpRequestMessage(HttpMethod.Get, url);

return await policy.ExecuteAsync(() => GetForecasts(msg));
}

private IAsyncPolicy GetPolicy() {
return Policy.Handle<Exception>().RetryAsync(3);
}

private async Task<string> GetForecasts(HttpRequestMessage msg)
{
var resp = await _client.SendAsync(msg);
if (_rng.NextDouble() > 0.95) {
throw new Exception( "oops");
}

return await resp.Content.ReadAsStringAsync();
}

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

#ресайленс

💣 Задача 5: Неочевидности при ретраях. Ответ

При ретрае HttpRequestMessage выдаст ошибку:

InvalidOperationException(SR.net_http_client_request_already_sent)

Чтобы это исправить, вам нужно внести переменную msg внутрь GetForecasts.

🅰️В общем, передавая параметры в лямбду при ретраях, смотрите внимательно, а не нужно ли их создавать заново при каждом запросе. Так-то! Ну признавайтесь, ведь не думали об этом!

#ресайленс

dick pic

🥅 Service Mesh
Уже в 10-ый раз я пытался разобраться с тем, что такое Service Mesh и с чем его едят. Ндавно вот была очередная 11-ая попытка. Закреплю здесь все, что понял, чтобы облегчить себе следующую попытку.

🧑‍🏭 Service Mesh – это когда ваш сервис перестает сам делать запросы к другим сервисам. Вместо этого мы ставим рядом с нашим сервисом сайдкар (просто еще один сервис) и делаем запросы к нему. Этот сайдкар понимает, к какому сервису мы хотим обратиться и идет к этому сервису к сайдкару этого сервиса! Вот так вот. Пояснительный дикпик выше. Подробное описание ниже:
[Подробное описание]
 
❓А что это дает?
С точки зрения производственной практики в целом ничего. Но с точки зрения отладки – это мастхэв. Сайдкары инкапсулируют в себе всю логику по взаимодействию между сервисами – ретраи, трейсинг, логирование времени запроса и прочее.
 
Есть определенные инструменты, которые могут анализировать взаимодействие сайдкаров между собой и предлагать вам оптимизации, если ваши коммуникации перегружены.

🅰️Когда надо брать?
Когда вы чувствуете, что погрязли в рутине настройки межсервисных коммуникаций и почти перестали писать бизнес-логику.
#servicemesh

❓Как запустить продуктовую команду, если у вас нет продукта?
Продолжаю проходить курс на ProductMindset и сегодня смотрел тему по скарму. Я уже давно вроде как знаю этот фреймворк, но только сейчас заметил некоторый его фундаментальный недостаток – скрам позволяет работать только если у вас уже есть продукт и его метрики. Но что делать если продукта еще нет?
 
🦤 У нас в Додо, как мне кажется, как раз такая ситуация с продуктами для управления процессами на кухне.

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

Ⓜ️Мысль, как исправить это: Перед запуском скрам команды в таком случае необходимо провести разработку/разведку продукта. То есть взять несколько спринтов, за которые продуктовая команда для начала выяснить:

1️⃣ Какие основные метрики они собираются улучшать
2️⃣ Как улучшение этих метрик связано с целями компании
3️⃣ Какие изменения за один квартал можно успеть сделать чтобы улучшить эти метрики.

❗️Тут мне кажется важно, что первый бэклог, который будет сформирован не должен быть годовым. Потому что, руководствуясь одним из принципов скрама – работа короткими итерациями, – в течение первого пробного спринта могут вылезти какие-то другие метрики, а какие-то стать ненужными и это нормально.
#процессы

Как IDE влияет на архитектуру вашего решения.
Я тут наткнулся на статью в соседнем C# канале: Ваш Язык Влияет на то, Как Вы Думаете. https://news.1rj.ru/str/NetDeveloperDiary/1630

Там рассказывается о том, что DI контейнеры в Java считаются плохой практикой, а в .NET наоборот считаются хорошей. И все не из-за того, что сама концепция DI плохая, а из-за особенностей языка.

Как-то давно я думал о чем-то подобном, что вообще не только сам язык определяет то как вы думаете, но еще и менее очевидная мысль – IDE которой вы пользуетесь тоже определяет ваш образ мыслей.
 
Как-то мне пришлось писать на Go. (Абсолютно богомерзкий язык на тот момент!) Под рукой не было GoLand от JetBrains, и я воспользовался Visual Studio Code. В расширении для Go был баг, из-за которого автокомплит не работал.
 
И тут я понял, что классическая структура с папочками и разными файлами, тут настолько неудобна, что пришлось от нее отказаться. Потому что вспоминать название какого-то метода и класса гораздо проще, когда все файлы свалены в одну папку.
 
То есть один только автокомплит позволяет вам в принципе думать о том, чтобы раскидать файлы по папочкам!

🅰️ Какой практический вывод можно сделать? Да самый прямой! Если у вас в разных командах в почЁте разные IDE, то и архитектура проектов этих команд может различаться чуть сильнее чем вам хотелось бы. Чтобы избежать таких изменений продумывйте ограничения (главное не запрещайте IDE – это тупизм) которые помогу избежать слишком больших различий. StyleCop и все вот это вам в помощь.

🦾Внедрение IoT решений
Третьего дня ребята из одной из крутейших наших команд показывали результат своих экспериментов с умными весами. Ну как умными. Весы умеют отдавать свои показатели через http. И что, они теперь умные? Я вот свои показатели по http отдать не могу. Получается тупой – не преодолел технологическую сингулярность.

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

🪵И для меня сразу открылась веточка развития под названием "Архитектура IoT". А именно ответ на вопрос, а как вообще люди приходят к внедрению этого дела у себя в бизнесе.

В голове сложились такие этапы:
1️⃣ Любительский эксперимент, который упрощает локальную рутину.
2️⃣ Несколько разрозненных любительских экспериментов, без упорядочивания и стандартизации
3️⃣ Упорядочивание и стандартизация платформы - подключение новых решений по стандарту.

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

❓Как не упустить этот этап? Вопрос хороший, и, кажется, скоро мы увидим на него ответ. Я пока пойду искать опыт внедрения в интернете.

🅰️Кстати, если видели какие-то материалы по этой теме, накидайте в комментарии. Интересно будет почитать.
#IoT #architecture

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

Я смотался в Грузию месяцем раньше чем начался Пиздец.

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

Тут важная, не отоносящаяся к основной линии ремарка про отношение к русским в Грузии:
Люди порой боятся, что к русским теперь плохо относятся в Грузии, а это вот ни разу не так. Вчера говорил с хозяйкой съемной квартиры, вот ее слова: "Слава Богу, что вы успели уехать. Это такой кошмар!" Не бойтесь – в Грузии живут прекрасные люди!

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

Есть один друг, который купил билет в Тегеран (да, в это время все еще есть люди, которые не читают новости). Вот 100 раз хотелось его отговорить, с учетом всего. Но человек выбрал путь – я могу лишь сделать его чуть более гладким – что-то оплатить с иностранной карты, где-то подбодрить и сказать, что все получится. А иногда достаточно просто быть на связи, чтобы человек мог тебе проговорить свои мысли и немного осмотреться. (Блять, ну и разумеется, я просто для галочки проинформировал, что там так-то тоже пиздос!)

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

Ну и, да, если кому-то нужна помощь в Батуми, то я здесь и готов встречать в аэропорту, давать насколько могу ночлег, показывать, что тут и как с деньгами и вообще осваиваться. Такие дела. Если нужно кого-то встретить, пишите!

UPD: С другом, который летел через Тегеран все в порядке - долетел до Дубая. Вот уж воистину. А еще друг из Минска прилетел в Тбилиси вчера. Так что зря даже Максим Кац нагнетал по этому поводу.