Всем привет!

Меня зовут Леонид Ченский, и я решил начать вести свой канал, посвященный разным темам из жизни разработчика.

Расскажу немного о себе:
➡️мне 26 лет
➡️закончил университет им.Баумана, факультет Информационного Управления с красным дипломом
➡️проф.погружение в IT началось с 1.5 годового курса от Mail.Ru “Технопарк”
➡️в IT работаю с 2019г.
➡️ex. Golang-разработчик
➡️уже 3 года как TeamLead
➡️выпустил 4 потока обучения Go разработчиков в Ozon Школе “Route256”: прошел путь от тьютор до декана школы
➡️приглашенный спикер подкаста Reg.ru ▶️
➡️учасник golang meetup-а ▶️
➡️"человек который творил эту эпоху и сам стал эпохой" (ну вы поняли😉)


На данный момент являюсь Teamlead-ом команды DBaaS ScyllaDB в Ozon Tech в департаменте платформы.
До этого 2 года был руководителем команды в Логистике Ozon, а еще до этого - golang разработчиком в этой же команде. К слову, в этой команде мне приходилось проектировать сервисы, способные держать более 450k запросов пользователей в секунду. Highload-а было много.

Помимо разработки я также делился своей экспертизой в школе Route256 (школа от Ozon для разработчиков уровня middle). Сначала был тьютором, проверял домашние задания и консультировал учеников, далее был преподавателем и лектором, а после дошел до позиции декана в Route256.

Здесь в канале я планирую продолжать делиться своей экспертизой, а также выносить какие-то важные темы для обсуждения, советовать полезные, на мой взгляд, материалы и просто публиковать своими мысли 📢

Добро пожаловать!👋

🚀КАК С НУЛЯ РАЗРАБОТАТЬ МИКРОСЕРВИСЫ, КАК В BIGTECH?

📆 Уже сегодня в 18:00 по МСК я проведу бесплатный открытый урок по микросервисам!

🎥Трансляция будет доступна по этой ссылке.

Курс будет посвящен разработке микросервисов, где я буду рассказывать про самые актуальные темы и проблемы. Лендинг курса можно посмотреть по этой ссылке.

Когда меня спрашивают, почему я выбрал 👩‍💻 в качестве языка разработки.

Я просто выбрал быть более продуктивным разработчиком⚡️

А вообще мой первый язык разработки 👩‍💻 и я 2 года на нем разрабатывал и он мне очень понравился, но как говорится, лучше больше, чем меньше.

📣 Вчера состоялся открытый урок по микросервисам! Спасибо всем, кто подключился, надеюсь вам понравилось!

📹Как и обещал, запись открытого урока уже доступна по ссылке.

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

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

👩‍💻 Язык Go не стал исключением и я подробно погрузился в его устройство. Что я узнал:
🟠Go написан на go - да, как бы странно это не звучало, но всем, чем мы пользуемся в go, написано на нем же, все исходные файлы открыты и их можно изучать.
🟠Go не просто язык программирования, go - это целая экосистема!
🟠Основные 3 кита, делающих go таким, каким мы его знаем: планировщик, сборщик мусора и устройство памяти, и netpoller.

У меня ушло немало времени, чтобы разобраться во всех тонкостях устройства данного языка. По итогу я собрал самые лучшие материалы раскрывающие подробно все нюансы Go и решил поделиться ими с вами в своем репозитории: https://github.com/moguchev/golang. Периодически я актуализирую данный список источников, добавляю новые статьи, видео и новые темы, поэтому советую добавить в избранное🌟

А какие технологии хорошо знаете вы?

#go

‼️ЗАДАЧА О ДВУХ ГЕНЕРАЛАХ. ЧАСТЬ 1.

Зачем я спрашиваю на собеседовании у Senior разработчиков задачу о 2-ух генералах?

Давайте начнем с самой задачи:

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

Достичь такого соглашения (в случае надёжного канала связи) очень просто — достаточно одного сообщения с временем начала штурма и одного сообщения, подтверждающего согласие.
Сложность задачи заключается в невозможности разработать алгоритм гарантированного обмена этими сообщениями при ненадежном канале связи: т.е сообщение может потеряться, или мы можем не получить подтверждение.

ПРИЧЕМ ЗДЕСЬ РАЗРАБОТКА? Все просто: в большинстве микросервисных системах так или иначе используются брокеры сообщений (тот самый посыльный). Когда два сервиса обмениваются асинхронно сообщениями, они как 2 генерала на двух холмах, не знают дошло ли сообщение или нет.