Марат и его записки программиста
287 subscribers
82 photos
1 video
63 links
Коротко о сложном: Инжиниринг данных, бэкенд, ИИ и личный опыт.
Автор: Марат, 15 лет в разработке
Vk: https://vkvideo.ru/@club231048746
GitHub: https://github.com/MaratNotes/marat_notes
Download Telegram
Когда Kafka — не панацея: Sharded Task Queue от Яндекса

На канале сейчас рассказываю про Kafka (тык1, тык2) и её использовании при построении ETL-процессов. Поэтому сегодня решил разобрать доклад, где Kafka оказалась недостаточным решением — про внутреннюю систему Яндекса Sharded Task Queue (STQ).

🔹 Что такое STQ?
Это месседж-брокер, а не классический сервер очередей (вроде Kafka или RabbitMQ).
Основная цель: надёжное выполнение отложенных задач с произвольной точностью (например, отправить уведомление через 40 минут, или месяц или год).
Система не сохраняет порядок задач, что критически важно для отложенных операций.

🔹 Как рождалось решение.
Авторы не стали сразу пилить монстра. Они честно говорят, что решали проблему одну за другой, как и бывает в реальных задачах. Это показывает инженерную работу, а не просто презентацию готового результата. В итоге сложились следующие требования:

Базовые: Произвольная точность выполнения, ретраи, независимость от падений сервисов.

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

Именно эти требования сразу отсекли простые варианты вроде Cron и заставили искать специализированное решение.

🔹 Сравнение с Kafka и RabbitMQ
Главный вывод: классические брокеры — это про порядок (FIFO), а отложенные задачи — про произвольный доступ ко времени выполнения. Попытка сделать «отложенную очередь» на Kafka — это костыли. STQ же хранит задачи как база данных с индексами, что позволяет гибко двигать их по времени. Это ключевое архитектурное отличие, продиктованное требованиями.

🔹 Результат
Система стала критической инфраструктурой для 700+ микросервисов (такси, доставка, банк) с пиковой нагрузкой под 150k RPS. Философия — «разработчик не должен думать о проблемах очередей», и судя по отзывам, у них получилось.

🔸 Что огорчило
Информационный вакуум. Кроме этого видео и пары упоминаний в вакансиях, подробной информации не нашел. Возможно, есть ещё пару докладов, но в названии и контексте там не указана STQ. Очень жаль, что такая крутая инженерная разработка не имеет публичной документации. Хочется заглянуть под капот!

Итог
Отличный пример, что нет серебряной пули. Инструменты вроде Kafka — мощные, но для узких задач (как отложенные выполнения) часто нужны специализированные решения.

Ссылка на доклад: https://vkvideo.ru/video-17796776_456241737?pid=152308462

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

Интересно обменяться кейсами!

#ITИнсайты
🔥1
ETL. Коротко о важном.

Вы когда-нибудь запускали DAG, который работает сам — и не требует вашего участия?

В этом видео:

● Что такое ETL на самом деле
● Ключевые характеристики процесса на проде
● Batch vs Streaming: когда что использовать
● Пример использования обоих подходов на возможном кейсе

И главное — почему хороший ETL — это система, которая работает без тебя

👉 https://vkvideo.ru/video-231048746_456239032

👉 https://youtu.be/oo2e15ohHY4

P.S. Накопились вопросы по видеоконтенту, завтра опубликую пост про это, прошу поучаствовать в ответах🤗

#КакРаботаютДанные
🔥4
Приветствую!

Хочу посоветоваться по видеоконтенту.
Пишите в комментариях: какие темы вам интересны?

Мои планы на ближайшие недели:

1️⃣ Видео про Task Flow API
— Уже от нескольких подписчиков была просьба
— Покажу, как он упрощает написание DAG’ов

2️⃣ Дополнительные аспекты Kafka*
— Также был запрос от подписчика
— Best practices: retention, offset’ы
— Как не сломать топик при первых запусках
— Что делать, если consumer “отстал”
*возможно, это будет после пункта 3 и реализации потокового режима для примера магазина

3️⃣ Реализация пакетного режима для интернет-магазина с последнего видео
— Генерируем заказы, пользователей, покупки
— Обрабатываем через Airflow + Kafka
— Без event-driven, но надёжно

А дальше при обзоре новой темы, будем добавлять логику в этот пример с магазином.
— Добавлю мониторинг (кто, что, когда)
— Настрою логирование (чтобы было видно, где сломалось)
— Введу data lineage — кто обработал, откуда взял

Чтобы показать:
не “вот мой DAG”, а “вот как растёт настоящая система”.

Жду ваших мыслей. Какие темы хотели бы увидеть?

Спасибо, что читаете🤗
Такое разное кэширование: как вывозить нагрузку, когда данных много

Если вы работаете с высокими нагрузками и большими данными, это видео — must see. Степан Полохин из Яндекса на примере взаимодействия с колоссальным монорепозиторием (14 ТБ, 8000 коммитов в день!!!) рассказывает, как спасает ситуацию грамотное кэширование.

Что особенно понравилось:
Докладчик виртуозно сочетает глубокую проработку темы с понятностью изложения. Сложные концепции кэширования и устройство собственной СУБД «Object» объясняются настолько ясно, что становятся доступны даже не-экспертам. Отдельно хочется отметить качество слайдов — они визуализируют сложные архитектурные решения без лишней воды, что делает материал предельно наглядным.

Ключевые идеи доклада:

1️⃣ Кэшируйте всё, что движется. Главный вывод доклада. Тяжёлые операции вроде подсчёта разницы между коммитами не должны вычисляться каждый раз. Готовый ответ из кэша радикально ускоряет работу и разгружает серверы.

2️⃣Многоуровневый подход — ключ к успеху. Яндекс использует сразу несколько стратегий:

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

Кэши на диске: Собственная БД «Object» позволяет ускорить запуск серверов и избежать излишнее число запросов запросов к основной базе данных.

Кэширование ответов: Результаты тяжёлых запросов кэшируются целиком.

3️⃣Индексы — ваш друг. Для ускорения сложных запросов (например, история изменений файла) необходимы специальные индексы. В системе их уже несколько, и этого мало — команда разрабатывает очередной.

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

Ссылка на видео: https://vkvideo.ru/video-65336816_456239606

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

#ITИнсайты
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥2
Марат и его записки программиста
Снятся ли хакатоны электроовцам?🐑

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

И ловлю себя на мысли:

Я автоматически увеличиваю объём задания, потому что при решении будет использоваться LLM.
На пару минут даже офигел.

🔹 Больше не требуется проектировать задачу для человека.
🔹 Теперь нужно ставить задачу для человека + ИИ.

LLM меняют не только процесс решения, меняется сама логика постановки задачи.

На секунду стало неприятно и внутренне неудобно:
— А что нас ждёт, если за последние лет 5-7 такой скачок?
— Когда мы перестанем понимать, что внутри кода?

Обдумав, вспомнил:

Технологии всегда пугали. Потому что они двигают нас вперёд.
Именно этот дискомфорт — признак того, что развитие продолжается.

Когда-то преследованию подвергались книгопечатание, потом радио, телевидение и интернет. А теперь это классика☺️

Сейчас очередь искусственного интеллекта.
Интер
Результат поста про использование LMM при участии в хакатонах:

🔥 IT_ONE Cup. Code & Analyst — онлайн-хакатон для аналитиков и backend разработчиков

Участвуйте командой (1–5 человек) — решайте задачи из жизни банков и финансовых систем.

Две задачи:
🔹 Трек 1: Проанализируйте кредитный процесс банка, выявите узкие места и создайте ТЗ для системы мониторинга производительности (для аналитиков)
🔹 Трек 2: Постройте "Финансовый радар" — сервис обнаружения подозрительных транзакций в реальном времени (для разработчиков)

Возможности:
Реальный кейс в портфолио
Призовой фонд — до 900 000 ₽ и для ТОП-5 — фирменный мерч
Нетворкинг с экспертами

Регистрация до 16 октября:
👉 https://cnrlink.com/itonecupmsunitgirls

Старт — 17 октября.

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

Если кому-то интересно, подавайте заявки, участвуйте и эксперементируйте!
🫡3👍1
Квантовые технологии и куда они нас ведут

В последнее время в рубрике были в основном технические доклады, поэтому сегодня — переключаемся на научпоп!

Чем мне нравится подкаст «ТехноЛогично» — так это тем, что в нём раскрывают сложные темы через живой диалог с действительно классными собеседниками. В свежем выпуске Дмитрий Заур и Алексей Фёдоров под модерацией Виктора Корейши рассказали, где сегодня находятся квантовые технологии — и куда они нас ведут.


🔬 Что такое квантовый компьютер?

Это не просто «быстрый комп», а принципиально новое устройство, использующее законы квантовой физики на уровне отдельных частиц.

Наши обычные компьютеры — будь то смартфон или сервер — работают с битами: каждый бит — это как крошечный выключатель: «0» (выкл) или «1» (вкл). Миллиарды таких переключателей щёлкают миллионы раз в секунду, выполняя всё — от расчётов до TikTok-роликов.

А квантовый компьютер оперирует кубитами. И вот в чём магия: кубит может быть одновременно и 0, и 1 — это называется суперпозицией. А если у вас, скажем, 5 кубитов, они могут находиться в суперпозиции сразу всех 32 (2 в 5 степени ☺️) возможных комбинаций нулей и единиц.

Это даёт колоссальное преимущество в параллелизме: в теории квантовый алгоритм может обрабатывать все эти состояния одновременно. Но на практике всё осложняется декогеренцией — это процесс, при котором кубиты «теряют» своё квантовое состояние из-за взаимодействия с окружающей средой (тепло, вибрации, электромагнитные поля и т.д.). Из-за этого суперпозиция разрушается, и кубит «схлопывается» в обычный 0 или 1 — как в классическом компьютере. Поэтому квантовые компьютеры работают при сверхнизких температурах и в условиях максимальной изоляции.

Представьте: вы забыли код от сейфа.
● Классический компьютер будет перебирать комбинации по одной.
● Квантовый — как бы «проверит» все варианты сразу и мгновенно найдёт правильный.

💡 Где это пригодится?
Квантовые компьютеры не универсальны — они не заменят ваш ноутбук. Но для определённых задач они могут стать революционным ускорителем:

● Моделирование молекул: новые лекарства, катализаторы, материалы.
● Оптимизация: маршруты доставки, управление инвестиционными портфелями, энергосети.
● Синергия с ИИ: ускорение обучения моделей и обработки сложных данных.

По сути, квантовый компьютер — это как GPU для квантовых задач: узкоспециализированный, но невероятно мощный в своей нише.

🇷🇺 Россия в квантовой гонке
В стране активно развиваются четыре физические платформы:
● ионы,
● нейтральные атомы,
● фотоны,
● сверхпроводящие цепи.

Самый мощный российский квантовый компьютер — ионный, с 20 кубитами. При этом:
● точность однокубитных операций — >99%,
● двухкубитных — 95–97%.

Для сравнения: мировые лидеры уже демонстрируют 35–40 кубитов с >99% точностью даже для двухкубитных операций.

Отставание около 3–4 лет, в основном в стабильности, масштабировании и инфраструктуре.
Но главное преимущество России — люди: сильная школа теоретической физики, Физтех, МГУ, традиции Ландау… Именно талантливые учёные — наш главный актив.

📚Что почитать и посмотреть?
Если заинтересовались — вот отличные точки входа:

«Начало бесконечности» Дэвида Дойча — о квантовых вычислениях, эпистемологии и будущем науки.
«Что такое жизнь?» Эрвина Шрёдингера — провидческая лекция 1944 года о связи квантовой физики и биологии.
Фильм «Оппенгеймер» — не только про атомную бомбу, но и про эпоху, где историческое развитие квантовой физики показано с удивительной точностью.

Главный вывод
Квантовые компьютеры — не фантастика, а следующий этап эволюции вычислений. Они не заменят классические системы, но станут мощным «ускорителем» для задач, которые сегодня просто нерешаемы.

🎧 Ссылка на выпуск для кайфового прослушивания (и просмотра):
https://vkvideo.ru/video-145457488_456239761

#ITИнсайты
🔥3
Почему я снова набрал задач, как будто свободного времени не существует?

Этой осенью я, кажется, умудрился превратить всё своё «свободное» время в продолжение работы — только под другим соусом.
Внутреннее выступление в компании про LLM, подготовка и оценивание хакатона, сертификация на технического собеседующего по Python, ведение Telegram, запись видео…
И да — я сам всё это захотел.

Сижу, жёстко расписывая тайминги и раставляю помадоры на выходные:
🔹 Суббота, 12:00–22:30 — только блог, без отвлечений
🔹 Воскресенье утром — репетиция выступления
🔹 Воскресенье днём — проверить, корректно ли настроено всё под Llama.Desktop и проанализированы ли все проверки

А на работе, между прочим, график ещё жёстче — там я тоже обязан быть на 100%. 😁

Звучит как образец сверхпродуктивности.
Но на деле — усталость накапливается стремительно.
Тело и мозг уже шепчут: «Марат, нам нужен отдых!»

Я понимаю: всё это — мой выбор. Возможно, эти вложения окупятся позже.
Но иногда ловлю себя на мысли: «Слушай, а зачем я вообще на всё это подписался?»

Наверное, потому что хочется расти, быть полезным, оставаться востребованным специалистом.
Но не забыть бы при этом — что я тоже часть этого уравнения. А не просто ресурс для выполнения задач. И мой отдых - моя важная ответственность☺️

Если ты тоже ловишь себя на этом — знай: ты такой не один. И, может, стоит просто… остановиться на пять минут, а лучше на пару дней😃.

Без плана. Без цели. Полный релакс.💤

#личное
🔥3
Автоматизация RAG на реальном кейсе

Вчера выступал по теме запуска локальных моделей внутри кампании, где работаю. Оказывается тема ИИ интересует гораздо больше людей, чем я предполагал. Продолжая эту тему, разберём крутой кейс по промышленному использованию RAG (Retrieval-Augmented Generation) из доклада X5 Tech.

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

Ключевым решением стал переход на модульную и гибкую архитектуру. Основные усилия были направлены на:

🔷 Создание сервиса Data Drive: Этот центральный хаб берет на себя хранение, версионирование и обработку документов. Он позволяет заказчикам самостоятельно обновлять данные, обеспечивает консистентность и управляет парсерами, решая проблему с дубликатами и неструктурированными файлами.

🔷 Внедрение графового пайплайна генерации: Вместо жесткой последовательности шагов, логика преобразована в граф из последовательных и условных блоков (например, перефразировщик, классификаторы). Это позволило устранить дублирование кода, исправить баги и дать возможность гибко настраивать и тестировать различные сценарии обработки запросов через конфигурационные файлы.

🔷 Полный рефакторинг сервиса поиска (Ретривер): Сервис был переписан с нуля за три недели, что позволило добавить ранее недоступную функциональность, такую как поддержка фильтров и тегов, и интегрировать его в новую экосистему.

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

Личное впечатление: Понравилось честность и непосредственность докладчика. Слайд с тем как работала система до рефакторинга - просто песня, в целом костыли и болевые точки очень знакомые и отзывающиеся. Также понравилось наполненность доклада и точность в пояснении изменений.

Вывод: Этот кейс — отличный пример для всех, кто сталкивается с необходимостью превратить набор скриптов в отказоустойчивый и управляемый продакшен-сервис.

📹 Ссылка для просмотра: https://www.youtube.com/watch?v=JObQiulQe7Y

#ITИнсайты
👍3
Внимание! По Вашему адресу зарегистрировано плановое отключение электроэнергии с 12:00 17.10.2025 по 20:00 17.10.2025

На этой неделе постоянное отключение электроэнергии, как же парит😁😁

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

Со следующей недели выпуск видео продолжится😊
🆒4
Отпуск начался — и сразу в хакатон☀️

Вчера официально стартовал мой отпуск… и в тот же день прошёл первый чекпоинт хакатона Code & Analyst, где я участвую в роли эксперта — помогал формулировать задания и теперь оцениваю решения.

Сначала подумал: «Ну вот, два часа вместо отдыха…»
Но уже через пять минут после начала сессии поймал себя на мысли, что заряжаюсь энергией.

Потому что за экранами — десятки команд, в основном студенты и junior-разработчики, которые:
🔹 уже спроектировали архитектуру,
🔹 задают точные вопросы про API, очереди, валидацию данных и масштабируемость,
🔹 и при этом — горят задачей и хотят реализовать её качественно.

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

Был и полезный инсайт для нас, авторов задания:

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

Запомню на будущее: в техническом задании важна максимальная ясность.

Мне предстоит еще два чекпоинта, и проверка, и оценка заданий, а также наслаждение моим отпуском. Пусть у вас тоже будет и классный отдых, и работа, которая вдохновляет. 🌴💻

И последнее на сегодня насчет работы:
А вы участвуете в эвентах внутри своей компании или сообщества? Какими интересными мыслями после них можете поделиться?
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥31
Векторный поиск как новый способ думать о данных

Недавно послушал выпуск Podlodka Podcast #445 — «Почему текстовый поиск устарел» с Андреем Васнецовым (сооснователь Qdrant), и честно — получил удовольствие.

Подкаст длинный — почти полтора часа — но при этом лёгкий, без сложных формул и академичных выкладок. Андрей говорит о сложном просто, так что его можно слушать и за клавиатурой, и за уборкой квартиры — суть дойдёт в любом случае.

Вот несколько идей, которые особенно запомнились:

🔹 Векторные базы — это не базы данных, а поисковые движки.
Они ближе к Elasticsearch, чем к PostgreSQL. Им не нужна транзакционность — им нужны масштабируемость, отказоустойчивость и скорость поиска в памяти. Важно понимать границы применимости, как в примере про векторный поиск в PSQL, что похоже на попытку скрестить ужа и ежа, и для многих продакшн-задач не работает и скорее всего не будет работать.

🔹 Главный компромисс — не «скорость или точность», а «скорость И точность И память».
Меня поразили цифры: средний вектор — 6 КБ. Умножьте на миллионы записей — и получаются гигабайты, которые для скорости должны быть в оперативной памяти. Решение? Бинарная квантизация, сжимающая векторы в 32 раза — и при этом теряющая всего около 5% точности (что, честно, поражает). Кстати, не путайте это с квантизацией самих моделей (как в LM Studio, про что будет у меня отдельное видео) — это разные вещи, хоть и объединённые общей логикой: «сжимаем, чтобы уместиться в реальный мир».

🔹 Интерфейс поиска придётся пересматривать.
Андрей привёл отличную аналогию: в TikTok нет строки поиска — система учится на свайпах, паузах, повторных просмотрах. Это неявный фидбек, который гораздо естественнее для векторного пространства, чем текстовый запрос. Возможно, будущее поиска — в агентах, которые сами формируют запросы, или в интерфейсах, где пользователь даже не замечает, что «ищет».

🔹 RAG — главный use case, но не единственный.
Крутой пример: обнаружение аномалий на кофейной плантации через сравнение векторов зёрен. Вместо обучения новой модели на каждый вид брака (пересушенные зёрна, плесень), можно один раз обучить модель на векторы «похожести». Новый тип брака? Просто добавьте его вектор в базу, и для анализируемого экземпляра будет искаться схожий класс. Элегантно, эффективно и без переобучения. Кстати, похожие задачи освящены в базовых курсах по машинному обучению, например, при анализе семян пшеницы, Часто оказывается, что простая кластеризация (вроде k-means) эффективнее бустинга, потому что цель — не классифицировать по известным меткам, а находить «похожее» или «непохожее».

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

Мой вердикт: Рекомендую прослушать всем, кто работает с данными, поиском или ML.
Если вы используете RAG или просто хотите понять, зачем векторные БД выделились в отдельный класс систем — этот выпуск для вас.


🎧 Послушать / посмотреть https://www.youtube.com/watch?v=BOWq8JI-XNg

➡️ А вам что показалось самым интересным? Сталкивались ли вы с векторным поиском на практике?

#ITИнсайты
👍5
Эвристика настроения: когда эмоции выдают себя за разум

В психологии принятия решений и когнитивных искажений есть такое понятие:

Эвристика настроения — когнитивное упрощение, при котором люди оценивают объекты, ситуации или решения на основе своего текущего эмоционального состояния, даже если оно не имеет отношения к делу.

Иными словами — мы путаем «как я себя чувствую» с оценкой события.

Как это работает на практике:

🔹Ты в отличном настроении после утреннего кофе → оцениваешь рискованный проект как «перспективный и безопасный».

🔹Ты раздражён из-за пробки → считаешь, что идея коллеги «глупая и нереализуемая».

🔹В дождливый день ты смотришь на отпуск у моря и думаешь: «Зачем мне это?» — а в солнечный: «Какой же кайф!»

Во всех этих случаях оценка основана не на фактах, а на текущем настроении.

Хорошее настроение укрепляет уверенность в собственных рассуждениях. То есть настроение становится ментальным ярлыком:

● Мне сейчас хорошо → всё в порядке → решение правильное
● Мне тревожно → это опасно → надо отказаться

Даже если тревога вызвана совсем другим (например, недосыпом).

Почему это важно?

Мы постоянно принимаем решения под влиянием эмоций, не осознавая этого:

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

А потом удивляемся: «Почему я совершил такой выбор?»

Как с этим работать?
Замечай своё настроение перед важным решением.
Просто спроси себя: «Как я себя чувствую прямо сейчас? Может, это влияет на мою оценку?»

Откладывай решения в экстремальных состояниях.
Не принимай решений в гневе, эйфории, усталости или тревоге, если можно подождать.

Используй чек-листы.
Эвристика настроения обходит логику, но структурированный подход снижает её влияние.

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

Практическое задание:
Перед следующим нетривиальным решением поставьте таймер на 2 минуты и честно спросите себя:

«Как я себя чувствую? И как это чувство может искажать мою оценку?»


Часто этого бывает достаточно, чтобы вернуть себе контроль.

💬 А вам удаётся замечать влияние настроения на решения?
Или эмоции всё равно берут верх?
Пишите в комментариях — будет интересно почитать!
👇

#ОшибкиМышления
2👍2🫡1
This media is not supported in your browser
VIEW IN TELEGRAM
Наслаждаюсь отдыхом😊😊

Контент будет после отпуска, он получился напряжным по дополнительным активностям (расскажу позже), надо расслабиться🔥👍
🔥6
Ура! Хакатон окончен!

Был частью организаторской команды IT_ONE Cup. Code & Analyst — и вот какие мысли остались.

Хакатоны — это не про идеальный код.
Они про скорость, адаптацию, принятие решений при нехватке данных.

🔹 Многие думали не “что сделать”, а “зачем” — и предлагали свои варианты решения;
🔹 Кто-то писал ТЗ на систему мониторинга так, будто уже работал в банке (либо у них были дополнительно классные менторы);
🔹 Были интересные идеи по использованию LLM в процессе мониторинга мошенеческих транзакций;
🔹 Встречались отлично оформленные репозитории с понятными гайдами по запуску и работе.

Что бы я изменил в оценке?
🔹 Времени катастрофически не хватает. Нас было трое экспертов на один трек — 58 работ за 2–3 дня. Это морально и физически очень тяжело;
🔹Необходима структурированная система оценки: чёткие критерии с баллами, сводная таблица, минимальная субъективность. Сейчас у нас было всего четыре блока, и, честно говоря, личные предпочтения всё равно влияли на итог — по крайней мере, у меня.

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

Если говорить про саму оценку, то понял следующие правила для себя:

Логика принятия решений:
На хакатоне невозможно всё сделать идеально. Но можно и нужно показать, почему ты пошёл именно этим путём.

● Что было известно на момент выбора?
● Какие гипотезы ты проверял?
● Почему отказался от альтернатив?

Пояснения, комментарии, подход к архитектуре

Хорошо оформленный репозитарий влияет на оценку:

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

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

Зрелость: умение взвешивать компромиссы
Инженерная зрелость — это не в том, чтобы знать все технологии, а в том, чтобы уметь выбрать ту, что подходит именно здесь и сейчас.
Фраза вроде «Я взял SQLite вместо PostgreSQL, потому что данные временные и локальные» говорит гораздо больше, чем десяток бездумно скопированных подходов из интернета или LLM.

💡 Вывод
Хакатон — это не соревнование навыков, а диагностика мышления.
Технические навыки — обучаемы.
А вот способность:

● задавать правильные вопросы,
● объяснять свои решения,
● взвешивать компромиссы —

это то, что отличает не просто хорошего разработчика или аналитика, а инженера, готового к реальным вызовам.

Именно таких людей хочется видеть в своей команде. И именно такие критерии делают хакатоны не просто «гонкой за призами», а настоящей школой профессионализма.

P.S. Спасибо всем, кто принял участие.
Вы — те, кто строит будущее. Горжусь всеми командами и их подходами, просто красавчики!
👍5
Вернулся с отпуска.
Первые полторы недели — не отдых. А работа. Состояние было просто катастрофическим, не было настроения отдыха совсем. Чем я занимался на самом деле:

🔸 Оценка решений участников хакатона;
🔸 Смена работы между разными дочками — оформление документов, перевод;
🔸 Оформление командировки — сразу после «отдыха», причём с учётом смены работы: пришлось разбираться, у кого и как заверять бумаги, чтобы ничего не сорвалось

И всё это — под лозунгом «Ну я же в отпуске!».

На выходе:
🧠 Мозг — перегружен
💔 Эмоциональная накрутка: «Я же должен отдыхать!»
📉 Усталость, усиленная выгоранием

Понял одну простую, но жёсткую вещь:

«Отпуск» — это не даты в календаре. Это состояние.

А у меня его не было.


Теперь знаю наверняка:
📌 Нужно резко отключаться от каких-либо рабочих процессов — иначе я просто меняю географию работы
📌 Документы лучше не оформлять во время отпуска. Узнал о смене работы за день до старта отпуска, решил: «Ничего страшного, справлюсь». Но на деле это сильно ударило по качеству отдыха. Лучше было отложить отпуск на неделю, всё оформить — и уйти по-настоящему
📌 Работа над своим внутренним состоянием и самоощущением, важнее чем работа для других.

Вывод:


Следующий отпуск — будет настоящим.
Без почты. Без оценок хакатона. Без документов и командировок.

P.S. А вы умеете по-настоящему отдыхать?
Или «вроде отдыхаете, но всё равно в работе»?
Делитесь в комментариях 👇
🤪4👍3
Сегодня стартует Highload 2025!

Буду на стенде ГПБ, где можно окунуться в атмосферу любимых фильмов и увидеть, что происходит за кадром, как работает ИТ-экспертиза большого банка.

Мы объединили ИТ и кино, чтобы рассказать об используемых технологиях через знакомые и любимые сюжеты.

Свет, камера, ИТ!🎥
🔥6
Усталость — это не только про компанию. Это про Вас.

Прибыл с Highload 2025. Обдумываю мысли и впечатления.

Стоя у одного стенда, услышал:
Хочу написать на Хабре статью о том, как тяжело работать в БигТехе

И я подумал:
А ведь то же самое говорили и маркетологи, и инженеры-нефтяники, и сотрудники авиационного завода.

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

Вот мои способы для продуктивной работы и чтобы чувствовать себя способным решить любую задачу:

🔹 1. Физическая нагрузка и питание

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

Главное чувствовать меру в длительности и интенсивности. Не нужно убиваться. Я, например, бегаю 4-5 раз в неделю в своё удовольствие. И не чувствую после этого «вселенскую тяжесть бытия».

Вместе с тренировками стандартизировал питание. Так проще видеть прогресс и, что главное: не заедать стресс. А если вдруг начинает тянуть на сладкое, сразу понимаю: «Ага, это симптом. Я заедаю стресс. Надо разобраться откуда это и что с этим делать».

🔹 2. Тайминг и концентрация

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

🔹 3. Хобби — не роскошь, а необходимость

Важно помнить, что наш отдых как профессионалов, часть нашей работы и наша ответственность. Я восстанавливаюсь, чтобы снова быть эффективным.

Поэтому важно выбрать то, что приносит удовольствие:

● Сборка конструктора
● Полив цветов
● Приготовление вкусной еды
● Вечерние прогулки
● Посещение театра или выставки
● Просмотр любимых сериалов

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

📌 А какие методы помогают вам?
- Как вы справляетесь с выгоранием?
- Что работает, даже если кажется странным?
- Есть ли у вас "ритуалы перед работой"?

Делитесь в комментариях 👇
Может быть, кто-то найдёт здесь свою подходящую технику.

#БудниПрограммиста
👏2🤔1