Всем привет, меня зовут Михаил, я работаю Java/Kotlin разработчиком в ОТП Банке.

Все мы знаем про Redis. Часто используем его для in-memory кэша. В основном это ключ и значение. Но что, если можно пойти дальше и, как в том фильме, раскрыть все возможности Redis на 100%?

Сегодня я хочу поговорить о Sorted Set в Redis. Что это за зверь и как его использовать.

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

Присаживайтесь, будет интересно!

Всем привет, меня зовут Михаил, я работаю Senior Java разработчиком в ОТП Банке.

Смотря на всю ситуацию на рынке, я подумал: хм, вот джуны притворяются мидлами и сеньорами и ходят по собесам. А что, если все будет наоборот?

Учитывая, что ситуация на рынке для джунов совсем плачевная, я решил провести эксперимент. 30 дней. Только я, фейковое резюме джуна, новый Telegram-аккаунт - и все!

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

Интересно, чем все это закончилось и как это было? Присаживайтесь поудобнее!

Всем привет, меня зовут Михаил, я работаю главным экспертом (Java/Kotlin) в ОТП Банке.

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

Умение говорить "нет" - один из самых важных скилов в разработке. Ни знание фреймворков, ни владение языками программирования не сравнится с этим навыком.

Сказать "нет" бывает тяжело. Особенно в начале пути, когда ты еще молод и боишься. Боишься, что после этого к тебе начнут относиться хуже. Или не дай бог уволят.

Так давайте же посмотрим, почему этот скилл так важен и как обладание им меняет жизнь в разработке!

Всем привет, меня зовут Михаил, я работаю senior Java/Kotlin разработчиком в ОТП Банке. В свободное от работы время я занимаюсь менторством. Ко мне приходят разные люди: кто-то уже работает на проекте, кто-то только учится.

Сейчас, в эпоху ИИ, найти информацию стало куда легче, чем раньше. Раньше ты гуглил и тыкал по ссылкам, а теперь все в одном приложении. Да еще и код можно не писать - ну красота же. Но что, если ты и до этого не умел писать код и решил "вкатываться в айтишку" (ненавижу эту фразу)?

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

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

Сегодня поговорим о том, как ИИ влияет на обучение с нуля и как им лучше пользоваться для обучения.

Всем привет, меня зовут Михаил, я работаю главным экспертом в ОТП Банке.

До банка я почти не работал в командах с выстроенными процессами. Суета, спешка, неадекватные сроки, переработки до ночи и постоянное тушение пожаров - всё это было привычной частью работы. Я видел, как команды выгорали, а проекты разваливались из-за отсутствия процессов.

В какой-то момент я сказал себе: «Стоп. Хватит. Пора уходить в компанию, где всё организовано правильно». Мне казалось, что там не будет хаоса, бессмысленных авралов и вечной гонки за дедлайнами.

Ну что могу сказать - я попал.

Только вот ожидания и реальность оказались совершенно разными.

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

Всем привет! Меня зовут Михаил, я работаю главным экспертом в ОТП Банке.

Я люблю тестировать свои решения и почти всегда пишу unit- и integration-тесты. Но вот с нагрузочным тестированием ситуация обычно совсем другая: о нем вспоминают ближе к релизу, когда архитектуру уже поздно менять.

В какой-то момент я поймал себя на мысли:

А как вообще заранее понять, сколько ресурсов будет потреблять сервис под нагрузкой?

Сколько памяти съест приложение? Когда упрется в CPU? Как поведет себя БД при разном кол-ве запросов?

Чтобы ответить на эти вопросы, я написал небольшую библиотеку для локального нагрузочного тестирования на Java Virtual Threads. Она запускает большое количество задач, собирает метрики и формирует отчет - прямо в консоли или в CSV.

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

Всем привет, меня зовут Михаил, я back-end разработчик в ОТП банке. Сегодня хочу рассказать о профдеформации - о том, как разработка перестраивает мозг без спроса.

Разработка - это не восьмичасовой найм. Это перепрошивка, о которой никто не предупреждает на собеседовании. Мы видим, как всё работает за кулисами. А потом вдруг ловим себя на том, что с женой разговариваем эндпоинтами, а в очереди к врачу видим легаси-монолит.

И знаете что? Это не лечится.

Дальше - несколько моих личных симптомов. Пишите в комментариях свои, уверен, что у каждого такое было!

За несколько лет работы я сменил несколько проектов и команд. Стек менялся: где‑то был Kotlin, где‑то классическая Java, где‑то вообще старый монолит на виртуалках.

Но самое сильное различие было не в технологиях.

Всё решали люди, которые руководят разработкой.

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

И самое неожиданное — один из них, при всех своих минусах, оказался для меня полезнее остальных.

В этой статье — три реальных кейса и то, чему они меня научили. И как каждый из руководителей влияет на разработку.

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

Эта статья - про ад и слезы. Про реальный опыт.

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

Сейчас я расскажу, как я не сломался. Хотя был близко. Очень близко.

Поехали!

Всем привет! Меня зовут Михаил, я главный эксперт в ОТП банке.

Несколько лет я мечтал поработать на Kotlin. Мне это удалось — был большой проект РЖД, я вкатился, писал код, радовался. Kotlin мне правда понравился.

Но давление менеджеров, нереальные сроки и просто выгорание вынудило меня выходить на рынок, и я пошёл искать работу… и тут меня ждал сюрприз. Вакансий, где нужен чисто Kotlin, в России — единицы. А те, что есть, чаще ищут Java/Kotlin с упором на первую.

В этой статье — моя история: как я вкатывался в Kotlin без подготовки, как мне понравилось, и почему я всё равно сейчас пишу на Java. Читайте, если думаете о переходе, — возможно, это поможет скорректировать ожидания.

Поехали!

Всем привет! Меня зовут Михаил, я главный эксперт в ОТП Банке.

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

Разберем всё по шагам, с замерами производительности. Поехали!

Всем привет!

Многопоточность в Java развивается очень быстро, а многие всё ещё ограничиваются обычными потоками и ключевым словом synchronized. Сегодня я хочу рассказать именно о виртуальных потоках: как с ними работать, почему они меняют подход к многопоточности и какие задачи решают лучше традиционных механизмов. Буду объяснять просто и понятно, чтобы материал был полезен как новичкам, которые только знакомятся с виртуальными потоками, так и опытным разработчикам, которые хотят понять современные практики и возможности Project Loom.

Всем привет!

Многопоточность в Java не стоит на месте, а многие до сих пор используют только synchronized и создают потоки через new Thread(). С этого дня я запускаю серию уроков по современной многопоточности: как её правильно строить, в чём преимущества новых подходов по сравнению со старыми и что из классики всё ещё стоит использовать. Постараюсь объяснять максимально просто и наглядно, чтобы уроки были полезны и стажёрам, которые только начинают разбираться в теме, и опытным разработчикам, которым интересно узнать современный стиль работы с потоками.

Поехали!

Всем привет!

Сейчас я работаю Senior Java Developer в банке, и за последние годы мне довелось пройти немало собеседований — разных по уровню, стилю и степени жесткости. Сегодня я хочу рассказать об одном из них и поделиться опытом, который может быть полезен тем, кто тоже готовится к новым вызовам.

Всем привет!

Я работаю Senior Java Developer в одном из банков, и за последние годы мне довелось пройти не один десяток собеседований, выслушать массу неожиданных вопросов и потратить немало времени на подготовку. И вот что я понял: Kafka - одна из самых любимых и в то же время самых коварных тем на технических интервью. Независимо от уровня кандидата, вопросы по Kafka появляются почти всегда - от базовой архитектуры до тонкостей гарантий доставки и работы consumer groups.

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

Всем привет!

Я Senior Java Developer в банке, и за эти годы мне довелось пройти немало собеседований. Где-то было спокойно, где-то — как в допросной, с каверзными вопросами, странными задачами и вечным «а почему так, а не иначе?». В процессе я собрал целую коллекцию тем, которые всплывают снова и снова, особенно когда дело касается баз данных.

Сегодня хочу поделиться этим опытом и разобрать вопросы, которые чаще всего задают именно по SQL-базам.

Всем привет!

Сейчас я работаю Senior Java Developer в одном из банков, и за последние годы мне довелось пройти множество собеседований, столкнуться с десятками непростых вопросов и вложить кучу времени в подготовку. И со временем я заметил одну закономерность: Spring — одна из самых объёмных и любимых тем на Java‑собеседованиях, причём спрашивают её у кандидатов любого уровня.

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

Всем привет!

Работая Senior Java Developer в одном из банков, я успел пройти уйму собеседований, столкнуться с десятками каверзных вопросов и понять, сколько усилий требует подготовка. И каждый раз убеждаюсь в одном: тема JVM, память и GC — одна из самых недооценённых и одновременно самых частых на Java-собесах. Многие знают об этом “что-то где-то слышал”, но как только разговор заходит про Heap, Metaspace, JIT, Safepoint или разные типы GC — начинаются проблемы.

Поэтому эта статья — вторая часть моей шпаргалки по подготовке к Java-собеседованиям. Здесь я собрал всё самое важное о работе JVM и управлении памятью простым, человеческим языком, без боли и академической зауми. Разберём архитектуру JVM, устройство памяти, JIT, GC, типы ссылок и самые частые вопросы, которые любят спрашивать на интервью.

В профиле уже есть первая часть для подготовки — Многопоточность без боли.

Всем привет!

Я работаю Senior Java Developer в одном из банков, и за последние годы мне пришлось пройти не одно собеседование, услышать десятки каверзных вопросов и потратить уйму времени на подготовку. И вот что я понял: многопоточность — это одна из самых сложных и любимых тем на Java-собеседованиях, независимо от уровня кандидата.

Поэтому в этой статье я хочу помочь вам уверенно подготовиться к секции по concurrency: разберём ключевые термины, посмотрим, как это работает на практике, и дам несколько советов, которые реально помогают на собесах. Поехали!

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

В этой статье я покажу, как я вынес всю логику Transaction Outbox в отдельный Spring Boot Starter, который можно подключить одной зависимостью. Он создаёт таблицу Outbox, конфигурирует шедулер, отвечает за отправку в Kafka и очистку, позволяя микросервисам сосредоточиться только на бизнес-логике.