Eugene Kozlov

🗺 Карта канала "Евгений Козлов пишет про IT"

2025-11-17T07:40:04.644Z

Здесь ссылки на посты, статьи и Github репозитории созданные и найденные мной за время существования канала.

🟢 Backend, Software Engineering

Проблема развития Junior / Middle Backend разработчиков
Цикл постов о ресурсах по прокачке в Backend #0 #1 #2 #3
Хорошие практики разработки типичных back-end приложений
Как практиковаться начинающему разработчику?
Подборка ресурсов по Git
Полезные технические ресурсы программисту-стартаперу
Научные статьи по Computer Science
Саморазвитие в Computer Science через практику языка Си

🟢 Docker, K8s, Microservices

Цикл постов о виртуализации и контейнерах #1 #2 #3 #4
TOP 3 ресурса по погружению в Docker, Kubernetes, Microservices, Cloud Native.
Подборка для изучения и практики Kubernetes
What happens when ... Kubernetes edition!
Создать K8s кластер в одну команду
Монолитная архитектура
Прагматичный взгляд на Микросервисную архитектуру.

🟢 Linux, DevOps, SRE

Подборка бесплатных ресурсов по изучению командной строки и утилит Linux #1 #2 #3
Изучение DevOps через упражнения
Бесплатный видеокурс по основам SRE от инженеров Google Cloud
SRE Interview Preparation Guide
Обзор сетевых очередей Linux

🟢 Concurrency, Performance

🟢 Языки программирования

🔵 Golang

🔵 Ruby

🔵 Python

🟢 OLTP СУБД

🟢 OLAP. Data Engineering

🟢 Kafka

🟢 Big Tech Interview

🟢 Soft Skills, Mindset

1 to 1 - что это, зачем, как подготовиться?
Какие вопросы стоит задать перед тем как принять оффер? #1 #2
Зарплатные переговоры
Как правильно задавать вопросы, если ты начинающий айтишник
Наглядный жизненный урок
Почему обучение — это новая прокрастинация

🟢 Личное

Про оргструктуры компаний

2025-04-08T11:51:35.666Z

В рамках прохождения курса "Школа Технического директора" от Стратоплана собрал конспект с кратким обзором основных видов организационных структур компаний.

Плоская оргструктура - хороша тем что все решения принимаются быстро а минус в том что руководитель в такой системе станет бас фактором. Так как руководить в одиночку всеми специалистами напрямую задачка для человека с высоким уровнем компетенций.

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

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

Проектная оргструктура. Хороша тем, что каждый департамент сфокусирован на своем проекте и приносит конкретную измеримую пользу бизнесу. К минусам можно отнести проблему что в такой оргструктуре с ростом компании будет проблемой "выравнивание" культуры между проектами, выравнивание экспертизы специалистов. Сфера применимости - outsource компании.

Матричная оргструктура - одна из самых популярных оргструктур, к ее плюсам можно отнести высокую гибкость, а также то что менеджмент уделяет внимание всем возможным аспектам (delivery / people management). Основные минусы такой оргструктуры - двоевластие и размытие ответственности.

Дивизионная оргструктура. Плюсы: масштабируемся быстро, просто создаем новый дивизион. Четкие уровни управления. К минусам можно отнести высокий уровень дезинтеграции и дублирование функций в каждом дивизионе.

Дивизионная оргструктура с делением на продукты

Дивизионная оргструктура с делением на рынки

Дивизионная оргструктура с делением по локации

💎 Learn Rails from Junior to Senior. My way

2024-01-23T13:57:51.650Z

Продолжаю рассказывать по каким материалам учился и прокачивался в первом профессиональном стеке - Ruby & Rails. Далее вы найдете огромную кучу ресурсов, которые помогли мне

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

Аналогичный пост по Ruby - здесь.

💎Getting Started

У Rails просто офигенная документация, я очень часто использовал ее для решения повседневных задач. Для меня это один из примеров того как должна выглядеть дружелюбная к разработчику дока.

Ну и само собой я не могу не отметить классику - туториал Майкла Хартла по написанию клона твиттера

Книги

Agile Web Development with Rails 7 - тот самый туториал про интернет магазин
The Rails 7 Way - энциклопедия по Ruby on Rails

💎 Best practices

Репозитории компании разрабатывающих на Ruby в которых они ведут свои соглашения и правила по написанию кода на Ruby on Rails.

Если вы хотите максимально быстро прокачаться лучше ресурса не найти - учитесь на чужих ошибках и впитывайте чужой опыт.

💎 Templates

Для того чтобы с нуля стартовать с крутым набором инструментом и не тратить время на настройку локального окружения можно воспользоваться готовыми сборками:

Статья о том из каких библиотек строят проекты Evil Martians - Gemfile of dreams: the libraries we use to build Rails apps

💎 Performance

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

💎 Active Record

Всё что нужно знать чтобы хорошо уметь готовить ActiveRecord и выжимать из него максимум

самый популярный вопрос на собеседовании - Making sense of ActiveRecord joins, includes, preload, and eager_load
Rails Database Best Practices (About queries)
Getting the Most out of your Database with Ruby on Rails (About configuration)
Understanding Locking in Rails ActiveRecord

PostgreSQL

💎 Архитектура / Паттерны

Rails довольно гибкий и мощный фреймворк в котором многое держится на соглашениях, и если бездумно ими пользоваться то проект может превратиться в запутанное спагетти

💎 Rails Security

Работая в production важно не только делать фичу но и писать безопасный код и защищать данные клиентов от вредоносного вмешательства.

💎 Блоги компаний

Простым языком об Apache Kafka, как, зачем и почему

2023-08-13T10:50:59.784Z

В данной статье я хочу попытаться рассказать максимально доступно и просто о такой непростой технологии как Apache Kafka. Расскажу о том:

Кем и зачем она была создана.
Доступно рассмотрим из каких абстракций и примитивов состоит.
За счет чего достигается высокая пропускная способность.
Поговорим про отказоустойчивость и за счет чего она достигается.

Многие новички часто задают вопрос "Почему?" касаемо любой новой технологии. Надеюсь что этой статьей я смогу ответить на большинство “Почему?” связанных с Apache Kafka.

Краткий экскурс в историю. Причины появления Kafka

Apache Kafka — распределенный, реплицируемый журнал с открытым исходным кодом, разрабатываемый в рамках фонда Apache. Написан на Java и Scala. Сложно, непонятно, но пойдем дальше.

Разработан в компании LinkedIn в начале 2010х, далее был передан в фонд Apache. Сейчас авторы проекта работают в компании Confluent которую сами и основали.

Kafka зародилась в LinkedIn как решение для задач про передаче больших объемов данных между сервисами, в частности для построения моделей машинного обучения. Классические брокеры сообщений не могли обеспечить нужную пропускную способность (throughput) и LinkedIn решил создать “свой велосипед”

Из чего состоит Apache Kafka?

Что же придумали разработчики Kafka чтобы достигнуть высокой скорости передачи данных? Ответ: сделали брокер максимально простым и топорным: он хранит все сообщения на диске и позволяет делать с ними только 2 простых но очень эффективных с точки зрения железа операции:

добавить запись в конец файла
прочитать файл с позиции X до позиции Y

Как следствие, нельзя:

искать, фильтровать данные на стороне кластера, только на стороне клиента
удалять данные (за удаление данных отвечает Kafka)

За чтение сообщений отвечают потребители (consumers).За отправку сообщений в Kafka отвечают производители (producers). Писатель и читатель при взаимодействии с брокером указывают обязательный параметр - topic или тема. За счет него логически идет разделение потоков данных на стороне kafka.

Чуть подробнее о потребителях

Потребитель по порядку читает сообщения из темы и направляет брокеру Kafka специальные сообщения о том что он прочитал. В этом самом сообщении брокеру передается специальный идентификатор offset - позиция на которой остановился читатель.

Если читатель перезапускается то при повторном подключении к брокеру он получит последнее актуальное состояние offset и продолжит читать сообщения с того места на котором остановился. Offset в каком то смысле похож на индекс в массиве. Зная индекс мы можем сразу обратиться к нужному элементу и продолжить обработку всех последующих за ним.

И это всё? Просто файлы?

На самом деле нет. Представим, у нас есть топик X, в который пишется очень много сообщений. Мы понимаем что в одного потребителя не справляемся и хотим распаралелить процесс. Если наш topic это просто файл то читать из него несколькими потребителями становится проблематично, так как нужно потребителей синхронизировать между собой, чтобы не получилось так что каждый потребитель обрабатывает одно и то же. Синхронизация это время, и оно очень ценно, с ростом количества потребителей время синхронизации будет линейно расти.

Что же делать? Разработчики Kafka решили разделить топик на N независимых сущностей (по факту это те же файлы) назвав партициями. Теперь нас ничто не останавливает от того чтобы создать N потребителей и быстро вычитывать данные, так как потребителей не нужно синхронизировать, каждый читает только свой кусочек, свою партицию.

Мы достигли цели, пропускная способность за счет деления топика на партиции способна расти линейно, успевай добавлять партицию и потребителей.

Набор потребителей в Kafka именуется Consumer Group (группа потребителей). При добавлении или выходе потребителей из группы kafka требуется ребалансировка, чтобы либо выделить новому потребителю свою партицию либо назначить уже работающему консьюмеру партицию которую читал умерший консьюмер.

Что насчет отказоустойчивости?

Репликация

Что может пойти не так с Kafka брокером? Да всё что угодно, например сервер на котором он развернут может выйти из строя. В таком случае мы не сможем ни писать сообщения ни читать их, а это грусть печаль, бизнес стопорится, деньги не зарабатываются. Что спасает в таких случаях? Правильно, избыточность.

Если базы данных умеют восстанавливаться от сбоев за счет репликации то почему бы и Kafka не перенять эту механику? Так посчитали и разработчики Kafka и добавили механизм репликации данных между узлами. Теперь вместо одного брокера получаем кластер брокеров.

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

Репликация конфигурируется для каждого топика через переменную Replication Factor - сколько копий для партиции нужно иметь в кластере.

Controller

У одного узла в кластере Kafka есть специальная роль - controller, в его обязанности входит как раз таки на основании состояния кластера назначать лидеры для партиций топиков. Лидер партиция - партиция с которой взаимодействуют потребители и произовдители. Аналог мастера в мире БД. Остальные копии лидер-партиции являются ведомыми и их обязанность - участвовать в репликации.

Для того чтобы гарантировать в кластере уникальность роли controller а также хранить и отслеживать состояние брокеров кластера Kafka использует kraft / Apache Zookeper.

Итог

В данной статье я постарался описать максимально простым и понятным языком как устроен брокер Apache Kafka и почему именно так а не как иначе. Многие вещи в этой статье не удалось рассмотреть, например семантики доставки, это было сделано осознанно чтобы не растягивать статью.

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