🍚 Как сделать так чтобы RICE заработал?
Я тут прохожу курс для product ownerов https://productmindset.net, и там у них есть таблица скиллов по грейдам, где один из инструментов приоритезации, которым должен уметь пользоваться крутой PO – RICE.
Это такая скоринговая модель, где вы оцениваете то насколько много пользователей заденет ваша фича, насколько вы уверены что сделаете ее, насколько она приблизит вас к желаемым метрикам, ну и то насколько вы вообще сами считаете эту штуку важной (ага магический коэффициент, который позволяет подгонять итоговое значение).
Мы как-то пользовались этой штукой, чтобы приоритезировать техдолг. И она работала, ну как сказать... Честно говоря не то чтобы плохо, но просто в какой-то момент уже заебало ее считать, а потом один хер задачи не делать.
И я долго рефлексировал, что же с этим всем не так?
🅰️ Так вот, как мне кажется все дело в том, что эта штука супер-херово работает в отсутствие стратегии. То есть если вы насквозь оцените свой бэклог, то получится, что задачи из разных контекстов, бьющие в разные метрики, начнут смешиваться друг с другом. То есть делали вы что-то в бэкофисе, потом по приоритету вам попалась задача из клиентского приложения, потом снова бэкофис и так далее. И вот это переключение контекстов будет сжирать по итогу продуктивность. Однако!
🅰️Если оценивать задачи по RICE внутри одного контекста, то получится гораздо лучше!
P.S. Мне вообще в последнее время кажется, что внятная стратегия для команды разработки это что-то вроде коллективного здравого смысла. Если она есть, то вам скорее всего не понадобится никакой RICE. Ну и наоборот, если вы не можете сформулировать стратегию, то никакой ветер не будет вам попутным.
Я тут прохожу курс для product ownerов https://productmindset.net, и там у них есть таблица скиллов по грейдам, где один из инструментов приоритезации, которым должен уметь пользоваться крутой PO – RICE.
Это такая скоринговая модель, где вы оцениваете то насколько много пользователей заденет ваша фича, насколько вы уверены что сделаете ее, насколько она приблизит вас к желаемым метрикам, ну и то насколько вы вообще сами считаете эту штуку важной (ага магический коэффициент, который позволяет подгонять итоговое значение).
Мы как-то пользовались этой штукой, чтобы приоритезировать техдолг. И она работала, ну как сказать... Честно говоря не то чтобы плохо, но просто в какой-то момент уже заебало ее считать, а потом один хер задачи не делать.
И я долго рефлексировал, что же с этим всем не так?
🅰️ Так вот, как мне кажется все дело в том, что эта штука супер-херово работает в отсутствие стратегии. То есть если вы насквозь оцените свой бэклог, то получится, что задачи из разных контекстов, бьющие в разные метрики, начнут смешиваться друг с другом. То есть делали вы что-то в бэкофисе, потом по приоритету вам попалась задача из клиентского приложения, потом снова бэкофис и так далее. И вот это переключение контекстов будет сжирать по итогу продуктивность. Однако!
🅰️Если оценивать задачи по RICE внутри одного контекста, то получится гораздо лучше!
P.S. Мне вообще в последнее время кажется, что внятная стратегия для команды разработки это что-то вроде коллективного здравого смысла. Если она есть, то вам скорее всего не понадобится никакой RICE. Ну и наоборот, если вы не можете сформулировать стратегию, то никакой ветер не будет вам попутным.
productmindset.net
Product Mindset - Помогаем людям и компаниям развиваться
🔥4
💣 Задача 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);
}
private IAsyncPolicy GetPolicy() {
}
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.
#ресайленс
Если вы считаете, что не стоит закладывать бомбы замедленного действия в основы вашей системы, то я сейчас вам покажу откуда такая бомба может на вас готовиться.
Вот этот ретрай не заработает. Вопрос: как думаете, почему?
[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 выдаст ошибку:
Чтобы это исправить, вам нужно внести переменную msg внутрь GetForecasts.
🅰️В общем, передавая параметры в лямбду при ретраях, смотрите внимательно, а не нужно ли их создавать заново при каждом запросе. Так-то! Ну признавайтесь, ведь не думали об этом!
#ресайленс
При ретрае HttpRequestMessage выдаст ошибку:
InvalidOperationException(SR.net_http_client_request_already_sent)Чтобы это исправить, вам нужно внести переменную msg внутрь GetForecasts.
🅰️В общем, передавая параметры в лямбду при ретраях, смотрите внимательно, а не нужно ли их создавать заново при каждом запросе. Так-то! Ну признавайтесь, ведь не думали об этом!
#ресайленс
🈴 Разбор проекта с явной (Explicit) архитектурой
Поскольку я херовасто понимаю теоретические излияния, то всегда стараюсь совместить их с практикой.
Сделал небольшой визуальный разбор статьи
DDD, Hexagonal, Onion, Clean, CQRS, … How I put it all together
На примере репозитория
Если вы, как и я запутались в ПОРТАХ и АДАПТЕРАХ и не поняли, что это такое, то этот разбор поможет вам осознать все это.
Все для вас, дорогие радиослушатели! 📻
UPD: Fuck там на певром слайде опечатка – не АДАПТЕРЫ, а ПОРТЫ.
[Вот ссылочка на miro]
Поскольку я херовасто понимаю теоретические излияния, то всегда стараюсь совместить их с практикой.
Сделал небольшой визуальный разбор статьи
DDD, Hexagonal, Onion, Clean, CQRS, … How I put it all together
На примере репозитория
Если вы, как и я запутались в ПОРТАХ и АДАПТЕРАХ и не поняли, что это такое, то этот разбор поможет вам осознать все это.
Все для вас, дорогие радиослушатели! 📻
UPD: Fuck там на певром слайде опечатка – не АДАПТЕРЫ, а ПОРТЫ.
[Вот ссылочка на miro]
👍1
🥅 Service Mesh
Уже в 10-ый раз я пытался разобраться с тем, что такое Service Mesh и с чем его едят. Ндавно вот была очередная 11-ая попытка. Закреплю здесь все, что понял, чтобы облегчить себе следующую попытку.
🧑🏭 Service Mesh – это когда ваш сервис перестает сам делать запросы к другим сервисам. Вместо этого мы ставим рядом с нашим сервисом сайдкар (просто еще один сервис) и делаем запросы к нему. Этот сайдкар понимает, к какому сервису мы хотим обратиться и идет к этому сервису к сайдкару этого сервиса! Вот так вот. Пояснительный дикпик выше. Подробное описание ниже:
[Подробное описание]
❓А что это дает?
С точки зрения производственной практики в целом ничего. Но с точки зрения отладки – это мастхэв. Сайдкары инкапсулируют в себе всю логику по взаимодействию между сервисами – ретраи, трейсинг, логирование времени запроса и прочее.
Есть определенные инструменты, которые могут анализировать взаимодействие сайдкаров между собой и предлагать вам оптимизации, если ваши коммуникации перегружены.
🅰️Когда надо брать?
Когда вы чувствуете, что погрязли в рутине настройки межсервисных коммуникаций и почти перестали писать бизнес-логику.
#servicemesh
Уже в 10-ый раз я пытался разобраться с тем, что такое Service Mesh и с чем его едят. Ндавно вот была очередная 11-ая попытка. Закреплю здесь все, что понял, чтобы облегчить себе следующую попытку.
🧑🏭 Service Mesh – это когда ваш сервис перестает сам делать запросы к другим сервисам. Вместо этого мы ставим рядом с нашим сервисом сайдкар (просто еще один сервис) и делаем запросы к нему. Этот сайдкар понимает, к какому сервису мы хотим обратиться и идет к этому сервису к сайдкару этого сервиса! Вот так вот. Пояснительный дикпик выше. Подробное описание ниже:
[Подробное описание]
❓А что это дает?
С точки зрения производственной практики в целом ничего. Но с точки зрения отладки – это мастхэв. Сайдкары инкапсулируют в себе всю логику по взаимодействию между сервисами – ретраи, трейсинг, логирование времени запроса и прочее.
Есть определенные инструменты, которые могут анализировать взаимодействие сайдкаров между собой и предлагать вам оптимизации, если ваши коммуникации перегружены.
🅰️Когда надо брать?
Когда вы чувствуете, что погрязли в рутине настройки межсервисных коммуникаций и почти перестали писать бизнес-логику.
#servicemesh
Redhat
What is a service mesh?
Read this article to find out more about what a service mesh is, how it works, and the benefits and challenges of implementing a service mesh.
👍2
❓Как запустить продуктовую команду, если у вас нет продукта?
Продолжаю проходить курс на ProductMindset и сегодня смотрел тему по скарму. Я уже давно вроде как знаю этот фреймворк, но только сейчас заметил некоторый его фундаментальный недостаток – скрам позволяет работать только если у вас уже есть продукт и его метрики. Но что делать если продукта еще нет?
🦤 У нас в Додо, как мне кажется, как раз такая ситуация с продуктами для управления процессами на кухне.
Есть какой-то разрозненный набор сервисов, но на какую единую задачу они работают, толком сказать никто не может. Какие метрики у этого набора продуктов? Или хотя бы у каждого из продуктов?
Ⓜ️Мысль, как исправить это: Перед запуском скрам команды в таком случае необходимо провести разработку/разведку продукта. То есть взять несколько спринтов, за которые продуктовая команда для начала выяснить:
1️⃣ Какие основные метрики они собираются улучшать
2️⃣ Как улучшение этих метрик связано с целями компании
3️⃣ Какие изменения за один квартал можно успеть сделать чтобы улучшить эти метрики.
❗️Тут мне кажется важно, что первый бэклог, который будет сформирован не должен быть годовым. Потому что, руководствуясь одним из принципов скрама – работа короткими итерациями, – в течение первого пробного спринта могут вылезти какие-то другие метрики, а какие-то стать ненужными и это нормально.
#процессы
Продолжаю проходить курс на ProductMindset и сегодня смотрел тему по скарму. Я уже давно вроде как знаю этот фреймворк, но только сейчас заметил некоторый его фундаментальный недостаток – скрам позволяет работать только если у вас уже есть продукт и его метрики. Но что делать если продукта еще нет?
🦤 У нас в Додо, как мне кажется, как раз такая ситуация с продуктами для управления процессами на кухне.
Есть какой-то разрозненный набор сервисов, но на какую единую задачу они работают, толком сказать никто не может. Какие метрики у этого набора продуктов? Или хотя бы у каждого из продуктов?
Ⓜ️Мысль, как исправить это: Перед запуском скрам команды в таком случае необходимо провести разработку/разведку продукта. То есть взять несколько спринтов, за которые продуктовая команда для начала выяснить:
1️⃣ Какие основные метрики они собираются улучшать
2️⃣ Как улучшение этих метрик связано с целями компании
3️⃣ Какие изменения за один квартал можно успеть сделать чтобы улучшить эти метрики.
❗️Тут мне кажется важно, что первый бэклог, который будет сформирован не должен быть годовым. Потому что, руководствуясь одним из принципов скрама – работа короткими итерациями, – в течение первого пробного спринта могут вылезти какие-то другие метрики, а какие-то стать ненужными и это нормально.
#процессы
👍1🤔1
Как IDE влияет на архитектуру вашего решения.
Я тут наткнулся на статью в соседнем C# канале: Ваш Язык Влияет на то, Как Вы Думаете. https://news.1rj.ru/str/NetDeveloperDiary/1630
Там рассказывается о том, что DI контейнеры в Java считаются плохой практикой, а в .NET наоборот считаются хорошей. И все не из-за того, что сама концепция DI плохая, а из-за особенностей языка.
Как-то давно я думал о чем-то подобном, что вообще не только сам язык определяет то как вы думаете, но еще и менее очевидная мысль – IDE которой вы пользуетесь тоже определяет ваш образ мыслей.
Как-то мне пришлось писать на Go. (Абсолютно богомерзкий язык на тот момент !) Под рукой не было GoLand от JetBrains, и я воспользовался Visual Studio Code. В расширении для Go был баг, из-за которого автокомплит не работал.
И тут я понял, что классическая структура с папочками и разными файлами, тут настолько неудобна, что пришлось от нее отказаться. Потому что вспоминать название какого-то метода и класса гораздо проще, когда все файлы свалены в одну папку.
То есть один только автокомплит позволяет вам в принципе думать о том, чтобы раскидать файлы по папочкам!
🅰️ Какой практический вывод можно сделать? Да самый прямой! Если у вас в разных командах в почЁте разные IDE, то и архитектура проектов этих команд может различаться чуть сильнее чем вам хотелось бы. Чтобы избежать таких изменений продумывйте ограничения (главное не запрещайте IDE – это тупизм) которые помогу избежать слишком больших различий. StyleCop и все вот это вам в помощь.
Я тут наткнулся на статью в соседнем C# канале: Ваш Язык Влияет на то, Как Вы Думаете. https://news.1rj.ru/str/NetDeveloperDiary/1630
Там рассказывается о том, что DI контейнеры в Java считаются плохой практикой, а в .NET наоборот считаются хорошей. И все не из-за того, что сама концепция DI плохая, а из-за особенностей языка.
Как-то давно я думал о чем-то подобном, что вообще не только сам язык определяет то как вы думаете, но еще и менее очевидная мысль – IDE которой вы пользуетесь тоже определяет ваш образ мыслей.
Как-то мне пришлось писать на Go. (
И тут я понял, что классическая структура с папочками и разными файлами, тут настолько неудобна, что пришлось от нее отказаться. Потому что вспоминать название какого-то метода и класса гораздо проще, когда все файлы свалены в одну папку.
То есть один только автокомплит позволяет вам в принципе думать о том, чтобы раскидать файлы по папочкам!
🅰️ Какой практический вывод можно сделать? Да самый прямой! Если у вас в разных командах в почЁте разные IDE, то и архитектура проектов этих команд может различаться чуть сильнее чем вам хотелось бы. Чтобы избежать таких изменений продумывйте ограничения (главное не запрещайте IDE – это тупизм) которые помогу избежать слишком больших различий. StyleCop и все вот это вам в помощь.
Telegram
.NET Разработчик
День 1313. #TypesAndLanguages
Ваш Язык Влияет на то, Как Вы Думаете. Начало
Кажется очевидным, не так ли? Ваш язык диктует правила, и вам нужно играть по правилам. Однако последствия гораздо серьёзнее, чем вы думаете. Дело не только в том, что мы выбираем…
Ваш Язык Влияет на то, Как Вы Думаете. Начало
Кажется очевидным, не так ли? Ваш язык диктует правила, и вам нужно играть по правилам. Однако последствия гораздо серьёзнее, чем вы думаете. Дело не только в том, что мы выбираем…
🔥1
🦾Внедрение IoT решений
Третьего дня ребята из одной из крутейших наших команд показывали результат своих экспериментов с умными весами. Ну как умными. Весы умеют отдавать свои показатели через http.И что, они теперь умные? Я вот свои показатели по http отдать не могу. Получается тупой – не преодолел технологическую сингулярность.
🤖Так вот, для меня в их рассказе стало самым интересным, что для производственного IoT решения как ни крути нужен локальный хаб, который может быстро обмениваться данными с устройствами на местах. Иначе раундтрип по сети до сервера убьёт напрочь всю отзывчивость интерфейса.
🪵И для меня сразу открылась веточка развития под названием "Архитектура IoT". А именно ответ на вопрос, а как вообще люди приходят к внедрению этого дела у себя в бизнесе.
В голове сложились такие этапы:
1️⃣ Любительский эксперимент, который упрощает локальную рутину.
2️⃣ Несколько разрозненных любительских экспериментов, без упорядочивания и стандартизации
3️⃣ Упорядочивание и стандартизация платформы - подключение новых решений по стандарту.
⚠️Вот мне кажется, что между 2️⃣ и 3️⃣ этапами очень легко упустить момент, и подойти к третьему этапу с таким зоопарком технологий и физических устройств, что стандартизировать это будет уже очень больно.
❓Как не упустить этот этап? Вопрос хороший, и, кажется, скоро мы увидим на него ответ. Я пока пойду искать опыт внедрения в интернете.
🅰️Кстати, если видели какие-то материалы по этой теме, накидайте в комментарии. Интересно будет почитать.
#IoT #architecture
Третьего дня ребята из одной из крутейших наших команд показывали результат своих экспериментов с умными весами. Ну как умными. Весы умеют отдавать свои показатели через http.
🤖Так вот, для меня в их рассказе стало самым интересным, что для производственного IoT решения как ни крути нужен локальный хаб, который может быстро обмениваться данными с устройствами на местах. Иначе раундтрип по сети до сервера убьёт напрочь всю отзывчивость интерфейса.
🪵И для меня сразу открылась веточка развития под названием "Архитектура IoT". А именно ответ на вопрос, а как вообще люди приходят к внедрению этого дела у себя в бизнесе.
В голове сложились такие этапы:
1️⃣ Любительский эксперимент, который упрощает локальную рутину.
2️⃣ Несколько разрозненных любительских экспериментов, без упорядочивания и стандартизации
3️⃣ Упорядочивание и стандартизация платформы - подключение новых решений по стандарту.
⚠️Вот мне кажется, что между 2️⃣ и 3️⃣ этапами очень легко упустить момент, и подойти к третьему этапу с таким зоопарком технологий и физических устройств, что стандартизировать это будет уже очень больно.
❓Как не упустить этот этап? Вопрос хороший, и, кажется, скоро мы увидим на него ответ. Я пока пойду искать опыт внедрения в интернете.
🅰️Кстати, если видели какие-то материалы по этой теме, накидайте в комментарии. Интересно будет почитать.
#IoT #architecture
🔥3
Разговаривают как-то два программиста – опытный и новичок. Опытный говорит:
— Знаешь, какая разница между продакт оунером и скрам мастером?
Молодой мотает головой, мол не знает. Опытный продолжает:
— Когда продакт оунер видит программиста, он кричит: "Ой, бля!". А когда скрам-мастер видит программиста, он говорит: "Оп-па!", а программист говорит: "Ой, бля!".
#компильдот
Please open Telegram to view this post
VIEW IN TELEGRAM
😁3
Компильдот от...
⚙️ Короче, у нас в компании один замечательный(да что уж там говорить – охуенный!) инженер @pastushenkoy ввёл лучшую в мире инженерную практику – анекдоты категории Б по вторникам.
👆 Чуть выше, вы видели продолжение этой практики от меня – компилированный анекдот, или компильдот. Компильдоты будут появляться здесь по вторникам (а может по пятницам, я пока не знаю, кажется, что в пятницу будет пизже ).
🔞Также я официально начинаю прием заявок на публикацию компильдотов! Важное условие – они должны быть про айтишную жизнь. Других ограничений нет. Они могут быть абстрактными, пошлыми и кринжовыми, главное чтоб про что-то айтишное.
#компильдот
⚙️ Короче, у нас в компании один замечательный
🔞Также я официально начинаю прием заявок на публикацию компильдотов! Важное условие – они должны быть про айтишную жизнь. Других ограничений нет. Они могут быть абстрактными, пошлыми и кринжовыми, главное чтоб про что-то айтишное.
#компильдот
Please open Telegram to view this post
VIEW IN TELEGRAM
🍾3🐳1
This media is not supported in your browser
VIEW IN TELEGRAM
♨️ Новый, жаркий, кодогенерированный!
Вчера, пока все ждали обращения Волан-де-Морта, я нахуячил себе новенький логотип для канала. Да не простой, а анимированный!😵💫
Когда-то, не так давно, я преподавал детям курсы по разработке игр (да-да, вот что я делал эти 8 лет ). И в эти игры входили всякого рода анимации. Анимации в Adobe Flash (да преупокоится он с миром), ключевые анимации в 3D Max и еще много-много где. И вот что я вам скажу – ненавижу анимировать что-то руками. Это я очень МЯГКО постарался сформулировать.
🅰️ В этот раз я нашел Python 🐍 библиотеку, которой пользуется один крутой математический блоГГер 3Blue1Brown. Называется она manim. Пара часов с матами и кряхтеним, но все заработало!
🐻❄️Теперь у меня крутой анимированный по-программистски логотип. И даже исходнички имеются!
P.S.: Да, я знаю, что нам всем в эти тревожные времена не до логотипов. Но так вам скажу. Не хочу позволять этим людям контролировать мои нервы. В общем, берите manim, и берите власть над собой в свои руки!
Вчера, пока все ждали обращения Волан-де-Морта, я нахуячил себе новенький логотип для канала. Да не простой, а анимированный!
Когда-то, не так давно, я преподавал детям курсы по разработке игр (
🅰️ В этот раз я нашел Python 🐍 библиотеку, которой пользуется один крутой математический блоГГер 3Blue1Brown. Называется она manim. Пара часов с матами и кряхтеним, но все заработало!
🐻❄️Теперь у меня крутой анимированный по-программистски логотип. И даже исходнички имеются!
P.S.: Да, я знаю, что нам всем в эти тревожные времена не до логотипов. Но так вам скажу. Не хочу позволять этим людям контролировать мои нервы. В общем, берите manim, и берите власть над собой в свои руки!
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6
Про зоны ответственности.
Напишу тут этот пост, и чтобы запомнить эти злоебучие времена, и чтобы запомнить, какие выводы я из них сделал.
Я смотался в Грузию месяцем раньше чем начался Пиздец.
Как и все из моего окружения, кто успел уехать, я стал помогать тем, кто выбирается с нашей Родины, чтобы не сгинуть в этой ебучей войне. Найти билеты, просто помочь добрым словом.
Тут важная, не отоносящаяся к основной линии ремарка про отношение к русским в Грузии:
Люди порой боятся, что к русским теперь плохо относятся в Грузии, а это вот ни разу не так. Вчера говорил с хозяйкой съемной квартиры, вот ее слова: "Слава Богу, что вы успели уехать. Это такой кошмар!" Не бойтесь – в Грузии живут прекрасные люди!
Но это ладно. Самое главное, что я вынес для себя из этого опыта – человек сам выбирает, как и куда ему ехать. Моя задача только помочь ему купить билеты на этот путь. Какой бы дебильный путь ни был выбран.
Есть один друг, который купил билет в Тегеран (да, в это время все еще есть люди, которые не читают новости). Вот 100 раз хотелось его отговорить, с учетом всего. Но человек выбрал путь – я могу лишь сделать его чуть более гладким – что-то оплатить с иностранной карты, где-то подбодрить и сказать, что все получится. А иногда достаточно просто быть на связи, чтобы человек мог тебе проговорить свои мысли и немного осмотреться. (Блять, ну и разумеется, я просто для галочки проинформировал, что там так-то тоже пиздос! )
В общем, сегодня мы многое поняли: если человек сделал выбор, за который несет ответственность только он, это его дело. Значит психологически он готов именно к такому пути, а в таких ситуациях психология важнее всего.
Ну и, да, если кому-то нужна помощь в Батуми, то я здесь и готов встречать в аэропорту, давать насколько могу ночлег, показывать, что тут и как с деньгами и вообще осваиваться. Такие дела. Если нужно кого-то встретить, пишите!
UPD: С другом, который летел через Тегеран все в порядке - долетел до Дубая. Вот уж воистину. А еще друг из Минска прилетел в Тбилиси вчера. Так что зря даже Максим Кац нагнетал по этому поводу.
Напишу тут этот пост, и чтобы запомнить эти злоебучие времена, и чтобы запомнить, какие выводы я из них сделал.
Я смотался в Грузию месяцем раньше чем начался Пиздец.
Как и все из моего окружения, кто успел уехать, я стал помогать тем, кто выбирается с нашей Родины, чтобы не сгинуть в этой ебучей войне. Найти билеты, просто помочь добрым словом.
Тут важная, не отоносящаяся к основной линии ремарка про отношение к русским в Грузии:
Люди порой боятся, что к русским теперь плохо относятся в Грузии, а это вот ни разу не так. Вчера говорил с хозяйкой съемной квартиры, вот ее слова: "Слава Богу, что вы успели уехать. Это такой кошмар!" Не бойтесь – в Грузии живут прекрасные люди!
Но это ладно. Самое главное, что я вынес для себя из этого опыта – человек сам выбирает, как и куда ему ехать. Моя задача только помочь ему купить билеты на этот путь. Какой бы дебильный путь ни был выбран.
Есть один друг, который купил билет в Тегеран (да, в это время все еще есть люди, которые не читают новости). Вот 100 раз хотелось его отговорить, с учетом всего. Но человек выбрал путь – я могу лишь сделать его чуть более гладким – что-то оплатить с иностранной карты, где-то подбодрить и сказать, что все получится. А иногда достаточно просто быть на связи, чтобы человек мог тебе проговорить свои мысли и немного осмотреться. (
В общем, сегодня мы многое поняли: если человек сделал выбор, за который несет ответственность только он, это его дело. Значит психологически он готов именно к такому пути, а в таких ситуациях психология важнее всего.
Ну и, да, если кому-то нужна помощь в Батуми, то я здесь и готов встречать в аэропорту, давать насколько могу ночлег, показывать, что тут и как с деньгами и вообще осваиваться. Такие дела. Если нужно кого-то встретить, пишите!
UPD: С другом, который летел через Тегеран все в порядке - долетел до Дубая. Вот уж воистину. А еще друг из Минска прилетел в Тбилиси вчера. Так что зря даже Максим Кац нагнетал по этому поводу.
❤2
📆Недавно с нами случился абсолютный краш. Один из подконтрольных нашей команде сервисов вдруг начал сыпать ошибками. Сообщения в них говорили, что сервис не может достучаться по сети до базы, до редиса, до соседних сервисов. И вообще ему плохо и у него лапки 🐾.
🌚Вот вчерась оно снова повторилось. Но, к счастью, на этот раз мы уже предварительно смотрели в код и примерно понимали, где там могут быть проблемы. А проблемы, они в CancellationToken.
То есть кто-то приходит и кидает нам большой запрос к базе. Затем по таймауту в две минуты соединение отстреливается. В базе запрос не отменяется. Минус один коннект у коннекшн пула. Затем ситуация повторяется до победного – пока весь пул на поде не забьется. Вот так вот просто.
В итоге все это добро пожирало сначала коннекшн пул, а потом еще и потоки и CPU. Из-за чего и ответы от других сервисов не успевали обработаться, что и приводило к картине, будто вся сеть отключилась.
🅰️Мой вывод из этой ситуации. Если в асинхронный метод не проброшен CancellationToken, то нужно чтобы приложение просто не собиралось нахер.
А я пошел пробрасывать оные. Там дохера где надо. :
UPD: А может и не только в токенах дело. Возможно старая бага Entity вылезла ¯\_(ツ)_/¯
UPD2: Тут на самом деле недавно у нас был пиздец какой краш. Сначала в стране, а потом и вдобавок система наебнулась на 4 часа. Но по этому крашу мне пока рассказать нечего.
А еще хочу добавить: Спасибо Грузии за то что помогает нам всем бежать от кровавого мудака и его войны! Сердечное спасибо 🧡
Сакартвелос гаумарджос! 🇬🇪 (Да здравствует Грузия!)
#трудовыебудни #опыт
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥1
🍆Новый взгляд на ретраи, или как откосить от армии. Задача.
Короче, если вы следили за новостями, то наверное заметили, что в последние пару дней распространилась новость о том, что с ВИЧ в армию не берут. Замечательный @pastushenkoy прислал в связи с этим тематическую задачку на ретраи!
Итак! Дано:
Два факта
а) с ВИЧ дают категорию D и не берут в армию вообще
б) если ты занимаешься анальным сексом с вич-инфицированным, он передается тебе с вероятностью 8%
Решаем простую задачку с собеседования и подбираем n так, чтобы 0.92^n было как можно ближе к нулю
Решение:В принципе, сотни анальных половых актов с вич-инфицированными будет достаточно, чтобы не попасть под мобилизацию! Ooooo you not in army now! 👋
#юмор
Блин, я еще сейчас вот о чем подумал, это получается анекдот категории Д?
Короче, если вы следили за новостями, то наверное заметили, что в последние пару дней распространилась новость о том, что с ВИЧ в армию не берут. Замечательный @pastushenkoy прислал в связи с этим тематическую задачку на ретраи!
Итак! Дано:
Два факта
а) с ВИЧ дают категорию D и не берут в армию вообще
б) если ты занимаешься анальным сексом с вич-инфицированным, он передается тебе с вероятностью 8%
Решаем простую задачку с собеседования и подбираем n так, чтобы 0.92^n было как можно ближе к нулю
Решение:
#юмор
Блин, я еще сейчас вот о чем подумал, это получается анекдот категории Д?
Please open Telegram to view this post
VIEW IN TELEGRAM
🌭1
Не используйте Guard Clauses💂♀️
📺 Недавно посмотрел видос на канале Code Opinion про то что Guard Clauses это не очень круто. Тут я конечно озадачился(охуел) потому что я и не знал про такую штуку, а она оказывается уже говно! Поразительная результативность.
Выглядит она вот так:
Ну и защищает понятно от чего – от вселенской пустоты текстовых полей. Похожа на Assert. Да и по факту это ассерт, что уж тут. Пихаете его в первых строках контроллера вместо ифчика для проверки ввода.
🅰️ Так вот автор предлагает так не делать. А предлагает более изящную конструкцию – создавать отдельный тип под каждое такое поле. То есть просто создаем класс Username со всеми проверками в конструкторе и пользуемся им. Если что-то не пошло, то система просто не сможет создать класс и выкинет ошибку – просто, понятно и сильнее типизированно.
✅Такой подход я уже видел в использовании. И он мне дико нравится, но я не до такой степени задрот – мне лень такие классы генерить.
Но если бы кто-то замутил кату, оттачивающую создание таких классов, было бы прям неплохо.
#libraries
📺 Недавно посмотрел видос на канале Code Opinion про то что Guard Clauses это не очень круто. Тут я конечно озадачился
Выглядит она вот так:
Guard.Against.NullOrEmpty(userName, nameof(userName))Ну и защищает понятно от чего – от вселенской пустоты текстовых полей. Похожа на Assert. Да и по факту это ассерт, что уж тут. Пихаете его в первых строках контроллера вместо ифчика для проверки ввода.
🅰️ Так вот автор предлагает так не делать. А предлагает более изящную конструкцию – создавать отдельный тип под каждое такое поле. То есть просто создаем класс Username со всеми проверками в конструкторе и пользуемся им. Если что-то не пошло, то система просто не сможет создать класс и выкинет ошибку – просто, понятно и сильнее типизированно.
✅Такой подход я уже видел в использовании. И он мне дико нравится, но я не до такой степени задрот – мне лень такие классы генерить.
Но если бы кто-то замутил кату, оттачивающую создание таких классов, было бы прям неплохо.
#libraries
YouTube
Stop using trivial Guard Clauses! Try this instead.
Guard clauses, on the surface, sound like a great idea. They can reduce conditional complexity by exiting a method or function early. However, I find how guard clauses are used in the real world to be of little value. Often polluting application-level code…
🤔2
Парное программирование – моя любимая практика, которую я не могу использовать.
👬Обожаю парное программирование (в узких кругах – гачимучи программирование), как концепцию. Вместо код-ревью пулл-реквестов на стопицоттыщ строк ты смотришь, как решение рождается прямо у тебя на глазах, а потом и сам пишешь что-то.
✅ Снижается бас-фактор, улучшается взаимопонимание, увеличивается покрытие тестами и все такое. Но для меня это все так и осталось на бумаге. Сколько бы я ни пытался следовать этой практике.
🛑Удивительно, но в конечном итоге останавливающими факторами в этой практике для меня стала физиология.
🍕В Додо все ходят есть в 12:00. Не знаю почему, но вот люди так делают. ¯\_(ツ)_/¯
Я в это время есть еще не хочу. Но в 13:30 мне обычно уже хочется ЖРАТЬ. А у моего напарника все с точностью до наоборот. Уже в 11:50 он смотрит на экран голодными глазами, а в 13:30 у него пик продуктивности. И это никак не перебить дисциплиной там или таймерами – желудку не прикажешь.
Есть еще пара причин, но они скорее исправимые.
🪘Иногда просто хочется посидеть одному. Адепты парного программирования говорят, что вот в этот-то момент и происходит прокрастинация – то с чем призвана бороться сия экстремальная практика! И, да, когда я пишу код один, я прокрастинирую постоянно. Честно говоря, я не знаю, как в итоге у меня получается делать задачи, ведь оглядываясь назад, я понимаю, что весь день нихера не делал.
🧑💻 Ну и финальное – я просто не умею в TDD. Уже сто раз пытался, но задачи, которые можно сделать по TDD попадаются настолько редко, что йобнешься.
Чаще всего задача, которая приходит, она вообще не про код. Она про то, чтобы понять, как работает какое-то легаси, где оно лежит, и к кому сходить, чтобы пролили свет на все это. И как ты напишешь на это тесты?
Тут скрыт сугубо личный опыт, плохо сформулированный, с матами и непотребствами, читать осторожно:
🤬 В довесок ко всему, 20% каждой задачи – это вообще инфраструктурная срань какая-нибудь. То конфиги поправить, то сертификат настроить, то строку подключения к базе найти, то телепрезенс какой-то поставить, то линтер настроить на своем компе . Потому что в чужом проекте он сортирует импорты по алфавиту и у тебя все ломается (нахуя он их так сортирует? Ну потому что так красивее. – Заебись красота! )
(А еще линтер меняет табы на пробелы и наоброт – это просто пизда ! Пускай гит перестанет подсвечивать уже эти изменения, чтобы не будоражить компульсии у людей )
🅰️ Короче, не зашло, но не потому что сама концепция плохая, думаю, что у нее есть ограничения.
🏄 #extremeprogramming
👬Обожаю парное программирование (в узких кругах – гачимучи программирование), как концепцию. Вместо код-ревью пулл-реквестов на стопицоттыщ строк ты смотришь, как решение рождается прямо у тебя на глазах, а потом и сам пишешь что-то.
✅ Снижается бас-фактор, улучшается взаимопонимание, увеличивается покрытие тестами и все такое. Но для меня это все так и осталось на бумаге. Сколько бы я ни пытался следовать этой практике.
🛑Удивительно, но в конечном итоге останавливающими факторами в этой практике для меня стала физиология.
🍕В Додо все ходят есть в 12:00. Не знаю почему, но вот люди так делают. ¯\_(ツ)_/¯
Я в это время есть еще не хочу. Но в 13:30 мне обычно уже хочется ЖРАТЬ. А у моего напарника все с точностью до наоборот. Уже в 11:50 он смотрит на экран голодными глазами, а в 13:30 у него пик продуктивности. И это никак не перебить дисциплиной там или таймерами – желудку не прикажешь.
Есть еще пара причин, но они скорее исправимые.
🪘Иногда просто хочется посидеть одному. Адепты парного программирования говорят, что вот в этот-то момент и происходит прокрастинация – то с чем призвана бороться сия экстремальная практика! И, да, когда я пишу код один, я прокрастинирую постоянно. Честно говоря, я не знаю, как в итоге у меня получается делать задачи, ведь оглядываясь назад, я понимаю, что весь день нихера не делал.
Чаще всего задача, которая приходит, она вообще не про код. Она про то, чтобы понять, как работает какое-то легаси, где оно лежит, и к кому сходить, чтобы пролили свет на все это. И как ты напишешь на это тесты?
Тут скрыт сугубо личный опыт, плохо сформулированный, с матами и непотребствами, читать осторожно:
(
🅰️ Короче, не зашло, но не потому что сама концепция плохая, думаю, что у нее есть ограничения.
🏄 #extremeprogramming
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1