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

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

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

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

🙏Kafka #3: Как устроен Topic. Партиции.
Ок, топик мы создали, начали писать туда сообщение и вдруг поняли, что тачка не вывозит. Что делать? На помощь приходят партиции. Топик состоит из партиций (пояснительный дикпик 1).

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

Соотвественно сообщения по партициям не копируются, а распределяются!

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

Partition0: 1️⃣1️⃣1️⃣1️⃣1️⃣
Partition1: 2️⃣2️⃣2️⃣2️⃣2️⃣2️⃣

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

Как данные читаются из партиции?
Хорошо, мы научились писать в партиции, а как же из них читать? Это не так просто, ибо партиция, это по сути отдельно живущая штука. Что-то типа сетевой папки.

Из одного топика могут читать сколько угодно консьюмер-групп (пояснительный дикпик). Но вот из одной партиции может читать только один консьюмер! Один, в рамках одной консьюмер-группы, разумеется 🖼, как меня правильно поправили в комментариях. (пояснительный дикпик 3).

Из этого пункта следует два вывода:
❗️Сколько партиций, столько и консьюмеров в группе – ни больше ни меньше. Потому что, если сделаете меньше, то часть событий просто пролетит мимо вас. А если сделаете больше, то лишний консьюмер будет стоять и передергивать в сторонке. (на третьем дикпике мы как раз аидим таког третьего лишнего)

❗️Если продьюсер не указал ключ партиции, то сообщение распределится между партициями по RoundRobin'у. То есть вот так:

Partition0: 1️⃣1️⃣2️⃣1️⃣2️⃣
Partition1: 2️⃣1️⃣2️⃣2️⃣1️⃣2️⃣

И вам потом придется бегать по партициям и собирать все во что-то более менее приемлемое. Так что будьте с этим аккуратнее.

🅰️Практические выводы:
1. Когда делаете новый топик, то сразу думаете про количество партиций. Думаю, что стоит считать предполагаемую нагрузку по сообщениям. Так как добавление партиций – это нетривиальная операция. Короче, это число с бухты-барахты не выбирают. (у нас в компании вот выбрали по лунному календарю и гороскопу, но не с бухты-барахты блять!)
2. Продьюсер должен задавать ключ партиции. Иначе в партициях будет хаос из данных по разным сущностям. (но хер знает, может вы носитель хаоса, и вам так комфортнее 😉)

Дисклеймер: Вся информация здесь, это моя личная вольная интерпретация прочитанной доки по кафке, просмотренных видосов и разговоров с коллежанами. Если у вас есть возражения, то приносите их в комменты. Я очень благодарен всем, кто комментирует, лайкает и вообще проявляет активность в канале и в личке. Это супер-помогает мне не терять мотивацию!
#kafka

👋 Как обсудить задачу, чтобы все поняли её одинаково. Метод "Дано Когда Тогда".
Возьму небольшой перерыв в кафкианской саге и расскажу тут про одну мегаполезную штуку, которая вот уже год служит нашей команде верой и правдой и помогает делать встречи короче и продуктивнее.

❓ С самого начала работы в IT у меня крутился в голове вопрос, как же сформулировать задачу так, чтобы в конце все поняли её одинаково?
 
Заебывало знаете ли, что, бывает, сидишь на встречах, слушаешь по 30 минут, как люди спорят, куда надо подвинуть кнопку, а в итоге выясняют, что они вообще говорят о разных кнопках. И потом еще 30 минут слушаешь, как люди пытаются выяснить, кто из них бОльший долбоеб. (А потом выясняют, что говорили про разных людей, ахах!😂)
 
🅰️ Освоил простую, но эффективную технику и спустя год работы с ней, могу порекомендовать её однозначно. Она простая до того, что стыдно писать про неё пост (но я все же напишу). Называется техника "Дано, Когда, Тогда".
 
Суть простая. Когда кто-то из бизнеса описывает функционал, то проговаривает каждую фичу в формате:
"Дано: Кто-то хочет что-то"
"Когда: Этот кто-то делает действие"
"Тогда: Видит результат в таком-то формате"

К примеру, одна из наших фич с сумрачным названием:
Скопировать поп-ап управления отложек МенСмены в МенОфиса/ День

Что должно быть в результате? Хер знает. Вызываем технику Дано Когда Тогда:
 
Дано: Я как региональный управляющий могу зайти в Менеджер Офиса.
Когда: Я в интерфейсе МО на главной странице в разделе Трекинг — Отложено нажимаю мышкой на отложенные заказы
Тогда: Появляется такой же интерфейс как в Менеджере Смены при нажатии на кнопку Отложенных заказов - 0 в разделе Кухня на вкладке Главная.

В первой формулировке не понятно даже то, откуда в менеджере смены надо брать этот (ебучий) поп-ап. В приемочном критерии же четко прописан путь до искомого контрола. При этом все присутствующие попробовали по этому описанию найти нужный поп-ап и убедиться, что имеется в виду одно и то же.

Такое описание привело к тому, что мы начали рассматривать различные корнер-кейсы и выяснили, что к примеру не все детали интерфейса нужно будет переносить в окончательном решении:

Дано: Я как Менеджер Офиса выбираю пиццерию Сыктывкар-1. Я открываю Отложенные заказы на главной и вижу отложенные заказы из Сыктывкара-1.
Когда: Я смотрю на место, где в Менеджере Смены есть иконка принтера
Тогда: Вижу, что в Менеджере офиса ее там нет.

Конкретно этот критейрий снял головную боль по переносу функционала печати, который намертво вбит в Менеджера Смены.
 
⁉️ Тут же возникнет вопрос. Но, Дмитрий, пардон, есть же User Story Mapping, есть же доски в Miro, макеты, разве этого добра не хвататет?
 
Хватает, но User Story Mapping – формат тяжелый, как хрюкающие подсвинки сатаны. А функционал бывает не визуальным, к примеру в итоге действия должен проигрываться звук, так что фигмы никакой не будет. И еще плюсом этого формата является то, что он позволяет покрыть, как маленькие задачи, так и довольно большие.
 
User Story Mapping все еще отличный инструмент, но подходит он скорее для очень больших задач. Которых у нас не так много.

Как начать использовать Дано, Когда, Тогда? Да супер-изи!
1️⃣ Для пункта Дано, попросите продакта максимально описать пользователя, который будет производить действие. Его роль в системе, данные, которые должны быть заполнены, что он хочет сделать.
2️⃣ Для пункта Когда. Попросите сформулировать, что будет делать пользователь. Откуда он начинает своё действие, куда кликает, чтобы прийти на нужный экран или  перевести систему в нужное состояние.
3️⃣ Для пункта Тогда попросите описать конечный результат. Как поменялось состояние системы? Что увидел пользователь? Почему ему это было полезно?
 
Повторяйте до тех пор, пока не покроете все крайние случаи. Будет сложно, но через несколько PBRов навык отточится, и вы поймете насколько глубоко нужно детализировать каждый пункт и сколько таких пунктов нужно.
 
Еще можно позвать инженера по тестированию, чтобы он помог вам не сдаться на пути в бездну и помочь МАКСИМАЛЬНО детализировать крайние случаи.
#процессы

🙏 Kafka #4: Как устроены партиции. Сегменты.
Источник пояснительного дикпика
#kafka

🙏 Kafka #4: Как устроены партиции. Сегменты.
Хорошо, мы создали топик, разделили его на партиции. Но вдруг партиция раздулась так сильно, что ему пришла финита! А увеличивать место больше некуда по финансовым соображениям. А вы до этого читали, что из Кафки ничего не удалить! ЧТО ДЕЛОТЬ⁉️

Главное – не переживать! Дело в том, что кафка все пишет в файлы. Но делает это хитро. Когда размер файла достигает 1 Гб или возраст файла достигает недели (что быстрее наступит), брокер создает новый файл и начинает писать в него. С новым файлом произойдет то же самое, когда он увеличится до 1 Гб или проживет неделю.
 
Такие файлы называются сегМЕНТАМИ. (пояснительный дикпик выше 👆) Ну ладно просто сегментами. И партиция по сути состоит из таких сегментов. Тот файл, в который кафка пишет прямо сейчас называется активным сегментом.

❓И как все это самоочищается?
Вы можете настроить всё так, чтобы эти сегменты понемногу чистились автоматически. Либо, когда место на диске начинает заканчиваться, либо когда возраст сегмента достигает определенного значения. Активный сегмент хрен удалишь, по понятным причинам. (Ну точнее, вы конечно можете его удалить, но если вы так делаете, то либо вы гений, либо у меня для вас нет хороших новостей сегодня)
 
Разме сегмента можно настроить, как на уровне настроек брокера, так и на уровне настроек топика. Кто кого переопределяет, тут я ХЗ. Выглядят эти настройки вот так:
log.segment. bytes
log.segment. ms

🅰️ Практические выводы:
1. Кафка все таки что-то удаляет, но удаляет сегментами. То есть откусывает кусочки партиции.
2. Настраивать сегменты имеет смысл, если вы понимаете, что у вас в брокере мало памяти, или же, если вы знаете, что данные в топике не нужно хранить дольше определенного срока.

В следующем посте буду разбираться с индексами и тем, как консьюмер ищет сообщения по партициям и их сегментам.
#kafka

😅Компильдот! 💡
Самые внимательные заметили, что в прошлую пятницу обошлось без компильдота. А все почему? Потому что я отдыхаю. Отдыхать – важно, посему компильдот про отдых сегодня, товарищи!

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

Так-с компильдот запостил, пора бы и ещё отдохнуть. Ставь лайк 👍, если готов лезть на потолок ради пары дополнительных дней отпуска и говняшку Скрэппи 💩, если в этот ноябрь всё еще пашешь, как трактор! 🚜
#компильдот

🤕 Как я случайно справился с зимней хандрой

🅰️ TLDR: Я начал работать только при дневном свете (с 8:30 до 16:00). Получилось меньше рабочих часов, но больше итоговой работы и удовольствия от неё.

Как обычно в ноябре - декабре это бывает, меня поприжало. Собственно, почему и не было постов. Туман в голове, рассеянность, общая слабость, невозможность войти в поток (ой да блин, я даже дышал с трудом, какой там нахер поток).

Справиться с этим состоянием не получалось. Ничего не помогало – ни витамины, ни походы к психологам. Сначала я старался все же делать посты через силу, но в итоге решил не давить из себя раба по капле, и просто забил, сконцентрировавшись на более достижимых аспектах моей жизни – прохождении Red Dead Redemption 2.

🧈 Но вмешался случай и случайным образом я случайно нашел решение проблемы (абсолютно СЛУЧАЙНО). Делюсь с вами.

❌ Итак, для того чтобы в зимний период избавиться от тумана в голове нужно всего лишь… Работать только при дневном свете! ❌

Короче, я начал вставать с рассветом в 8:30, начинать работу в 9:00 и заканчивать в 16:00. По МСК это период с 8:00 до 15:00. Важно еще то, что после окончания работы у меня остается полтора часа светового дня на свои дела. То есть я не работаю от рассвета до заката прям, а немного гуляю при свете дня.

И, о чудо – продуктивность не то что выросла, а вернулась к дозимним показателям!
 
🛌 Засыпать, я, естественно, начал тоже раньше, но этот аспект я не особо контролировал – он сам пришел в норму.
 
Тут возможно меня покритикуют, что я получается меньше работаю: типа 7 часов + перерыв на обед и турнички, итого всего 6 часов. Но йопт, лучше наверное 6 часов продуктивной работы в удовольствие, чем 8 часов недовольного топтания говна в ступе?

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

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

О пути из разработчика в лидеры, внутренней перестройке, погружении в бизнес и о том, что делает СТО в Dodo Engineering

💻 Так совпало, что три года назад наша IT-команда официально стала компанией Dodo Engineering. И сегодня мы празднуем её день рождения. В честь этого и грядущего Нового года — спецвыпуск подкаста.

🎙Гость — Павел Притчин, в роли ведущего — Дмитрий Афонченко, наш разработчик.

Паша рассказывает о том,
как выглядит Dodo Engineering со стороны СТО, как происходила его трансформация из простого разработчика в технического лидера, какие навыки и книги помогают ему в работе.

Узнаем, как Паша относится к падениям Dodo IS, когда в последний раз писал код, как фиксирует свои результаты, на каком уровне СТО (джун, мидл, сеньор) находится и откуда у него есть время на подкаст.

И куда, в конце концов, делась рубрика «монолитометр».

🎧 Где послушать:

Web
Apple Podcasts
Google Podcasts
Я.Музыка

🤬Быстрая мысль про ChatGPT.
С новым годом, етить его на право! 🎄

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

Короче, ChatGPT можно использовать в качестве советника для составления имен для доменных сущностей. Я попробовал спросить эту штуку, как мне лучше назвать класс для составного продукта – CompoundProduct или CompositeProduct и вот что он мне ответил. (смотри на скрине)

Для меня это частично решает проблему глоссария: когда выбираешь между похожими по смыслу определениями при занесении новой записи. Всегда хочется спросить совета, как будет точнее. И кажется, что нейронка как нельзя лучше подходит для такого вопроса.
#chatgpt #инструменты

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

🙏 Kafka #5: Сегменты и индексы. Как брокер указывает консьюмеру на своё место?

Кажись у меня появилась энергия даже на такую душную тему, как кафка.

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

🚸 Начнем с того, что кафка работает по TCP и использует свой бинарный протокол. Как он работает?

1️⃣ Когда консьюмер подключается к брокеру, он посылает в него запрос на поиск нужного оффсета: void seek(TopicPartition, offset). Есть еще seekToBeginning или seekToEnd, они работают почти так же, только ищут по времени, а не по оффсету.
2️⃣ Брокер находит нужный оффсет.
3️⃣ Консьюмер вызывает метод poll(timeout) и начинает консьюмить.
(Пояснительный дикпик 1)

🅰️ Как брокер быстро находит нужный оффсет? Понятное дело по индексу. Обычно индекс кажется загадочной структурой, которая магически ускоряет всё в этой жизни, но на деле это тупо файл.

Мне проще разбирать штуки на конкретных примерах, поэтому представим, что нам пришел запрос seek() с параметрами TopicPartition = "configured-topic-0" и offset = 1.
 
1️⃣ Сначала по имени партиции находим нужную папку.
2️⃣ Потом в нужной папке находим файл с индексом.
3️⃣ В файле индекса находим нужный offset.
4️⃣ В файле сегмента находим нужное сообщение по offset.
(Пояснительный дикпик 2)

Так и работают индексы в кафке. Индексы по времени устроены так же, только мы лезем в файл с расширением .timeindex.

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

🤖 Tralebot

🏇Недавно прошёл Red Dead Redemtion 2. Прохождение заняло 60 часов чистого времени и три месяца в целом.
 
Игра невероятна! Столько пищи для размышлений я давно не получал. Словно прочитал какой-нибудь многотомный эпос. Да и по времени, кстати, так и выходит. Единственный момент в том, что в игре дохрена каких-то новых для меня английских слов.

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

Так я начал мутить себе телеграм-бота переводчика, который умеет заносить слова в словарь, а потом гонять по ним квизы.
 
Прикольный и небольшой проект, на котором я решил лишний раз Clean Architecture паттерн (хер его знает, паттерн ли это или типа такая структура проекта просто). Заодно подтянул своего хорошего друга Сашу Коновалова на настройку инфраструктуры, ибо мне возиться со всеми этими деплоями лень, а он вроде как недавно курсы девопса прошёл (а не как я Red Dead Redemption).
 
Собственно, поэтому я сюда и не писал. Что-то увлекся этим ботом и допиливанием фич по нему, а еще за этот месяц с помощью него выучил 124 новых слова.
 
🅰️ Тут я хочу поделиться репозиторием, который будет полезен, если хотите посмотреть:
1️⃣ Как по-быстрому настроить деплой на сервак с докером по коммиту в мастер

2️⃣ Как настроить секреты, чтобы они не лежали в репе

3️⃣ И как настроить оплату в телеге через нативный телеговский виджет.

4️⃣ Ну и хз, можете подсмотреть еще архитектуру бота. Там много что есть еще что допиливать с технической стороны, но мне что-то лень, я сейчас в основном фичи новые пилю. (Хочу чтобы эта штука сыпала в меня ачивками за каждое дейсвтие и тешила мое ЧСВ)

5️⃣ Чуть позже хочу сделать там еще запись в логи через Loki, это чтобы можно было смотреть их прям в графане и не деплоить и не лазить в кибану.

Секретный пункт 6️⃣ Ой и да, там нет тестов. Это плохо, но я пока типа в творческом поиске, поэтому положил на них с прибором ибо переписывать их после каждого нового переосмысления мне лень. Простите, не делайте так – тесты это очень и очень хорошо.
 
Самого бота пока не рекламирую, так как он в стадии пре-альфа тестирования. Но в ридмихе репозитория ссылка есть, так что можете опробовать, если хотите. 😉
#петпроекты #cleanarchitecture

🌴 Expression Trees

Рубрика задротские штучки.

Если вы заглядывали в репозиторий TraleBot’а, то видели там метод IsApplicable у каждой команды. Этот метод в тупую проверяет пользовательский ввод, и, если тот подходит под условия, то вызывается метод Execute у команды.
 
Я подумал, что было бы круто как-то ускорить все эти проверки, и вспомнил, что когда-то давно на одной работе тимлид советовал мне переписывать большие if'ы на Expression Tree. Тогда я поверил, что это всё ускоряет и вопросов не задавал, а сейчас решил проверить, а реально ли оно быстрее работает?
 
🅰️ Оказалось и правда быстрее. К примеру вот такое выражение

return person != null
&& person.Name != null
&& person.Age < 9;
 
Оказалось примерно в два раза медленее, чем аналгичное скомпилированное ExpressionTree (тут неполный код, чисто для примера):

var hasNameAndAge = Expression.AndAlso(
Expression.AndAlso(
objectNotNull,
hasNameNotNull),
hasAgeLessThanParam);

SimpleCodeScenario: 2.662 ns
ExpressionsScenario: 1.213 ns

И вот я пока что-то ХЗ почему так.

P.S: код самого бенчмарка я загнал в sharplab.io, про который когда-то давно рассказывал. Вот ссылочка на него

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