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

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



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

• 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. Честный фидбек как всегда приветствуется.


#лайф 🤝🏻

Всем привет 😤! Сегодня хочу коротко разобрать два подхода в разработке ботов: polling и webhook.


Оба подхода отвечают на один вопрос: как бот узнаёт, что пользователь написал новое сообщение?

В случае с polling бот сам регулярно обращается к серверу Telegram и спрашивает: «Есть новые обновления?» Если есть — забирает их и обрабатывает. Если нет — ждёт немного и спрашивает снова.

С webhook логика обратная. Тут бот заранее сообщает Telegram публичный HTTPS-адрес своего сервера. И когда появляется новое сообщение, Telegram сам отправляет его на этот адрес.

Можно представить так:

• Polling — это когда вы сами каждые пару минут подходите к почтовому ящику и проверяете письма.

• Webhook — это когда курьер сам звонит в дверь, как только письмо появилось.

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

Но у polling есть важная особенность:

Для одного бота должен работать только один активный polling-процесс.

Если запустить этого же бота ещё где-то — например, не только локально, но и на VM одновременно, — процессы начнут мешать друг другу, потому что оба будут пытаться забрать одни и те же обновления 🥵.


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

Тут уже другая важная особенность:

Для одного бота нельзя одновременно использовать polling и webhook. Работает что-то одно.

То есть, если webhook уже установлен, polling нормально работать не будет — сначала нужно удалить или закомментировать ваш webhook 🤔.


Давайте подытожим. Кратко:

• Polling — бот самостоятельно и постоянно спрашивает API Telegram, были ли какие-то запросы от пользователя.

• Webhook — API Telegram самостоятельно сообщает, о событии на вашу настроенный и выделенный URL.

Для локальной разработки и первых тестов — советую выбирать polling, он обычно проще и удобнее.

Для прода, стабильной серверной работы и более удобной интеграции с инфраструктурой — советую выбирать webhook.


P.S. Если интересно, мой бот, который помогает обрабатывать текст — использует polling. А обвязка веб-аппа (команды /start и /help), использует webhook, потому что бот и обвязка веб-аппа с веб-аппом — живут на одной VM. Да и я хотел потестить эти два архитектурных решения на своих мини-проектах.


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

🍾 — я больше про webhook.

💡 — я polling-enjoyer.

☺️ — я использую и то, и то.


#статья 📚

Всем привет!

Прошло несколько недель с момента, когда я наконец-то расквитался со своими небольшими проектами, которые давно начал. Пришло время попробовать описать это чувство.

Оно похоже на то, будто ты полностью освободил комнату, в которой жил целый год. Вынес старую мебель, убрал лишнее, посмотрел на пустое пространство — и теперь можешь обставить его заново.

Только в этот раз не с нуля, а уже с опытом 😁.


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

• Для кого эта идея,

• Какую боль она закрывает,

• Почему человеку вообще может быть нужно такое решение,

• Как в общих чертах будет выглядеть интерфейс,

• Вокруг какого контентного ядра всё должно собраться.

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

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

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

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


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

«Ну вот, это не залетело, значит я просто потратил время впустую».

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


К чему я это пишу? Смотри ниже:

Во-первых, хотел выйти на связь.

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

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

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

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


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

🔮 — я только в начале пути.

🍾 — уже 10+ ступеней за спиной, но ни одна не выстрелила.

⌨️ — напишу в комментарии, а может и нет.


#лайф 🤝🏻

Математика, физика, программирование и аналитика связаны сильнее, чем кажется. Давайте разберем, почему так 👥👥?


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

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

Не в смысле «знать больше формул», а в смысле — лучше видеть структуру задачи 😤.


Когда ты учишь математику, ты по сути тренируешь умение раскладывать хаос на части. У тебя есть условие, переменные, ограничения, связи между объектами и какой-то результат, к которому нужно прийти. Это очень похоже на реальную рабочую задачу аналитика. Только вместо x, y, функций и графиков у тебя: выручка, пользователи, конверсия, период, сегмент, гипотеза и итоговое решение.

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

• Что известно?

• Что неизвестно?

• Какие есть ограничения?

• Что влияет на результат?

• Где причина, а где просто совпадение?

• Какой вывод можно сделать честно, а какой делать рано?

Это еще не все, потому что физика добавляет к этому ещё один важный слой. Она учит смотреть не только на результат, но и на условия, при которых этот результат появился. Тело не просто «движется», оно движется с какой-то скоростью, под действием сил, в конкретной среде, с трением, массой и начальными условиями. В аналитике то же самое. Метрика не просто «упала» — она упала где-то, у кого-то, за какой-то период, относительно какой-то базы сравнения и под влиянием каких-то факторов. Если это не выяснить, можно очень уверенно анализировать вообще не ту проблему 👨‍💻.


Давайте на примере:

«У нашего сервиса просели продажи». Звучит понятно? На самом деле нет 🔨🔨🔨.

Какие продажи? Выручка или количество заказов? За какой период? По всем пользователям или только по новым? Просели относительно вчера, прошлой недели или плана?

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

Математика учит держать структуру. Физика учит искать причинность и учитывать условия. Программирование даёт инструмент, чтобы это быстро проверять. Аналитика собирает всё это в рабочий вывод, по которому можно принять взвешенное решение 🌃.

SQL в этом смысле — не просто «язык запросов» к БД. Это способ задать вопрос данным.

Python — не просто «язык программирования». Это способ быстро проверить гипотезу.

Графики — не просто красивые картинки. Это способ увидеть изменение или аномалию в данных.


Но главная проблема в другом. Можно знать математику, физику, SQL и Python. И всё равно теряться, когда появляется рабочая задача: «Почему упала конверсия?», «Как понять, успешен ли релиз?», «Какую метрику выбрать для проверки гипотезы?». Потому что здесь уже недостаточно помнить теорию. Нужно выбрать правильный ход: «Что уточнить первым?», «Где может быть ошибка в данных?», «Какой вывод делать рано?», «Какая метрика реально связана с решением?», «Где команда уже бежит делать фичу, хотя проблему ещё не поняла?».

И вот именно тут школьные и универские «скучные предметы» начинают раскрываться по-другому. Математика — это не про формулы ради формул. Физика — не про задачки с брусками. Программирование — не про «выучить язык». Это всё инструменты мышления.

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


P.S. Если вас когда-нибудь спросят: «Зачем вообще учить математику или физику?» — можете просто переслать им этот пост 😁.


#статья 📚

Данные сами по себе ничего не значат. И Вавилонская библиотека объясняет это лучше любой лекции по аналитике 🤯.

Есть такой образ: библиотека, в которой хранятся все возможные книги. Вообще все.

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

Звучит как мечта, да? На самом деле — нет. Давайте разберем почему 🔨🔨🔨.


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

Вот тут-то и начинается самое интересное. Проблема такой библиотеки не в том, что в ней нет ответа. Ответ там как раз есть.

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

Допустим, у нас есть небольшой алфавит из 30 символов и текст фиксированной длины — 1000 символов. Количество возможных текстов, которые можно составить — будет расти не линейно, а взрывным образом:

Если на месте каждой буквы может стоять один из 30 символов, то для текста длиной 1000 символов получится 30¹⁰⁰⁰ вариантов.

На самом деле 30¹⁰⁰⁰ — это число, которое мозг не может нормально воспринять. Но давайте попробуем его оценить:

• Количество атомов в обозримой вселенной ~ 10⁸⁰, и это сильно меньше, чем число наших вариантов.

• Количество секунд с момента Большого взрыва ~ 4.3 ⨯ 10¹⁷, и это также сильно меньше, чем число наших вариантов.

В общем, число наших вариантов настолько гигантское, что даже если бы каждый атом сам по себе стал отдельной огромной Вселенной, то общее число атомов в них всё равно не приблизилось бы к 30¹⁰⁰⁰ 🥵.


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

Ключ кроется в том, как искать этот ответ. Если нет способа поиска и правил фильтрации мусорных комбинаций, то шансы найти что-то нужное — около-нулевые.

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

В БД сервиса может быть куча таблиц, событий, логов, графиков, дашбордов, выгрузок, сегментов ЦА и метрик. Данные могут занимать терабайты дискового пространства. Суть в том, что эти данные сами по себе не дадут ответа на вопросы вроде:

• Почему часть пользователей перестаёт пользоваться сервисом?

• Что именно сломалось после очередного релиза?

• Где продуктовая гипотеза подтверждается, а где это просто совпадение в данных?

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

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


В итоге, именно поэтому доступ к данным сам по себе не делает человека аналитиком 🤡.

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

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

С данными то же самое. Если нет вопроса — есть шум. Если есть хороший вопрос — появляется шанс найти смысл.


P.S. Забавно то, что в Вавилонской библиотеке этот пост был до его написания 🌚.


#статья 📚

Есть классная логическая задача про день рождения Шерил. Давайте её разберём 👍.

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

Эта задача раскрывает один принцип аналитического мышления: важно не просто смотреть на факты, а понимать, какие выводы из них может сделать другой человек 👥👥.



Условие у задачи такое:

Альберт и Бернард только что познакомились с Шерил. Они хотят знать, когда у неё день рождения. Шерил предложила им десять возможных дат:

• 15 мая,
• 16 мая,
• 19 мая,
• 17 июня,
• 18 июня,
• 14 июля,
• 16 июля,
• 14 августа,
• 15 августа,
• 17 августа.

Затем Шерил сказала Альберту месяц своего рождения, а Бернарду — день. После этого состоялся диалог:

Альберт: Я не знаю, когда у Шерил день рождения, но я знаю, что Бернард тоже не знает.

Бернард: Поначалу я не знал, когда у Шерил день рождения, но знаю теперь.

Альберт: Теперь я тоже знаю, когда у Шерил день рождения.

Вопрос: когда у Шерил день рождения?



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


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

• 18 — только 18 июня,
• 19 — только 19 мая.

Если бы Бернард услышал число 18 или 19, он бы сразу понял дату полностью, потому что такие дни в списке уникальны.

Но Альберт говорит: «Я знаю, что Бернард тоже не знает».

Значит, Альберт уверен, что месяц Шерил не содержит уникальных дней. Если бы Альберт услышал май, он не мог бы быть уверен, потому что в мае есть 19 мая. Если бы услышал июнь — тоже не мог бы быть уверен, потому что в июне есть 18 июня.

Следовательно, месяц, который назвала Шерил — не май и не июнь ☺️.


2. Тогда остаются только эти даты:

• 14 июля,
• 16 июля,
• 14 августа,
• 15 августа,
• 17 августа.

Дальше Бернард говорит: «Поначалу я не знал, но знаю теперь».

После слов Альберта Бернард понял, что май и июнь отпали. Теперь он смотрит на оставшиеся даты.

Если бы у него было число 14, он всё ещё не знал бы точную дату, потому что 14 есть и в июле, и в августе.

Но он говорит, что теперь знает. Значит, число не 14 🌚.


3. Теперь остаются:

• 16 июля,
• 15 августа,
• 17 августа.

После этого Альберт говорит: «Теперь я тоже знаю».

Если бы Альберт знал, что месяц — август, он всё ещё не смог бы выбрать между 15 августа и 17 августа.

Но он говорит, что теперь знает точную дату. Значит, месяц не август. Остаётся только один вариант: 16 июля 😐.


В итоге: 16 июля — это день рождения Шерил.

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

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



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



#решение 🤓

Планировал написать в канал на прошедших выходных, но не вышло 🌚.


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

Сразу спойлер: код был исправен и работал корректно.

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

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


В Яндекс Облаке на одной VM — дружно жили мои старые проекты: бот и мини-приложение с трекером времени.

Долгое время всё работало исправно. Потом VM просто перестала достукиваться до Telegram API из-за провайдера — и всё. Обвязка мини-приложения перестала работать, бот просто умер.

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

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

Деплой закрутился по новой: отдельно поднял серверы, установил Docker на них, поднял БД, настроил бэкапы, домен, прокси, вебхуки, доступы и всё остальное, что обычно не видно пользователю 🥵.


Со стороны это звучит душно. Так и есть. Но в этом и есть взрослая часть разработки.

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

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

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

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

Для себя я воспринимаю это как маленький экзамен.

Не в смысле: «если получилось, то я теперь всё умею».

А в смысле: «я уже могу не только придумать и написать бота или мини-приложение, но и довести его до состояния, где оно живёт на сервере, работает с БД, имеет бэкапы, переносится на новую инфраструктуру и не исчезает при первом ударе реальности».

Это, по сути, первый этап 😁.


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

Теперь буду пытаться пройти второй этап, не забывая, что первый этап может периодически повторяться 👥👥.


Если вы или ваши друзья тоже делаете пет-проекты или свои первые сервисы, хочу сказать простую вещь:

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

Прямо на примере:

• Сначала ты учишься писать код,

• Потом учишься его запускать,

• Потом учишься чинить то, что запустил,

• Потом учишься деплоить свой код и обслуживать его,

• Потом учишься думать не задачами, а системами.

И вот где-то там начинается настоящее инженерное взросление.

Со временем пет-проекты перерастают в системы и сервисы, которые работают стабильнее и лучше, потому что их автор всё лучше умеет превращать идею и хаос в то, что работает и живёт 😤.


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


#лайф 🤝🏻