tgindex
✨Уютный микросервис✨

✨Уютный микросервис✨

Статистика

В этом канале я буду делится различными знаниями в построении распределенных систем и микросервисов. Буду вкидывать разные темы, сможем их обсуждать, делится своим опытом и так далее. Меня зовут Олег и я старший разработчик в BigTech.

Последний пост
6 апр.
Последнее чтение
00:29
Постов за неделю
0
Всего постов
20
Тип
открытый
Язык
русский
Категория
Технологии
В каталоге с
12 авг.
Подписчики
1 150
0 за 4 дн.
Сутки
0
0,00%
Неделя
 
Месяц
 
Просмотров на пост
1 917
20 постов
Вовлечённость
166,7%
к подписчикам
Постов в день
0,0
всего 20
Упоминаний
0
каналов
Охват размещения
оценка
1/24сутки в ленте
1/48двое суток
1/72трое суток

Оценка по просмотрам недавних постов: пост набирает почти всё за первые сутки.

Посты

  • 6 апр.716113

    Микросервисы на Go 3.0 Есть анонс, который у меня бывает очень редко, а именно раз в полгода. Я открыл продажи на новый поток курса по микросервисам 🥳 Курс подойдёт если ты: — Переходишь на Go с Python, PHP, JavaScript, Java, .NET или другого языка и хочешь быстро разобраться со всей внутрянкой построения микросервисов — Уже работаешь с Go, но хочешь систематизировать знания: освоить архитектуру, лучшие практики, и поднять квалификацию — Уходишь от монолита на работе и хочешь строить микросервисы так как это делают в крупных компаниях, чтобы подтянуть грейд и зарплату Технологии которые изучим и применим в итоговом проекте: 🔍gRPC + HTTP через OpenAPI 🔍PostgreSQL с транзакциями, блокировками и Transaction Manager 🔍Unit-тесты и интеграционные тесты 🔍Kafka с батчингом и outbox-паттерном 🔍Redis с хранением сессий и распределенными блокировками 🔍Circuit Breaker, Retry, распределённый Rate Limiter 🔍Полный мониторинг: логи, трейсы, метрики (Prometheus, Grafana, OpenTelemetry, Jaeger, Kibana) 🔍Чистая архитектура и интеграция в неё всех упомянутых технологий 🔍Nginx для роутинга, балансировки и нагрузочного тестирования Главный принцип курса, максимум практики, приближенной к продакшену. Я специально замутил проект так, чтобы после курса ты открывал вакансию и понимал что знаешь о чём там написано, не плыл на собесе когда спрашивают про Kafka или distributed tracing, и мог куски кода утащить прямо в свой рабочий проект. При этом я стараюсь не душить теорией. Берём технологию, даю минимум базы и сразу идём практиковаться. А дальше по ходу дела докидываю теорию и она ложится гораздо лучше, потому что ты сразу суёшь её в код. И так технология за технологией. Продажи курса открыты до конца недели, следующий поток будет только через 6 месяцев. Почитать подробнее про программу и залететь на курс можно на сайте - https://clck.ru/3SxQk2 P.S. Если будут любые вопросы касательно курса, технологий внутри, что-то уточнить, проблем с оплатой и прочее, то пиши в поддержку — https://t.me/olezhek28_support

  • Как писать PostgreSQL-код в Go так, чтобы его не хотелось сжечь на код-ревью? Если ты работаешь с Go, то, скорее всего, SQL-запросы ты уже писал) Но дальше обычно начинается самое интересное: - Как правильно работать с PostgreSQL именно в Go? - Что брать в проекте: database/sql, pgx или pgxpool? - Когда нормально писать голый SQL, а когда удобнее builder? - Как делать миграции? - Как не ловить SQL-инъекции, проблемы с NULL, утечки соединений и прочие радости, которые обычно всплывают уже не в учебном примере, а в живом сервисе? И главное: как всё это выглядит в реальном production-подходе в нормальных командах? Чтобы это всё разобрать, сегодня я провожу открытый урок: PostgreSQL в Go: подключение, запросы, миграции и SQL-инъекции На уроке будет практика по базе и best practices работы с PostgreSQL в Go: - поднимем PostgreSQL через docker compose - сравним database/sql, pgx и pgxpool - разберёмся, когда нужен пул соединений и почему это важно - посмотрим запросы через голый SQL и через squirrel - разберём миграции через goose - отдельно пройдёмся по SQL-инъекциям, NULL-полям и утечкам ресурсов Ну и на уроке расскажу детали о новом потоке курса по микросервисам. Напомню, что в курсе мы максимально на практике работаем с: PostgreSQL, Kafka, Redis, gRPC, Docker, полным стеком observability через Grafana, Prometheus и OpenTelemetry. Посмотреть подробную программу курса можно здесь - тык И прям в эфире стартанем продажи курса. Среди купивших ещё и подарки розыграем))) Когда урок? Сегодня в 19:00 по МСК Где пройдёт? Ссылка на урок будет в канале по микросервисам: Залететь в канал по микросервисам Залететь в канал по микросервисам Всех жду на уроке, записи не будет 👀

  • 4 мар.1 07961

    У меня куча рабочих процессов которые раньше жрали по полдня. Сейчас я нажимаю одну кнопку Год назад начал пихать AI-агентов во всё подряд. Код, контент, аналитика, публикации - много чего уже перестроил. Но ещё больше предстоит) И я задумался - а ведь об этом интересно рассказывать отдельно Короч завёл новый канал) Там буду показывать как реально использую AI каждый день: 🔍 кейсы из продакшена со скриншотами 🔍 фейлы и косяки - когда нейронка делает дичь 🔍 инструменты и пайплайны - что работает, что дропнул 🔍 мысли о том куда катится разработка с AI Любая новость - только через мой опыт. Копипаст чейнджлогов и коллекций промтов не будет А если тебе интересно как я угораю по нейронкам залетай ЗАЛЕТЕТЬ В КАНАЛ ПРО AI ЗАЛЕТЕТЬ В КАНАЛ ПРО AI ЗАЛЕТЕТЬ В КАНАЛ ПРО AI Выложил туда уже поджигающий жопы пост ахаха

  • Как прокачаться в микросервисах? На прошлой неделе я анонсировал новый поток курса «Микросервисы, как в BigTech 2.0», где за 8 недель ты строишь полноценную систему из 6 микросервисов для обслуживания завода по производству космических кораблей — с взаимодействием по HTTP, gRPC и Kafka, полным покрытием тестами и настроенным мониторингом. Технологии, с которыми ты поработаешь: 🔍gRPC + HTTP через OpenAPI 🔍PostgreSQL + Redis + теперь еще и MongoDB 🔍Unit-тесты и e2e-тесты 🔍Kafka для событийно-ориентированной архитектуры 🔍Полный мониторинг: логи, трейсы, метрики, алерты (Prometheus, Grafana, Elasticsearch, Kibana, Jager, OpenTelemetry) 🔍Чистая архитектура и интеграция в неё всех упомянутых технологий 🔍Интеграция с Telegram для отправки уведомлений 🔍Envoy Gateway для роутинга и аутентификации всего входящего трафика Главный принцип курса — максимум практики, приближенной к продакшену. Я специально замутил проект так, чтобы ты мог куски кода прямо в свой рабочий проект утащить. Курс идеально подойдёт, если ты: — Переходишь на Go с Python, PHP, JavaScript, Java, .NET или другого языка и хочешь быстро разобраться со всей внутрянкой построения микросервисов — Уже работаешь с Go, но хочешь систематизировать знания: освоить архитектуру, микросервисы, лучшие практики и поднять свою квалификацию — Уходишь от монолита на работе и хочешь научиться строить микросервисы так, как это делают в крупных компаниях, чтобы подтянуть грейд и зарплату Летний поток прошёл на ура: 100+ учеников и куча реальных отзывов, которые можешь почитать здесь На курсе осталось меньше четверти мест и продажи заканчиваются уже завтра. Поэтому если хотел жестко прокачаться в микросервисах сейчас самое время ⬇ ЗАЛЕТЕТЬ НА КУРС

  • Взлом алго собеса Разложили с Вовой Балуном за алгосы) Чисто пару методов за вечер освой и не еби себе голову этими алгосами больше)) Для многих собесов хватит этого СМОТРЕТЬ ВИДЕО

  • 4 жестких задачи с Go собесов У меня на ютубе вышел новый ролик с Женей айти красавчиком. Залетайте посмотреть, как мы валим друг друга задачками с собесов. СМОТРЕТЬ ВИДЕО

  • Советчик хуев, или Как я сломал жизнь ученику Ты никому не нужен — вот так я хочу сказать всем, кто ждёт, что их кто-то найдёт, схантит, сам потащит на собес, сам поможет разобраться и так далее. Люди с руками, мозгами, опытом сидят и ждут, что «им позвонят», «им дадут шанс», «их повысят». Если бы я так сидел и тоже ждал, то неиронично жил бы в картинках из своей рекламы) Ну хотя бы супа поел)) Я так недавно помогал чуваку с устройством на работу. Дал ему базовые советы: как резюме написать, какие проблемы исправить. У него там всё грустно было — последнее место работы - несколько месяцев почти год назад (округли до года и поставь, что ты ещё работаешь), пустые формулировки (из разряда «работу работал»), вообще непонятно, что он делал. Проходит время, чувак пишет: «Я сделал всё, как ты сказал, и меня вообще перестали звать на собесы». Думаю, что за фигня? Скидывает «исправленное» резюме — на английском. Говорю: «А зачем на англиском? Повыпендриваться?». Скидывает — такое же слабое, как раньше было. Всё те же 4 месяца висят. Говорю: «Округли до года». Он: «Не могу, в августе устроился — как мне в будущее крутить?» Совет первый! Запомните, дату начала работы сдвигать нельзя!Дальше спрашиваю: «А что ты делаешь вообще, кроме резюме?» — «Откликаюсь». — «Сколько?» — «Ну, 5-6 откликов в НЕДЕЛЮ». Я в ахуе. Говорю: «Чувак, а что если конверсия в собесы 2%? Тебе понадобится 50 откликов для первого собеса. Твоим темпом ты будешь 10 недель к этому идти». — «Ну что надо?» — «Как минимум 50 откликов в день». — «А нет столько вакансий». Совет второй! Откликайтесь как можно реже, чтобы HR подумали, что вы очень важный человек, и захотели бы вас пригласить!Забиваю в поиск «golang» в хедхантере — больше тысячи вакансий. Прошу показать, как он откликается. Смотрю — листает такой: «Сюда я уже откликнулся, а тут сеньоры, это пропускаем, тут тоже сеньоры, пропускаем, тут город другой, тут ещё что-то не так». — «Бля, ну ты чё? Нахрена пропускаешь?» — «Ну серьёзно же, я джун-мидл». Объясняю, что у них может быть вакансия на мидла, просто не опубликованная. Или на сеньора пройдёшь. Хер его знает, какие у них требования. Зачем за них то решать? Совет третий! Откликайтесь только на те вакансии, которые на 100%, буква в букву с вами совпадают, и только там, где вы пипец как работать хотите! Вот такие дела. Человек ждёт, что мир к нему сам придёт. А когда не приходит — винит ситуацию на рынке, экономику. Но не готов потратить час в день на нормальные отклики. Понятное дело, что и вакансии фейковые бывают, и найм слабее стал, но я от самого подхода сгорел. Говорю делай так, он отвечает что так и делал, а потом оказывается что делал совсем не так. Поэтому, если ты тоже сидишь и ждёшь — вставай и делай. Да, хотелось бы, чтобы рынок найма был по-другому устроен, но как есть, другого идеального момента не будет. Накидайте в комменты ещё вредных советов, которые гарантированно дадут оффер!

  • 25 мая 2025 г.1 6921816из olezhek28go

    Docker для Начинающих за 1 Час – Полный Курс с Практикой В этом видео за 1 час ты с нуля освоишь Docker на практике. Этот гайд поможет с нуля собрать полностью рабочее окружение для практической разработки. Всё покажу на экране и начнем без установок, прямо в браузере. СМОТРЕТЬ ВИДЕО

  • 4 мар. 2025 г.2 4241327из olezhek28go

    Новая map в Golang - как она устроена под капотом? Сегодня решил вас порадовать и поделиться контентом из Гофер фермы. Как никак вопрос актуальный для собесов и возможно эти знания скоро пригодятся. В этом ролике я напомнил как мапа была устроена раньше и в чём были её слабые места. А после этого показал что поменяли в новой версии, чтобы исправить былые недостатки. Ролик выложил на отдельный канал, чтобы не смешивать с основным контентом. Поэтому подписывайтесь, чтобы новые ролики не упустить и лайк поставить не забудьте, будет полезно для продвижения нового канала. Уже встречали вопросы по новой мапе на собесах? СМОТРЕТЬ ВИДЕО

  • Как я потратил полгода на фигню Время историй) Сегодня очередная порция старческих воспоминаний, о том где я свернул не туда)) Я только начинал свой путь в айти. Был молодой, горячий, хотел доказать всем, что я чего-то стою, ну или как минимум хотел, чтоб не уволили после испыталки хаха Дали мне как-то задачу: сделать инсталляционный пакет для ПО комплекса, который палит нарушения на перекрестках. Задача довольно обычная, но у меня родился к ней сильный интерес. Я ударился в ресерч, нашёл варианты реализации и продавил их использование. Я чувствовал как делаю что-то полезное, что сократит другим людям муки установки ПО. До моей утилиты вся установка выглядела, как 50 страниц текста различных команд, которые надо выполнить в четкой последовательности. Как говорится: "одна ошибка и ты ошибся") Я хз как я там ресерчил, но для решения проблемы я откопал какую-то малоизвестную херню под названием WIX Toolset. Писать там надо было на шарпе + какой-то диалект xml. Ладно бы я поигрался с этим недели 2-3 и замутил инсталятор, но меня же пробил интерес. Я начал накручивать всё новые и новые фичи, и никто меня не останавливал. Прошло полгода, и инсталятор был готов. Помимо необходимых функций, в него включался парад не особо нужных украшательств. Конечно я жестко кайфанул, что довёл разработку мини-продукта с 0 до внедрения, но потом пришло горькое осознание. Прикиньте, я спустил полгода на какую-то херню, которую нигде не юзают. Держу пари вы и не слышали про этот Wix Toolset никогда. Ниразу мне это хрень хоть отделенно больше не была нужна по жизни. Да ещё и поддерживать тот код было очень сложно. Короч не технология, а как говорил классик: "пчёлы, мёд, говно и гвозди". И на это я потратил кусок жизни. У меня чуваки на курсе и менторстве за полгода жизнь себе поменять успевают. Гошку осваивают и ЗПшку поднимают. А я блять за те полгода успел узнать как дерьмово WIXToolset чистит реестр в винде. Какое-то чувство упощенной возможности одолевало мной, когда я это осознал(( Вместо этого я мог бы взять Docker. И задачу бы решил, и востребованный навык освоил. Да и самое решение было бы куда технологичнее. А так я зарылся в старый, никому не нужный инструмент, который больше нигде и никогда не пригодился. А чё ж я не взял докер? Да потому что я в душе не знал о его существовании тогда и подсказать было не кому. Короч, лучше перед тем как ввязываться в долгую разработку хорошенько пересерчить этот вопрос и пообщаться с людьми, которые могут дать совет. Столько времени сможете сэкономить и заполнить его куда более полезным занятием. А вы когда-нить вбухивали кучу времени на освоение странных технологий, которые никогда больше не юзали?

  • Выдал всю базу о собеседованиях на Golang Неструктурированно и бессистемно готовиться к собеседованиям — это как ссать против ветра. Вроде облегчился, но есть нюанс) Можно часами сидеть и смотреть рандомные записи слитых собесов, надеясь, что чувак всё решил правильно, а не интервьюеры решили тактично промолчать на фейлы. Ещё можно посмотреть leetcode, neetcode и easyoffer, охереть от количества никак не структурированных задач, сойти с ума и пойти на PascalABC писать. Поэтому я решил помочь вам и сделал курс по подготовке к собеседованиям на Golang. Курс стал результатом анализа десятков собеседований, сотен задач и огромного количества часов личного опыта. Что внутри? — 33 популярные задачи, которые частенько встречаются на реальных собесах — 7 разделов — от простого к сложному. Ты не просто выучишь решения, а разберёшь все нюансы и ловушки, на которых тебя попытаются поймать — Подробные объяснения: не только "как решить задачу", но и "почему именно так". Я покажу, что важно для интервьюера, и как отвечать так, чтобы у него не осталось вопросов. Кроме того, ты получишь: — Чатик с ребятами, кто тоже хочет вкачать собесо-скил. С ними можно будет обсуждать задачи, делиться опытом и устраивать тестовые собесы. — Структурированный подход, который снимает хаос в подготовке. От простого к сложному, с акцентом на то, что действительно важно. Почему это работает? Этот курс — не набор рандомных задач. Это скомпонованный по темам материал, который охватывает важные для собеса аспекты языка в виде хитрых задачек. Зарешал задачки с курса, получил коробку денег (ну я ж не поэт, я программист) Это твоя возможность подготовиться быстро, эффективно, и с новыми знакомствами. Я считаю, лучший подарок на Новый год! Там кстати даже в подарок курс купить можно)) Всё, мне надоело уговаривать вас получить то, что вам же принесёт больше уверенности, деняк и красивых женщин рядом. Ладно, про женщин перебор был))) Переходите по ссылке, читайте красивый лендинг и залетайте на курс https://olezhek28.courses/golang-interview Ставь 💯 если побежал снимать деньги со сберкнижки и покупать курс или уже купил!) P.S. Кот, кстати одобряет!

  • Почему опытные разработчики проваливают собеседования? (и как это исправить) Когда я залетал в айтишку, то считал самым главным умение кодить. Ну ещё проектировать системы, писать алгоритмы и разбираться во всякой умной теории. Оказалось, что львиная доля успеха крутится в умении общаться с людьми, в том числе и на собесах. Люди эти не всегда приятные, задают странные вопросы, дают абсурдные задачи. Волей не волей складывается ощущение, что я один такой дурачок и не понял правил игры, хотя их раздавали на входе. Каждому же знакома ситуация, когда на собесах спрашивают какую-то рандомную херню, которая никогда на работе не пригодится? Да ладно на работе, даже на кухне этим не повы***ваться. А эти дебильные задачи - у меня от них жопа горела. В реальной жизни за такой код руки отрывают, а тут давай скажи, что код выведет. Я не понимал на кой хрен спрашивать одно, а на работе просить сделать совсем другое. Это как токаря вместо вытачивания детали начать спрашивать вес гаечных ключей. Тоже про инструменты с деталями, но смысла в этих вопросах ноль. После такого осознания было два варианта. Первый - гореть дальше, сетовать на тупой найм и вообще рассказывать о том, какой говнистый этот ваш капитализм. Второй - прохавать правила игры, выйти победителем и всё равно говнить капитализм ахаха После своего грандиозного обсера на собесе я решил топать по второму пути. Потому что пока я страдал от неудачи мой кореш набил руку на задачках и увеличил ЗП на 100к, не упарываясь в самокопания. И я точно не был тупее его, но просирал время, хотя мог бы сделать также. Конечно меня это простимулировало лучше всяких психологов. Прикол тут в том, что не нужно решать миллиард задач и учить тома теории. Здесь работает принцип 80/20. Прорешав самые популярные задачи, ты существенно увеличиваешь свои шансы на успех, главное принцип понять. Это правило работает независимо от уровня компании — будь то небольшая фирма или крупный BigTech, вопросы на собеседованиях часто однотипные, ровно как и задачи. Поэтому нарешиваем, осваиваем базу и получаем максимум результата из минимума усилий. Легко не будет, но страдать придётся куда меньше. Остается главный вопрос: "где раздобыть красиво собранный набор типовых задач, разбитых по темам, да ещё и с шикарными видео решениями?". И тут надо ж так случилось, я знаю ответ. Охереть же совпадение? Завтра расскажу, как порешать эту проблему. Если вы, конечно, хотите вкачать собес-скилы и найти местечко поуютнее) Ставь 🧑‍💻 если хочешь! Ну шо, уже все догадались что будет дальше?)))

  • Жизнь дала мне под дых Получив сочный офер на 250к, я добился повышения на работе. Ещё робко, но уже с удовольствием, я налил себе банановый смузи и сел изучать рынок найма дальше. Я наткнулся на Weekend Offer от одной популярной барахолки, где ещё можно снять хату и пробить тачку. Для меня это был новый формат. Мне казалось это весело, всего за пару дней намутить себе оффер. В этот раз я рвался не за большими деньгами, а скорее за признанием. Мне вновь хотелось услышать предложение о работе, и тем самым получить удовольствие от того, что я хорош и преодолел все препятствия. Перед собесом я был более-менее спокоен и уверен в себе из-за прошлого успеха, но меня ждала неожиданность. Я попал туда, где не спрашивали теорию в формате вопрос-ответ, как раньше. Они просто дали две задачи. Это были не алгосы, а задания на знание гошки и умения на ней писать. Конечно, без канкаренси в этих задачах не обошлось. В то время я не то что бы каждый день писал конкурентный код и, конечно, пососал. Это был жесткий удар по самолюбию. С уверенности, что пройду любой собес, я свалился в состояние "еб*** я лох". В этот момент я подумал, что, возможно, все мои предыдущие успехи на собеседованиях были просто удачей. А я этого всего не достоин. Мало того, что ничего не решил, так ещё и молчал половину времени, что тоже создало не самое хорошее впечатление. По итогу я пришёл к выводам: 1. Нужно активно вести диалог с собеседующим. Спрашивать вводные у задачи. Сверять путь, по которому пошёл решать. Думать вслух, чтобы интервьюер понимал, что ты анализируешь задание, а не тупо сидишь с бессмысленным взглядом. 2. Нужно решать типовые задачи. В них есть свои приколы и ловушки, которые в реальной жизни могут обходить тебя стороной, а тут докопаются до всего. А какие неожиданности на собесах бывали у вас?

  • Как я преисполнился в собесах Неизвестность от гошных собесов начала пропадать, когда меня позвали на публичное мок-интервью. Я хотел узнать цену, а меня позвали на ютуб в открытую отвечать на вопросы умного дяди. Было страшно, потому что я не знал, что будут спрашивать. И очень не хотелось облажаться, да ещё и публично( Интернет же всё помнит, потом будут угорать. При это хотелось себя испытать. Я ещё и на успех надеялся, а там уже тачки, деньги, слава ахахаха Я почитал теоретической базы и двинул на эфир. По моим ощущениям на гошные вопросы я ответил хорошо, и даже эфир на 100+ человек не смутил. И тут я в себя поверил)) Тревога снизилась, уверенность выросла, и я подумал, что могу и на настоящий собес заглянуть. Следом я съездил в Иваново на подкаст "Мы обречены" и совсем важной птицей себя почувствовал. Был уверен, что теперь успех неминуемо настигнет меня. Спустя неделю попал на собес в зелёный облачный провайдер. Собес шёл часа полтора, вопросы были стандартные. Немного спросили за кафку и всё. Спустя 10 минут после собеса мне звонит рекрутер и говорит: "го скорее к нам, даём 250к на руки". Я охренел от такой скорости, а тем более суммы, потому что на тот момент моя ЗП была 140к. Вывод, который я сделал из моего успеха: Важно уметь грамотно молоть языком и подробно отвечать на поставленный вопрос. А умение это мне помогло развить пересказывание корешам всего того, что я начитался по гошной теории. Когда пересказываешь, теория лучше в голове оседает. После такой безумной удачи я подумал, что способен собрать все оферы мира на ещё большую кучу денег. Но жизнь готовила мне удар под дых... А у вас бывали такие моменты, когда жестко прёт на собесах, офер за офером летит в руки или раз на раз не приходится?

  • Что нужно знать для собесов? Когда я устраивался в Озон, код был чище, печенье в офисе вкуснее, а ТындексТеоретикус не был крестным отцом половины джунов в РФ. До собеса туда я сидел в лабе при Политехе, кодил, закрывал таски и думал, что умею программировать. Как вдруг зовут на собес. Я вообще был без понятия, что на нём спросят. До этого у меня был всего один собес, где мы смотрели видосы с моего ютуб-канала и угорали. На нервяке я начал листать какие-то книги и смотреть курсы невпопад. Инфы в голову лилась тонна, но толку ноль, потому что читал я хрен пойми что, и отношение к реальности эта инфа имела слабое. И вот, вдогонку к стрессу, я ещё и усталость словил перед собесом( Спустя время я осознал, что развитие из такого тревожного состояния - это полная херня. Ты просто пытаешься тревогу буквами из книг унять, но только больше её раскачиваешь и устаешь, а вера в себя снижается. Причина такой нервозности одна - страх неизвестности. Я постоянно проигрывал в голове разные сценарии, и, конечно, концентрировался на самых фиговых. Даже нормально сериал вечером посмотреть не мог. В один из вечеров переизбыток тревоги на слезы даже разъ***л. Самое ужасное в этой тревоге то, что даже если ты будешь знать ответ на вопрос, то из-за обилия эмоций тебя может переклинить, и ничего внятного ответить не сможешь. Поэтому я думаю, что самое главное в подготовке к собесам - развеять эту неопределенность. Выяснить темы, которые важны, и сфокусироваться на них, а не пытаться объять все знания мира. Что обычно спрашивают на гошных собесах? (я только про гошную часть, а не про весь бэк) - Какую-нить дрочь на слайсах с ловушками - Могут докопаться до работы строк и их устройстве - Куда без интерфейсов?! А там ведь тоже можно подловить на тонкостях - Мапки. Как говорил один из моих тимлидов: "Дайте мне мапку и я решу любую бизнес задачу"))) - И конечно канкаренси. Тут тебя и за горутины притянут и за всякие паттерны, ну и куда без "очень важного" знания о работе планировщика Разумеется, только теоретическими вопросами всё не заканчивается. Частенько дают разные задачки с кодом, где эти темы и прощупывают. А что у вас на собесах спрашивали? И какой уровень духоты вы встречали?

  • Твой опыт не влияет на зарплату Очень часто я слышу о том, что люди в поте лица задротят алгоритмы и другие hard скилы. Они думают, что чем больше они шарят в технологиях, тем выше их ЗПшка. Эту мантру говорят джунам, которые хотят залететь в айти. Позадроть литкод пару лет, сделай 4 pet-проекта, пройди 3 бесплатных стажировки. И только после этого ты имеешь морально право искать работу. Говорят это мидлам и сеньорами, когда не хотят повышать зарплату и грейд. У тебя же небольшой опыт! Потрудись ещё годик за копейки и тогда точно повысим. Всё это сказки, которые рассказывают те, кому выгодно сэкономить на нас деньги! Конечно, хочется просто писать код и не вникать в социальные процессы, НО реальность диктует иные правила. Если желаешь расти по бабкам и находить интересные проекты, выход один - нужно постоянно мониторить рынок и ходить по собесам. Думаешь сидеть в одной компании и старательно делать таски? Итог один - получишь прибавку процентов 10 за год, даже если поразишь всех на performance review. На собесах же ты имеешь шанс кратно увеличить свой доход за выполнение тех же задач. Так было и у меня, когда я переходил в Озон, и когда из него уходил. Правда мой путь до оферов не был столь прост, как в этих строках. Я проваливал собесы, нервничал из-за неопределенности, офигевал от странных задач, и, конечно, тупил на торгах за зарплату. Получив уйму пощечин от жизни, я осознал правила игры, и впоследствии собесы из проблемы превратились в милые посиделки. А как это было расскажу в следующих постах. А какие у вас провалы бывали на собесах?

  • Жопа горит, а сервис лежит Как-то раз в чатик нашего проекта написали сообщение о том, что одна из ручек сервиса не работает, просто отдает 500ю ошибку. Я полез разбираться и обнаружил, что она стабильно имеет 100 запросов в секунду, которые отваливаются с ошибкой. Сижу и думаю, какого хрена я про это узнал спустя месяц, еще и от клиентов?! Такие ситуции нужно ловить сразу, иначе косяки выплывают наружу, и пользователи грустят. А где их грусть, там и негодование начальника ахаха. Так что надо как-то следить за состоянием сервиса. И дело не только в том, что хочется запалить момент, когда он начнёт просасывать. Хочется иметь больше информации о моменте, когда посыпались ошибки, иначе придётся открывать шоу "Экстрасенсы ищут баг на проде". А если сервисов несколько? Прикинь, система из 50-ти сервисов. Там вообще хрен поймёшь что произошло, если никак не мониторить её состояние. Что нам нужно, чтоб штаны остались сухими? 1. Логи Это база. Печатаем ошибки, чтоб потом понять на каком из этапов что-то пошло не так. Но не стоит писать "произошла ошибка пук". В лог нужно добавлять необходимый контекст. Произошла ошибка в обработке какой-нить задачи - напиши айдишник этой задачи. Сломался парсинг атрибутов пользователя - бахни в лог инфы о пользаке, чтоб понятно было кто он такой. Сколько раз мне логи время экономили... Видишь ошибку, лезешь в логи, а там написано "ты, дурень, зачем указатель ниловый разыменовал" и сразу всё на свои места становится. Быстрая правка - и в продакшн. 2. Метрики Они нужны, чтобы запалить, сколько всяких ошибок сервис наваливает. Кроме этого, можно засекать нагрузку на сеть, на CPU, на диск и так далее. И, конечно, всякие бизнесовые показатели тоже отлеживать важно. Из самых базовых текнических метрик можно за основы взять 4 золотых сигнала, которые умные дядьки из гугла рекомендуют. ➡️ Latency - время обработки запроса. Сервак отвечает дольше обычного - повод подумать, а всё ли ок. И конечно важно разделить это время для успешных запросов, и тех, что с ошибкой. А то один кривой запрос всю статистику запороть может. ➡️ Traffic - обычно это количество запросов в секунду. Можно прикинуть нагрузку, которая летит в сервис и если она возрастёт, то мы это заметим. ➡️ Errors - моя любимая метрика. Сколько запросов лажает и отдает пользователю ошибку. Чем больше ошибок, тем сильнее горит жопа у всех причастных. ➡️ Saturation - насколько хреново вашему сервису. Можно оценивать заполненность оперативы, или нагрузку на CPU, или показатели системы ввода-вывода. Короче, что важнее в конкретном сервисе, то и палим. 3. Алерты Они-то в начале истории меня и подвели. Мало метрики считать, надо ещё и оповещать, когда они отклоняются от нормы. То есть в момент, когда у нашей ручки начинают копиться ошибки в ответах, алерт менеджер должен присылать собщение "ребятки, у нас жопа на проде". В Озоне помню ещё и железная леди звонила. Спишь ночью, и тут звонок, а из трубки сексуальный машинный голос "Привет, это алерт, исправь меня пожалуйста". 4. Трейсы Это киллер-фича в мире микросервисов. Твой фронтенд может дернуть один микросервис, а тот ещё с десяток сервисов под капотом вызовет, и потом иди разбирайся, кто и где налажал в этой цепочке. А трейсы весь путь запроса пометят, еще и в красивом UI отрисуют. Там сразу будет видно, кто всем подсирает своими 500ками. Мониторинг — это не просто хотелка перфекциониста, это необходимость в современных реалиях, иначе жопа твоя будет гореть не переставая.

  • Как подружить сервисы друг с другом? Инженеры по всему миру навыдумывали всяких технологий, что башка кругом идёт, когда пытаешься во всём этом многообразии разобраться. Надо тебе намутить общение между сервисами - так одни говорят REST API юзай, другие крутят пальцем у виска и втюхивают свой gRPC, а кто-то сидит в уголке и натирает до блеска малоизвестный GraphQL. Ну и кого слушать? Чаще всего технологии появляются, чтобы решить какую-то проблему, которую другие технологии или не решают, или решают фигово. Осталось понять, когда какую технологию применять, и будет нам счастье. Сейчас глянем на примерах, когда лучше юзать REST, когда gRPC, а когда и GraphQL можно расчехлить. 1. REST Это как швейцарский нож в мире API. Он идеально подходит, когда вам нужно общаться с фронтендом. REST работает через HTTP/1.1, и браузеры отлично поддерживают этот протокол. JSON, который чаще всего используется в REST, легко обрабатывается на фронте, да и все к нему привыкли. Есть у тебя магаз, где ты свои огурцы с кабачками продаешь. Заходишь ты на сайт магаза, и фронтенд запрашивает информацию о товарах с бэкенда. REST здесь нормас так ляжет. Ещё ж кайфово, если ребятки rest full поддержат, чисто по http методам будет ясно что делает та или иная ручка. Видишь patch метод и сразу всё ясно про это ваше обновление. Несмотря на то, что JSON не самый лёгкий по весу формат и HTTP/1.1 не самый быстрый протокол, REST остаётся удобным и универсальным решением для большинства веб-приложений. 2. gRPC А вот если ты вписался в мир микросервисов, то я тебе конечно соболезную, но надо как-то с этим жить. Запрос идёт с фронтенда, и чтобы собрать ответ, нам надо слазать в пяток микросервисов. Скорость тут уже начинает ролять сильнее. Надо мутить быстрый и эффективный способ обмениваться данными. Тут-то и выходит на авансцену gRPC. Во-первых, он работает через HTTP/2, что уже делает его быстрее, так как умные ребята серьезно потюнили этот протокол с версии 1.1. Во-вторых, gRPC использует бинарный формат данных Protobuf, что уменьшает размер передаваемой информации. А коль сообщенька весит меньше, значит и летит по сети быстрее. gRPC отлично подходит для взаимодействия между микросервисами, когда скорость и эффективность имеют решающее значение. Правда, чтоб настроить инфраструктуру для работы gRPC нужно побольше попотеть, но если сервисов много и вы завтра не планируете закрывать контору, то кажется игра стоит свеч. 3. GraphQL Решил ты сделать магаз с кучей фильтров, где можно по-всякому вертеть, какие данные отображать при поиске, а какие нет. Не будешь же ты каждый раз получать с бекенда все данные, а фильтровать их уже на фронте. Это шляпа какая-то, которая забьет тебе сеть. Надо быть хитрее и запрашивать только то, что действительно нужно. GraphQL — это как SQL для API: вместо того, чтобы получать фиксированный набор данных, как принято в контрактах REST или gRPC, ты можешь запросить ровно то, что нужно. Это снижает нагрузку на сеть и ускоряет загрузку данных, особенно когда речь идёт о сложных и динамичных запросах. Итого REST — проверенный годами варик, особенно для взаимодействия между фронтендом и бэкендом. gRPC идеально подходит для быстрого и эффективного взаимодействия между микросервисами, когда важна производительность. GraphQL даёт максимальную гибкость в запросах данных, позволяя получать только то, что нужно, и оптимизируя взаимодействие между клиентом и сервером. Короче, как обычно всё зависит от контекста. Так что вникай в контекст и включай голову. Опять думать придётся((( 🔥 - мне REST больше всего по душе 🌭 - gRPC one love 🍌 - юзаю graphQL и не стесняюсь этого!

  • 30 июл. 2024 г.2 4312211из olezhek28go

    РАСПРЕДЕЛЕННАЯ СБОРКА ЛОГОВ (Разгоны #4) Новый разгон! На сей раз по запросам в комментах. Расскажу про то как устроена распределенная сборка логов и нафига она нужна. Поглащать этот разгон можно и чисто в аудиоформате, словно короткий подкаст. А в комментах можете накинуть темы для новых разгонов и необязательно технические))) Для тех, кто не хочет смотреть: 1) Логи из контейнера летят в файлик на ноде и хранятся там пока не удалишь 2) Агенты (например, fluentd) собирают с разных нод логи из файлов и засылают их по сети в инструмент для отработки логов (logstash) 3) Обработчик логов их фильтрует, преобразует и куда-то сохраняет для использования в долгую 4) Хранилка логов (elasticsearch) сохраняет и индексирует логи, делая их доступными для поиска, фильтрации и т.п. 5) И дальше уже мы можем в красивом UI эти логи поглядеть (Kibana) Прошлые разгоны: * ПОЧЕМУ ТЫ ПЕРЕРАБАТЫВАЕШЬ? * ЗАЧЕМ МЫ ГОНИМСЯ ЗА УСПЕХОМ? * ЗАЧЕМ ПИСАТЬ ЧИСТЫЙ КОД?

  • 19 июл. 2024 г.2 252127из olezhek28go

    Новый контент подъехал! Не так давно я заглянул на подкаст к ребятам из KOTELOV. Посидели душевно, обсудили много всякого разного. 📺 Поговорили о медийности, её плюсах и минусах ☕️ Я рассказал, как из блогера стал айтишником 🤡 Поразгоняли о качественном контенте и как его лучше готовить 🧑‍🌾 Публичные выступления и сложности с ними связанные тоже затронули 🧑‍💻 И конечно курс обсудили, куда без него Атмосфера подкаста на диком приколе) Мне очень понравилось то, что получилось) И конечно смотрите до самого конца, они даже кринжовую волью мудрость от меня не вырезали ахахахах СМОТРЕТЬ ПОДКАСТ

✨Уютный микросервис✨ — tgindex