🧐 Практика попизже всяких KISS, DRY и прочей аббревиатурной хуиты: Dependency pruning

Общались недавно со Степой Гранкиным (автором одного из самых популярных навыков для Алисы), и я ему как всегда ныл, про то что мир меняется слишком быстро и непонятно, кто все эти люди, которые знают, какие апдейты, в каких библиотеках происходят?
 
И тут Степа сознался, что он теперь один из них…

Оказалось, что у него в команде принята практика Dependency pruning. В общем, её задача в том, чтобы регулярно удалять неиспользуемые/обновлять используемые в проекте библиотеки. И ты не просто плашечку вверх двигаешь, а читаешь доку. Что там поменялось, что крутого дает и так далее. И делать это раз в неделю или раз в две. Тут как сами решите, но желательно почаще.
 
Выходит регулярно и по чуть-чуть – не так больно, как все везде и сразу и по вдохновению.
 
Я использую эту связку вот в таком для себя сценарии – попробовал интересные мне библиотеки в свои пет-проекты и регулярно их обновляю. Раз в две недели. Плюс пет-проектов в том, что можно добавлять еще незрелые штуки и следить за ними. Это не очень оказывается запарно, но дает хороший триггер для нестрессового обновления знаний.
 
Пишу “нестрессового”, потому что для меня пиздец какой стресс, когда заходишь, а там – ебать-читать. 🤬

🅰️ Итого: Попробуйте завести в пет-проектах или на работе практику регулярного обновления зависимостей – и код в чистоте и голова в порядке. 👨‍⚕️

🎧 Вот вам и пример применения практики (может не самый лучший, но все же)

Недавно (9-го января) заехал новый релиз testcontainers-dotnet. Из него я узнал, что там обновился какой-то Ryuk. Заодно узнал, что это за хрень такая.
 
Оказывается это resource reaper! Это ничем не примечательно, кроме того, что я сейчас играю в Mass Effect 3 и уничтожаю сраных жнецов(reapers)

🏭 А resource reaper – это штука, которая уничтожает контейнеры в докере, после того как они перестают быть нужными.

В любом случае, для общего кругозора интересно. Потому что я, если честно думал, что всем этим сама библиотечка TestContainers занимается, и типа если быстро хлопнуть 🍔 бургер за Собянина запущенные тесты, то получится контейнеры не сдохнут. А оно вон оно как.
 
P.S.: получается в докере постоянно происходит та же херня что и в mass effect! Наверняка контейнеры тоже строят горн и пытаются победить жнецов!

PPS: А еще эта штука названа в честь персонажа из “Тетради смерти”. Придется еще и ониме теперь смотреть. Видите какая практика полезная!

🛵 Курьер на карте – продолжение.

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

Но и по-своему неприятно – значит что-то не работает. Ибо вряд ли кто-то пришлет скриншот с подписью "Глянь как заебись работает!" Если это не дикпик, разумеется.

🔥 Решили в общем бороться с проблемой. Для этого приступили к сбору информации. Решили придумать дашборд, который вмещает в себя всю необходимую информацию о том, как там с нашей точностью.
 
Получился дашборд, который скорее показывает, как там обстоят дела с нашей неточностью. Он собственно на пояснительном дикпике. Ну и по нему видно, что поездок с достаточным количеством точек – меньше половины. Грустненько.
 
В общем наша фича содержала фатальный недостаток и не один, а целых четыре:

👌 Поставили интервал обновления в 1 минуту. Это оказалось катастрофически мало. Так было специально – не хотели перегрузить МАПИ в новогодние пики. Но мы еще и не дали возможность получать этот интервал с бэка, а значит изменить его так просто не получится.

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

👌 Не учли, что координаты могут приходить с отвратительной точностью – типа километров в 200. В наше-то время и такой просчет. И не стали отсеивать такие точки, а просто отдаем их как есть. Мне почему-то стыднее всего за этот пункт, ведь в принципе я с этим лет пять назад уже сталкивался.

👌Еще есть недостаток, про который мы знали, но пока решили забить – когда курьер доставляет два заказа, как это отображать? получается сейчас временами курьер как бы съебывается от вашего дома, причем все время глядя на вас. Но на самом деле сделать как-то адекватно эту фичу сейчас нереально сложно, поэтому решили отложить.

🅰️ Итого
Сейчас выходит, что только ~30% пользователей видят фичу на уровне "сносно", у остальных она не работает. (на дикпике красным показан процент не от общего числа поездок,а от тех, на которых вообще курьер показывается, поэтому я указываю прям реальный процент).

Но руки не опускаем. 🛐 Сначала исправим частоту обновления, потом сделаем так, чтобы как можно больше курьеров по возможности использовали приложение для старта поездки. Ну и напоследок доведем до ума саму отправку координат, прикрутим фильтры для отлова точек с низким accuracy, посмотрим, как сделать так, чтобы сами точки чаще отправлялись (кстати уже процент ползет вверх понемногу).
 
Ну и, конечно, молю всех богов, чтобы все это успеть сделать до конца января. Ибо, ну не круто ваще, когда такая фича, и такое говнище.
 
Короче, вот такие дела. Может вам будет полезно, если будете делать что-то с картами. Ну и делитесь опытом, если тоже нарывались на подобное дерьмо.

🐜 Mircrok8s для своего проекта. Микрообзор.

Я тут приарендовал себе сервер на Hostinger. Выбрал этот хостер потому что вроде как из всех мне доступных он показался самым дешевым по соотношению цены-качества.

За 89$ в год получаешь тачку (по скидке за первый год, потом 215$, что в целом тоже норм):

2 vCPU Cores
8 GB RAM
100 GB NVMe Storage

 
Посколько у этой штуки оказалось 2 ядра и 8 гигов оперативы. Решил попробовать поставить туда microk8s и перевести на это дело тралебота.
 
По прошествии 3 месяцев могу сказать, что полет нормальный. Во первых дохрена чего узнал про кубер за это время:
🟢Как балансировка в нем работает, и почему она работает только в облаке, а не на личном серваке – из-за облачного LoadBalancer

🟢Как задеплоить базку в кубер так чтобы все было чики-пуки – с помощью StatefulSet

➕Из плюсов этой штуки (сравниваю с деплоем в докер, который был у меня до этого):
🟢Графану с прометеусом – сожно поднять буквально одной консольной командой. Есть проблема с недостатком доки про то, как добавить в observability свой дотнетный сервис, но я методом тыка все же разрешил эту проблему.

🟢Не нужно париться с внутренней сетью – все связи между базкой и прочими штуками внутри куберовской сети, а если нужно получить внешний доступ посмотреть что-то в базке к примеру, то можно сделать port-forwarding на время.
 
🟢Чуть удобнее писать скрипты для CI/CD чем в случае с докером. Ну для меня по крайней мере.
 
➖Из минусов:
🟢Там все настроено за вас, и порой работает не так, как в обычном кубере. К примеру чтобы открыть сервис в интернеты в microk8s нужно вызвать команду microk8s enable dns + поставить у сервиса NodePort, а не LoadBalancer, как было бы в случае кубера, который развернут в облаке.
 
🟢И по некоторым моментам не хватает документации. Как раз в примере с графаной. Куча туториалов не говорят, что тебе нужно указать в лейблах

heritage:Helm
release:kube-prom-stack

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

Курьер на карте – фича года для клиентов.

Расскажу вам байку. В 2019 году Додо Пиццу наградили на какой-то международной выставке, как один из самых прогрессивных проектов про еду, в которых есть айтишка.

☹️ Суть в чем, мы этот приз получили, немного порадовались, но потом наш CEO написал, что мы молодцы, НО… На данный момент у нас айтишка не удовлетворяет спросу бизнеса (медленно пилим фичи). Поэтому награду мы пока покроем оранжевой тряпочкой и снимем её под фанфары, когда все будут удовлетворены.

Я тогда просто непередаваемо расстроился: Ну какого хуя?! Мы же все делаем заебок. Да даже лучше чем заебок порой!

Ну и не я один расстроился, у нас даже спустя года полтора после этого случая в официальные цели компании на год включили "Сделать так чтобы было не стыдно снять тряпочку с награды”
 
В общем сняли мы в итоге тряпочку? Понятно, что не сняли. Я думаю, что сейчас эта штука где-то стоит и большинство уже и не сечет, что это за пыльная оранжевая херота? А это – незакрытый гештальт целого отдела!

😎️️️️️️ Короче, Серега Орлов в комментах к моему посту про курьера на карте резонно заметил, что я как-то слишком жестко критикую нашу работу, и что есть много положительных сторон, которые я не подсвечиваю.

🏆 Я критику понял и принял, и согласился. И тут нашу команду RocketScience 🚀 наградили вот такой пиздатой статуэткой, да еще и со светодиодной подсветкой! Это не какой-нибудь ебаный кусок железа с позолотой в форме мужика, а нормальная такая штука. 🥇
 
В общем, решил ошибок не повторять – новые гештальты не открывать, а сразу признать, что хорошо поработали, а все ошибки понемногу устраним. Через год уже и не вспомним, что там какие-то шероховатости были.

P.S.: Вот, Серега! Я написал про награду! Ты думал, что я не смогу, после того, как я поговнился на нашу фичу? А я смог!

🚂 Поезда закаляют.

Охуенная тема – прогать в поезде.

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

Короче идея такая. Я нахожу такие задачки по своему пет-проекту, которые можно делать чисто через тесты. Ну то есть там только бизнес-логику реализвать. Пасу их до поездки (ну типа не делаю сразу). И, когда еду, то это становится почти как кроссворды разгадывать – че-то пописал, оно позеленело -> profit.

Есть пара моментов, когда без интернета тяжело:

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

Но в целом, получается это в каком-то смысле прокачивает умение писать тесты. Ну и плюс, это чуть чуть прокачивает TDD в теории.

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

Не надо, прошу, я люблю тесты писать! (хруст костей)

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

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

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

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

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

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. Как я понимаю сейчас для этой штуки делаются наиболее широкие инструменты для автодокументации. И вообще создаются дизайн-гайдлайны по проганью АПИшек. Нет смылса тащить туда контроллеры ни в каком виде.
 
Мне такое объяснение показалось наиболее осмысленным. Но я тут готов если что к дополнительным пояснениям.