Павел Сорокин | Java

Мы относимся к отдыху как к ремонту: много поработал, устал, разрядился - значит, можно несколько дней ничего не делать, чтобы снова вернуться в рабочее состояние 😎 Но после поездки на Кавказ я подумал, что у отдыха есть другая, менее очевидная сторона На 8 дней мы уехали в небольшое ущелье в Северной Осетии, сейчас в трех местных поселениях живет около 200 человек, хотя раньше их было больше 3000 Почти каждый день мы куда-то ходили: в горы, к леднику, по ущельям, сплавлялись по горной реке, ходили в баню и на термальные источники. Слушали рассказы местных и гида о том, как здесь жили сотни лет назад, во что верили и как был устроен их быт Формально это не очень похоже на отдых. Каждый день расписан, иногда по десять часов проводишь на ногах, но именно там я действительно переключился Когда надолго вырываешься из своей рутины, начинаешь замечать, что твой привычный способ жить - только один из возможных. Другие люди по-другому устраивают быт, по-другому относятся к работе, семье, времени и собственным проблемам Какие-то проблемы, которые дома казались сложными и безвыходными, внезапно выглядят вполне решаемыми. Появляются новые мысли и варианты И так получается, что отдых нужен не только для того, чтобы восстановиться, иногда его главная польза в том, чтобы ненадолго выйти за рамки своей жизни и увидеть, что мир устроен гораздо шире 👀 Так что обязательно путешествуйте, смотрите, как живут другие, пробуйте разные места и форматы отдыха Иногда лучший способ разобраться со своей жизнью - на время оказаться совсем в другой 😉

System Design Interview: как не утонуть в задаче «спроектируй YouTube за 50 минут» System Design сильно отличается от лайвкодинга: тебе не дают маленькую задачку, а просят что-то вроде «спроектируй Avito / YouTube на миллион пользователей» 🙄 Здесь вообще нет идеально правильного ответа, интервьюер смотрит на то умеешь ли ты: 🟣 собирать требования и не уходить в дебри 🟣 аргументировать выбор технологий 🟣 доводить схему до вменяемого состояния Поэтому первое, что нужно иметь до собеса - структура Без структуры можно очень быстро закопаться, например, начать с выбора базы, потом внезапно обсуждать Kafka, а после вспомнить про картинки и уйти в CDN. Not good 👎 Лучше придерживаться простой структуры: Собираем требования ⤵️ Не рисуем микросервисы, а понимаем задачу: что такое объявление? есть ли фото? можно ли редактировать, удалять? сколько храним? Плюс фиксируем, что вне скоупа (авторизация, аналитика и тд) Далее нефункциональные требования: сколько пользователей, какой DAU, сколько чтений и записей, сколько лет храним данные, какой RPS и так далее Без этих вопросов выбор технологий очень затрудняется, потому что система с 1000 пользователей и система с 100 млн пользователей - это 2 кардинально разные вещи Переходим к примерным расчетам ⤵️ Нам нужно понять порядок: сколько запросов в секунду, сколько данных в день и сколько места нужно на хранение. Лучше брать удобные числа для вычислений, например, картинка весит не 1.37 MB, а 1- 2 MB. На этом этапе супер точности никто не требует Далее Domain Entities & API ⤵️ Этим этапом фиксируем, с чем вообще работаем: какие есть сущности и как пользователь будет с ними взаимодействовать. Например, для сервиса объявлений это может быть: объявление, пользователь, фото, поиск, лента. Дальше грубым наброском накидываем API: POST /ads GET /ads/{id} GET /feed POST /ads/{id}/photos GET /search DELETE /ads/{id} Каждый шаг поясняем, выбираем REST? Объясняем почему: простой, понятный, широко используется и нагрузки позволяют Рисуем High Level Design ⤵️ Это примерная, верхне уровневая архитектура проектируемой системы: клиент → load balancer → backend → database Схема должна быть законченной, даже если пока абстрактной. Потому что законченная простая схема лучше, чем роскошный кусок архитектуры, который обрывается на середине. Показал пример High Level Design и Low Level Design во вложениях к посту Переходим к Low Level Design - выбираем конкретные технологии ⤵️ ❗️ И очень важное правило: не использовать то, что не понимаешь Лучше выбрать знакомый инструмент, чем накидать модных слов и сидеть с растерянным взглядом на первом уточняющем вопросе И в конце, если успеваем, прогоняем систему по сбоям: Что будет, если база упала? Что будет, если кэш протух? Что если очередь забилась? Какие метрики смотрим? Где бутылочное горлышко? Это поможет показать, что мы реально понимаем то, что делаем Нет четкого чек-листа на то, насколько успешно пройден собес, но в целом есть несколько вещей, которые почти всегда бросаются в глаза: 🟣 Насколько нормально ты собрал требования, не потерял ли половину функционала и проговорил ли границы системы 🟣 Как ты ведёшь интервью: есть ли план, следишь ли за временем, далеко ли уходишь от главной темы 🟣 Как ты принимаешь решения: какие были варианты, какие плюсы и минусы, почему выбрал именно это 🟣 У тебя должна быть законченная история: требования, схема, какие-то решения. Даже если не успел углубиться в детали, важно, чтобы было ощущение, что система “собрана”, а не оборвалась на полуслове 🟣 Понимаешь ли ты, как система будет работать под нагрузкой, что будет при фейлах 🟣 Читаема ли схема или всё выглядит как спутанная гирлянда из стрелок, в которой сложно разобраться. Схема - это твой финальный артефакт Накидай 🔥, если заходят такие посты, а в комментах напиши, какие еще темы разобрать подробнее

Как разобраться в многопоточности ОТ и ДО - ПОЛНЫЙ ROADMAP Главная проблема изучения многопоточки в том, что её вообще непонятно как учить, и обычно всё выглядит так ⤵️ Ты берёшь рандомные статьи, открываешь, читаешь про synchronized, потом видишь отсылку на JMM, открываешь JMM, там happens-before, гуглишь happens-before - и через два часа у тебя 47 вкладок, полная каша в голове и желание закрыть ноут и пойти поспать Чтобы эту проблему решить - я собрал для тебя Базу Знаний Многопоточки. Вот что внутри: 🔵 Видео-урок, который даст понимание ЧТО, В КАКОМ ПОРЯДКЕ и ДО КАКОЙ ГЛУБИНЫ учить 🔵 Полная структура изучения со всеми темами, чтобы идеально подготовиться к собесам на миддла и выше 🔵 Конспект к уроку и 2 дополнительных видео по изучению многопоточности (теория + лайфкодинг) Чтобы получить урок+конспект бесплатно - подписывайся на мой канал и запускай бота, он сразу пришлёт тебе урок сообщением ⬇️

Серебряная пуля и perfect pick У нас часто есть ощущение, что где-то существует правильный ответ Правильная архитектура. Правильный стек. Правильная база данных. Правильный момент, когда идти на собес. Правильный кандидат. Правильный партнер. 😎 Правильное решение, после которого можно наконец-то спокойно действовать Но проблема в том, что в жизни почти никогда нет идеально правильных и неправильных ответов Кажется, что все вокруг знают, как жить, как строить бизнес, как проектировать архитектуру, как выбирать людей и как принимать решения. Но если честно посмотреть на реальность - никто до конца не знает, как «на самом деле правильно» Мы просто принимаем достаточно хорошие решения, чтобы оно работало И это очень видно в разработке. Ты заходишь в старый проект, видишь сервис, который выглядит криво, косо, странно, местами вообще просто насрали в репозиторий А потом выясняется, что сервису 20 лет. Он пережил 5 команд, 3 переписывания, 14 бизнес-поворотов, миграцию на облака и так далее В моменте никто не знал, что этот кусок кода будет жить 10 лет. Просто тогда приняли такое решение. В том контексте оно было нормальным. Потом контекст изменился, система выросла, решение обросло зависимостями, и теперь оно выглядит как «исторически сложилось» Ну да, кривое. Ну да, косое. Но оно работает. И бизнес на этом живет Очень много вещей в мире сделаны не идеально. Они сделаны достаточно хорошо, чтобы выполнять свою функцию. Но мы часто хотим серебряную пулю 💩 Идеальное знание. Идеальное решение. Идеальный выбор. Идеальный момент для действия Это fallacy of perfect pick - ожидание, что где-то есть идеальный выбор, и если мы достаточно долго подумаем, сравним, почитаем, посмотрим ещё одно видео, спросим ещё одного умного человека, то найдём тот самый вариант без риска, боли и последствий Но цена бесконечного выбора часто выше, чем разница между «очень хорошим» и «идеальным» Например, человек думает, когда идти на собес. Ему кажется, что надо ещё подучить многопоточку, потом Spring, потом Kafka, потом System Design, потом ещё чуть-чуть алгоритмы, потом пройти 3 mock interview, потом ещё раз повторить Java Core И вроде все логично. Он готовится 😇 Но после какого-то момента это уже не подготовка, а форма избегания. Потому что пока ты готовишься - ты как будто контролируешь ситуацию. А когда пошёл на собес - рынок уже даёт тебе обратную связь. И она может быть неприятной. То же самое с выбором кандидата. Можно бесконечно искать идеального человека: умного, ответственного, харизматичного, с опытом, без странностей, чтобы сам себя онбордил, сам все делал и желательно еще не хотел денег Но такого может не быть И тогда нормальная стратегия - не искать мифического единорога, а достаточно быстро найти достаточно хорошее решение То же самое с архитектурой. Можно месяцами выбирать между Kafka и RabbitMQ … Короче понятно 🖕 Идеальных решений не существует. Эту старую пословицу «лучшее - враг хорошего» придумали не просто так Можно бесконечно впадать в прокрастинацию и откладывать выбор с мыслью: «Я ещё недостаточно готов», «я сейчас плохо себя чувствую», «через неделю буду знать лучше», «с понедельника начну новую жизнь», «в будущем я наконец-то приму правильное решение» Но в будущем ты тоже не будешь обладать идеальным знанием Идеальный момент не наступит. Серебряная пуля не прилетит. Таблетки «принял и всё стало понятно» не существует Нужно просто продолжать ДЕЛАТЬ НЕИДЕАЛЬНО ☹️ Да, это пиздец как больно. Больно видеть и думать «я мог бы лучше», «а можно было бы еще это и это», «а что если». Но надо сделать не идеально, местами криво, но достаточно нормально, чтобы оно работало. Это лучше, чем откладывать и не делать вообще

Пока работаешь на одном проекте, очень быстро привыкаешь к его ограничениям Какие-то таски начинаешь решать на автомате, потому что похожие вещи писал десятки раз: код работает → фичи выкатываются → з/п на карту падает Из-за этого перестаешь сталкиваться с задачами, где нужно думать над эффективностью решения, а не просто сделать так, чтобы оно работало. 😆 Как раз этим летом появился движ, где такую среду можно получить — CodeRun Summer Challenge Главная особенность челленджа в том, что здесь в зачёт идёт performance engineering - чем быстрее и эффективнее работает решение, тем выше ты поднимаешься в лидерборде. По сути, это тот же подход, который используют на тех.собесах в крупных компаниях Что по формату: • 15 задач от легких к хардовым • новые задачи открываются волнами по 5 штук каждые 5 дней • общий зачёт и отдельные лидерборды по каждому языку Стартовать можно в любой день до 17 июля, так что если ты начинающий Java-разработчик, то это идеальный полигон, чтобы набить руку, а если опытный - хороший способ проверить, не заржавели ли скиллы 🤔 Призы: • топ-1 по каждому языку получает мерч-пак CodeRun • топ-3 общего зачёта - коллекционный лего-набор • топ-200 общего зачёта - скип отборочного контеста и пробное интервью По сути, это еще одна возможность потренироваться на задачах, где важно не просто получить правильный ответ, а найти действительно эффективное решение. А если попадешь в топ - можно еще и попробовать свои силы в Яндексе. Поэтому участвуем тут. Накидай 🔥, если интересно, и напиши в комментах, какие задачи показались интересными, мб разберу какие-нить в видосах

Ну что, часть из вас оказалась права: я записал подкаст с крутейшим Владимиром Балуном - бывшим тимлидом Яндекса и основателем школы Balun.Courses 😎 Когда все вокруг кричат, что нейросети скоро заменят программистов, возникает вопрос: Почему тогда сильные разработчики до сих пор стоят так дорого? Поговорили не про очередные промпты и «как использовать ChatGPT», а про вещи, которые действительно определяют карьеру разработчика: 🟣почему фундаментальные знания становятся только ценнее с развитием ИИ 🟣 что на самом деле происходит с IT-образованием 🟣 зачем сегодня нужны преподаватели, если ответы можно получить за секунду 🟣стоит ли сейчас вообще входить в IT 🟣какие навыки останутся востребованными через 5–10 лет Получилось довольно легко и я бы сказал, воодушевляюще 🥴 Если переживаешь, что же будет с индустрией в ближайшем будущем 😱, определенно, будет полезно Смотреть на YouTube: youtube.com/watch?v=XlGOWZoZAOo

И сигну от меня получаааеет: @Vonaski 😎

Самые сильные люди, с которыми мне доводилось работать, почти никогда не делают только то, что написано в задаче🙃 И это одна из самых ценных вещей в работе - когда человек делает чуть больше, чем его просили Но не в формате переработок, ночных созвонов и прочего трудового героизма. А просто когда ему становится интересно докрутить задачу дальше 😎 Буквально недавно поставил дизайнеру вполне конкретную задачу - сделать первый экран сайта. Даже в голове уже представлял, что примерно хочу увидеть на выходе. Через какое-то время он присылает результат, и я понимаю, что он сделал не совсем то, что я ожидал. В хорошем смысле Потому что помимо самой то задачи, он докрутил идею ещё на несколько шагов вперёд. Сам придумал концепцию, сам её реализовал, добавил детали, которые я не описывал и в итоге результат получился сильнее, чем моя первоначальная задумка И я поймал себя на мысли, что практически всё, что по-настоящему изменило мою жизнь, происходило похожим образом 🙂 Когда я снимал видосы на YouTube, мог просто сделать очередное видео "Как написать ТГ-бот на Java", выложить его и пойти дальше. Но самые большие результаты всегда приходили после тех видео, в которые хотелось вложить чуть больше, чем требовалось. Или с обучением, когда можно было ограничиться поверхностным разбором темы, а я сидел и ещё несколько часов копался в материалах, искал примеры, переписывал объяснение, потому что хотелось сделать лучше Для этого даже есть хорошее слово - оверперформ Не в корпоративном смысле, где тебя пытаются заставить работать за троих. А в нормальном, человеческом, когда дали задачу на один уровень, а ты посмотрел на неё на два уровня глубже И именно такие люди потом чаще остальных оказываются в самых интересных проектах с интересными зарплатами. Просто потому, что они регулярно делают намного больше, чем от них ожидали

Почему retry может положить систему? 😔 В какой-то момент почти любой сервис начинает ловить таймауты к соседям. Где-то сеть моргнула, где-то зависла база, где-то просто не повезло. Первая реакция обычно максимально логичная: добавим пару ретраев и станет стабильнее Не ответил на запрос - попробуем ещё раз. Если всё идемпотентно, то вообще без риска. Но как только одному из сервисов становится реально плохо, вся эта история начинает работать в обратную сторону 👀 Представь обычную цепочку: Order Service ходит в Payment Service. Платёжка начала тормозить, не умерла, но отвечает по 3–5 секунд, а потом вообще перестаёт. Order такой: «Окей, не ответил - попробую ещё раз, не получится, то повторю снова» И так делает не один запрос, а сразу вся система. В этот момент ретраи превращаются из «страховки» в «давай добьём всё окончательно» Нагрузка растёт → сервис отвечает ещё медленнее → растёт количество таймаутов → таймауты рождают новые ретраи 🫢 Классический замкнутый круг, где система сама себе ухудшает состояние. Обычно в этот момент вспоминают про exponential backoff. Типа не долбим сразу, а ждём: сначала секунду, потом две, потом четыре. Плюс добавляем jitter, чтобы все клиенты не проснулись одновременно и не прилетели в одну и ту же миллисекунду Это действительно лучше. Но есть одна неприятная деталь, о которой редко думают: Backoff не уменьшает нагрузку, он её откладывает Если сервис быстро восстановился - всё красиво, запросы разъехались по времени и он успел их переварить. Но если даунтайм длинный, то все эти отложенные ретраи всё равно прилетят. Просто чуть позже и более плотной волной И вот ты уже в ситуации, где баг пофиксили, релиз откатили, а система всё равно не оживает 😐 Потому что на неё одновременно падает обычный трафик, накопленные ретраи и ещё пользователи, которые сами жмут «повторить». Сервис снова захлёбывается, ловит таймауты, генерит новые ретраи - и поехали по второму кругу 🤔 Это то самое состояние, когда триггер уже убрали, а система всё равно не может восстановиться, потому что сама себя держит под нагрузкой. В этот момент приходит довольно неприятное осознание: ретраи - это не всегда про надёжность. Иногда это про то, как замедлить восстановление в несколько раз 🟣И один из нормальных подходов - retry budget Идея простая: ретраи разрешены, но ограничены, например, не больше 10% от успешных запросов. Пока сервис отвечает нормально, бюджет есть, можно ретраить флапы. Как только он начинает сыпаться, успешных ответов становится мало, бюджет быстро заканчивается, и ты автоматически перестаёшь накидывать сверху дополнительную нагрузку ❗️Иногда это дополняют retry circuit breaker’ом - если процент ошибок слишком высокий, ретраи временно вырубаются вообще. Потому что в этот момент лучше быстро получить ошибку, чем ещё сильнее убить сервис и затянуть восстановление. И тут важно понять, retry - это нагрузка, которую ты берёшь в долг у системы. Пока всё хорошо - это почти незаметно и даже полезно. Когда всё плохо - этот долг внезапно приходит с процентами. 🆗 Поэтому хороший retry - это всегда про ограничения, контроль и понимание, в каком состоянии находится сервис. ❌ А плохой retry - это когда система уже лежит, а ты продолжаешь верить, что следующая попытка точно сработает Накидай 🔥, если было полезно 😎

Самая дорогая ошибка разработчика - перепутать комфорт с ростом Я уже рассказывал о знакомом из Ижевска, перед которым стоял выбор его дальнейшей карьеры. В комментах у многих начали расходиться мнения, что ему стоит лучше сделать, и это натолкнуло меня на определенные мысли Очень многие разработчики думают, что уперлись в потолок потому, что им не хватает мотивации, дисциплины или они мало изучают Я замечал это и на себе, и на своём окружении. Человек может быть сильным разработчиком, работать по 8 часов в день, закрывать задачи, получать хорошие отзывы. Но при этом через год обнаруживает, что особо-то никуда не сдвинулся 🙄 Самый простой способ это проверить - попробовать вспомнить, что нового появилось в твоей работе за последний год Не новую версию библиотеки или фикс очередного бага, а именно что-то новое для себя: • новая зона ответственности • новое архитектурное решение • сложная проблема, над которой пришлось поломать голову Если таких вещей не было - это повод задуматься Когда-то я заметил, что многие задачи начал делать практически на автомате Получаешь таску → понимаешь, как решать → пишешь код → закрываешь тикет С одной стороны это приятно и работается спокойно, а с другой - именно в этот момент рост часто начинает замедляться Когда растешь как разработчик, довольно часто чувствуешь себя немного глупым, потому что постоянно сталкиваешься с тем, чего еще не знаешь: незнакомые сервисы, новые проблемы в проде, новая зона ответственности и так далее Это не самые комфортные периоды работы, зато именно после них обычно понимаешь, что скиллы стали круче Мне кажется, одни из самых полезных вопросов, которые можно себе периодически задавать это что-то вроде: • Что я спроектировал за последний год? • На какие решения я реально повлиял? • Чему научился, чего не умел раньше? Если трезво отвечать на эти вопросы, то становится понятно, что зачастую текущий проект уже отдал тебе все, что мог дать. И тут только 2 пути: • надеяться на то, что кто-то напишет и предложит проект покруче • самому искать возможности для роста И второй, естессно, правдоподобней и куда быстрее Накидай 🔥, если согласен и как обстоят дела с твоим потолком - уже достиг его или есть куда расти?