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

А ты доверяешь своему проекту? Для Cursor или любого другого VSCode‑форка есть ненулевая вероятность, что при открытии чужой репы IDE тихо запустит какие‑нибудь скрипты в фоне.​ Недавно наткнулся на историю: человек скачал репозиторий с автономным ИИ‑агентом "просто посмотреть код", открыл папку в Cursor и IDE сразу сама запустила какие‑то node‑скрипты в терминале. Без единого клика. Спасло его только то, что данные были зашифрованы, пароли в менеджере, а крипта в холодном кошельке.​ Откуда вообще берётся риск В классическом VSCode есть Workspace Trust — та самая модалка "доверяете ли вы этому воркспейсу?", от ответа зависит, можно ли запускать расширения и скрипты.​ Есть Tasks с режимом runOn: folderOpen, который позволяет запускать скрипты при открытии папки. Удобно для честной автоматизации и идеально для атаки.​ В чистом VSCode это завязано на trust. А вот в Cursor, по их же документации, workspace trust по умолчанию отключён и никакого лишнего вопроса вы просто не увидите.​ В результате злоумышленнику достаточно положить в репозиторий tasks, которые стартуют при открытии папки, и дождаться, пока кто‑то откроет эту репу в форке с выключенным trust. Node‑скрипт в таске имеет доступ к ОС, а дальше полёт фантазии, от телеметрии до кражи ключей.​ Что можно сделать прямо сейчас Минимальный чек‑лист: включить workspace trust; отключить автоматический запуск tasks.​ В settings JSON это две строки: "security.workspace.trust.enabled": true, "task.allowAutomaticTasks": "off" После того как прочитал эту историю, первым делом пошёл и проверил свои настройки IDE. Если такие практичные разборы про разработку, безопасность и реальные кейсы из проектов заходят — у себя в Telegram‑канале регулярно разбираю подобные штуки и показываю, как это влияет на живые продукты. Ссылка на канал.

Железо в ипотеку: почему разработчикам снова придётся считать память Друг недавно пошёл купить планку памяти на 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. Кстати, я регулярно делюсь такими находками и своими экспериментами в инди-хакинге у себя в телеграме 👉 Дебаж с ноги