🚀 Новое видео: Airflow и Kafka — интеграция для надежной обработки данных!

Приветствую! Подготовил для вас практический гайд по интеграции двух мощных инструментов — Apache Airflow и Apache Kafka.

📌 Что вас ждет в этом видео:

● Настройка Kafka в Docker-окружении с правильной конфигурацией

● Создание Producer DAG для генерации и отправки событий в Kafka

● Consumer DAG для чтения и обработки сообщений с гарантированной доставкой

● Практическая демонстрация работы всей системы

🎥Ссылки на видео:
Vk: https://vkvideo.ru/video-231048746_456239030
Youtube: https://youtu.be/fAhoNLrSzGo?si=jLkbDa2Sz2DRSIFE

Все материалы и код уже ждут вас в репозитории. Не пропустите разбор важнейших аспектов работы с Kafka и Airflow!

Github: https://github.com/MaratNotes/marat_notes/tree/master/how_data_works-practice_cases/13_kafka_airflow


P.S. В комментариях жду ваши вопросы по теме! Какие аспекты работы с Kafka и Airflow вам бы хотелось разобрать подробнее?

#КакРаботаютДанные

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

Суть парадокса
В книге упоминается исследование, где анализировались решения судей по ходатайствам об условно-досрочном освобождении (УДО):

🔹 Вероятность положительного решения (разрешить УДО) была высокой в начале рабочего дня — около 65%.
🔹 Затем она постепенно снижалась почти до 0% к обеду.
🔹 После перерыва на еду вероятность снова резко возрастала до исходного уровня.

То есть судьба человека зависела… от того, успел ли судья поесть и отдохнуть😳.

Почему это парадокс?
Как хочется в идеальном мир: судебные решения должны основываться на фактах, законах и обстоятельствах дела, а не на том, голоден ли судья или устал. Но на практике: эмоциональное и физическое состояние человека оказывает огромное влияние на его решения. В данном случае, усталые и голодные судьи склоняются к более легкому решению по умолчанию и отказывают в УДО.

Личный опыт
Читая про этот парадокс, вспомнил, как на заре карьеры работал в маленьком коллективе на 4-5 человек, и директор все самые важные переговоры с заказчиками назначал аккурат после их обеда😁. Теперь я понимаю, что он, сам того не зная, использовал знание о «парадоксе судьи». И, видимо, это работало, так как договоры заключались!

Lifehack. Как использовать это знание (без нарушения УК😉)

✅ Важные решения, «архитектурные», моральные выборы — буду принимать утром или после полноценного отдыха. Реализовать важную часть логики в конце рабочего дня — плохая идея, шанс на баг вырастает.

✅ Если мне нужно «продать» сложную идею начальнику или коллегам, буду стараться назначать встречу на время, когда они с большей вероятностью будут в ресурсе (не перед обедом и не в пятницу вечером). Это повышает шанс на положительное решение.

💭 Финал

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

📌 А Вы замечали, что Ваши решения зависят от времени суток, голода или усталости?

#ОшибкиМышления #Книги

Утренний апгрейд: с бега на велосипед

По утрам, до начала рабочего дня, я стараюсь проводить лёгкую тренировку (low pulse cardio) — чтобы привести мысли в порядок и разогнать активность перед погружением в код, DAG’и и обсуждения.

🔄 Смена стека
Раньше это был бег.
Но этот требует дополнительного времени: добраться до места тренировки (около 15 минут в одну сторону), размяться, пробежать, вернуться, принять душ…
В общем, долго по логистике.

Перешел на велосипед. Тот самый, что годами стоял на техобслуживании — задача по его ремонту висела в трекере с меткой low priority. Спас друг: сделал за меня часть ресерча и нашел в соседней деревне молодого парня (лет 16, красавчик, что ищет способы заработка и привнесения доли упорядоченности и счастья в мир👍), который за адекватные деньги провел полный апгрейд: заменил амортизаторы, настроил передачи, поставил новые ниппели…
Теперь велосипед работает как новый. Полностью доволен.

🚴Новый маршрут
Собственно, к истории. Обычно я езжу по трассе — привычный маршрут, предсказуемый, но скучноватый. И, честно, горок там слишком много — утомляют даже в лёгком темпе.

Вчера решил разнообразить — поехал к реке.
Маршрут проходит через маленькую деревню, где построены премиальные дома — так что добавляется лёгкий элемент экскурсии: “О, особняк в стиле готики… А тут цветник прям на дороге - красиво!"

И вот, на одной из улиц, посреди дороги лежали две собаки. Сначала подумал: “Что за мешок такой странной формы?” Потом понял — собаки. Одна — большая, черная, спокойная. Вторая — помельче, размером с кокер-спаниеля. Подумал: «Прикольно, лежат себе». Проезжаю мимо — большая даже ухом не повела, а вот маленькая... Видимо, испугалась и решила, что лучшая защита — это нападение. Сделала резкий выпад и цапнула за икру! 😅

Боль была символической. Я даже не остановился — подумал: “Ну, мелочь, ничего страшного”.

📈Итоги инциндента
Вообще назад планировал поехать поэтому же маршруту, но решил: "На фиг надо!". Cделал круг и вернулся по другой улице.
Далее зашел в магазин купить творог, колу и шоколадку (баланс белков и глюкозы!). И только там заметил, что штанина мокрая. Оказалось, даже самый «легкий укус» способен кровоточить. А к обеду на этом месте расцвел такой синяк, что можно было проводить презентацию на тему «Недооцененные риски периферийных маршрутов».

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

💬 А у вас были похожие неожиданные случаи во время тренировок или прогулок? Делитесь в комментах!

#ХоббиПрограммиста

Когда 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Инсайты

ETL. Коротко о важном.

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

В этом видео:

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

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

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

👉 https://youtu.be/oo2e15ohHY4

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

#КакРаботаютДанные

Приветствую!

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

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

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

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

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

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

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

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

Спасибо, что читаете🤗

TaskFlow API. Просто и чисто.

В этом видео разбираю, как TaskFlow API упрощает жизнь в Airflow:

🔹 Не нужно писать ti.xcom_pull
🔹 Функции становятся задачами
🔹 Можно тестировать вне Airflow

Покажу, как переписать старый DAG с xcom_push/pull → на clean Python-функции.

Vk: https://vkvideo.ru/video-231048746_456239033
Youtube: https://youtu.be/5am7DYgDZ40?si=1P5sgabPJboz-s59
Репозитарий: https://github.com/MaratNotes/marat_notes/tree/master/how_data_works-practice_cases/15_task_flow

#КакРаботаютДанные

Результат поста про использование LMM при участии в хакатонах:

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

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

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

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

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

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

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

Если кому-то интересно, подавайте заявки, участвуйте и эксперементируйте!

Квантовые технологии и куда они нас ведут

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

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


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

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

Наши обычные компьютеры — будь то смартфон или сервер — работают с битами: каждый бит — это как крошечный выключатель: «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Инсайты

Почему я снова набрал задач, как будто свободного времени не существует?

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

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

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

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

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

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

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

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

#личное

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

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

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

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

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

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

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

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

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

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

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

#ITИнсайты

⚡ Внимание! По Вашему адресу зарегистрировано плановое отключение электроэнергии с 12:00 17.10.2025 по 20:00 17.10.2025

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

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

Со следующей недели выпуск видео продолжится😊

Векторный поиск как новый способ думать о данных

Недавно послушал выпуск 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Инсайты

Эвристика настроения: когда эмоции выдают себя за разум

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#ОшибкиМышления

Наслаждаюсь отдыхом😊😊

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