Всем привет 😤

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


#лайф 🤝🏻

В последнее время я плотно засел за метрики, и больше всего меня цепляет вот этот момент:

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

Давайте объясню, как это работает — на простом примере.

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

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



Чаще всего готовый продукт докручивают через A/B-тесты вкупе с разными метриками.

Если говорить про A/B-тесты простым языком:

Одной половине пользователей показывают вариант интерфейса A, другой — вариант интерфейса B. Потом продуктовый аналитик смотрит, на каком варианте люди дольше задерживаются, чаще покупают, реже уходят 🔨🔨🔨.

При таком подходе побеждает не тот вариант, который субъективно красивее, а тот, у которого цифры выше. Победивший вариант потом раскатывают на всех пользователей ⌨️.



Вот именно из-за этого, кстати, ту самую хронологическую и последовательную стену (Дуров, верни стену) в социальной сети в один момент переключили на «умную с рекомендациями».

Тебя не спрашивали, будет ли это удобно — спрашивали цифры. И эти цифры показали, что так люди залипают в ленте дольше 🥸.



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

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



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



Но, несмотря на такую «жестокую» реальность у метрик, которые лежат в основе A/B-тестов, есть слабое место, про которое легко забыть:

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

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



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

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

Да и вообще, всё не так фатально, на самом деле, я думаю, что этот нарратив хорошо просматривается в моём посте.



P.S. Если у тебя есть друг, который постоянно бомбит, что обновление любимого приложения всё испортило, — перешли ему этот пост. Тут объяснение 🤯.



#статья 📚

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



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

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



Но не всё так плохо, потому что есть то, что не подделаешь и не автоматизируешь.

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

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

Кстати, люди, которых я читаю, также говорят про это в той или иной форме 😁.



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

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

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



P.S. Если мысль откликается — закиньте реакцию на пост. Если нет — с интересом почитаю комментарии 🤯.



#лайф 🤝🏻

Привет! Меня зовут Лёша, и это Math and Code 🖥



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

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

🧊 Без историй про быстрые деньги, без «вход в IT за месяц» и без прочего инфо-шума.



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



С чего начать читать Math and Code:

📎 Почему математика, код и аналитика — одна цепочка

📎 Данные сами по себе ничего не значат

📎 Как продукты докручивают через метрики и A/B-тесты

📎 Что я понял за 2 года в аналитике

📎 Задача про день рождения Шерил

📎 Таймтрекер в Telegram

📎 Честно: бот не взлетел

Кстати, вся навигация по постам — здесь.



Что можно сразу потестировать (этот список будет расти):

💾 Таймтрекер — @TimeTrackerTGBot

💾 Бот для деловой переписки — @TextHelperTGBot



Я наконец-то сделал хороший общий закреп, а также пересобрал всю навигацию по постам.

Добро пожаловать 👥👥



#навигация 📝

Антифрод ловит 99% нарушителей и ошибается лишь на 1% честных юзеров.

Тебя забанили перманентно — звучит как приговор. Но значит ли это, что ты точно нарушил 🌚?



Разберём такой кейс. Сейчас, во время дикого развития антифрод-систем и автоматических банов — будет очень актуально, на мой взгляд.

Та же ошибка, кстати, может жить в спам-фильтрах, антиплагиате, и особенно её любят использовать маркетологи в новостях про «99% точности» — так что это не просто головоломка, а прикладной принцип. Проще жить, когда его понимаешь и ловишь 🪑.



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

• Нарушители редки — 1 на 1000 аккаунтов.

• Система ловит 99% нарушителей.

• И ошибочно банит 1% честных юзеров.

Тебя забанили. С какой вероятностью ты действительно нарушил?

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



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

Чтобы было удобно считать, возьмём 100 000 аккаунтов, тогда:

1. Реальных нарушителей среди них — 100.

2. Система ловит 99%. Значит из этих 100 — поймает 99. Запомним это число.

3. Честных юзеров у нас 99 900. Система ошибается на них в 1% случаев. Кажется, мелочь, но 1% от 99 900 — это 999.

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

5. В итоге, давайте сложим всех забаненных: 99 (настоящих) + 999 (ложных) = 1098.

6. Какая доля из этих 1098 реально виновна? Считаем: 99 / 1098 ~ 9%.

Вся суть этих расчётов в том, что для этого случая бан — ещё не доказательство виновности.

Из всех юзеров, кого безжалостно забанили, реально нарушали примерно 1 из 11. Это те самые ~9%, а не 99%. Чувствуете разницу 😁?


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

Другими словами: одна красивая цифра в 99% растворилась из-за того, что сами нарушения встречаются очень редко 🥷.

Вывод: метрика без базовой ставки не значит ничего 🥷.

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


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

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

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

Поэтому «точность 99%» должна быть рядом с ответом на вопрос: «А как часто вообще встречается то, что мы ловим?» ☺️.



P.S. Закиньте это тем, кого часто банят «за нарушение, которого не было». Интересно, какую вероятность они назовут в начале 💼?



#решение 🤓

Привет! Решил написать небольшой лайф-пост 😤.

Сейчас сильно погрузился в написание вопросов к моему новому сервису. Занимаюсь именно этим уже около 2,5 месяцев, каждый вопрос пишу самостоятельно.

2,5 месяца назад я думал, что самое главное — написать качественный текст. На самом деле, это только процентов 60 всей работы 🔨🔨🔨.



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

• Выделение жирным через **

• Выделение кода через `

• Списки через -

• Заголовки через ###

• И так далее!

Пришлось писать простой движок, который обрабатывает эту разметку и форматирует текст. А вот саму разметку я решил вводить в вопросы с помощью ИИ 👨‍💻.



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

1. Ввести ~70% оформления с помощью агентного ИИ.

2. Удостовериться, что введено ТОЛЬКО оформление и ничего больше.

3. Затестить оформление текста.

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

Решал я его так:

Задача:

Прогоняю промпт, в котором от и до описываю правила оформления, даю примеры эталонной разметки, ставлю жёсткие запреты на исправление текста и описываю, какой отчёт по правкам мне нужен.

Результат:

Получаю файл с разметкой.

Задача:

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

Результат:

Получаю файл с вырезанной разметкой.

Задача:

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

Результат:

Если расхождений нет — значит ИИ действительно занимался оформлением и ничего не переписывал. Задачу можно считать выполненной.

Кстати, тут мысль шире, чем просто разметка текста: даже если редко пользуешься ИИ, принцип один — не верь ему на слово. После получения ответа, придумай, как проверить его фактами. В моем случае, например, помогли скрипты ⚙️.



Дальше остаются сладкие 30% ручного оформления, под которое хочу сделать небольшую панель, чтобы редактировать текст через сам сервис, а не копаться в JSON-файлах — за 2,5 месяца я от них прилично подустал 🤡.

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

Вот такая моя первая попытка в build in public. Как вам? Жду фидбек, хаха 👥👥.



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



#лайф 🤝🏻

«Производная, матрицы, теорвер, а где мне это вообще пригодится?» — вопрос, который я в универе слышал чаще любого другого 🤡.

Обычно на него отвечают абстрактно: «математика учит думать». Знакомо? Это правда, я и сам об этом писал, кстати. Но сегодня раскрою эту тему по-другому — на точных примерах рабочих задач.

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



Производная 📁

• В вузе это предел отношения приращений и таблица правил дифференцирования.

• В работе — ответ на вопрос «с какой скоростью меняется метрика».

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

Кто заметил замедление первым, тот и нашёл проблему до того, как она стала пожаром. По сути ты смотришь на производную метрики, просто в отчёте её называют «темп роста» ☺️.



Теорвер 📁

• В вузе это задачки про шары и монетки и вендинговые аппараты.

• В работе — почти всё, что связано с решениями в условиях неопределённости.

Классика, когда запустили фичу, конверсия выросла на 2% — это реальный эффект или случайный шум, который завтра рассосётся? Ответ на этот вопрос — это статистическая значимость, и на нём стоят все A/B-тесты.

Я недавно разбирал задачу про антифрод, где «система ловит 99% нарушителей», но банит в основном невиновных — это чистая условная вероятность, на которой горят даже опытные аналитики. Вот так шары и монетки внезапно оказываются деньгами и банами 😁.



Линейная алгебра 📁

• В вузе это матрицы, которые постоянно нужно перемножать.

• В работе — таблица «пользователи × товары» это буквально матрица, в которой: строка — человек, столбец — товар, на пересечении — покупал или нет.

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



Статистика 📁

• В вузе это среднее, дисперсия, распределения и немного душности.

• На работе — самый быстрый способ отловить враньё в отчётах или в рекламе.

Классика, когда в вакансии или в каком-то отчёте написано «средняя зарплата в компании 200к». А медианная при этом 90к, потому что несколько топов тянут среднее вверх, и половина людей получает меньше 90к. Одно слово — «средняя» вместо «медианная» — и отчёт рассказывает совсем другую историю. Кто понимает эту разницу, читает такие отчёты насквозь. Кто нет — просто верит написанному 🔨🔨🔨.



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

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

Хорошая вузовская программа кладёт это в голову насовсем, и именно за это платят аналитикам.

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



P.S. Сейчас для меня это очевидно, но если честно, учась в универе на прикладной математике, я не сразу это осознал. Было бы здраво, если бы тогда кто-то скинул мне такой пост. Поэтому, если у тебя есть знакомый, который сейчас задаётся похожими вопросами, — перешли ему 👨‍💻.



#статья 📚

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



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

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

Ниже три самых популярных способа 👨‍💻.



🔍Первый способ🔎

Ось, которая начинается не с нуля. Смотри: какой-то показатель вырос на 1,5%. Само по себе — ни о чём. Но если убрать снизу ноль и начать шкалу впритык к «ростовым» значениям, эти 1,5% растянутся на всю высоту картинки и превратятся в крутую гору. Цифры те же, но подсознательный вывод противоположный.

Пример: ровно так в новостях небольшое колебание курса или цен подают как «резкий обвал» или «взлёт», хотя там разница в пару процентов, центов или копеек.

🔍Второй способ🔎

Удобно выбранный период. Тут данные вообще не трогают, просто решают, с какого момента их показать. Если провести понятную аналогию, то она будет такой: это как показывать свои фото только с одного ракурса. Фото настоящее, не обработанное, просто кадр и ракурс были выбраны заранее заинтересованным лицом, так сказать.

Пример: реклама какого-нибудь фонда или монеты: «доходность +40%». А если отмотать чуть левее точки, с которой начали рекламный график, — окажется, что перед этим фонд упал на 60%, и эти «+40%» просто отскок от дна, потому что кто-то решил купить просевший актив. Но подается это как уверенный рост.

🔍Третий способ🔎

Игра с размером картинки. Это любят в инфографике. Допустим, надо показать, что чего-то стало в два раза больше. Честность — это когда отображают столбики, один из которых вдвое выше, но не всегда делают именно так, смотри пример ниже.

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

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



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

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

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



Способов не три, их точно больше. Что тогда с этим делать? Правило простое: когда видишь убедительный график, сначала смотри не на линию, а на оси и подписи. Также, лучше всего задать пару вопросов, если что-то смущает или кажется уж ОЧЕНЬ позитивным:

• Ось начинается с нуля или нет?

• За какой период построен график? Почему именно за этот период?

• «Больше на N%» — это относительно чего? Было 1, стало 3 — это тоже +200%.

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



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



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



#статья 📚

Привет, закидываю второй build-in-public по проекту, который сейчас собираю 🌚.

У меня с понедельника начался отпуск, поэтому я с головой ушел в свои проекты 🫥.

За последние 5 дней я собрал нормальный лендинг проекта и авторизацию 👨‍💻.

Что могу сразу сказать:

• Если вы видите, что кто-то говорит про сборку идеального лендинга с ИИ за 1-2 часа, то это просто фарс.

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

Давайте теперь поподробнее:


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


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

Большая часть работы была под капотом: пароли хешируются через Argon2id, сессии работают через защищённую HttpOnly cookie, а от перебора паролей добавлены кулдауны по комбинациям email и IP. Ну и на сессии пользователей сделан TTL, который спустя определенное время разлогинивает пользователя 🤒.



Пока это всё ещё локальный MVP, который лежит у меня в столе: пользователи, сессии и прогресс хранятся в JSON. Потом еще буду переезжать на PostgreSQL отдельно, но это в будущем.

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



В общем, отпуск очень продуктивно проходит. Большое спасибо, что читаете ⌨️!



#лайф 🤝🏻

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



Подумал об одной простой вещи:

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

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

По аналогии — это как закипание воды: сначала она долго греется до 99°, визуально не меняясь, а закипает только в самый последний момент 😐.



Сложность и проблема периода до 99° в том, что обычно его приходится проходить в одиночку. Это нормально, но иногда морально тяжело. Здраво, когда у вас уже есть сильное комьюнити, но это 100°, если вы поняли о чем я 🔨🔨🔨.



С моим проектом по сути такая же история сейчас:

ℹ️ Сначала шоу-кейсы, чтобы доказать, что я могу собрать просто что-то работающее.

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

ℹ️ Собрана обертка приложения, прям полностью: весь каркас и логика. Я на днях переехал на PostgreSQL, устранил какое-то дикое количество багов (около 40), которые мне выявил Claude в связке с ChatGPT. Моё ручное тестирование не отлавливало их, потому что баги были куда глубже. В общем, это очень хорошо.

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

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



В общем, двигаемся дальше и посмотрим, что будет. Столкновение моего проекта с реальностью всё ближе и ближе, волнительно 👨‍💻.



P.S. Напишите в комментах, над чем сейчас работаете вы, интересно почитать. Или:

☺️ — тоже на отрезке до 99°.

🍾 — уже кипел, знаю это чувство.

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



#лайф 🤝🏻