Всем привет 🔥! С наступающим Новым Годом вас, ребята. Я благодарен вам за то, что мы вместе прошли через 2025 год и также войдем в 2026. Я очень рад, что вы со мной 🥇.

Давайте разберем базовую проблему с перфекционизмом, и если она у вас есть — это будет повод оставить ее в 2025, а в 2026 войти уже без нее 😎.


Перфекционизм — это когда ты не делаешь дело, потому что оно "ещё не идеально" 💀.

Снаружи это выглядит благородно: "я просто хочу качество", но если копнуть это обычно так:

• шлифуешь мелочи: шрифт, формулировку, переменную, анимацию 🥱.

• откладываешь релиз / пост / разговор 🤔.

• прогресс = 0, потому что ничего не вышло в мир 😋.

Самое токсичное, что перфекционизм часто маскируется под высокие стандарты. Хотя по факту — это не про качество, это про избегание боли 🧠.


Давайте формализуем этот перфекционизм, чтобы стало понятно как с ним бороться:


1. Модель перфекционизма как "функция потерь" (loss function):

Представь, что качество результата — это число q от 0 до 1, где 0 — это мусор, а 1 — это идеально 🚶. Тогда "боль" от задачи можно представить как функцию L(q), которая показывает, насколько плохо получилось. Если подход к задаче здоровый, то потери убывают плавно, например так:

L(q) = (1 – q)².

Сделал лучше → стало меньше "болеть". Всё логично. А вот перфекционизм часто выглядит как штраф с обрывом, смотрите:

L(q) = { 100, q < 0.95;
(1 – q)², если q ≥ 0.95 }

То есть мозг говорит: "Сделал на 0.94? Всё равно теряем 100 из 100, всё плохо." И ты залипаешь в правках того, что скорее всего даже не заметят пользователи, читатели и так далее 💡.

Вытащим проблему: такая L(q) не оптимизирует результат — она заставляет избегать действия, потому что почти любой результат воспринимается как провал 😦.


2. Почему “идеально” почти не случается (и это нормально):

Почти на любой результат — текст, код, выступление можно посмотреть со стороны статистики. Давайте представим качество результата как случайную величину 🤔:

Q ~ N(μ, σ²),

• μ — текущий уровень выполнения.

• σ — разброс: сон, настроение, задача, удача и так далее.

Перфекционизм хочет, чтобы каждая попытка была из правого хвоста нормального распределения, то есть: "10/10 всегда". Но хвосты нормального распределения — это редкость 😐.

Допустим, если "идеально" — это: μ + 3σ, то вероятность такого результата ≈ 0.13%. А это примерно 1 раз на 770 попыток 🤷‍♀️.

И при всем этом перфекционист обычно такой: "Почему у меня не получилось идеально с первой?" 🚶‍♀️


3. Маленький пример “из жизни” (чтобы было на что опереть теорию):

Допустим, ты пишешь пост:

• Первая версия — Q = 0.70. Норм, но сыровато.

• Вторая — Q = 0.82. Уже читаемо и по делу.

• Третья — Q = 0.90. Приятно и легко читается.

• Четвёртая — Q = 0.93. Почти идеал.

И дальше начинается перфекционистская классика: ты добиваешь 0.95+, но каждая правка даёт микроэффект, а времени и нервов сжирает в разы больше 🥴.

То есть по факту ты платишь очень дорогую цену за прирост с 0.93 до 0.96 — и часто такие правки заканчиваются моментальным выгоранием 🎮.


4. Как бороться с этим (самое простое, что пришло в голову):

• Ставим порог в "достаточно хорошо": например, Q ≥ 0.80. По факту, это критерий остановки. Если его не выставлять, то продолжать задачу можно бесконечно 🤯.

• Ставим таймбокс на задачу: "Не более n минут". Это возвращает в реальность 🤯.

• Ставим здоровую стратегию: не выжимать один результат до 0.99,
а сделать 10 результатов по 0.8 и поднять μ через опыт и фидбек 🤯.

• Разделяем "черновик" и "итог": сначала делаем так, чтобы работало, потом так, чтобы работало правильно, потом так, чтобы работало быстро. Это я использую, когда пишу своё приложение 🤯.

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


💡 — перфекционизм моя проблема.
☺️ — поборол перфекционизм, в посте база.
🌊 — что же ждать в следующем посте?


#статья 📚

Ребята, всем привет!) С наступившим Новым годом 🌚.

Решил наконец сделать первый розыгрыш в этом канале — разыграю вот такой подарок: https://t.me/nft/InputKey-117533

Передавать буду сам со своего аккаунта: @lesha_privet


Нюанс:

• Покупал подарок прямо в Telegram, поэтому передать победителю смогу только 24.01.2026 после 18:30.

• Значит, до этого момента розыгрыш и идёт 😎.

Чтобы участвовать, нужно:

• Быть подписанным на канал.

• Нажать кнопку «участвую» под постом.

Хотите — кидайте друзьям, пусть тоже поучаствуют, но это естественно по желанию.

Инвайт-ссылка:
https://t.me/+RNKHBw94FGEwZTNi


Если розыгрыш зайдёт — буду делать такие штуки почаще. Всем удачи 🤝🤝.


😎 — участвую.
⌨️ — закинул другу.
🔮 — вот бы почаще так.

Привет 😎! Сегодня решил написать небольшую статью о том, что я понял за 2+ года работы в аналитике.

Самое базовое — это образ мышления 🤯. Для меня это фундамент работы аналитиком.



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


1. Максимально подробно выясняем задачу, которую будем решать 😤.

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

🤔 Очень часто заказчик или клиент сам до конца не понимает, что именно он хочет. Я не раз ловил себя на том, что начинаю “решать задачу”, которая на самом деле существует только в общих словах.

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


2. Прикидываем возможные варианты решения 😐.

Когда задача стала понятнее, полезно остановиться и подумать: а какие вообще есть варианты решения?

🤔 Здесь важно не хвататься за первую идею, которая пришла в голову, а хотя бы выявить и сравнить 2–3 варианта между собой. Также, часто есть типовые подходы, которые уже где-то применялись, их не нужно игнорировать.

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


3. Выбираем целевой вариант 😏.

Если вариантов несколько — почти всегда стоит обсудить их с заказчиком или клиентом.

🤔 Это позволяет заранее отсечь слабые решения и зафиксировать одно целевое. Иногда бывает, что приходится брать ответственность на себя и выбирать решение самостоятельно.

Да, ответственность — это некомфортно, но без нее рост медленный. Со временем начинаешь понимать, что такие моменты и есть реальный профессиональный апгрейд. Особенно если в итоге твой выбор оказывается успешным. А если нет — это всё равно полезный опыт.


4. Декомпозируем решение 🥵.

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

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

Поэтому важно много коммуницировать и объяснять общую логику решения, даже если конкретная задача кажется совсем мелкой.


5. Принимаем и тестируем 😀.

Под конец крайне важно не забивать на тестирование.

🤔 Тестирование — это попытка сломать уже готовое решение. Если более подробно:

• Сначала проверяем общее решение.

• Потом краевые случаи.

• Потом тестируем на ограничения.

Большая часть багов, которые вылезают в проде, появляются именно потому, что этот этап проходится формально или “на глаз”.


6. Доводим результат до заказчика / клиента 🧱.

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

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

Задача закрыта 💸.



По такому паттерну можно пустить 80% типичных задач в аналитике ⌨️. Кстати, для меня это очень похоже на исследование функции:

• Сначала смотрим область определения 🥇.

• Потом анализируем общее поведение и краевые значения 🥇.

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

Если пропустить хотя бы один шаг — функция начинает “ломаться”, и всё нужно переделывать 😦.



Отдельно стоит сказать про то, что такой подход хорошо качает базу, без которой далеко не уедешь 🥵:

• Hard skills — знания предметной области и инструментов. Это пункты: 2, 4, 5.

• Soft skills — коммуникация, умение договариваться и объяснять. Это пункты: 1, 3, 6.

В итоге, для меня это рабочая основа, которая реально помогает в повседневных задачах. Всё остальное — надстройки ☺️.



Интересно почитать, кем работаете вы и какие паттерны используете в своей работе ✅.

⌨️ — работаю аналитиком, базовый подход.

💡 — интересно почитать ещё что-то из этой области.

🔮 — напишу про свою работу в комментарии.



#статья 📚

Привет 😍! Сегодня решил написать про рефлексию. Я давно пользуюсь этим инструментом, поэтому пришло время поделиться тем, что понял для себя 😐.

Рефлексия помогает оценить свои поступки и понять:

• Что сработало, что нет 🤔

• Где ты был прав, где ошибся 🤔

• И почему всё вообще произошло именно так 🤔

Мне нравится такая метафора: рефлексия — это долото. Есть «камень» — действие или ситуация. И если работать аккуратно, можно «высечь» из него статуэтку: увидеть причинно-следственные связи 👍.


А зачем она вообще нужна 🥸?

1) Когда действия не приближают к цели 🚨:

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

• Когда причина ясна — корректируешь действия так, чтобы они реально вели к цели.

2) Когда сложно разобраться в чувствах 🚨:

• Берёшь ситуацию и эмоцию, которую в ней испытывал, и ищешь первопричину: почему ты так отреагировал.

• Поняв причину, начинаешь иначе реагировать в похожих ситуациях, то есть меняешь «внутреннюю настройку».

3) В итоге грамотная рефлексия может 🚨:

• Экономить твои деньги и время на тесте идей и гипотез.

• Экономить нервы, если дискомфортные ситуации повторяются, а ты не понимаешь почему.

В чём тогда подвох 🥵?

Если кратко, то я вынес для себя две максимально неприятные проблемы:

• Нет «третьего лица», которое со стороны проверит твою логику на адекватность 🫣.

• Рефлексия легко превращается в самобичевание: «это я во всём виноват», и дальше по кругу 😦.

Короче, продолжая метафору: каменщик может так увлечься долотом, что просто расколет почти готовую статуэтку 🛑.


А при чём тут математика 🤷‍♀️?

Вообще процесс рефлексии похож на метод последовательного приближения 👈:

• x₀ — первое объяснение: «почему я так сделал и что чувствовал?» 😡

• Дальше итерации x₁, x₂,… по твоему «правилу рефлексии». Правило задаёшь ты сам: оно про то, насколько жёстко ты копаешься в своих мыслях и чувствах, где именно ставишь границы 😐.

• И в идеале ты сходишься к более честной причине, к которой ранее мысленно не приходил 🌚.

Закрепим простым примером из жизни:

Дано: я третий вечер подряд залипаю в игры и сериалы вместо того, чтобы делать что-то важное 🥵.

Решение:

• Факт: уже 3 дня вечером я «сливаюсь» в дешёвый дофамин ❌.

• Что я чувствую: усталость, раздражение, лёгкая тревога из-за того, что я опять ничего полезного не сделал 😩.

• Зачем я это делаю на самом деле: мозг хочет быстрый отдых, потому что весь ресурс истощился 🤬.

• Истинная причина: либо я перегружен, либо на начало важного дела нужно потратить очень много сил за раз (страшно и непонятно, с чего начать) 🏥.

Вывод: подход «соберись тряпка» не сработает, нужно уменьшить затраты сил на старт важного дела: таймбокс 20 минут на самый простой первый шаг и базовое правило сна, например, лечь до 00:30. Если после 20 минут пошло — продолжаю. Если нет — значит, реально нужен отдых, и я закрываю день без чувства вины 🤯.


Вот такая история у меня с рефлексией. Интересно, как у вас 💬?


🍾 — пользуюсь постоянно, уже на опыте.

🔮 — загоняюсь из-за рефлексии, не моё.

😎 — буду пробовать использовать.

💎 — похоже на аналитику, только вместо клиента — ты сам.


#хинт 😮‍💨

🎉 Результаты розыгрыша:

🏆 Победитель:
1. Dmitry (@Festfull)

✔️Проверить результаты

Всем привет 😎!

Время розыгрыша пролетело очень быстро. Я даже не заметил 👍.

Сейчас решил немного отдохнуть от своего приложения — ошибки с БД меня добили ещё в конце 2025 года, и в новогодние праздники был небольшой тильт 😦.


Но отдых от постоянной работы даёт плюсы — появились новые идеи. В итоге я почти 2 недели занимался ботом, у которого ИИ под капотом.

MVP-версию практически добил, и самое главное — разобрался с оплатами этого ИИ-сервиса 🥵. Это, кстати, сейчас реально сложный этап, местами даже сложнее, чем сама разработка 🤯.


С ботом тянуть не буду, поэтому сейчас все силы бросил туда. Суть простая:

Он помогает переводить человеческий текст с кучей эмоций и брани в деловую, фактическую речь — без наездов и перехода на личности 😁.

Про механику и кейсы распишу отдельным постом.


Чтобы этот лайф-пост навёл на мысли — закину несколько тейков, над которыми можно подумать:

1. Стать кем-то — это не удачный момент и не стечение обстоятельств, а выбор и действия под этот выбор 😤.

2. Про деньги проще думать, если держать в голове, что их «отбирают» (рынок / конкуренты / реальность), а не «выдают» просто за старания и хорошие качества 👻.

3. Если есть идея — лучше начинать сейчас, а не ставить дедлайны «на потом». Чем дальше срок, тем больше мозг рисует картинку, что всё получилось. А потом ты боишься проверить реальность. В общем, чем быстрее тестишь — тем выше шанс, что нащупаешь идею, которая реально выстрелит 😐.

Как вам такие тейки? Пока делал бота, они сами лезли в голову — и я решил собрать их в одном лайф-посте, вместо того чтобы растягивать на 3 отдельных ☺️.


И ещё: думаю разгребать список тем для постов и сделать хорошую навигацию по моему каналу, а то тут уже много всего накопилось 💪.


🍾 — тейки базовые, согласен с ними.

🔮 — тоже мучаюсь с оплатами ИИ-сервисов.

💡 — жду тест бота.

😎 — обновленная навигация в канале не помешала бы.


#лайф 🤝🏻

Всем привет 🤝🤝! Пока делаю своего бота, решил написать про пару нюансов разработки, которые легко пропустить 👍.

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


1. Почему ответы бота могут «ломаться», если в ответах используется HTML-вёрстка 🥵?

Суть:

Для удобства копирования ответа бота, я оборачиваю его ответы в тэги <blockquote>...</blockquote>. В итоге бот присылает цитату, текст из которой копируется одним нажатием 😐.

Проблема:

ИИ-сервис, который отправляет ответ боту, иногда вставляет в текст символы: <, >, &. Telegram воспринимает такие символы, как HTML-разметку, когда сообщение отправляется с «parse_mode=HTML», и вот на этом моменте начинается лотерея:

• Разметка ломается 🫣.

• Куски текста могут пропасть 🤬.

• Иногда сообщение вообще не отправляется или отправляется криво 🌚.

Решение:

Перед тем как форматировать текст — нужно применить к нему встроенную функцию escape().

По-человечески:

escape() заменяет «опасные» символы на безопасные, чтобы Telegram не думал, что это теги 🤯. Например:

• < — превращается в &lt;

• > — превращается в &gt;

• & — превращается в &amp;

Важный нюанс:

После escape() текст становится длиннее. Поэтому порядок работы с текстом ответа в коде должен быть такой:

• Сначала применяем к тексту escape() 🤔.

• Потом делим то, что получили на части, чтобы не упереться в лимит Telegram для одного сообщения (4096 символов) 🤔.

• В конце форматируем части, оборачивая их в цитату или выделяя жирным 🤔.

Вывод: чтобы бот не ломал ответы на ровном месте — можно один раз написать корректный обработчик текста с escape() и разбивкой на части, а дальше просто стандартно его использовать ✅.


2. Почему если в системном промте, который уходит из бота в ИИ-сервис, жёстко задан язык ответа — модель ИИ просто игнорирует эту настройку и становится непредсказуемой 🥵?

Суть:

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

Проблема:

Модель ИИ видит в начале системного промта настройку «OUTPUT_LANGUAGE=en», которая означает, что ответ нужно выдавать на английском языке. Но весь остальной системный промт, а также текст пользователя на русском языке 🥵.

Решение:

Так как в момент отправки запроса, мы точно знаем язык, который установил себе пользователь бота — просто собираем системный промт из словаря, в котором есть версия промта на русском языке, а также версия точно такого же промта на английском языке 👻. То есть мы просто держим версии одного промта на разных языках. Кстати, такая история ещё и нормально масштабируется, если нужно будет добавить новые языки. Да и словари — это как будто база базовая 😎.

Вывод: если хочешь стабильный язык ответа — лучше не пытаться «переломить» ИИ модель одной жёсткой строкой, просто дай ей системный промт на нужном языке ✅.


Вот такие два момента помогают сэкономить 1-2 дня разборов с кривыми ответами или с нестабильным поведением ИИ модели 🤓. Скажите, было полезно? Могу ещё рассказать про нюансы разработки ботов как-нибудь 👩‍💻.


⌨️ — Было полезно.
☺️ — Просто лайк.
🔮 — Делаю ботов, жду еще разборы.
💡 — Еще не делаю ботов, но собираюсь.


#Статья 📚

Всем привет 👩‍💻!

Поймал себя на мысли про рынок труда и ИИ. Хочу её зафиксировать:

Баланс хардов и софтов реально сдвинулся в последнее время.

Давайте ниже эту мысль раскроем 😁.


Раньше было проще 🤔. Сильные харды сразу видно:

• Пет-проекты,

• Код на гитхабе,

• Мощный стек в резюме,

• «Я это делал сам» на собеседовании 👍.

Естественно, сейчас харды всё ещё ценятся, но просто доказать их стало сложнее. Потому что ИИ делает так, что очень много людей, которые не особо разбираются — выглядят так, как будто умеют, и причём довольно хорошо. И в такой реальности — уже непонятно, где человек реально шарит, а где просто нормально «промтит» и собирает 🌚.


У меня такое ощущение, что именно из-за этого — рынок стал платить не за «я знаю», а за «я довожу до результата» 🤔. Тут важная оговорка, чтобы без иллюзий:

Харды никуда не делись. На сложных системах без хардов ты просто утонешь 🥵.

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


Ниже опишу то, что сейчас стало весить сильнее по моим ощущениям:

• Умение нормально выяснять задачу 🤯.
Не просто «я так понял», а докопаться, что надо и что на самом деле происходит.

• Коммуникация 🖥.
Донести, зафиксировать, договориться, при этом не развалить процесс.

• Ответственность 😎.
Сделал → выкатил → проверил → собрал фидбек → улучшил и так по кругу.

• Системность 🧠.
Умение ставить правильный приоритет и декомпозировать задачи, а также контролировать риски по ним.

И вот, кстати, прям больная тема: пет-проекты как маркер «я это умею» как будто обесценились, особенно если это просто проект в папке на рабочем столе. Дело в том, что сейчас пет-проект можно собрать быстрее, чем раньше 🏃. Поэтому реально важно, когда он в состоянии «я довёл до столкновения с реальностью», а не в «я просто сделал и потестил сам» 🚬. К слову, после столкновения с реальностью:

• У пет-проекта появятся: пользователи, метрики, может быть монетизация.

• У автора пет-проекта: end-to-end опыт доведения своего проекта.

Вывод для себя я вижу такой ⌨️:

Софты сейчас прокачивать проще всего и выгоднее всего, потому что именно они стали сильнее отличать людей друг от друга.

А харды — да, их тоже надо держать, но часть хардов реально можно ускоренно подтягивать с ИИ, если не лениться, потому что ИИ ускоряет путь «понял → сделал → поправил».

Если совсем кратко, то ощущение такое: сейчас выигрывают те, кто быстро тестирует гипотезы, хорошо общается и доводит до результата, а не до «почти готово» 😐. Как вам такой взгляд?


🔮 — согласен, софты стали важнее.

🍾 — нет, харды всё ещё решают.

⌨️ — где-то посередине.

☺️ — просто лайк.


#лайф 🤝🏻

Всем привет 😐! Сегодня хочу рассказать про три основных архитектуры приложений или систем, о которых часто говорят на начальном этапе проработки приложения — и это, кстати, часто спрашивают на собесах 🤔:

• Монолитная архитектура,

• Микросервисная архитектура,

• Сервисно ориентированная архитектура, сокращённо SOA.

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


1. Монолитная архитектура — это один большой гипермаркет.

Представьте большой гипермаркет «всё в одном» (монолит): можно купить одежду, еду, столовые приборы, даже склад с товарами есть — всё внутри одной системы. В чём же подвох 🤔? Рассказываю:

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

2. Микросервисная архитектура — это рынок.

Представьте рынок с кучей палаток (микросервисов), на котором каждая палатка отвечает за своё: мясо, овощи, кофе, штаны, куртки, шапки. У каждой палатки свои правила, свои стратегии продаж и продавцы, своя логика 🥵. Все эти палатки общаются между собой напрямую — условно «через API». Например, продавец первой палатки пришёл во вторую, спросил цену товара, договорился, сделал закупку и так далее. То есть нет единого центра, который «пропускает» каждое взаимодействие продавцов через себя. В чём же тут подвох 🤯? Рассказываю:

Такая архитектура даёт отличную гибкость и независимость «палаток» друг от друга, но за это приходится платить инженерными сложностями: нужно поддерживать API, заниматься версионированием, отслеживать ошибки интеграций между «палатками», поддерживать наблюдаемость нашей системы 😡.

3. SOA — это торговый центр.

В торговом центре тоже много магазинов, но они сильно больше рыночных палаток 😁. Также ощущение от торгового центра другое, так как есть общая инфраструктура и общий коридор, через который все ходят и взаимодействуют. В данном коридоре находится администрация, которая отслеживает корректность взаимодействий между магазинами. Если кто-то что-то нарушает, то его дальше не пропускают 👻.

Как вы уже догадались, коридор с администрацией — это аналогия на интеграционную шину, которая проверяет корректность данных, пересылаемых от одного магазина другому, с помощью правил, которые «вшиты» в эту шину 👍. Сотрудники магазинов могут напрямую не знать правил, но обязаны им следовать, иначе их попросту не пропустят в общий коридор 😱.

Если подытожить пункты выше: с монолитом все ясно, SOA обычно более централизованная, а микросервисная архитектура более децентрализованная. Вот и вся суть 🤝🤝.



Куда же без вишенки на торте 😎? Давайте закончим этот пост простым объяснением для обработчика сообщений, который появляется в микросервисной архитектуре и SOA. Кстати, про эти обработчики сообщений тоже часто любят спрашивать 👈. Сходу закину простой прикладной пример:

Если API — это «подойти и поговорить в моменте», то очередь или брокер сообщений — это оставить заявку через администратора или курьера, которая потом гарантированно доберётся до адресата 🗂.

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



Как вам такой пост, было полезно? Кстати, что думает насчёт постинга раз в неделю по воскресеньям (иногда со сдвигом на понедельник)? Как будто так будет удобно и стабильно 😺.



💎 — Кайф, еще бы почитал такое.

💡 — Первый раз слышу о таком.

⌨️ — Постинг в вс отличная идея.

☺️ — Без разницы когда выходят посты, главное чтобы выходили.



#Статья 📚

Ребята, всем привет 😎! Залетаю в ленту в середине недели, потому что на выходных ездил на машине в Минск 💨.

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

Вообще ездить на своей машине (какая бы она ни была) — это кайф: смотришь природу, чувствуешь расстояние, находишься «в моменте» 👍. Но после этой поездки я прям прочувствовал одну штуку: чем лучше машина, тем более «экспоненциально» растёт удовольствие от дальняка. Особенно когда расстояние большое и ты за рулём много часов подряд 🤔.



Перед выездом я думал, что 700 км — это 8 часов, если трасса свободная. Ошибался 🥵. По факту получилось примерно 11-12 часов в среднем из-за остановок, погоды и темпа 🤯.

Минск очень понравился: широкие и чистые улицы, спокойно, людей мало. Сначала это ощущается странно, но когда вернулся в Москву — вот там уже стало непривычно от толп людей и темпа 🥵.

Единственный минус — времени было мало, поэтому нормально поездить по городу и окрестностям не получилось. И это как раз тот пункт, который хочется наверстать. Возможно, в следующий раз попробую побороть страх перелётов — тогда на исследование будет больше времени, а также не будет ватности после дороги. Но тут ключевое слово «возможно» 🥸.



В общем, ставлю поездке 8/10: было очень интересно, но физически тяжело из-за плотной езды.

Обязательно поеду ещё — просто уже с чуть более продуманным планом, чтобы кайфа было больше, чем физической усталости 😤.

Кстати, следующий пост будет про REST и SOAP — уже в стандартном режиме. Это я держу в курсе 😁.



☺️ — тоже люблю ездить на машине.
🔮 — лучше бы полетел на самолете.
⌨️ — я тоже боюсь самолетов.
💡 — жду про REST и SOAP.



#лайф 🤝🏻

Всем привет 😐! Продолжаю тему API. Сегодня разберём REST и SOAP так, чтобы стало понятно, даже если вы не работали с интеграциями вообще.

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



1. REST — это общение «как в современном мире» 😁.

REST чаще всего выглядит как обычные ссылки и запросы в интернете. Например, у вас есть система с документами. Тогда API будет примерно таким:

• POST/documents → «Создай документ».

• GET/documents/123 → «Дай документ №123».

• PUT/documents/123 → «Обнови документ №123».

• DELETE/documents/123 → «Удали документ №123».

И почти всегда данные внутри — в формате JSON 😤. Это такой формат «ключ: значение», который легко читать и человеку, и машине. Например, ответ метода POST/documents будет выглядеть как-то так:

{
  "id": 123,
  "type": "act",
  "status": "created"
}

Теперь почему REST любят, загибайте пальцы 👍:

• Быстро делать.

• Быстро менять.

• Удобно дебажить, открываешь Postman/Swagger — и вперед.

• Легко подружить с вебом, мобильным приложением или микросервисами.

2. SOAP — это общение «как через официальное письмо» 🥵.

SOAP — это уже другая атмосфера, в которой всё строго и официально 🤪. Тут данные обычно гоняются в XML — это формат, где всё завёрнуто в теги, например:

<Document>
  <Id>123</Id>
  <Type>act</Type>
  <Status>approved</Status>
</Document>

И самое главное, в SOAP почти всегда есть жёсткий контракт, который описывает 😎:

• Какие методы существуют.

• Что они принимают.

• Что возвращают.

• Какие поля обязательные.

• Какие типы данных допустимы.

Эта штука обычно описана через WSDL или XSD 😏. WSDL — это описание методов и их параметров, а XSD — это схема того, как должен выглядеть XML-файл с собранными данными. Тут сильно останавливаться не буду, так как наберётся на отдельный пост 🥵.

Давайте лучше напишу, где SOAP часто встречается 🤔:

• Банки,

• Практически весь госсектор,

• Крупные «федеральные системы»,

• Любые максимально формальные интеграции, если обобщить.

3. Теперь, когда основа ясна — давайте поговорим про самое важное отличие простыми словами ☺️.

REST — мы договорились общаться, но «формат» нашего общения можно двигать быстрее.

SOAP — вот правила общения на 50 страниц, и ты обязан говорить ровно по ним.

Отсюда вытекает главная головная боль, которую я сам постоянно вижу: доработки в SOAP обычно делаются очень долго 🤬. И это не «мне так кажется» — это реально типичный сценарий.

Спросите почему ❌? Потому что изменение — это не просто «добавить одно поле». Обычно цепочка, по которой идёт изменение, такая:

• Согласовываешь изменение с другими системами,

• Меняешь контракт: XSD-схему и описание метода,

• Тестируешь изменение в тестовом контуре от и до,

• Потом выкатываешь данное изменение на продуктивный контур.

И вот так «добавим один новый атрибут в XSD-схему» превращается в мини-проект на несколько недель 🫣.

Справедливости ради, в REST тоже бывают контракты, но там чаще проще 😁:

• Добавил поле с атрибутом в ответ, который возвращает метод,

• Обновил Swagger/OpenAPI.

Чувствуете, насколько легче звучит? Я, да 👍.


4. Закономерный вопрос: тогда зачем вообще SOAP, если он такой тяжёлый?

Отвечаю 😎. Потому что SOAP часто выбирают там, где важны: формальность, предсказуемость, а также, чтобы каждая сторона говорила строго одинаково. Также, если понимаете, что интеграция на годы и будет редко меняться — это ваш случай.



Что в итоге 🌚?

Совсем кратко: SOAP — это как официальный документооборот, а REST — как быстрый чат. Кратенько по различиям, для закрепления: REST — быстрее, проще, гибче, а SOAP — строже, тяжелее, но по регламенту.

Кстати, уже неплохая база под прохождение собеседований получается 😤. Потом нужно будет собрать всё это в один «подготовительный» пост, когда напишу про контракты и брокеры сообщений отдельно. Здравая идея ⌨️?



💡 — стало понятнее.

☺️ — просто кайфовый лайк.

🖥 — давай подробнее про контракты: Swagger / WSDL / XSD.

⌨️ — давай потом ещё про очереди и брокеры сообщений.



#статья 📚

Всем доброго вечера 👩‍💻! Решил спонтанно написать в канал в середине недели и рассказать, что последние две недели очень плотно занимаюсь режимом. Это, оказывается, реально трудно: ложиться до 00:30 и спать минимум 7–8 часов. Интересно, как у вас с этим 🤔?

За эти две недели я уже пару раз ложился сильно позже 00:30, ну и несколько раз просто не мог уснуть вообще. Не думал, что это настолько сложно 🥵.

Наверное, проблемы с быстрой перестройкой вылезли из-за того, что последние пару месяцев я садился за свои проекты как раз в районе 23:30 и сидел в полном фокусе до 2:30 ночи. Первое время проблем из-за ночной работы не было, но потом настроение начало качаться в разные стороны, как маятник 😡.

В общем и целом, сейчас, с налаживанием режима, энергии и сил стало заметно больше — несмотря на слякоть на улице. Чувствую, что принял правильное решение. Правда, личные проекты немного пострадали: их пришлось заморозить на несколько недель, хотя они уже готовы на 80% и 90% 😱.


Честно скажу: за данный период я понял, что этот канал — одна из самых ценных вещей, которая у меня есть 🏆. Очень ценю вас и благодарю за то, что находите время читать то, что я пишу. Спасибо вам 🤝🤝!

Сейчас наметил для себя такой путь:

• Пересобираю навигацию по этому каналу, потому что тематики стали разнообразнее, а постов накопилось много 👍.

• Доделываю бота, который конвертирует эмоциональную речь в деловую, и дропаю сюда 👍.

• Доделываю приложение с трекингом активностей и привычек и тоже дропаю сюда 👍.

По результатам буду кратенько отписываться в формате лайф-постов. А технические посты никуда не денутся — к концу недели напишу про очереди и брокеры сообщений, как и планировал ⌨️.


#лайф 🤝🏻

Всем привет ☺️! Продолжаю тему интеграций.

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



Если совсем коротко:

• API — это «подойти и сразу получить ответ».

• Очередь — это «оставить задачу на обработку».

• Брокер сообщений — это система, которая такие задачи принимает, хранит и раздаёт дальше.

Теперь разберем на простом
примере:


API — это как подойти к человеку, задать вопрос и не уходить, пока не получишь ответ 😡.

Например, ты говоришь: «Отправь комплект документов во внешнюю систему прямо сейчас».

Если всё ок — ответ получаешь быстро. Но если система, к которой ты обращаешься:

• Отвечает долго 🥵,

• Перегружена 🥵,

• Временно недоступна 🥵,

• Просто упала 🥵,

то ты будешь стоять и ждать. А если таких запросов много — ждать будут уже все 😱.


Очередь и брокер — это «оставить записку и уйти». Теперь сценарий другой 😐.

Ты не стоишь и не ждёшь ответ прямо сейчас, а просто оставляешь задачу: «Нужно отправить комплект документов №123».

Сообщение с твоей задачей попадает в очередь, а потом обрабатывается брокером. В этом вся прелесть ☺️.


Итог на бытовом примере таков:

• API — это подойти к человеку и ждать, пока он ответит.

• Очередь — это оставить записку на холодильнике.

• Брокер сообщений — это система, которая этот «холодильник» обслуживает: принимает записки, хранит их и отдаёт в обработку.

Самый главный плюс тут в том, что тебе не нужно ждать ответ в моменте. Ты просто передал задачу и пошёл дальше 😤.



Тогда кто делает реальную работу?

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

Он не знает, как:

• Отправлять документы,

• Начислять бонусы,

• Обновлять статусы,

• Рассылать уведомления.

Он только доставляет сообщение 🥵.

А реальную работу делает обработчик сообщений — это уже отдельный код или сервис, который принадлежит системе-получателю 😁.

То есть:

• Брокер — хранит и раздаёт задачи.

• Обработчик — забирает задачу и выполняет её.

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



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

Допустим, пользователь нажал кнопку «Отправить комплект документов» 👩‍💻.

Без очереди система должна прямо в этот момент:

• Собрать данные.

• Упаковать их.

• Отправить наружу.

• Дождаться ответа.

• Обработать ошибку, если что-то пошло не так.

С очередью логика другая:

• Пользователь нажал кнопку.

• Система быстро создаёт сообщение: «Отправить комплект №123».

• Кладёт его в очередь.

• Пользователь сразу получает ответ: «Задача принята в обработку».

• Дальше обработчик сам забирает сообщение и делает тяжёлую работу в фоне.

Зачем это вообще нужно?

Очереди и брокеры сообщений используют не потому, что это модно и круто, а потому что это делает систему:

• Быстрее для пользователя — не нужно ждать тяжёлую обработку 👍.

• Устойчивее — если внешняя система временно недоступна, сообщение не пропадает сразу 👍.

• Масштабируемее — если задач стало много, можно добавить больше обработчиков 👍.

• Менее связанной — одна система не обязана всё время ждать другую 👍.

Именно поэтому такие штуки часто появляются там, где есть:

• Отправка документов 🌚.

• Уведомления 🌚.

• Платежи 🌚.

• Синхронизация данных 🌚.

• Тяжёлые фоновые процессы 🌚.

Ещё один важный нюанс!

Сообщение может прийти не один раз. Например, из-за повторной отправки или ошибки при обработке 😏.

Поэтому обработчики обычно делают идемпотентными.

Страшное слово, но смысл простой: если одно и то же сообщение пришло повторно, система не должна сломаться или сделать одно и то же действие дважды ☺️.

В итоговом итоге — именно поэтому очереди и брокеры так любят в больших системах: они делают архитектуру не «сложной ради сложности», а живучей ☺️.



P.S. Вот такая ночная паста получилась 🤪.



☺️ — стало понятнее.

🔮 — жду лайф-пост.

⌨️ — просто лайк, спасибо.

💡 — давай теперь про контракты обмена: Swagger, WSDL, XSD.



#статья 📚

Наконец-то я запустил своего Telegram-бота и теперь хочу отдать его на живой тест 😐!


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


Что бот делает:

• Убирает лишние эмоции и токсичность из текста.

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

• Подходит для деловой переписки, сообщений клиентам и ответов на почту.

• Экономит время на формулировках, когда не хочется подбирать слова вручную.

Если потестируете бота и дадите развёрнутый фидбек по делу, я дам вам в благодарность 7 дней бесплатной подписки 🙌🙌. Подписка просто увеличивает дневной лимит запросов 😤.


Что особенно интересно узнать:

• Что удобно / неудобно 🤔?

• Чего не хватает и что стоит улучшить 🤔?

• Что непонятно 🤔?

• Где бот реально полезен 🤔?

• Нашли ли какие-то баги 🤔?

Вот ссылка на бота: @TextHelperTGBot


Честный фидбек сейчас — это самая полезная помощь для меня 🤝🤝.


#лайф 🤝🏻

Всем привет! Продолжаю тему интеграций 👩‍💻. Сегодня хочу простыми словами разобрать контракты обмена: Swagger, WSDL и XSD 🖥.

На мой взгляд, это одна из тех тем, которая сначала кажется скучной, а потом резко становится очень важной, когда интеграция начинает ломаться на ровном месте 🥵.



Сразу суть:

Контракт обмена — это заранее зафиксированное правило, по которому две системы общаются друг с другом 👻.

Зачем он нужен?

Потому что фразы уровня: «ну мы же договорились, что там придет номер, дата и статус» — в реальной жизни не работают 🫣.

Давайте смоделируем ситуацию:

• Система А — отправила дату строкой.
• Система В — ждет нормальный формат даты.

• Система А — назвала поле clientId.
• Система В — ждет поле customerId.

• В системе А — поле необязательное.
• В системе В — это поле обязательное.

И вот, казалось бы, системы А и В всего лишь обменялись данными, а по факту: словили баг, откат интеграции, созвон с выяснением, кто что имел в виду 😤.



Контракты обмена проще понять, если в начале ввести какой-нибудь наглядный бытовой пример 🤔. Представьте два склада, которые постоянно пересылают друг другу коробки с товарами 😐.

Если между ними нет нормального регламента, начинается хаос:

• На одной коробке написали артикул, а на другой забыли 🥵.

• Где-то вес указан числом, где-то текстом 😦.

• Где-то обязательна накладная внутри, а где-то на это просто забили 🤪.

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

• Что должно быть на коробке,

• В каком формате это должно быть указано,

• Что обязательно,

• Что опционально,

• И по какому маршруту всё вообще едет.

Теперь переведем это в более технические термины:


Swagger — это, если говорить по-простому, удобное и наглядное описание REST API 🔍. В нём видно:

• Какие методы есть,

• Что они принимают,

• Что возвращают,

• Какие поля и параметры нужны.

Плюс его удобно открывать, читать и сразу тестировать 🌚. Поэтому для REST-интеграций это максимально рабочая и удобная история 👍.


WSDL — это уже более официальный и тяжёлый контракт, который часто идет рядом с SOAP 😡. Если упростить, WSDL описывает:

• Какие операции вообще доступны,

• Какие сообщения можно отправлять,

• В каком виде это происходит,

• Куда именно нужно стучаться.

То есть это уже не просто «список REST-ручек», а более строгий регламент взаимодействия 😎.


XSD — это схема, которая говорит, как конкретно должен выглядеть XML с собранными данными 👍. Проще говоря, в сравнении с WSDL:

• WSDL отвечает на вопрос: что умеем делать?

• XSD отвечает на вопрос: как именно должны выглядеть данные внутри сообщения?

То есть с помощью XSD мы можем жёстко зафиксировать, что:

• OrderId — это целое число,

• Date — это дата в нужном формате,

• Status — только из допустимого набора значений,

• А какое-то поле вообще обязательно и без него документ невалиден.

И вот здесь как раз становится понятно, зачем всё это нужно. Контракты обмена — это не бюрократия. Это способ сделать так, чтобы две системы одинаково понимали одни и те же данные 🤓.

Что это даёт на практике 😳? У вас: меньше сюрпризов на интеграции, быстрее находите ошибки, легче тестировать, проще дорабатывать, ниже шанс, что одна сторона поймёт данные «по-своему». И еще миллион плюсов 👍.

Если подытожить совсем кратко, для закрепления:

• Swagger — удобный контракт для REST,

• WSDL — формальное описание взаимодействия в SOAP,

• XSD — строгая схема самих XML-данных.

А общий смысл у них один: не дать системам «договариваться на словах» 🤝🤝. Потому что в интеграциях самая дорогая по времени фраза обычно звучит так: «Я думал, вы это поле по-другому обрабатываете» 🤯.



💡 — стало понятнее.

⌨️ — полезно, нужны ещё такие посты.

💎 — жду лайф-пост.

😎 — просто лайк.



#статья 📚

🌎 Навигация по Math and Code


Чтобы не теряться в канале — собрал пять подборок по темам. Заходи в нужную и читай по порядку или вразнобой.


⚙️ Аналитика и системное мышление

🟦 Математика, физика и точные науки

🖥 Код и разработка

👨‍💻 Мои проекты: боты и приложения

⌨️ Лайф: режим, мысли и выводы


Подборки будут дополняться по мере выхода новых постов.


#навигация 📝

Всем привет ⌨️! Хочу зафиксировать одну мысль про своего бота @TextHelperTGBot, которого я недавно выкатил в прод.

Если кратко: бот не взлетел.

Какого-то заметного спроса не случилось, да и по БД видно, что пользовались им совсем мало. Тут, как будто, есть два базовых варианта:

• Либо я не совсем попал в ЦА.

• Либо сам бот закрывает слишком узкую задачу, чтобы люди реально встраивали его в свою повседневность.

Но при этом во всей этой истории есть момент, который меня скорее порадовал, чем расстроил.

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

И вот здесь я поймал очень простую мысль:

В саму потребность я, похоже, всё-таки смотрел правильно 🌚.

То есть проблема была не в том, что запрос надуманный. Запрос как раз реальный. Проблема, скорее, в другом:

Я попытался закрыть эту потребность не на своем уровне 🥵.

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


Была ещё мысль пофантазировать, что кто-то где-то увидел мою идею, вдохновился и выкатил её на весь Telegram. Звучит, конечно, красиво, но это скорее история из параллельной вселенной 🖕.

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

И вот это, кстати, очень полезное столкновение с реальностью.

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


Если подытожить, для себя я из этой истории вынес вот что:

• Потребность можно считать верно, но промахнуться с формой реализации.

• Пет-проект ценен даже тогда, когда не выстрелил, потому что он быстро возвращает тебя из мира гипотез в мир фактов.

• Столкновение своих идей с реальностью — это не провал, а нормальный способ калибровать мышление.

Так что едем дальше. Скоро, думаю, принесу сюда уже свой Telegram Web App — и там тоже будет очередное столкновение с реальностью, только уже на новом уровне 🤪. В этот раз хочу не забыть открыть комментарии, чтобы максимально собрать живой фидбек.


P.S. Кстати, по моим трем долгам, о которых я писал, картина позитивная:

1. Навигацию в канале — сделал ✅.

2. Бота — сделал ✅.

3. TG Web App — сейчас как раз активно добиваю 🥊.

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

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


⌨️ — уважаю такой подход.

😎 — здравая рефлексия.

🖥 — жду пост про TG Web App.

🍾 — сталкивался с таким же у себя.


#лайф 🤝🏻

Ребята, привет ⌨️.


В последние дни плотно занимаюсь миграцией своего таймтрекера с Flutter на новый стек: React 18 + TypeScript + Vite + Tailwind CSS + FastAPI + PostgreSQL.

Чувствую, что достаточно прокачался в веб-разработке, чтобы показать то, что получилось в итоге.


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

1. Сколько постов в неделю вам комфортно читать?

2. В какое время вам удобнее их видеть?

Ниже закину опрос. Если хотите, можете ещё написать в комментариях, какой формат постинга вам заходит больше всего и почему 👍.


#лайф 🤝🏻

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

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

Звучит разумно. Но тут как раз и спрятан главный подвох. Давайте разберём по шагам.


1. Что значит «локально лучший» и «глобально лучший» 😐?

Представьте, что у нас есть задача, в которой нужно собрать итоговое решение из последовательности шагов. Тогда можно смотреть на неё с двух уровней:

• Локально — какой шаг выгоднее прямо сейчас.

• Глобально — какое итоговое решение лучше среди всех возможных.

Если записать совсем формально, то глобальная цель выглядит так: найти решение S*, для которого значение F(S*) оптимально на множестве допустимых решений.

Ну а сам жадный алгоритм мыслит проще:

• Смотрит на текущее состояние задачи;

• Выбирает лучший шаг прямо сейчас;

• Не перебирает все будущие последствия этого шага;

• Обычно не откатывается назад.

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


2. Когда жадный алгоритм вообще работает 😺?

Тут нужно сразу сказать важную вещь: жадный алгоритм — не «плохой» и не «наивный». Во многих задачах он работает отлично. Обычно для этого должны выполняться два условия:

• Лучший шаг сейчас не ломает лучшее решение потом.

• Оставшаяся часть задачи после такого шага сохраняет ту же структуру.

Если сказать совсем по-простому: если локально хороший выбор совместим с хорошим итогом — жадный подход сработает. Если нет — он даст красивое, но слабое решение.


3. Давайте посмотрим маленький математический пример, где жадность мощно ошибается 😐.

Допустим, у нас есть монеты номиналом: 1 рубль, 3 рубля, 4 рубля. Нужно набрать сумму 6 рублей минимальным количеством монет.

Что сделает жадный алгоритм? Первым делом он выберет самую большую подходящую монету:

• Берём 4 рубля, так как она самая большая.

• Остаётся добрать 2 рубля.

• Берём два раза по 1 рублю.

• Итого, жадный алгоритм собрал 6 рублей тремя монетами.

Но оптимальное решение другое: две монеты по 3 рубля. Что произошло? Жадный алгоритм выбрал лучший в моменте вариант — монету в 4 рубля. Но этот локально лучший шаг испортил итоговый результат.

Это и есть главная мысль всего поста: иногда ближайшая выгода уводит от лучшего итога.


4. Где это встречается в реальной жизни 🌚?

На самом деле — почти везде. Например, у тебя есть 4 часа вечером. Можно сделать одно из двух:

• Либо сесть за одну сложную задачу, которая реально двигает проект.

• Либо закрыть 4 мелкие и понятные задачи, чтобы быстро почувствовать прогресс.

Жадный алгоритм в голове обычно говорит так: «возьми то, что проще, что быстрее закрывается, где награда ближе».

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

Что произошло? Расскажу:

• Локальная функция «почувствовать быстрый прогресс» была максимизирована.

• Глобальная функция «реально продвинуть важный результат» — нет.

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


5. Где здесь главный вывод 👍?

Жадный алгоритм полезен там, где задача устроена так, что лучший шаг сейчас действительно совместим с лучшим итогом.

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


P.S. Если совсем кратко, главный вывод такой: не всякая ближайшая выгода ведёт к лучшему исходу. Иногда самый разумный на вид шаг — это просто способ проиграть на дистанции 😦.


⌨️ — использовал этот алгоритм в коде.

🍾 — буду применять в жизни, но с головой.

💡 — главное двигать ядро проекта, а не имитировать движение.

😎 — лайк.


#статья 📚