Парное программирование – моя любимая практика, которую я не могу использовать.
👬Обожаю парное программирование (в узких кругах – гачимучи программирование), как концепцию. Вместо код-ревью пулл-реквестов на стопицоттыщ строк ты смотришь, как решение рождается прямо у тебя на глазах, а потом и сам пишешь что-то.
 
✅ Снижается бас-фактор, улучшается взаимопонимание, увеличивается покрытие тестами и все такое. Но для меня это все так и осталось на бумаге. Сколько бы я ни пытался следовать этой практике.
 
🛑Удивительно, но в конечном итоге останавливающими факторами в этой практике для меня стала физиология.

🍕В Додо все ходят есть в 12:00. Не знаю почему, но вот люди так делают. ¯\_(ツ)_/¯

Я в это время есть еще не хочу. Но в 13:30 мне обычно уже хочется ЖРАТЬ. А у моего напарника все с точностью до наоборот. Уже в 11:50 он смотрит на экран голодными глазами, а в 13:30 у него пик продуктивности. И это никак не перебить дисциплиной там или таймерами – желудку не прикажешь.

Есть еще пара причин, но они скорее исправимые.
 
🪘Иногда просто хочется посидеть одному. Адепты парного программирования говорят, что вот в этот-то момент и происходит прокрастинация – то с чем призвана бороться сия экстремальная практика! И, да, когда я пишу код один, я прокрастинирую постоянно.  Честно говоря, я не знаю, как в итоге у меня получается делать задачи, ведь оглядываясь назад, я понимаю, что весь день нихера не делал.
 
🧑‍💻Ну и финальное – я просто не умею в TDD. Уже сто раз пытался, но задачи, которые можно сделать по TDD попадаются настолько редко, что йобнешься.

Чаще всего задача, которая приходит, она вообще не про код. Она про то, чтобы понять, как работает какое-то легаси, где оно лежит, и к кому сходить, чтобы пролили свет на все это. И как ты напишешь на это тесты?
 
Тут скрыт сугубо личный опыт, плохо сформулированный, с матами и непотребствами, читать осторожно:
🤬 В довесок ко всему, 20% каждой задачи – это вообще инфраструктурная срань какая-нибудь. То конфиги поправить, то сертификат настроить, то строку подключения к базе найти, то телепрезенс какой-то поставить, то линтер настроить на своем компе. Потому что в чужом проекте он сортирует импорты по алфавиту и у тебя все ломается (нахуя он их так сортирует? Ну потому что так красивее. – Заебись красота!)

(А еще линтер меняет табы на пробелы и наоброт – это просто пизда! Пускай гит перестанет подсвечивать уже эти изменения, чтобы не будоражить компульсии у людей)

🅰️ Короче, не зашло, но не потому что сама концепция плохая, думаю, что у нее есть ограничения.
🏄 #extremeprogramming

😂 Компильдот!
Наступило время пятничного компильдота! И вот он:

– Сколько программистов нужно, чтобы поменять лампочку?
– На самом деле – 100. Один вкручивает, остальные трое проёбываются.

Понравился компильдот? – шарахни лайк!
Не понравился? – поставь ты дизлайк штоле!

#компильдот

😇 Фейкай как Bogus
Не могу не написать хвалебную штуку про Bogus Faker. Мне иногда нужно для тестов заполнять фейковыми данными поля. И, если честно, то бесит постоянно что-то придумывать. Все эти мейлы-шмейлы, айдишники-хуишники.
 
📆 Третьего дня увидал библиотеку Bogus. И понял, что это довольно прикольная пижня! Короче, она умеет за вас генерить РЕАЛИСТИЧНЫЕ фейковые данные в тестовых объектах.

🧑‍🍳Как готовить? Есть у вас какой-нибудь классический User. Ну что там у него может быть? Наверняка мыло-хуило (простите), айдишник, телефон, дата рождения и еще подобное дерьмецо. Как будет выглядеть код с Bogus для генерации фейковых данных для такого юзера. Да писос как просто! Вот, полюбуйтесь:

var user = userFaker.Generate();

Ну блин, ладно, там не все ТАК просто. Надо перед этим маленько поднастроить:

 
var userFaker = new Faker<User>()
.RuleFor(user=>user.Email, faker=>faker.Person.Email)
.RuleFor(user=>user.FullName, faker=>faker.Person.FullName)
.RuleFor(user=>user.DateOfBirth, faker=>faker.Person.DateOfBirth)

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

⚠️ У него все же есть минусы. Вы можете сломать тесты просто обновив неудачно библиотеку. Это ж опенсорс. С этой точки хрения если хотите надежности входных данных в тестах, то обступайте стороной Bogus.

Комментарий внутреннего голоса автора: бля, да все что угодно можно сломать, обновив библиотеку.

🅰️Итого: если хотите генерить реалистичные данные для тестов, но не хотите писать эти данные руками, то Bogus поможет. Не могу порекомендовать такой подход для интеграционных тестов, там желательно чтобы ХОТЯ БЫ входные данные были железно прибиты к константам. А вот в юнитовых тестах – обфейкайтесь этим богусом.
 
🏃‍♂️Короче, быстро бегите и ставьте звезду🤩 библиотеке. Там их много (звезд), но кажется, что либа заслуживает большего!

UPD: Не, все же в комментах и на небольшой практике выяснилось, что не заслуживает. Сложно потом понимать из кода, откуда вообще взялись все эти Timothy и прочие реалистичные штуки.

#testing #unittests #libraries

🤬 Не ругайте чужой код.
Сегодня в очередной раз задумался над тем, как губительно сказывается на проектах деструктивная критика чужого кода. Решил себе записать по пунктам все негативные моменты:
1️⃣ Ругая чужой код ты снимаешь с себя ответственность за его улучшение. Ты просто признаешь факт и то что ты ничего с этим сделать не можешь, вместо того чтобы поискать хоть какое-то решение
2️⃣ Ты снижаешь свою планку. Если все говнокодят, и ничего с этим не сделать, значит и тебе можно.
3️⃣ Демотивируешь окружающих. Если твой коллега слышит такую критику, то неизбежно он переложит ее на себя и в лучшем случае подумает: "Хм, надеюсь я не такой." Но в худшем случае, он подумает: "Да я такой плохой 😔 Ну и ХУЙ с ним, пойду тогда тоже писать ГОВНО!".
4️⃣Подрываешь доверие в коллективе. Раз ты сказал про кого-то плохо, то что мешает кому-то говорить так же плохо про тебя?"

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

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

🥇 Думаю, что если бы Абрахам Маслоу собирал пирамиду софтскиллов для разработчиков, то скилл "не ругай чужой код, сцуко" поставил бы на первое место.
 
P.S.: Ну и вообще, мир не обязан быть красивым – он такой, какой есть😂
#softskills

😂 Компильдот.
Пятница йоптыть! А значит подошло время для компильдота! Где? Так вот же он!

Попадают в чистилище: продакт, тестировщик и программист. Бог им и говорит:
— Кто скажет мне число, которого я не знаю, попадет в Рай.
Продакт назвал — триллион, Бог сказал:
— Знаю и отправил его в Ад.
Программист назвал какую-то огромную степень двойки, Бог сказал:
— И это знаю — и тоже отправил его в Ад.
Тестировщик подумал и говорит:
— Дохуя!
Бог удивился:
— Я не знаю такого числа! А сколько это?
Тестировщик отвечает:
— А ты спроси у стрелочника на железной дороге.
Бог свое обещание выполнил — послал тестировщика в Рай, а сам обернулся человеком и спустился на Землю. Нашел стрелочника подходит и спрашивает:
— Слушай, мужик, а сколько это — ДОХУЯ?
Стрелочник подумал и говорит:
— Видишь рельсы?
Бог:
— Вижу!
Стрелочник:
— Видишь шпалы?
Бог:
— Вижу!
Стрелочник:
— Вот иди и считай шпалы. Как будет НУ ИХ НА ХУЙ! Так это только половина!

Понравился компльдот? – Шарахни лайк!
Не понравился? – Так втрепи уже говняшку скрэппи, не будь жмотом!
#компильдот

🦮 Задача 6: Таймауты и увеличение.
📏 Затянул с последним постом про ретраи. Такие времена, сами понимаете – нужно затягивать не только пояса (фьить - ха!).

Сегодня такая задачка. В репозитории bounded-disturbances это челлендж под номером 8.
В нормальном случае запрос проходит за 30мс. В 10% случаев у вас канал выдает задержку в 2 секунды. При этом 25% запросов выполняются минимум 1 секунду. (к примеру 75% запросов к базе данных несложные и выполняются быстро, а 25% очень сложные и это не исправить)

В этой задаче, вы можете задавать таймаут для каждого ретрая отдельно, то есть указывать его в виде ряда:
 
var timeouts = new [] { 666, 666 };
 
❓ Задача подобрать ряд таймаутов с нужным количеством ретраев и с нужными значениями элементов ряда так, чтобы 99% запросов прошли успешно и 95-ый перцентиль запросов был ниже 2 секунд. И еще одно условие – 70% процентов запросов должно проходить не больше чем за 200 мс.

То есть мы хотим сделать с помощью ретраев так, чтобы те запросы, которые могут пройти быстро, прошли быстро. Но при этом та часть запросов, которая идет медленно, доходила до конца.
 
✅ Не совсем понятный ответ тут:
А тут не все так однозначно! Фактически у нас есть два вида запросов – быстрые запросы, которые периодически тупят, и медленные запросы, которые периодически еще и тупят (Вот уж дейсвтительно – Тупой и еще тупее! Пха-ха! 😅). Под каждый из запросов нам нужны свои таймауты.
 
Под быстрые запросы нам подойдет таймаут в 50 мс, так как, если быстрый запрос не успел выполниться в это время, значит он уже не долетит.
 
Под медленные запросы нам нужен таймаут в 1100 мс, так как мы помним, что медленные запросы меньше чем за 1000 мс не выполняются.
 
Если мы составим такой ряд
var timeouts = new [] { 50, 1100 };

То для быстрых запросов у нас будет две попытки. А вот для медленных запросов будет только одна. При этом 100% быстрых запросов выполнится, а вот у медленных запросов 10% просто не дойдет до успеха (по вот этой формуле посчитал 1 - 0.1^1 = 1-q^n = 0.90), что даст нам общую успешность выполнения примерно 97.5%

🅰️ Но у нас цель по успешности в 99%. Именно поэтому мы должны воткнуть еще один таймаут для тупящих запросов, получив в итоге такой ряд:

var timeouts = new [] { 50, 1100, 1100 };

И это как раз то что нужно!

P.S. Ффух, на этом все. Нихерашеньки не шорт пост получится, товарищи. Да и объяснения тут, конечно, такие, что их нужно еще отдельно разбирать. Что я и сделаю в будущей статье на Хабр. Там можно будет и формулы прописать нормально, со всеми сигмами и дать кому-нибудь на ревью все это.

🔚 Засим про ретраи почти все. Спасибо, что читали! дальше будет еще одна мысль про них и на этом считаю свой опус-магнум завершенным.
#ресайленс

❓А зачем нам вообще ретраи?
Не так давно я попытался провести воркшоп по ретраям на основе репозитория и своих теоретических изысканий. Получилось говнястенько, но получилось! 💩
 
🆙 В конце этого воркшопа мне один очень крутой коллега (а мы других не держим) задал вполне легитимный вопрос: "Зачем нам вообще все это считать? Вот у меня задача есть, я везде могу сделать 5 ретраев и экспоненциальное увеличение таймаутов. И этого вполне хватает. Если за 5 раз сервис не ответил, значит, что он конкретно недоступен и смысла ретраить больше нет."

Тут я понял, что проебал мотивационную часть и в своем воркшопе и в цикле постов. 😅 Кек)
 
И это правильный комментарий, но мы тут собрались не для того, чтобы ретраями чинить упавшие сервисы.

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

🙅 То есть, вы пульнули запрос, а он по раунд-робину попал на какой-то залупный сервер у параши. А вы вместо того, чтобы ждать, пока он очнется, берете и пуляете новый запрос, который попадает на королевский сервер. По итогу, именно это и улучшает показатели вашего конечного сервиса. (Да, вы так же делаете, когда ждете своей очереди в Overwatch 2! Вы тоже ретраите, когда перезаходите в лобби!)

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

P.S. В общем, всем спасибо, кто дочитал и полайкал эту душнятину! 🙏🙏🙏 Буду и дальше работать над такими штуками и бороться за вторые места!
#ресайленс

🤪Компильдот.
Пятница етить её налево! Самое время прочитать все посты, что вышли за эту неделю. А вот и компильдотик для привлечения внимания. Но предупрежу, он жесткий. Возможно противный. Категория В не ниже. Оправдывает плашку 🔞 в названии канала. Читать, ну очень осторожно.

Ебутся как-то в жопу два программиста. Час ебутся, второй. Вдруг один спрашивает:
– Билли, да когда ты уже закончишь?
– Думаю, что через час.
Ебля продолжается час, потом еще час, еще час. Один снова не выдерживает:
– Билли, до коле, блядь?!
Второй останавливается и говорит:
– Да я думал, что за час управлюсь. Но, знаешь, Боб, тут сраное легаси!

После такого компильдота даже как-то неловко, но поставь говняшку Скрэппи, если не понравилось! Ну и лайк, если понравилось!
#компильдот

✍️ Service Mesh и политика ресайленса.
Не отпускают меня ретраи. Извините.

🅰️Но, короче, я задумался, что вообще Service Mesh и ретраи это топ сборка!

У вас есть инфраструктура, у которой известны SLA (базы, шины и прочее). Вы можете один раз посчитать по ним, сколько ретраев нужно при обращении к ним и на всю архитектуру раскатить общие настройки через Service Mesh. И у вас все сервисы разом оптимальнее работают с базами, шинами и прочим!

Понятно, что это все чревато, что можно переборщить, но надо пробовать на практике, на то и нагрузочные тесты!

💡Это просто как идея. Не претендую на охуительность (хотя ладно претендую).
#ресайленс #servicemesh

😄 Компильдот!
Пятница, туда её в душу! Значит время компильдота у нас. Прошлый компильдот про сношение в жопу, зашел, но лишь частично. Поэтому сегодня будет лайтовенькая смешнявка!

Программист обращается к компьютерному мастеру:
- Мне нужна ваша помощь.
- Ваша профессия?
- Я программист.
- Так почему же вы сами все не сделаете?
- Я беру слишком дорого...

Понравился компильдот? Ну так давай, не робей – поставь лайк! Ну а ежели анек не зашел, ты тоже в сторонке-то не стой – говняшка Скрэппи к твоим услугам! Всё строго анонимно!
#компильдот

🙏Kafka #1: Верхнеуровненвый осмотр и сравнение с RMQ
Как я раньше и говорил, по производственной необходимости нужно изучать Кафку (с мафлом, да-да!). Пролью свет на нее в цикле постов. Цикл будет на основе видео, которое я показывал в этом посте. (Поэтому, в случае претензий, мопед не мой – я только объяву разместил.)
 
🍆 Сегодня просто посмотрим на пояснительный дикпик 👆 и разберемся, из каких основных компонентов состоит кафкианский мессаджинг.
 
Cluster – ну тут все просто – это набор кафок. То есть, если вы хотите масштабироваться горизонтально, то кластер – это то, что вы будете расширять добавляя туда побольше кафок.
Broker – это собственно инстанс кафки, который занимается полезной работой. Их может быть много, и они в себе содержат топики.
Topic – это собственно то, что хранит в себе пересылаемые данные. То есть, когда сообщение попадет к брокеру, то он положит его в нужный топик.
Producer – это тот кто пишет в топики.
Consumer Group – это группа консьюмеров которые читают из топика. Тут есть нюанс, что каждый консьюмер в группе будет читать из своей партиции, но об этом позже. И это, кстати, тоже охренеть какое отличие! (Спасибо Юре Пастушенко 🥰 за исправление. Будьте как Юра – пишите мне, если видите, что я спорол хуйню!)
 
🐇 Так как я много работал с RabbitMQ, не могу не отметить, что верхнеуровнево все выглядит один к одному! Но есть значительные различия в том, как кафка работает с топиками. Это довольно сильно отличается от кролика и вот чем:
 
1️⃣В кафкианском мире консьюмер поллит брокера, чтобы забрать данные из топика. В отличие от кролика, где брокер пушит сообщения сам. Конечно в кролике тоже можно было перевести консьюмера в режим поллинга, но это не православный подход считается.
2️⃣Сама работа топиков сильно отличается от очередей (тут важная эмоциональная ремарка: да просто охуеть как сильно отличается. Это настолько разные штуки, что я бы их даже не сравнивал!). Так как в очереди сообщение живет до тех пор, пока его разок не прочтут, после чего удаляется (я намеренно опустил детали если что). В Кафке append-only подход. Поэтому хранение там организовано иначе. Там тоже сообщения удаляются, но по истечении времени, да и то если вы сами хотите. Об этом подробнее в следующем посте.
 
Такие вот верхнеуровненвые кафкианские пироги. Stay Tuned, как говорится.
#kafka

💪 Как выбрать Struct или Class?
Всегда на интервью спрашиваю у ребят и девчат, приходилось ли им выбирать между struct или class на практике. И в каком случае стоит применять одно, а в каком другое. (Спрашиваю, потому что сам не ебу, если честно, что там и как.Ставь лайкосик 👍, если тоже на интервью пытаешься узнать что-то новое!)
 
Это тот самый случай, когда ты теорию знаешь, но на практике вообще не ясно, как эту теорию применить. Вот сегодня, кажется, что я сформулировал довольно крепкий кейс, в котором нужно как минимум задуматься, отдать предпочтение структуре или классу.
 
❓Так вот, представим себе вот такой объект. Ему нужно быть структурой или классом?

public ???? TimeInterval
{
public TimeSpan From { get; set; }
public TimeSpan To { get; set; }
}

📖 Я считаю, что эта штука может стать структурой и для этого есть вполне практичный аргумент. Безо всяких там (бито-байтоёбств) оптимизаций по памяти и прочей лабуды. Рассмотрим такой тест (если лень читать, то я там сравниваю два одинаковых по наполнению TimeInterval):
 
[Test]
public void StructRef()
{
var from = new TimeSpan();
var to = new TimeSpan().Add(30.Minutes());
 
var interval1 = new TimeInterval()
{
From=from,
To=to
};
 
var interval2 = new TimeInterval()
{
From=from,
To=to
};
 
Assert.True(interval1.Equals(interval2));
}
 
Если мы сделали TimeInterval структурой, то он пройдет. Что и не удивительно, так как метод Equals проверит наши данные по значению.

Но если мы сделаем TimeInterval классом, то этот тест так просто уже не прокатит. Придется учинить оверрайдинг метода Equals для этого класса, а где оверрайдинг Equals, там и оверрайдинг GetHashCode.
 
🅰️ Теперь я приведу практический вывод, который вы можете использовать в повседневной разработке: Если вам в каком-то классе понадобилось переопределять Equals, то прежде чем это делать, задумайтесь, а не стоит ли вашему классу стать структурой?

Ну и еще нужно воспользоваться памяткой от Microsoft разумеется.

P.S.: Конечно тут можно использовать record struct а не просто struct. Надеюсь это очевидно)
#struct #class

😂 Компильдот.
Опятьница (опять пятница)! Ну ежкин дрын. Сегодня будет чуть больше жести, но без сношений сами знаете куда. Итак, встречаем:

Летят как-то в самолете тестировщик, проджект-менеджер и программист.
Самолет начинает падать, пилоты выпадают, программист садится за штурвал, а тестировщик и проджект становятся рядом.
Вдруг самолет резко шатнуло, и проджект начинает выпадать. Тестировщик хватает его за детородный орган и держит. Но в итоге хер отрывается и остается в руках у тестировщика. Тот подходит к программисту и говорит:
– Слушай, программист, тут наш проджект выпал.
– Выпал? Да и хуй с ним!
– Да вот хуй-то не с ним, хуй с нами.

Понравился компильдот? – Ну и куда ты пошёл? А кто лайк будет ставить? Пушкин?
Не понравился? – И что, вот так и оставишь этот компильдо безнаказанным? Вырази свое мнение там где тебя услышат – здесь! А говняшка Скрэппи всегда поможет в этом.
#компильдот

🙏Kafka #2: Топики
Сегодня поговорим про топики. Когда я читал про них, у меня все больше и больше мыслей возникало, что они похожи на таблицы в базе данных, только с более строгими правилами записи. Вот ключевые фичи топика:
 
✴️ Топик – это контейнер для одного типа событий. (по сути, как таблица в базе данных, пояснительный дикпик выше 👆)
✴️ Данные между топиками могут дублироваться.
✴️ Топик – append-only штука (то есть удалять оттуда нельзя)
✴️ В топике есть offset, по которому мы можем искать нужные события. Это по сути смещение от начала сегмента (про сегменты чуть позже, пока можете считать, что от начала файла с событиями)
✴️ События редактировать нельзя.
✴️ Схема данных событий в топике не проверяется.
✴️ Топик делится на партиции. (про это в следующем посте)
✴️ Из одного и того же топика могут читать разные консьюмеры, но читать они будут информацию из разных партиций.

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

🅰️Практический вывод:
1) Когда в своей практике вы создадите топик в Кафке? Когда ваше приложение будет кидать определенный ивент, к примеру о том, что оплата прошла. Вы создадите топик с назанием PaymentAccepted и будете слать в него события.
2) О чем нужно помнить? Что если послали, то удалить посланное из истории будет невозможно.

P.S.: Если что, у этой информации есть оригинал, он тоже коротенький, так что можете ознакомиться.
#kafka