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

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

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

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


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

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

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

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

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

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


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

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

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


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

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

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

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

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

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

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

• У автора пет-проекта: 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. Если совсем кратко, главный вывод такой: не всякая ближайшая выгода ведёт к лучшему исходу. Иногда самый разумный на вид шаг — это просто способ проиграть на дистанции 😦.


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

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

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

😎 — лайк.


#статья 📚

Всем привет 😐

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

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

Очень часто это ощущение появляется не потому, что ты реально стоишь на месте, а потому, что находишься внутри перегретого инфополя 💥.

Сейчас это инфополе примерно такое:

• Кто-то за вечер собрал приложение с ИИ, а через неделю уже запустил «стартап».

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

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

И даже если стараться от этого дистанцироваться, полностью выпасть из такого фона почти невозможно.


Самое неприятное здесь в том, что ты начинаешь смотреть не на свой реальный прогресс, а на чужую витрину. Причём обычно сильно отфильтрованную. Никто толком не показывает недели тупняка, кривые решения, откаты назад, усталость и моменты, когда вообще не понимаешь, туда ли идёшь. Зато результат, скорость и уверенность показывают почти все.

Из-за этого легко попасть в ловушку:

Вроде бы ты делаешь много, но тебе всё равно кажется, что недостаточно 🥵.

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

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

Если делаешь что-то впервые, с разгоном лучше быть очень осторожным 😤.

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


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

• Cмотреть на свой прогресс и сравнивать себя настоящего с собой прошлым, а не с чужой витриной успехов.

• Не загонять себя только из-за того, что вокруг все кажутся слишком быстрыми.

• Не путать скорость с пониманием.

Как-то так порассуждал 👍.


😎 — знакомое состояние.

⌨️ — инфополе правда давит.

💎 — я запустил стартап за 1 день.

🔮 — тоже ловил себя на сравнении с чужой витриной успехов.


#лайф 🤝🏻

Всем привет 😤

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

И вот самый главный вывод из этого пути:

Инфраструктура — это не идеальная схема, а компромисс между надёжностью, сложностью, стоимостью и твоей способностью всё это обслуживать.

Я уже рассказывал про свой трекер и про его метаморфозы от сборки на Dart до сборки на TS. Теперь хочу рассказать про такие же метаморфозы, но уже со стороны инфраструктуры 🤝🤝.


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

Изначально, как это часто бывает, хотелось сделать нормально, но в итоге это превратилось в раздутый набор облачных сущностей: managed DB, serverless container, registry, object storage, VPC и так далее 🥵.

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

• Раздутой по деньгам.

• Сложной в понимании.

• Тяжёлой в сопровождении.

• Психологически давящей из-за количества сущностей.

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


После этого я перестал спрашивать себя: «что архитектурно красивее?» — и начал спрашивать по-другому: «что реально соответствует масштабу продукта прямо сейчас?» Ответ получился довольно честным:

Мне нужен один сервер, один понятный деплой-скрипт, один понятный источник правды с данными и минимум инфраструктурной «магии».

Так я и пришёл к one-VM подходу. И тут сразу важно проговорить: one-VM — это не обязательно костыль. В моём случае это осознанный компромисс, когда для текущего этапа важнее скорость, ясность, контроль и низкая стоимость, чем теоретическая идеальность.

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


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

Тяжелее всего — собрать рабочий продовый контур, где всё начинает жить вместе: VM, Docker, домен, DNS, HTTPS, фронт, бэк, продовая БД и деплой-скрипт в конце концов.

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


Чтобы это не звучало как просто размышление, отдельно зафиксирую, что уже работает по моему трекеру:

• Домен живой.

• HTTPS работает.

• Mini App открывается из Telegram.

• Фронт и бэк подняты.

• Данные пишутся в продовую БД.

• Деплой уже описан, но пока не собран в единый скрипт.

Что ещё осталось:

• Чуть-чуть дополировать фронт, особенно расположение кнопок и тёмную тему.

• Собрать единый деплой-скрипт.

• Настроить бэкапы продовой БД.

• Оформить всё это как полноценный кейс.

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

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


P.S. Взял VM помощнее, чтобы потом отдельно запустить на ней ещё и бота. В итоге на одной VM будут жить два разных проекта. Попозже тоже про это расскажу.


🌊 — согласен, что инфраструктура — это компромисс.

🖥 — деплой и инфраструктура — моё любимое.

🍾 — жду пост про залив бота на ту же VM.

😎 — не люблю заниматься настройкой инфраструктуры и деплоем.


#статья 📚

Привет ⌨️


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

ИИ не убивает профессию разработчика. Он убивает только часть рутины.

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

• Усилил авторизацию и работу пользовательских сессий.

• Убрал слабые места, где клиент слишком много решал сам.

• Починил время, часовые пояса и границы дней.

• Сделал надежнее работу с привычками и сессиями.

• Добавил лимиты на спам-запросы.

• Подчистил ошибки, чтобы приложение не сыпалось на кривом вводе дат.

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

Если совсем коротко, то приложение стало заметно надежнее, чище и ближе к реальному релизу. Скоро буду выкатывать его 😺.


Но важный момент вообще не в этом. ИИ реально помог мне:

• Быстрее находить проблемы.

• Быстрее проверять гипотезы.

• Быстрее писать и переписывать код.

• Быстрее закрывать хвосты, на которые руками ушло бы сильно больше времени.

Но ответственность все равно оставалась на мне. Не ИИ решал:

• Что нужно фиксить прямо сейчас, а что можно заморозить.

• Что реально важно для приложения, а что пока просто полировка.

• Где риск допустимый, а где уже нет.

• Когда выкатывать и как потом поддерживать и развивать приложение.

И вот это, как по мне, ключевая мысль. Код — это вообще не вся разработка. Разработка — это еще:

• Выбор, что делать, а что не делать.

• Понимание, где можно упростить, а где нельзя.

• Умение держать в голове приложение целиком.

• Ответственность за итоговый результат.

И вот поэтому меня слабо убеждает весь этот шум про «конец профессий разработчика и аналитика». Потому что исчезает не профессия. Исчезает только часть механической работы 🥵.


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

Более того, мне кажется, что ИИ не схлопнет рынок, а наоборот расширит его.

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


Поэтому вся эта истерика про «вымирание» во многом выглядит как обычный контент под охваты.

Потому что пугать всегда проще, чем нормально разбираться в том, что реально меняется. А меняется, как по мне, вот что:

• Порог входа в создание продуктов снижается.

• Скорость разработки растет.

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

Но требования к человеку только повышаются. Потому что теперь мало просто писать код по чёткому ТЗ. Нужно еще уметь думать, выбирать, собирать систему и доводить ее до результата.

Так что профессия не исчезает. Она становится быстрее и местами даже жестче.

Потому что на фоне ИИ еще заметнее видно, кто просто генерит куски кода, а кто реально может собрать из этого работающий продукт, приложение, софт 👾.


☺️ — согласен.

🍾 — меня тоже утомил этот шум.

🔮 — перешлю другу, чтобы не паниковал.

🌊 — риски для профессии все равно большие.


#лайф 🤝🏻

Всем привет ⌨️


Я наконец-то довел до нормального состояния свой мини-апп для Telegram — @TimeTrackerTGBot


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


В итоге получился минималистичный трекер времени и привычек прямо внутри Telegram. В нём можно:

• Создавать активности: работа, учеба, спорт, проекты, отдых и всё, что хочется отслеживать.

• Смотреть историю активностей по дням.

• Смотреть, из каких сессий складывается активность.

• Вести привычки.

• Увидеть, куда реально уходит твое время.

Для меня это был не просто очередной pet-проект, а полноценная сборка от идеи до рабочего релиза: фронт, бэк, база данных, авторизация через Telegram, деплой, backup/restore и инфраструктура на VM. Про переезд с Dart на TS я промолчу 🥵.


Буду очень рад, если зайдете, потестируете и будете использовать.


P.S. Честный фидбек приветствуется.


#лайф 🤝🏻

Всем привет ⌨️


Переупаковал своего Telegram-бота для деловой переписки — @TextHelperTGBot


Сценарий использования простой:

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

Он помогает переписать сообщение спокойнее, корректнее и по делу.


Главное, что я специально докрутил:

Бот не должен просто раздувать текст в вежливую воду.

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

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


Что поменял после прошлого запуска:

• Поднял дефолтный лимит до 10 запросов в день.

• Убрал явный акцент на подписку.

• Добавил кнопку для обратной связи.

• Подкрутил ответы, чтобы они были менее сухими.

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

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


Сейчас оставляю бота бесплатным как небольшой showcase-инструмент.


Если кому-то будет нужен лимит больше 10 запросов в день — просто напишите мне, вручную увеличу.


Буду рад, если бот пригодится в рабочих переписках, особенно когда сообщение лучше не отправлять сразу 😁.


Ссылка еще раз: @TextHelperTGBot


P.S. Честный фидбек как всегда приветствуется.


#лайф 🤝🏻