Всем привет ⌨️! Наконец-то нашел время на небольшой лайф-пост про свой Telegram мини-апп, на который сейчас уходит почти все свободное время 😱.


Сначала кратко 👩‍💻:

• Много времени ушло на темную и светлую тему, чтобы мини-апп корректно подхватывал их из Telegram ⏳.

• Долго разбирался, как отключить системный свайп, который сворачивает мини-апп 🕹.

• Когда все стало «нормально работать», занялся рефакторингом, чтобы стало плавно и стабильно 🌃.

Теперь подробнее, что получилось сделать:

• Единый стиль 🧐.

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

• Списки без дерганий 🧐.

Я использую вертикальные списки, и при смене порядка элементы подскакивали. Чтобы исправить, пришлось кэшировать текущее состояние списка и пересобирать логику рендера этого списка — теперь перетаскивание гладкое, без «подскоков».

• Пришел к тому, что использовать тикер нужно только там, где он нужен 🧐.

Звучит очевидно, но вначале об этом не думаешь и просто вешаешь тикер на всю страницу. По итогу изменение одного элемента влечет за собой перерисовку всей страницы. Долго правил и встраивал тикер в конкретные виджеты. В результате мини-апп перестал подлагивать. Если честно — получилось только с третьего раза. В будущем сразу буду продумывать логику обновления виджетов на страничке.

• Живые графики без мельтешения 🧐.

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

• Анти-свайп — мастхэв 🧐.

Если у вас есть вертикальные списки, системный свайп Telegram будет сворачивать ваш мини-апп при прокрутке вверх. Это бесит. Решение: отключать свайп ещё на старте, прямо из index.html, и делать это с ретраями — Telegram API не всегда «просыпается» сразу. Звучит вроде просто, но боролся я с этой проблемой долго. Зато очень приятно, что анти-свайп работает стабильно.

• Нормальный деплой 🧐.

Я ушёл от ручной заливки и сделал автодеплой со схемой версий: каждый релиз — в отдельную папку, стартовая страница index.html указывает на релизный index.html из последней релизной папки. Плюс смог настроить кэш-политику. Теперь Telegram не «липнет» к старым версиям, а первая загрузка быстрая. Когда этого не было — я переустанавливал Telegram, чтобы пробить кэш, это просто ад.

Что вообще удалось вынести из всего этого 🤔:

• Если у вас есть желание что-то закодить своими руками — лучше это сделать, чем просто думать об этом. К слову, со временем очень затягивает 📚.

• Нейросети, особенно продвинутые — очень сильно помогают. Главное не просто делать ctrl+C и ctrl+V, а разбираться в том, что предлагает нейросеть и задавать вопросы. Со временем получится самостоятельно закрывать какие-то доработки и без сторонней помощи писать хелперы или описывать нужные классы. Очень хороший бустер, особенно когда хочется сразу видеть какой-нибудь результат 👁.

• Если, в итоге, мини-апп будет неиспользуемым, то я смогу забустить свое резюме описанием разработки от и до. Это приятный бонус 🔮!

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


💡 — лайк авансом.
🌊 — жду про подключение БД.
⌨️ — пойду поделаю свое приложение.


#лайф 🤝🏻

Внеплановый лайф-пост: почему притормозил с подключением БД?


Буквально в день, когда я сел подключать БД к мини-аппу, в голову пришли новые фичи и вообще новый отдельный раздел мини-аппа 🔥!

Принял решение отложить подключение БД и реализовать новый функционал ⌨️.


Сейчас этим уже занимаюсь и понимаю, что на 90% это правильное решение 👍. Объясню почему:

1. Во-первых, перед подключением БД нужно оптимизировать приложение, чтобы потом не гадать, из-за чего оно подвисает.

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

Вообще заметил, что в этот раз новый раздел вводить было намного проще. Жаль, что я не отслеживал, сколько времени это заняло в самый первый раз. По ощущениям, сейчас 100% быстрее 😀.

На самом деле очень жду момент, когда смогу сделать большое код-ревью, чтобы исходный код был максимально читаемым и масштабируемым. А там уже и до переезда на JS недалеко 🤨.

Но вообще переезд — не факт, что хорошая идея. Сяду с этим разбираться, когда закрою текущие задачки, а то, как всегда, бегу вперед 🌚.


💎 — нравится такой лайф-формат, его нужно больше.

💡 — жду какой-нибудь лонгрид на интересную тему.

😎 — интересно узнать, что с этим приложением будет в итоге.


#лайф 🤝🏻

Привет 😐! Недавно задумался о том, как именно работает доминанта. Если говорить кратко, то это утренняя установка на день, которая задает общее настроение 😎.


Простыми словами 🥱.

Доминанта — это призма: она не меняет факты, она меняет веса их интерпретации. Закрепишь в голове «сделаю минимум и продвинусь» — рутинные и сложные события читаются спокойнее 🤤. Закрепишь «я не вывезу» — те же события кажутся хуже и «подтверждают» провал 😨.


Раскроем суть ⌨️.

На мой взгляд, доминанта двигает два ключевых рычага:

1. Порог реакции 🤔.

Что считать важным, а что — нет. Одно и то же событие с разным порогом проходит фильтр по-разному: либо «сделаю позже», либо «занимаюсь этим сейчас».

2. Луч внимания 🤔.

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

Плюс есть инерция. Как только одна тема вырывается вперед, она «подтягивает» соседние: в голове формируется сюжет, и дальше все начинает подстраиваться под него 👩‍💻. Поэтому важны не только мысли, но и среда, в которой ты находишься в данный момент: настроение, люди рядом, физическое состояние — другими словами, это входы, которые усиливают доминирующий сюжет и ослабляют другие 🚶.



Давайте формализуем ⏳.


1. Разберем пороговый взгляд на ситуацию 🤯. Сырую оценку ситуации можно посчитать так: z = w · x + b, где:

• x — факты, связанные с ситуацией.

• w — веса этих фактов.

• b — смещение.

Решение по ситуации — это y = sign(z) 🤪. Функция sign() возвращает либо +1, либо -1 в зависимости от входной сырой оценки. Доминанта в этой формуле — это именно сдвиг b . Ее роль заметна при фиксированных w · x:

• Рост b повышает шанс, что z > 0 → нейтральная ситуация читается как «у меня получится / я разберусь».

• Падение b → нейтральная ситуация читается как «я не смогу / ничего не получится».

2. Рассмотрим конкурирующие мысли и распределение внимания ☠. Обычно несколько оценок z₁, z₂, …, zⱼ соревнуются за внимание. Доли внимания можно посчитать так: aᵢ = (e^(βzᵢ)) / (∑ⱼe^(βzⱼ)), β = 1 / T, где:

• aᵢ — доля внимания к i-й мысли (сумма всех aᵢ = 1).

• β — «острота» распределения.

• Т — «температура» распределения.

Если β большое, а T низкая, то распределение острое и мысль, которая забирает большую часть внимания, в итоге получает все внимание, которое есть. Если β маленькое, а T высокая — взгляд шире и мысли получают больше «воздуха» 😁.


3. Перейдем к структуре связей 👻.

Мысли связаны как граф: одни активируют другие. Во времени внимание стремится выравниваться вдоль доминирующего собственного вектора матрицы связей графа, а именно туда, где связи сильнее всего. Роль доминанты — «подкрутить старт» и усилить нужные мысли так, чтобы система тянулась в правильную сторону ☺️.

4. Закончим динамикой 🥵.

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

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


⌨️ — никогда об этом не задумывался.
💡 — просто закину эту реакцию.
😎 — пользуюсь доминантой ежедневно.


#статья 📚

Всем привет! Решил закинуть небольшой лайф-пост о разработке приложения, плюс пару мыслей, которые ясно осознал к 26 годам 🥸.


Начну с приложения🥵.

Я практически закончил с полировкой и оптимизацией новых фич, про которые писал в позапрошлом посте.

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

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

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

Хотя отмечу, что вначале я этим правилом не пренебрегал, поэтому уже есть достаточно хорошая структура, но из-за усложнения проекта она устарела. В общем и целом, буду дорабатывать ☠️.


Теперь о мыслях 👍.

Сейчас они засели в моей голове, как основа основ:

• Лучше фокусироваться на том, что в твоей зоне влияния, и действовать, чем просто ждать, что все само сложится так, как ты хочешь 😐.

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

• В молодости важно как можно раньше начать осознанно искать дела, которые по-настоящему интересны. Чем раньше начинаешь такой поиск и задерживаешься вокруг того, что цепляет, тем меньше потом сожалений о годах в откровенно чужой деятельности 🤯.

• Чем раньше учишься нормально чувствовать себя наедине с собой — без бегства в шум и чужие ожидания, — тем проще потом общаться с людьми и не терять себя в них ☺️.

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


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


P.P.S. Внизу поста прилагаю фотокарточку первого дня зимы.


🍾 — Согласен с выводами в посте.
💎 — Лайк за фотокарточку.
⌨️ — Напишу в комментариях, а может, и нет.


#лайф 🤝🏻

Всем привет! Закидываю в ленту очередной лайф-пост 😤.


Закончил две трудные недели:

• Отработал 12 рабочих дней подряд 🥵.

• Прогнал своё приложение по «краевым» кейсам, попробовал его сломать и поискать дыры в архитектуре — на удивление, ничего критичного не нашёл 😎.

• Разнёс кучу кода из main по отдельным файлам, пересобрал структуру проекта и нормально связал части между собой 👾.

• Не забывал про спорт и растяжку — наконец-то вижу прогресс, а не просто галочки 😺.

Без косяков, конечно, не обошлось:

• Рваный режим и недосып 🌚.

• Не самое правильное питание — классика, когда хочется закрыть просадку дофамина 🥸.

Сегодня наконец-то позволил себе нормально выдохнуть и просто отдохнуть.

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

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

Всем хороших выходных 😎!


⌨️ — читаю в режиме отдыха.
🍾 — заберу выводы себе.
💎 — тоже пора устроить себе выходной.


#лайф 🤝🏻

Всем привет 🥱! Давно ничего не писал сюда, пора исправляться. Сегодня пост про рабочее место в прямом смысле и немного про мой мини-апп. Если непонятно, как это связано — сейчас расскажу 🎮.

Я впервые по-настоящему почувствовал, насколько сильно эргономичное рабочее место влияет на продуктивность. Раньше вообще не думал ни про эргономику кресла, ни про высоту стола, хотя за ним провожу полдня 😨.

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

С мышкой и клавиатурой всё понятно, а вот со столами и креслами сложнее. Кому-то стандартные варианты мелкие, кому-то, наоборот, огромные. Вот здесь в игру и включается математика, а именно: нормальное (гауссово) распределение 😐. Большинство людей — около «среднего» роста, под них и делают массовую мебель. Если вы ближе к краям распределения, т.е. выше или ниже среднего, — подобрать удобное рабочее место сложнее и чаще всего дороже 👊:

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

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


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

Я замерял, сколько времени трачу на свои проекты и дела за пределами работы — сначала со старым рабочим местом, потом уже с новым. По цифрам и ощущениям вышло так:

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

• Полностью ушли фоновые боли в спине и шее — сейчас что-то ноет только после хорошей тренировки с гирей 🤔.

• Тренироваться стал больше на 1 тренировку в неделю 🤔.

Параллельно я наконец-то пробил психологический блок по бэкенду мини-аппа и уже сделал несколько шагов:

• Настроил виртуальное окружение на Python ⏳.

• Описал БД и поднял кластер PostgreSQL в облаке — оказалось, что это не так страшно. Сейчас разработка стоит мне примерно 1 рубль в час (кластер останавливаю, когда не работаю, и выбрал минимальные настройки). Боевая конфигурация, конечно, будет дороже 🟦.

• Полностью описал методы API и погонял их через Swagger — очень удобный способ тестировать эндпоинты ⚙️.

• Подключил API к клиенту так, чтобы новые записи сразу улетали в БД 🖥.

Это, конечно, не финал. Дальше — забор данных из БД при старте приложения, аккуратный деплой и тесты с разных устройств 🙌🙌.


P.S. Как только закончу с бэком, сделаю отдельный пост про само приложение: что оно умеет и зачем оно вообще нужно. Если честно, мне самому уже надоело тянуть с этим 🥵.


💡 — давай подробнее про распределения и их применение.

💎 — интересно про порядок разработки бэка мини-аппа от и до.

⌨️ — жду анонс приложения и лайф-посты.


#лайф 🤝🏻

Всем привет ⌨️! Так получилось, что я приболел на днях и сейчас пожинаю все плоды температуры, кашля и заложенного носа 😐.

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


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

• Делал растяжку и отжимания вместо гири 😩.

• Перестал заниматься приложением по поздним вечерам — оставлял небольшие окна по 40–50 минут 😩.

• Как видите, канал тоже ненадолго заморозился 😩.

• Старался спать больше 8 часов, в идеале — 9 😩.

• Старался нормально есть 😩.

Как думаете, помогло ли мне это всё 🤔?

Ответ: нет.


Помогло ли это отсрочить надвигающуюся простуду 🥵?

Ответ: определённо да.


По итогу, сейчас в голове крутятся два варианта:

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

• Либо если уж чувствуешь, что заболеешь, то ничего с этим не сделать ☠.

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

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

Вот такая небольшая работа над ошибками в виде лайф-поста. Подержал вас в курсе, получается 😁.


☺️ — Выздоравливай.
⌨️ — Сам сейчас болею.
💡 — Держи в курсе.


#лайф 🤝🏻

Ребята, всем привет 😐! Врываюсь с очередным лайф-постом прямо накануне Нового года 🚶.


Прошло чуть больше двух недель с момента, как я заболел. Я даже не думал, что будет настолько тяжело вернуться к обычным рабочим нагрузкам 😐.

Симптомы гриппа прошли достаточно быстро: температура вернулась в норму, восстановился аппетит, я смог нормально дышать носом и не кашлять 24/7. На это всё ушло где-то 6–7 дней 🫥.

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

У меня буквально есть силы только на работу 🤔.

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

Очень тяжело вылезти из состояния апатии после болезни. Хотя, наверное, это нормально: организм тратит все силы на то, чтобы выздороветь, а потом ему нужно перезарядить «батарейку». Кстати, это состояние не похоже просто на выгорание от большой нагрузки. Оно скорее как внешнее ограничение на систему (твой организм), которое кто-то поставил 🌧.

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


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

Просто немного контекста для понимания: за эти две недели я занимался разработкой приложения часа 3 всего. Потестил работу API, зафиксировал баги с обращением к API в клиенте приложения — и всё. До правок я не дошёл 😙.

Но думаю, что на праздниках получится прийти в себя, к тому же основная работа на этот период отступит ⌨️.


Вот как-то так на данный момент. Я, кстати, ещё думал над темами постов и решил написать лонгрид на тему перфекционизма. Ну и ещё много чего придумал — со временем расскажу 😎.


💎 — терпеть не могу болеть.
🍾 — тоже в апатии после болезни.
⌨️ — почитал бы про перфекционизм.


#лайф 🤝🏻

Всем привет 🔥! С наступающим Новым Годом вас, ребята. Я благодарен вам за то, что мы вместе прошли через 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% 😱.


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

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

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

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

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

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


#лайф 🤝🏻