Дебаж 🪲 с ноги 🦶

Железо в ипотеку: почему разработчикам снова придётся считать память Друг недавно пошёл купить планку памяти на 16 ГБ и вернулся с ощущением, что железо скоро будут продавать в ипотеку. Он зацепился за простую мысль: оперативка есть везде — в компьютерах, телефонах, приставках, серверах. Если память дорожает, значит очень быстро подорожает всё остальное железо.​ Для разработчиков это неприятный звоночек. На мобилках и десктопах подход «и так сойдёт, железо вывезет» будет работать хуже: более дешёвые устройства, больше экономии на начинке — значит, снова придётся думать про оптимизации, вес приложений, количество абстракций и то, что реально нужно тащить в рантайм.​ На бэке привычное временное решение «завалим проблему железом» (которое по традиции становится постоянным) тоже перестаёт быть очевидным. Если память, GPU и виртуалки дорожают, то горизонт «давайте просто докинем ещё один инстанс» превращается в всё более дорогой вид спорта.​ С другой стороны, на всё это сверху уже наезжает волна сервисов и приложений на LLM, сделанных без особых мыслей про ресурсы. Если виртуалки и GPU подорожают, LLM‑API, скорее всего, тоже станут дороже, а значит, экономика части проектов, построенных по принципу «шлём всё в большую модель и не паримся», может просто перестать сходиться.​ Разработка в итоге снова превращается в честный анализ критериев: что считать локально, что кешировать, какую модель брать, что выкинуть, чтобы продукт вообще жил в плюс, а не работал в минус ради красивых демо.​ Вопрос к читателям: если железо и облака ещё подорожают, вы скорее пойдёте в жёсткую оптимизацию всего или просто заложите рост себестоимости в цену продукта? Если такие разборы интересны, в Telegram делюсь ещё и практикой: как считаю экономику своих фич и LLM‑штук на реальных проектах.

Старый пост Сэма Альтмана На днях в одном из чатиков случайно наткнулся на старый пост Сэма Альтмана и вот этотblog.samaltman.com/...ortt Ему тогда было 30, друг попросил поделиться жизненными советами и Сэм выкатил длинный список. С тех пор прошло уже больше 10 лет, а текст всё ещё звучит пугающе актуально. Особенно символично, что он попался мне прямо перед первой рабочей неделей года. Вот несколько мыслей, которые особенно зацепили. Во‑первых, люди.Семья, близкие друзья, партнёр — это не «потом», не «когда будет время». Горстка реально близких людей важнее сотен контактов. Созваниваться до ночи, не терять старые связи, быть рядом — банально, но именно это чаще всего откладываем первым делом. Во‑вторых, время.Жизнь — не черновик. Если что‑то токсичное — это можно и нужно убирать. Если что‑то радует — стоит делать этого больше, без чувства вины. Про работу и успех.Самое сложное — не «как работать эффективнее», а вообще понять, над чем стоит работать. Не стек, не количество часов, а вопрос: что действительно заслуживает нескольких лет жизни. Про деньги и свободу.Деньги сами по себе счастья не гарантируют, но дают свободу. И свобода — это когда ты не думаешь об аренде, а не когда можешь купить самолёт. Зарабатывать часто интереснее, чем тратить, но тратить на друзей, опыт, путешествия и экономию времени почти всегда нормальная идея. Про расходы.Держать личные траты низкими — это не про аскезу, а про количество доступных решений в будущем. Эта привычка реально открывает двери. Отдельно зацепила мысль про то, чтобы помогать незнакомым людям просто так. Без выгоды, без причины. Почему‑то именно такие вещи потом вспоминаются лучше всего. У Альтмана там ещё десятки пунктов — про риск, обучение, окружение, родителей. Вопрос к залу: с каким пунктом Альтмана вы вообще не согласны и почему? Если тема откликается и интересно больше практики про разработку, продукт и мой путь с проектом, я подробнее разбираю такие штуки у себя в Telegram‑канале

Как Cursor помог переписать браузерное расширение за 2 часа: опыт миграции на единый стек Последние пару недель занимаюсь унификацией технологического стека для всех своих pet-проектов и поделок. Цель — собрать единый тех-радар, чтобы не тратить время на переключение контекста между разными фреймворками и библиотеками. Мой стек Frontend: - React (без сюрпризов) - WXT (лучший фреймворк для браузерных расширений) - MUI (библиотека UI-компонентов под Material Design) - Netlify (бесплатный и надёжный хостинг) Backend: - Supabase (как Firebase, только лучше) - Yandex Cloud (serverless-контейнеры + S3-хранилища) Процесс На выходных добрался до Speech to Text — браузерного расширения для транскрипции аудио. Оно было написано на vanilla JS ещё в первых версиях, и каждое обновление превращалось в квест по поиску багов и зависимостей. С помощью Cursor (AI-ассистента для кода) переписал всё расширение за пару часов: Перенёс на WXT (фреймворк для Chrome Extensions) Заменил самописные компоненты на MUI Добавил TypeScript для типобезопасности Заодно запилил новую фичу: транскрипцию системного звука через Chrome Tab Capture API Что получилось Теперь Speech to Text может расшифровывать не только микрофон, но и всё, что играет на компьютере: YouTube-видео, Zoom-созвоны, лекции, подкасты и т.д. Дополнительно добавил: Аудиоплеер для предпросмотра файла перед отправкой Анонимную расшифровку по прямой ссылке на аудио Бонус Модерация в Chrome Web Store прошла за 2 часа (обычно было 8-12). Предполагаю, что регулярные релизы дают "репутацию" у алгоритмов Google. Выводы Унификация стека — это не просто модное слово, а реальная экономия времени. Теперь могу быстро переключаться между проектами и переиспользовать компоненты без головной боли. Хотите больше деталей? Про процесс унификации стека, выбор инструментов и другие эксперименты с расширениями пишу в своём Telegram-канале @debug_leg. Там более неформальный формат: короткие посты, скриншоты процесса и честные истории про грабли. Подписывайтесь, если интересна кухня разработки.

Мой стек для запуска MVP 🚀 После отпуска я понял простую вещь - двух недель достаточно, чтобы забыть вообще всё, чем ты занимался. Если у тебя нет структуры, стек превращается в хаос из случайных библиотек, фреймворков и зависимостей. Поэтому я сел и собрал для себя техрадар - единый стек, который позволяет запускать pet-проекты и мини SaaS быстро и без боли. ⚙️ Frontend React 🧠 Почему: куча библиотек, море документации и огромное комьюнити. Плюс масса готовых компонентов - не надо изобретать велосипед. WXT ⚡ Почему: лучший фреймворк для браузерных расширений, если нужно быстро. Реально сокращает путь от идеи до первой установки MUI 🎨 Почему: так как большинство моих проектов - Chrome Extensions, UI-компоненты под Material Design органично вписываются в браузер от Google. Netlify ☁️ Почему: одна из самых удобных платформ для веб-разработки. Автоматическая сборка, тестирование и деплой в пару кликов. Работает стабильно и без боли. 🧩 Backend Supabase 🗄 Почему: open-source альтернатива Firebase, но с Postgres под капотом — понятным, гибким и предсказуемым. Есть всё: авторизация, база, edge-функции и SQL-запросы. Yandex Cloud 💾 Почему: недорогой S3, с "льготным" объёмом данных, за который не берут денег. Плюс умеет поднимать Docker-контейнеры в serverless-режиме. Идеально для пет-проектов. 🧱 Инфраструктура CI/CD — Jenkins 🔁 Почему: не прожорлив, стабилен и с кучей плагинов. Работает даже на обычном VPS. GlitchTip 🐞 Почему: не ест столько памяти, как Sentry, но совместим с его API и библиотеками. Отличный вариант для отслеживания ошибок. Umami 📊 Почему: не блокируется ad-блоками, лёгкая и быстрая. Отличная альтернатива Google Analytics и Яндекс.Метрике. 🧰 Инструменты JetBrains IDEA 💻 Почему: всю жизнь писал на Java и Kotlin - это мой родной IDE. Самый знакомый и надёжный инструмент. WebStorm 🧠 Почему: по сути та же IDEA, только заточенная под JS и TypeScript. Cursor 🚀 Почему: ускоряет разработку. Во второй версии можно подключить debug port Chromium и буквально «вайбкодить» с ИИ в реальном времени. DBeaver 📘 Почему: купить лицензию DataGrip сложно, а DBeaver - почти то же самое. Не идеально, но достаточно для работы с БД. GitHub 🌐 Почему: так исторически сложилось. Репозиторий, автодеплой, CI - всё в одном месте. 💬 Языки TypeScript 🧩 Почему: я привык к типизированной Java, и JS без типов меня бесит 😅. Плюс Cursor тратит меньше токенов, потому что не нужно проверять типы, и упрощается процесс vibe debugging - сразу понятно, что за данные под капотом. Python 🐍 Почему: стараюсь минимизировать, но иногда выручает. Особенно когда дело доходит до ML и AI - ребята из этой среды его обожают. (А вот Kotlin, как бы я его ни любил, сюда просто не ложится.) Сейчас думаю над системой логов и метрик — скорее всего, выберу VictoriaMetrics. Ещё у меня есть телеграм-канал, где я рассказываю, как всё это использую вживую, и делюсь процессом разработки своих пет-продуктов 👉t.me/...legg

Как понять, полетит ли твой пет-проект, ещё до того как ты его закодил Когда я впервые решил попробовать себя на маркетплейсах, первое, что сделал — посчитал математику. Какие товары выгодно продавать, а какие не имеет смысла даже закупать. С этого момента я понял одну простую вещь: экономика всегда важнее идеи. С IT-проектами, мини-SaaS и прочими пет-поделками всё работает точно так же. Некоторые идеи звучат круто, но экономика там минусовая ещё до релиза. А какие-то — наоборот, простые, скучные, но с отличной маржинальностью. Чтобы не тратить время на «мертвые» идеи, я собрал простой калькулятор экономики пет-проекта. Он помогает понять, сколько денег нужно вложить и сколько можно заработать за первые три месяца, если запускаться через поисковый трафик. Внутри — всё по делу: трафик, конверсии, CTR, CPC, расходы, цена подписки. В итоге калькулятор покажет, во что ты реально влезешь, и стоит ли вообще кодить идею или лучше оставить её в «папке с концептами». 🧮 Калькулятор можно посмотреть и попробовать тут: 👉 Google Sheets — Экономика пет-проекта Я сделал его под свои запуски, но он подойдёт любому, кто хочет тестировать идеи быстро и с холодной головой.

С чего на самом деле стоит начинать IT-проект Если бы год назад меня спросили, с чего начинать IT-проект, я бы не задумываясь сказал: с MVP. Так учили, так делают большие продуктовые команды, так звучит «по науке». Но чем больше я работаю, тем сильнее понимаю, что моё представление о minimal и value давно извратили корпоративные процессы. MVP — это уже не про скорость, а про маленький продукт с большой бюрократией. Проблема даже не в том, что минимальный продукт часто получается просто говном — с багами, уродливым дизайном и UX из 2010-го. Проблема в том, что на него уходит время. А это уже не MVP, а мини-стартап со всеми рисками. Сейчас я всё больше убеждаюсь, что главное — не идея и не продукт, а трафик. Сколько его, сколько стоит, где его взять, как купить, какая там конкуренция и какие риски. Трафик — это и есть спрос. Всё остальное — следствие. Иногда вместо MVP хватает лендинга. Он быстро отвечает на главный вопрос: стоит ли вообще делать MVP и какие фичи туда добавить. Ориентиры простые: CTR — как часто кликают по офферу (в рекламе, постах, реддите — не важно где). CR — как часто совершают целевое действие на лендинге. Если CTR высокий, а CR низкий — идея заходит, но оффер не цепляет. ❌ Плохо описана фича. ❌ Много нецелевой аудитории. Если CTR низкий, а CR высокий — наоборот: оффер норм, но ты не туда бьёшь. 🎯 Промах по таргету. 🎯 Слабая коммуникация. Если оба низкие — идея мёртвая. И вот теперь я думаю: может, всё MVP-мышление надо перевернуть? Не строить продукт, чтобы проверить спрос, а сначала проверить спрос, чтобы понять — нужен ли продукт. Короче, если твоя идея собирает внимание — проект почти точно полетит. Я пишу про такие наблюдения, тесты и свои эксперименты с инди-продуктами у себя в телеге

Как я ищу идеи без ChatGPT Очень часто вижу совет: «Хочешь найти идею? Просто спроси у ChatGPT». Но если реально хочу откопать живую идею и проверить рынок — иду не к ИИ, а в данные. Вот список сервисов, которые для этого использую 👇 🔎 Аналитика запросов Answer the Public — строит карту поисковых запросов на основе автокомплитов Google. Помогает понять, как реально формулируют вопросы пользователи. Semrush — мощный SEO-инструмент: ключевики, конкуренты, источники трафика. Удобен для оценки ниши и поиска новых идей. Wordstat Yandex — статистика по ключевым словам в Яндексе. Полезно для анализа российского рынка. Google Trends — показывает динамику интереса к запросам во времени. Отлично подходит, чтобы понять: хайп это или долгосрочный тренд. 📊 Аналитика посещаемости сайтов Similarweb — оценка трафика сайта, источники, география. Можно подсмотреть, откуда растут конкуренты. 📱 Аналитика мобильных приложений Sensor Tower — трекает загрузки и выручку приложений. Полезно для оценки рынка мобильных продуктов. Appmagic — похож на Sensor Tower, но с более детальными срезами по нишам. Удобен для ресёрча идей. App Store Spy — анализ ключевых слов и позиций приложений в сторе. Помогает с ASO. Read Reviews — парсинг отзывов из магазинов приложений. Можно быстро выявить боли пользователей. 🏢 Аналитика юрлиц (Россия) Rusprofile — финансы, учредители, судебные дела. Полезно для проверки конкурентов или потенциальных партнёров. 📢 Аналитика соцсетей TGStat — аналитика Telegram-каналов: рост, вовлечённость, пересечения аудиторий. Telemetr — ещё одна метрика по Telegram, иногда даёт чуть другие данные. VidIQ — анализ YouTube-каналов: теги, тренды, вовлечение. Нужен, если строишь продукт на контент-аудитории. ⚡️Как использовать - ищешь идею → смотришь, как её ищут (Answer the Public, Wordstat, Trends); - проверяешь конкурентов → Similarweb, Semrush, Appmagic; - анализируешь боли → Read Reviews, TGStat; - смотришь деньги и риски → Rusprofile. Кстати, я регулярно делюсь такими находками и своими экспериментами в инди-хакинге у себя в телеграме 👉 Дебаж с ноги

SCAMPER⁠⁠ Недавно я узнал про методику SCAMPER. Она из разряда простых, но мощных инструментов креативного мышления. Суть в том, что ты берёшь продукт или задачу и начинаешь смотреть на неё с семи разных углов: S — Substitute (заменить) C — Combine (комбинировать) A — Adapt (адаптировать) M — Modify (модифицировать) P — Put to another use (использовать иначе) E — Eliminate (убрать) R — Reverse (перевернуть) Методика работает как игра: задаёшь себе вопросы, которые обычно не задаёшь, и получаешь неожиданные варианты. Пример: возьмём банальный TODO-менеджер. – Что можно заменить? Ввод руками — на импорт задач из мессенджера. – Что комбинировать? Список задач + календарь в одну сущность. – Как адаптировать? Взять механику из игр и добавить квесты. – Что модифицировать? Из списка сделать канбан с лимитами. – Где использовать иначе? Движок для задач отдать командам саппорта. – Что убрать? Проекты и теги — оставить «сегодня» и «инбокс». – Что перевернуть? Планировать не с утра, а с конца дня — от дедлайна назад. Из одной скучной идеи рождается десяток направлений для MVP. А дальше уже вопрос проверки спроса. Такие инструменты отлично ложатся на indie-hacking и пет-проекты. Вместо того чтобы застревать в одной гипотезе, можно быстро погонять несколько вариантов и проверить, что реально работает. Для меня SCAMPER стал открытием: всего семь «рычагов», которые помогают находить новые решения даже там, где кажется, что всё давно придумано. Кстати, я регулярно делюсь такими находками и своими экспериментами в инди-хакинге у себя в телеграме 👉 (ссылка в профиле)

Портфель продуктов⁠⁠ Я всё больше прихожу к мысли, что моя стратегия - это не «ставка на одного единорога», а портфель продуктов. Я постоянно запускаю новые проекты. Да, не все они находят рынок. Но зато всегда есть шанс, что один или два "выстрелят". Почему не один? Потому что меня не драйвит идея "сидеть на одном продукте до посинения". Мне нравится запускать, проверять гипотезы на реальном спросе, а не тратить месяцы на интервью и бесконечные обсуждения проблем пользователей. Минимальный прототип -> рынок -> обратная связь. И вперёд. У этого подхода есть очевидные плюсы. Это диверсификация: один провал не убивает всё. Это быстрые тесты: можно пробовать разные рынки и модели монетизации. Это сглаживание дохода: разные продукты дают суммарный MRR и снижают волатильность. И, конечно, это опыт: каждый запуск учит чему-то новому, и следующий делать проще. Но есть и обратная сторона. Переключение между проектами рвёт фокус. Поддержка множества продуктов превращается в постоянный саппорт. Иногда ловлю себя на том, что не дожимаю тот проект, который стоит дожать, потому что «есть ещё три». Бренд тоже страдает: аудитории сложнее понять, о чём ты. Ну и усталость - постоянные запуски дают дофамин, но оставляют хвост незакрытых задач. Короче, портфель продуктов - это не магия и не серебряная пуля. Это осознанный выбор между рисками и свободой. Я понимаю, что так жертвую глубиной и стабильностью, но выигрываю в скорости, энергии и опыте. И знаете что? Пока мне нравится сам процесс. Запускать, смотреть реакцию, делать выводы и идти дальше. Это даёт мне больше мотивации, чем идея "строить идеальный продукт годами" (это уже проходили). Кстати, я регулярно пишу о своих продуктах, экспериментах и запусках в телеграме 👉(ссылка в профиле)

LLM умрут, а бизнесы на API рухнут⁠⁠ 35 лет подряд Янн Лекун угадывает повороты в ИИ. В 80-х он говорил про распознавание изображений, в нулевых - про нейросети, в 2016 - про самообучение. И вот сейчас он заявляет самое радикальное: LLM в том виде, в каком мы их знаем, мертвы. Проблема не в данных и не в мощности, а в архитектуре. Каждый токен чуть сдвигает модель в сторону, и чем длиннее вывод - тем выше шанс галлюцинаций. Никакие терабайты и GPU это не спасут. А теперь подумай, сколько сейчас продуктов держится только на API OpenAI. Чат-боты, резюмирование документов, генерация текстов. Все эти проекты живут лишь потому, что можно позвать API. Но новая волна придёт не от «больше параметров», а от моделей, которые учатся «как дети»: через видео, восприятие и понимание мира. И тогда поддерживать бизнес на API старых LLM станет бессмысленно. Новые модели будут быстрее, точнее и дешевле. Лекун прямо говорит: закрытые модели исчезнут, открытые и распределённые — победят. Meta уже вкладывает $20 млрд в перестройку стратегии. Сроки короткие: 3-5 лет до первых моделей мира, и около десятилетия до ИИ уровня человека. Для корпораций это вызов. А для indie-hacker’ов - шанс. У больших игроков всё завязано на старых API и инерции. А у нас есть свобода пробовать новое. Пет-проекты — это маленькие лаборатории, где можно тестировать идеи будущего и учиться жить «после LLM». Когда рынок перетрясёт, выиграют те, кто уже умеет мыслить продуктом, а не строками API. Я как раз пишу о своих экспериментах в инди-хакинге и пет-проектах у себя в телеге 👉 ссылка в профиле