😕 В последнее время чет заебался так.

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

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

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

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

P.S.: 🅰️ Ну и как всегда, какой-то практичный совет – трекайте свою активность, чтобы вовремя снижать нагрузку перед сезонными провалами энергии, если таковые у вас, конечно есть. Ну и чем точнее трекаете уровень энергии, тем пизже. Мне вот коммиты зашли, но это не единственный способ.

⚖️ Закон Конвея – реально закон, а не просто остроумное наблюдение!

Знаете про такую штуку, как закон Конвея? Он формулируется примерно так: организации проектируют системы, которые копируют структуру коммуникаций в этой организации.
 
Ну то есть, если рассмотреть на практике, то архитектура IT проектов компании и связанность между, будет в напоминать структуру отделов этой компании.
 
Так вот я всегда этот закон не считал законом. Я его относил к эвристическим утверждениям, типа CAP-теоремы, закона Мура и теоремы Эскобара. То есть это конечно интересное наблюдение, но теоретической и доказательной базы у него нет – это просто удобная мыслительная модель.
 
Однако, наткнулся на вот такое исследование от парней из Гарварда, где в общем-то они придумали, как оцифровать связанность проектов и в общем подтвердили закон Мура на практике.
 
Из интересного:

1️⃣ Какие брали данные. Взяли 5 пар компаний в пяти разных областях продуктов: Финансовый менеджмент, текстовые процессоры, операционные системы, табличный редакторы, базы данных. Сравнили между собой слабосвязанные и сильносвязанные системы, к примеру MySQL и BerkleyBD. Первую разрабатывают 60 организаций-контрибуторов из 25 стран. Вторую соответственно одна организация-контрибутор из одной страны. (пояснительный дикпик 2)

2️⃣ Как определили что такое сильносвязанные и слабосвязанные оргструктуры. Связанность организационной структуры считали вот по этой таблице (пояснительный дикпик 1). К примеру, в ней есть параметр "цель", в сильносвязанных оргструктурах она была расшаренной и явной, а в слабосвязанных разнообразные, неявные.

3️⃣ Как определили связанность архитектуры кода. Связанность программной архитектуры смотрели по связанности файлов исходного кода. Связанность между файлами определяли через Function Call. (пояснительные дикпики 3 и 4)

4️⃣ Какую метрику определили как ключевую для сравнения между проектами. На основе связи между файлами строили граф, в котором учитывали длинны путей, на основе которых построили метрику Propagation Cost, которая показывала стоимость изменений в каждом файле.

5️⃣ Самые интересные цифры:
 

Стоимость распространения (propagation cost) для открытых и коммерческих продуктов:
 

Пара финаносовый менеджмент:

Открытый продукт - 7.74%
Коммерческий продукт - 47.14%
 

Пара текстовые редакторы:

Открытый продукт - 8.25%
Коммерческий продукт - 41.77%
 

Пара таблицы:

Открытый продукт - 23.62%

- самая крупная стоимость из всех слабосвязанных продуктов!

Коммерческий продукт - 54.31%
 

Пара операционные системы 1:

Linux - 7.18%
Solaris - 22.59% (потенциально может затронуть более 2,400 других файлов при изменении)
 

Пара операционные системы 2: 

Linux - 7.21%
XNU - 24.83%
 

Пара базы данных:

Открытый продукт - 11.30%
Коммерческий продукт - 43.23%

 
6️⃣ Неожиданный поворот для одного из опенсорсных проектов – оказалось, что он самый сильносвящзанный среди слабосвязанных! То есть в среднем по статистике в слабсвязанных системах стоимость изменения была на порядок ниже. Однако в случае табличного редактора разница оказалась не столь значительной! Ребята посмотрели отдельно стурктуру контрибьюторов открытого проекта и оказалось, что в ней присутствует сильная связанность! Так как основных мейнтейнеров в проекте оказалось мало и они тесно взаимодейстовали между собой!
 
🅰️ Итого: Короче, к какому выводу мы можем прийти? Закон Конвея – релаьно закон, у которого есть статистическое хорошее обоснование и эксперимент. То есть как у вас выстроена структура компании плюс-минус такая будет и структура проектов. Такие дела!
 
Тут я не все описал подробно. Про Propagation Cost хочется возможно написать отдельно, как эта штука устроена, и как она выводилась для отдельных файлов, а затем для всего проекта в целом.

✅ StatusCake – чекалка для сайтов  

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

Короче, полезна в кейсах, когда вам надо супер-верхнеуровнево чекнуть, что ваш сайт работает. Типа через все ВПНы, НАТы и прочие сетевые прикольчики.

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

Ну то есть мониторинг может гореть, как сентябрь, а статус-кейк будет такой "It's fine". И наоборот – в мониторинге штиль, а статус-кейк будет орать, что все плохо, потому что какому-то надзору захотелось вас похарасить.

🅰️ Итого: Если вам нужно регулярно проверять достпуность вашего проекта из разных стран, то посмотрите на StatusCake. Он первым выстрелит, если у вас все работает, но по какой-то причине никто не может зайти только из какой-то одной страны.

🎂 Блин, а еще бесят тулзы, которые называют чем-то съестным. Я тут худеть пытаюсь, а тут у тебя алерт на пирог прилетел, ну и все – я ем пирог.

📀 Minimal API. Нужно ли переписывать существующие проекты на Minimal API? Что делать со старыми?

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

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

В общем. Сколько лет назад они вышли? Три года почти. Тогда Ник Чапсас рекламировал эту фичу тем, что теперь проект с нуля можно написать в три строчки.

Ну как бы круто, но тогда мне казалось, но резон сомнительный.😒

✅ Так вот спустя все эти годы, я наконец услышал нормальный довод: Контроллеры пришли к нам из мира MVC. Но с развитием отдельных фронтендов из MVC мы часто теряем V. Получается, что остается только MС. То есть не фреймворк, а какой-то рэпер ❤️.
 
В общем, майки переосмыслили эту ситуацию и сфокусировались при создании Minimal API на создании хорошо документируемых и быстро разрабатываемых API.
 
🅰️ Что это значит на практике.
 
1️⃣ Нужно ли нам переписывать старые проекты с MVC на minimal API? Ну в целом, если не лень, то можно. Если они не содержат никаких View.
 
2️⃣ Если запускаете новый проект, который будет чисто АПИшкой, то лучше сразу юзать minimalAPI. Как я понимаю сейчас для этой штуки делаются наиболее широкие инструменты для автодокументации. И вообще создаются дизайн-гайдлайны по проганью АПИшек. Нет смылса тащить туда контроллеры ни в каком виде.
 
Мне такое объяснение показалось наиболее осмысленным. Но я тут готов если что к дополнительным пояснениям.

🧑‍💻 DevForum в массы!

Вот уже почти четыре года так или иначе участвую в организации внутренней мини-конфы в Додо под названием Девфорум.

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

Ведем все это мы со Степой Гранкиным и Севой Паршиным в свободное от кода время.

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

🅰️ Итого: Подключайтесь к трансляции, посмотрите на нашу внутреннюю кухню) Без купюр, возможны маты и неприлично содержательный контент.

👩‍💻 Yet another dev – крутой канал по шарпу, в котором пока всего 27 человек.

Короче, пока свыкаюсь с новой ролью Engineering Manager'a и временно поставил постинг матерных постов сюда на паузу.

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

Не могу не прорекламировать канал yet another dev, в котором постится топовый контент по шарпу, и при этом там всего 27 подписчков.

Мое знакомство с этим каналом началось с поста на хабре Правило 16 байт: развенчиваем миф о производительности структур в C#
 
В общем автор делает там несколько бенчмарков, и приходит к выводу, что сейчас рекомендуемым размером для структур является 64 байта, ну и почему именно такой размер.

🐷Блок для душнил: если вы почитаете статью, то у вас возникнет неплохая пачка вопросов. И это норм. Там не супер-глубокое исследование, но довольно хороший старт для того, чтобы вы сами пошли и начали разбираться с этим.
 
В общем, автор канала, как и я не парится с пиаром и не часто постит, но старается постить какой-то свой контент, который, как мне кажется, ну достоин внимания. К примеру сегодня вот вышел пост про новые params в C# 13.

Ну и еще несколько пиздатых канальчиков вам, вдруг вы не знали:
C# Heppard – канал про перфоманс и работу с памятью в дотнете от Кирилла Бажайкина

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

📝 Ну и вот вам мемас в тему менеджерства, раз уж первый день лета

🥈 DevForum в массы 2

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

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

🏓 То есть работает по такому принципу. Сидит себе разработчик, пилит таски. Вдруг, бац, вспоминает: “А на девфоруме же недавно вот такое рассказывали, может я это сейчас заюзаю?” Ну или скорее “Чет, я где-то слышал, что вот так делают, правда не помню где. Но надо попробовать!”

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

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

🅰️ Итого: Приходите глянуть в 16:00 МСК, у Валеры есть стремительно растущий канал с анонсом предстоящего девфорума и всяким про разработку и жизнь марафонца-футболлиста)))

UPD: полумарафонца-футболлиста!

🧙‍♀️ Импакт от Геншина: Часть 1

Тут у нас в внутреннем канале написали про то как офигенно коллаба c Геншином повлияла на продажи в Турции. Там с Додо Пиццей мало кто знаком, а вот с аниме-дрочильнями знакомы почти все! Но теперь, все со всеми знакомы и повышают продажи додстеров 🎁 (Вдарили аниме-дрочильнями по бездодстерью!)

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

Что мы там вообще сделали

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

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

Я такие игры видел на куче сайтов и мне всегда было интересно, как такие штуки реализуют? Как справляются с нагрузкой? Как на бэке там все реализовано?

🐇Оказалось все не так сложно, но есть пара интересных нюансов, которые нужно учитывать при проектировании таких штук:

1️⃣У нас новая доступная для клика пасхалка открывалась каждый день.
2️⃣Игра стартовала каждую неделю в течение четырех недель подряд.
3️⃣Ну и наше любимое – в разных странах свое количество призов и разное количество игровых недель.

👍 Мы сделали три эндпоинта для работы с этой логикой через мобилку:
1️⃣Стартовать игру
2️⃣Получить список доступных пасхалок
3️⃣Открыть пасхалку по которой кликнули.

Был большой соблазн объединить 1 и 3 пункты, ну типа кликнул по пасхалке первый раз – вот и стартовал. Но в итоге оставили их раздельными и это довольно неплохо упростило тестирование. В старте игры были свои корнер кейсы, а в открытии пасхалок свои.

Тут бывалый взгляд наверняка отметит, что "Ну чуваки SRP – понятно, что так нужно было делать сразу!"

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

Это вообще было для меня некоторым открытием после веб-разработки. В вебе тебе добавлять-удалять новые эндпоинты – как два пальца обоссать. Но для мобилок – это боль. Ибо каждая версия приложения живет довольно долго и может еще год-два запрашивать уже давно неиспользуемую логику.

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

Ой, но вы бы знали, как мы про всю эту хрень спорили, порой просто жесть 🙏

🧙‍♀️ Импакт от Геншина: Часть 2

Еще одна вещь, которая стала для меня важной в этой задаче и может вам будет полезной.

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

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

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

🅰️ Кстати, рекомендую во всей времязависимой логике юзать эту штуку!

Юзается просто

public class MyService
{
private readonly TimeProvider _timeProvider;

public MyService(TimeProvider timeProvider)
{
_timeProvider = timeProvider ?? throw new ArgumentNullException(nameof(timeProvider));
}

public DateTimeOffset GetCurrentTime()
{
return _timeProvider.GetUtcNow();
}
}

А мокается потом изично, потому что класс абстрактный. Я вот заиспользовал, и был доволен, потому, что раньше для тестов нужно было городить свои городульки, а тут на тебе – все готово! 🪢

⚔️ Импакт от Геншина: Часть 3

Еще одна вещица, про которую хочу рассказать. Это про то что я наконец пощупал на этом проекте монгу.

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

Представьте себе такой домен, в котором:

1️⃣ Логика и хранимые данные часто меняются – добавляются новые таблицы, в самих структурах могут добавляться новые поля.

2️⃣ К примеру это какие-то временные акции, конкурсы итп.

3️⃣ Хранить такие данные нужно ограниченное время (год-два максимум, но может и больше).

А еще данные по каждому пользователю слабосвязанные и вам не нужны селекты через несколько таблиц

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

У нас это реализовано вот как:

🏓 Есть огромная таблица OperationalData. Она хранит в себе вот такой дженериковый тип данных:

public class OperationalData<T>
{
 string ShardKey {get; set;}
 T Payload {get; set;}
 int LifeTime {get; set;}
}

public class PromotionStatus
{
 string UserName {get; set;}
 Promotion CurrentPromotionType {get; set;}
 DateTime NextPromotion {get; set;}
}

public class Discount
{
 Guid Id {get; set;}
 DateTime AvailableFrom {get; set;}
 DateTime AvailableTo {get; set;}
}

И вот в такой приятной хранилке ты можешь делать вот такие штуки:

var userPromotionStatus = db.Collection.Find(x => x.ShardKey == $"PromotionStatus_{UserId}").ToPromotionStatus();

var userDiscount = db.Collection.Find(x => x.ShardKey == $"Discount_{UserId}").ToDiscount();

➕ Если вам нужно добавить новые данные, то никаких проблем, просто добавляете и пишете новые данные! Находтся такой объект супер-быстро. По одному шард-кею вы можете хранить и не только одну запись.

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

➖ Но есть минус, что делать селекты таких данных между пользователями вот так невозможно.

Я это очень удобно заюзал. Правда мне вот это как раз стрельнуло в ногу чутка. 🍌