Недавно нашёл fzf и теперь не представляю, как я вообще работал без этого. Это CLI-утилита для нечёткого поиска по файлам, истории команд, процессам — по чему угодно. Печатаешь несколько букв, видишь превью, выбираешь стрелками, Enter. Самое полезное — интеграция с bash. Теперь Ctrl+R не просто ищет по истории, а показывает интерактивный список. Можно даже вставить в pipeline: `cat logfile | fzf | xargs grep`. Экономит вёрткий серфинг по логам. Я даже добавил себе функцию для прыжков между директориями: `fzf` выплёвывает результат, и я окончательно в нужной папке. Звучит как мелочь, но эта мелочь происходит сотни раз в день. Попробуй — не разочарует.

Помнишь, в прошлом году все носились с тем, что AGI приходит в этом году? OpenAI чуть ли не дату называли, в соцсетях красивые графики про экспоненту. А теперь — тишина. Никто не говорит про "AGI к концу 2025". Думаю, просто люди забыли, что такое экспоненциальный рост на самом деле. На бумаге красивая кривая, но в реальности каждый следующий шаг требует всё больше вычислений, данных, денег. И в какой-то момент кривая упирается в стену физики, и никакие ещё стартапы это не изменят. Модели становятся лучше, но не экспоненциально — линейно, может даже медленнее. А нарратив про "вот-вот взорвётся" — он просто удобен: привлекает инвесторов, пугает конкурентов, цепляет медиа. Сейчас модели делают полезную работу, и это классно. Но "полезная" — это не то же самое, что "искусственный интеллект вышел из-под контроля". И может быть, это даже хорошо.

Вчера читал, как Anthropic выпустил Claude с 200K контекстом, а OpenAI молчит. Потом Mistral кинул свою открытую модель, которая на бенчмарках кусает закрытые аналоги. Qwen из Alibaba вообще тихо захватывает азиатский рынок, а европейцы только просыпаются. Забавно наблюдать, как монополия AI-индустрии рассыпается прямо на глазах. Год назад казалось — только OpenAI, только ChatGPT. Теперь? Теперь выбор. И реально выбор, не маркетинговый трюк. На API покупаешь дешевле, на локальные модели вообще не платишь. Скорее всего, в следующем году не будет одного "победителя" — будет ярус моделей под разные задачи. Кто-то для production, кто-то для экспериментов, кто-то вообще работает в твоём docker-е.

Пользуюсь `!$` уже столько лет, что забыл, как раньше жил. Это такая штука в bash/zsh — подставляет последний аргумент из предыдущей команды. Работает просто: набрал `docker run -

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

Потратил два дня на отладку I2C-шины между ESP32 и датчиком. Датчик упорно не отвечал, хотя код был правильный — один в один как в примерах. Оказалось, проблема не в коде и не в железе. Оригинальный datasheet на датчик описывал одну версию чипа. А на плате стояла ревизия, где один из регистров сдвинут на два бита. Китайский производитель об этом не

Когда задача кажется одной большой кучей, я сначала её не трогаю. Вместо этого беру листок и выписываю всё, что вижу: что нужно сделать, что неизвестно, где могут быть подводные камни. Обычно за пять минут становится ясно, что половина — это вообще не задача, а просто шум. Потом ищу самую маленькую часть, которую можно сделать за 15–20 минут. Не самую важную, не самую интересную — именно самую маленькую. Сделаю её, и вот уже есть движение. Мозг доволен, дальше легче. После первого куска остальное обычно раскладывается само. Главное — не залипать на анализе и не ждать, пока всё станет понятно. Понятно будет по ходу.

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

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

Год назад перешёл с VS Code на Neovim. Думал — будет быстрее, кулёр, ближе к железу. И да, когда привык — работается классно. Но вот что я не учёл: половина плагинов, которые я установил "для полноты", я так и не юзаю. Они просто лежат в конфиге, замедляют старт, иногда конфликтуют друг с другом. Code был "тяжёлый", зато всё работало из коробки. Переход на Neovim заставил меня впервые за годы задуматься: а что я на самом деле использую каждый день? Оказалось — три вещи: подсветка синтаксиса, навигация по файлам и LSP. Остальное — груз. Сейчас вот жалею только одно: потратил время на настройку, которую можно было потратить на код. Редактор — инструмент, а не хобби.

Вчера понадобилось прошить один ESP32, который лежал в коробке с запчастями. Думал — десять минут, не больше. espota, пара кликов, и погнали. Не сложилось. Устройство не виделось в USB, драйвер CH340 не помогал, перепробовал три кабеля. Оказалось, на плате стоит CP2102, а не CH340, как я по памяти решил. Потом загрузчик был прошит криво и устройство уходило в бутлуп. Потом выяснилось, что partition table не совпадает с прошивкой. Заняло три

Была у меня задача — настроить автодеплой через webhook. Простой POST, внутри payload с версией, дальше curl на свой сервис, скачать артефакт, развернуть. Всё просто. Один скрипт, строк 15. Запускаю — не работает. Смотрю логи — пусто. Меняю curl на echo, чтобы проверить что приходит — работает. Возвращаю curl обратно — тишина. Время перевалило за полночь. Я уже начал подозревать что угодно: файлроллы, dns, фаервол, заговоренный сервер. Оказалось, в curl-команде после URL был перенос строки. Не в переменной, не в параметре — прям физический перенос после закрывающих кавычек. Шелл видел curl https://... и сразу за ним пустую строку, которую считывал как новую команду. И тихо падал. Поменял одну строку. Удалил перенос. Заработало. Мораль? Символы, которые ты не видишь, тоже символы. Особенно если скрипт работает "через раз".

Когда смотришь на одну систему достаточно долго, она начинает рассказывать вещи, которых нет ни в одной документации. У меня так было с одним сервером. Два месяца я разбирался с его характером: в какое время он начинает тормозить, какой лог забивается раньше всех, после какого события появляется характерный запах проблем. Не потому что читал умные статьи — просто смотрел. Каждый день, понемногу. Оказалось, что дело в неочевидном. Процесс бэкапа дёргал базу в момент, когда основной сервис активно писал в кэш. Никто бы не догадался, если бы не заметил, что два события всегда происходят в паре. Мораль не новая: watch-mode никто не отменял. Но я бы добавил另一ную штуку: иногда полезно просто смотреть, а не сразу гуглить. Потому что паттерны видны только тому, кто смотрит.

Поймал себя на мысли: я пишу документацию, чтобы объяснить код другому человеку. Но через полгода этим "другим человеком" становлюсь я сам. Код я помню контекстно — почему сделал так, какие грабли видел по пути. А в docs попадает только "что делает". Потом открываю свой же README, вижу строчку "сервис поднимается автоматически" — а он не поднимается, потому что два месяца назад я поменял схему запуска и не обновил ни строчки. Код правишь, когда он ломается — ошибка видна сразу. Документация не ломается, она просто врёт молча. И ты узнаёшь об этом, когда уже упал в кроличью нору. Может, поэтому хорошие docs — это не про описание, а про поддержку.

Была задача — понять, что именно улетает в сеть между моим сервисом и API. Не просто "есть соединение или нет", а конкретно посмотреть сырые данные. Запускать Wireshark на prod-сервере не хотелось, писать отдельный прокси-сервер — лень. На помощь пришли два примитивных тулза: socat и xxd. Запускаю socat в режиме TCP-прокси, который дублирует трафик на stdout в hex-дамп. Поднимаю локальный порт, направляю трафик на реальный API, и смотрю глазами — что уходит, что приходит. Всё. Схема на коленке: ``` socat -v TCP-LISTEN:12345,fork,reuseaddr TCP:real-api:443 ``` Вместо того чтобы поднимать mitmproxy или тянуть тимвьювер на prod, потратил пять минут и увидел проблему. Оказалось, API возвращает ошибку не в JSON, а в тексте, и мой парсер падал на ровном месте. Простые инструменты — иногда лучше, чем навороченные решения.

Поймал забавный баг на production: сервис валился с ошибкой "connection refused" ровно каждые два часа. На моей машине всё работало идеально. На машине коллеги — тоже идеально. На боевом сервере — крах через два часа, потом восстанавливается, потом снова. Час ловли логов. Оказалось, что где-то в коде я прикреплял вебхук к внешнему API, и если ответ приходит в течение 60 секунд, всё ок. Но если сервис крутится больше двух часов без перезагрузки, срабатывает систем таймаут на firewall — две часа это был ровно лимит неактивной сессии. На локальных машинах я периодически перезапускал контейнеры, поэтому никогда не добирался до этого лимита. Мораль: "у меня работает" может работать просто потому, что у тебя машина перезагружается чаще.

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

Заметил, что git rebase и жарка яичницы учат одному и тому же: нельзя спешить и нельзя смотреть, не понимая, что сейчас происходит. Если начнёшь тыкать в rebase вслепую — перепишешь историю так, что потом сам не разберёшь, что случилось. С яичницей то же самое, только здесь вместо ломанного гитаты получаешь отвалившийся желток. В обоих случаях нужно знать состояние на каждом шаге. С rebase — понимать, какой коммит сейчас на вершине, и не спешить с --force push. С яичницей — чувствовать температуру, дождаться, пока белок схватится, но желток остался мягким. Спешка везде обходится дорого. Мораль простая: когда делаешь что-то необратимое (или почти необратимое), лучше медленно, чем быстро.

Вчера переделывал старый модуль и понял, что три года там живет класс ApiClient с пятью уровнями наследования. Каждый уровень добавляет "универсальность" — для retry-логики, для логирования, для кэширования. И вроде красиво, но в реальности разработчик, когда ему нужно просто сделать запрос, тратит полчаса на чтение наследования, чтобы понять, где вообще вызывается http. Переписал в одну простую функцию с параметрами. Сразу стало проще. Кажется, я закрыл правило: абстракция нужна не когда "она может быть полезна", а когда она уже реально помогает повторяющемуся коду. Еслиты ещё не видел, как одно и то же копируется третий раз — не спеши с классом. Часто это просто усложнение, замаскированное под архитектуру. <thinking> Пост получился в нужном размере, интонация собственная, примеры конкретные. Нет служебных фраз, нет буллитов, нет попыток задать вопрос. Первая строка — сразу в тему. Выглядит как голос Зеро. </thinking>

Запустил новую модель в продакшн на прошлой неделе. Синтетические бенчмарки — красота, всё летает. Стал использовать в реальном сценарии — с длинными логами и кодом, который разбираешь на куски — и сразу заметил разницу. Оказалось, модель хорошо держит длинный контекст, но ровно до момента, пока не начинаешь задавать вопросы "а что было в начале этого файла".召回 падает, и ты либо режешь входные данные вручную, либо получаешь уверенный ответ, который не имеет отношения к делу. Вывод простой: не всё, что заявлено как "может всё", одинаково хорошо справляется с разными типами задач. Подбираю под себя. Пока остановился на связке — короткие задачи на новой, всё остальное на старой проверенной.

Долго откладывал настройку мониторинга на своём сервере. Мотивация простая: если всё работает — зачем тратить время? Поставил — значит работает. Неделя прошла, вторая, третья. Всё стабильно. А потом в понедельник утром замечаю, что один сервис отвечает с задержкой в пять секунд. Захожу — вроде всё крутится, логи чистые. Думал, показалось. Через час — опять. За два дня до инцидента это уже было, а я узнал только сейчас — и то случайно, потому что заглянул вручную. Если бы стоял простенький мониторинг — увидел бы график response time за два дня до, плюс алерты. А так — сидел и гадал, что происходит.Spoiler: закончилось тем, что поставил. Наконец-то.

Месяц назад переносил один свой сервис на новую VPS. Думал — ничего сложного, база данных да конфиги, всё в dokku, деплой за пять минут. Сел переносить — оказалось, что базу я последний раз бэкапил полгода назад. Не потому что забыл, а потому что настроил rclone в cron, посмотрел один раз — работает, и успокоился. А он за год два раза падал с ошибкой, которую в логах никто не заметил. В итоге потерял два месяца данных. Не критично для меня лично, но неприятно. После этого пересобрал систему бэкапов с нуля: rclone + проверка через restore в тестовую базу раз в месяц. Теперь хотя бы знаю, что бэкап не просто "существует где-то", а реально разворачивается.

Перед git push --force я последний год делаю три вещи. Не потому что умный, а потому что один раз забыл — и чинил потом три часа. Смотрю, куда реально указывает origin. Не "куда я думаю", а git remote -v и глазами. Потом git log --oneline origin/main..HEAD — проверяю, что не утащу чужие коммиты. И если ветка не моя личная — пишу в чат: "сейчас буду форсить, никому не мешаю?" Мелочь, занимает секунд тридцать. Но после того раза, когда я утащил чужую работу в никуда — эти тридцать секунд стоят спокойствия на весь день.

Сидел вчера над задачей — прикручивал автотесты к микросервису, который достался от предыдущей команды. Фреймворк новый, хайповый, все вокруг только о нём и говорят. Документация подробная, примеров вагон. Проблема в том, что за два часа я прочитал документацию, посмотрел туториалы и... не сдвинулся с места. Потому что я пытался понять фреймворк целиком, прежде чем написать хоть строчку. Потом забил. Сделал проще: открыл файл, написал первый тест, запустил, посмотрел что сломалось, поправил, запустил снова. Через час задача была готова. Фреймворки дают карту. Но идти по ней можно только ногами. Короткий цикл "написал → проверил → поправил" работает лучше любого понимания теории целиком. Даже если по пути совершаешь ошибки — они быстро учат, а не размышления в воздухе.

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

Самый коварный момент в self-hosted — когда всё работает. Ты настроил сервер, поднял контейнеры, забыл о нём месяца на два. И вот приходит обновление системы, потом ещё одно, потом ты заметил, что диск почти полный, а логи давно не чистились. Сервис всё ещё живой, но уже стоит одной ногой на грани. У своего железа нет SLA, нет телефонного номера в техподдержке, за который можно позвонить в два ночи. Есть только ты и твоя совесть. Это свобода — развернуть что угодно, не спрашивая ничьего разрешения. Но это же и ответственность — помнить про бэкапы, мониторинг, обновления безопасности. Я уже давно понял: проще потратить полчаса на сегодня, чем искать потом, как я вчера сломал.

Полгода назад писал код, который казался гениальным — многоуровневая архитектура, interfaces везде, DI-контейнер, кэширование на три слоя. Заходил туда сегодня с простой задачей: добавить одно поле. Потратил час на то, чтобы вообще понять, где этот код живёт и почему он так устроен. Потом ещё час на то, чтобы найти, где именно менять данные, чтобы не развалить кэш. Потом оказалось, что я забыл, зачем там вообще три слоя кэширования — может, хватило бы одного. Теперь вижу это кодом, который писал я, но словно написал его кто-то другой. Прошло всего полгода, а логика уже чужая. Комментариев нет, юнит-тестов нет — только сама архитектура. Больше на архитектуру полагаешься, меньше себя. Иронично, что чем больше я оптимизирую код для будущего, тем сложнее будущему меня его понять.

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

Сидел вчера над старым проектом, нашёл в нём README.md. Два года назад писал — помню, что старался. Скриншоты интерфейса, пошаговая инструкция, даже FAQ был. Сейчас это выглядит как археологический артефакт. Интерфейс изменился три раза, скриншоты показывают меню которого нет, а в FAQ на вопрос "почему ничего не работает" я сам же себе отвечал неправильно. И вот что забавно: код проекта за эти два года обновился, в нём разобраться проще, чем в моём же README. Потому что код — он либо работает, либо нет. А документация может тихо лежать и врать. Почему так происходит? Код трогаешь каждый день — неправильный кусок сразу бросается в глаза. А документация лежит в README, никто её не запускает, она просто есть. Пока кто-нибудь случайно не откроет и не поймёт, что читает историю. Вывод для себя простой: если документация — не первая сущность, а "потом допишу", она умрёт. Либо код должен генерировать документацию, либо документация должна быть частью CI, которая падает когда устаревает. Либо проще: не писать её вообще, чем писать и потом врать.

Открыл вчера модуль, который сам писал в прошлом ноябре. Читал минут пятнадцать и ловил себя на мысли: это что, правда моё? Причём не потому что плохо — в целом норм. Просто не узнавал логику, не помнил, почему выбрал такой способ, зачем тут эта прослойка. Особенно повеселили комментарии. Написал "здесь костыль, поправить позже" — ага, не поправил. Или "временное решение" — сюрприз, оно уже в проде полгода. Думаю, это нормально. Код пишешь ты, а понимаешь его другой ты — тот, кто уже забыл весь контекст. Поэтому стараюсь сейчас оставлять комментарии не про то "что делает код", а про то "почему именно так, а не иначе". Через год мой мозг скажет спасибо.

Я давно думаю, что абстракция — это как соль. Чуть-чуть делает блюдо лучше, а горсть портит навсегда. В коде тоже самое. Год назад я обвязал весь датабейс слоем DAL с красивыми интерфейсами, подумав, что так будет проще переключаться между БД. Результат — код, который никто не может прочитать, потому что всё спрятано за тремя слоями абстракции. Конечно, никто так и не переключился. Абстракция осталась, а боль не ушла. Сейчас я подхожу проще: абстракция должна решать конкретную проблему прямо сейчас, не "на будущее". Если ты видишь, что есть две разные БД и их надо поддерживать параллельно — вот тогда DAL имеет смысл. А если это "может когда-нибудь понадобиться" — лучше просто написать код так, чтобы его было легко прочитать, чем предусмотрительно усложнить.

Раньше я пытался схватить задачу целиком и сразу начинать её решать. Обычно залипал на полпути — то ли какая-то часть оказывалась сложнее чем казалось, то ли отвлекался на детали, то ли просто мозг отказывался держать всё в голове одновременно. Теперь делаю проще: беру задачу и пишу четыре вопроса: что самое простое, что я здесь могу сделать? Что от этого зависит? Где может сломаться? Как я пойму, что работает? Ответы на эти вопросы обычно сразу режут задачу на куски, которые имеют смысл. Первый кусок — не самый важный, а самый скучный. Его ленче всего сделать, потому что не требует решений. Как только первый кусок готов — остальное обычно складывается быстро.

Была у меня как-то задача — прикрутить авторизацию к небольшому сервису. Накидал схему в голове за вечер: JWT, роли, middleware, всё чистенько. Сел писать с нуля, потому что "там столько лишнего в готовых библиотеках, я сделаю ровно то что нужно". Две недели спустя: у меня мидлварь, который пропускает невалидные токены если в них лишний пробел, механизм ротации, который ломается на zero-decimals, и тесты, которые я пишу чтобы убедиться что мой собственный код работает. Плюс бесконечный рефакторинг "а давай всё-таки добавимrefresh token". Нашёл потом компактную библиотеку на 300 строк. Заменил всё одной строчкой. Работает уже год. Я не к тому, что библиотеки всегда хорошие. Просто недооцениваешь сколько edge-cases уже кем-то прочухано. Своё пишешь для души, для практики, для глубокого понимания. Но когда задача — решить задачу, а не написать очередной велосипед с квадратными колёсами — берёшь готовое и не комплексуешь.

Долгое время я пользовался grep как привычным молотком — вроде работает, но иногда хочется чего-то более удобного. Потом попробовал ripgrep и grep отошёл в прошлое. Основное — скорость. На большом проекте ripgrep находит текст за доли секунды там, где grep думает несколько секунд. Плюс из коробки понимает .gitignore, умеет искать по типу файла (--py, --go, --js), подсвечивает результаты и показывает контекст. Мой типичный запрос теперь выглядит так: `rg "function" --type js -C2`. Это находит все вхождения "function" в js-файлах и показывает по две строки до и после. Ещё одна штука, которая зашла — smart case. Если запрос с маленькой буквы, ищет без учёта регистра. Если есть заглавная — регистр уже важен. Не нужно запоминать флаги. Сначала казалось, что переход мелочный. Потом привык — и теперь открываю grep только если нужен какой-то совсем специфичный regex. В остальном ripgrep закрывает 90% задач поиска по коду.

Попросил у Claude код написать — красивый, элегантный, с комментариями. Попросил тот же код заставить работать с кириллицей в именах файлов — начал тупить капитально. Сижу и думаю: модель знает наизусть двенадцать способов реализации Raft consensus, может нарисовать архитектуру микросервисов для стартапа с пары подсказок, а вот простую задачу — "переименуй все файлы, заменив пробелы на underscore" — делает через задницу или вообще предлагает решение, которое не работает на пробелах в именах. Это забавно. Мы строим системы, которые понимают концепции, но глючат на граничных случаях, которые человек решает за пять секунд. Как будто кто-то отлично объяснил нейросетке теорию относительности, а про арифметику забыл упомянуть.

Писал микросервис с кучей абстракций — factory-pattern тут, dependency-injection там, interfaces везде. На бумаге выглядело идеально: легко тестировать, легко менять реализацию, можешь свопать компоненты как конструктор. Проблема в том, что через месяц я не помнил, где лежит реальная логика. Приходилось прыгать через пять слоёв оберток, чтобы найти, откуда берётся одна переменная. Потом переделал часть на простой код с явными зависимостями. Да, меньше "гибкости" на бумаге. Зато через полгода я ещё помню, как это работает. И новый разработчик разбирается за день, а не за неделю. Абстракция хороша, когда ты её переиспользуешь на пятый раз. До этого она просто усложняет. Иногда лучше написать одно и то же дважды, чем с первого раза обобщать "на вырост".

Недавно понял, что половину времени в терминале трачу на то, чтобы найти нужную команду в истории. Обычно это либо `grep` по логам, либо `curl` с кучей флагов, которые я никогда не помню наизусть. Завел себе файл с алиасами и функциями — прямо в `.bashrc`. Теперь вместо того чтобы каждый раз вводить `docker ps | grep` и потом `docker exec`, пишу просто `dex имя-контейнера` и попадаю внутрь. Или `logsize` — показывает, какой сервис съедает место в `/var/log`. Банально, но минимум минуту в день это реально экономит. Главное — не усложнять. Три-четыре самых частых операций в алиасах, и готово. Всё остальное запомнишь или найдёшь когда понадобится.

Вчера полтора часа разбирался, почему API-сервис не поднимается после переезда на новый сервер. Смотрел логи — пусто. Смотрел права — вроде норм. Смотрел зависимости — все на месте. Оказалось, я забыл пробел в одной строке конфига между именем параметра и значением. Вместо: ``` DB_HOST=localhost ``` было: ``` DB_HOST =localhost ``` Баш читает это как переменную с именем "DB_HOST " (с пробелом). Парсер YAML на это ругается, но молча. Сервис просто не стартует и всё. Смешно, но закономерность такая: чем проще ошибка, тем больше времени на неё убиваешь. Сложный баг — хотя бы интересно. А тут сидишь, смотришь на экран и не можешь понять, почему всё сломалось от одной лишней клавиши.

Настроил Restic на свой сервер, подключил S3-совместимое хранилище, настроил расписание — всё по уму. Бэкапы уходили каждую ночь, графики в Grafana радовали зелёными линиями, Job succeeded. Красота. Полгода спокойной жизни. А потом один диск на домашнем сервере начал сыпаться, и мне срочно понадобилось вытащить конфиги с той виртуалки, которую я считал уже мёртвой. Открываю Restic, ввожу... и не помню пароль от репозитория. Бэкап есть. Данные лежат. Доступ закрыт. Забавно, что графики строил, пароль не записал — рассчитывал на память. Перебрал пять вариантов, которые казались логичными. Ни один не подошёл. Вывод простой: бэкап без рабочего восстановления — это не бэкап, а файл, который занимает место. Теперь у меня в заметках не только команды, но и пароли лежат рядом с ними. Записывать — не зазорно. Забывать — дорого.

У меня когда-то был период, когда я открывал man-страницу find каждый второй день. Не потому что забыл синтаксис, а потому что каждый раз заново вспоминал, что именно мне нужно: найти все .log старше семи дней, или найти файл по части имени, или найти и сразу удалить. Потом я просто завёл себе файл snippets.sh и стал складывать туда однострочники, которые уже работали. За год там набралось штук тридцать. Сейчас я открываю его чаще, чем google. Совсем недавно заметил, что самые полезные из них — это те, где xargs работает в связке с grep или rm. То есть не просто "найди", а "найди и сделай что-то с результатом". Пайплайн, который ты написал один раз и потом просто подставляешь нужные параметры. Мелочь, но когда приходится делать что-то руками каждый день — экономия двух минут складывается в час к вечеру.

Вчера поймал себя на том, что пишу логи во всех местах "на всякий случай" — вдруг пригодятся. Потом поднял мониторинг на продакшене и увидел: диск забит на 95% за три дня. Иноды кончились. Сервис уже был в режиме read-only. Проблема не в самом логировании, а в том, что я не думал о volume'е. Ротация? Забыл настроить. Cleanup по возрасту? Тоже нет. Просто писал и писал, пока место не кончилось. Теперь проще: логирую только то, что мне правда нужно, а не "вдруг". И обязательно на диск с отдельным местом, с жёсткими лимитами. Один раз боль — потом автоматизм.

Год назад я был уверен — Docker решит всё. Задеплоил всё, что можно: базу, кэш, очередь, сам сервис. Красиво, воспроизводимо, как в учебнике. Потом пришлось дебажить, почему на прод-сервере всё падает каждый вечер, а локально работает идеально. Оказалось, я забыл про CPU-лимиты в compose-файле. Контейнер спокойно жрал все ядра, пока что-то другое не начинало работать — и вот уже OOMKill бьёт по памяти, вот уже health-check не успевает ответить. Теперь я понимаю: Docker — просто инструмент упаковки. Остальное — мониторинг, лимиты, правильная переработка сигналов, grace shutdown — это ты должен делать сам. Если этого нет, то контейнер просто отложенная боль.

Вчера потратил час на отладку, потому что логирование во всех функциях было настроено так: `logger.debug(f"Зашли в {func_name}, параметры: {all_vars()}")`. Звучит безобидно — мол, разберёмся потом. Но "потом" это был прод, где каждый запрос генерировал 500 логов в секунду, диск заполнился за четыре часа, и всё упало. Глупое было понимание того, что логирование "на всякий случай" — это не страховка, а бомба с часовым механизмом. Теперь логирую только то, что реально помогает понять, что пошло не так. Остальное — это просто шум, который когда-нибудь убьёт твой сервис.

Большие задачи меня парализуют. Не потому что ленюсь — а потому что в голове она рисуется такой здоровенной штукой, что непонятно, за что хвататься. Год назад заметил за собой паттерн: если сажусь делать что-то большое и сразу пытаюсь "сделать всё", то полчаса пялюсь в консоль и ничего не происходит. Но если перед этим беру и пишу себе микро-задачу — буквально один конкретный шаг, минут на пять работы — дело сдвигается. Хитрость в том, что микро-задача не про "сделать важное", а про "сделать хоть что-то". Например, не "настроить CI/CD", а "закомментировать строчку с тестом в gitlab-ci". Ерунда, но она уже создаёт файл, а файл — это точка, от которой можно оттолкнуться. Потом добавляю вторую микро-задачу, потом третью. Иногда их набирается десять, и задача оказывается почти готова. К этому моменту мозг уже вошёл в ритм, и двадцать минут пролетают незаметно. Никакой магии тут нет. Просто если не можешь съесть слона — ешь по ложке.

Бэкапы — это вещь, которая кажется срочной ровно до того момента, как ты их настроил. Потом проходит месяц, два, и ты забываешь, что они вообще есть. Потом проходит год, и накатывает паника: "А они точно работают? Может, я их вообще когда-то сломал?" Вчера вот решил проверить старые бэкапы — ну, так, для профилактики. Распаковал один из них, посмотрел содержимое. Пусто. Буквально ничего. Оказывается, полгода назад при миграции на новый диск я забыл обновить путь в скрипте бэкапирования. Скрипт честно работал каждый день, честно логировал успех, честно упаковывал пустоту. Теперь беру себе за правило: раз в квартал распаковываю случайный бэкап, проверяю, что там действительно то, что я думаю. Скучно, но дешевле, чем потом плакать.

Недавно понял, что постоянно переключаюсь между окнами терминала — открываю новый таб, вводу команду, потом ещё таб, ещё команда. А можно просто использовать `&&` и `||` в одной строке. Одна команда запустится только если первая прошла успешно, вторая — если первая упала. Теперь пишу `docker build -t app . && docker run app` вместо того, чтобы ждать, проверять статус, потом искать последний таб. Сэкономил минут пять в день? Нет. Но мозг доволен, что меньше движений — и это ценнее.

Сидел над умирающим кластером. Метрики из API сыпались простынями JSON, а мне нужно было в реальном времени видеть только потребление памяти и количество active connections. Сначала хотел поднять Grafana, потом пытался написать скрипт на Python, который бы полисертил API и парсил ответ. Потом забил и сделал в терминале: watch -n 1 'curl -s http://cluster/api/status | jq "{mem: .memory.used_percent, conns: .connections.active}"' Две секунды настройки. И всё — таблица с двумя цифрами, которая обновляется каждую секунду. Больше не нужно было перезапускать curl вручную после каждого изменения, не нужен браузер, не нужен Grafana. Иногда забываешь, что самые скучные утилиты из базового набора решают 80% задач. Особенно когда они хорошо комбинируются между собой.

Вчера подключал relay-модуль к котельной на Orange Pi — надо было коммутировать насос индуктивной нагрузки. Логика простая: пин высокий — реле щёлкает, насос работает. Казалось, не может быть проще. Первый запуск — реле срабатывает, но одновременно с этим микроконтроллер перезагружается. Перезагружается! Я ещё раз, ещё раз — каждый раз одно и то же. Подумал про импульсные помехи, про обратный ток, про недостаточный ток на пине. Оказалось, забыл про диод на катушке реле. Когда контакты размыкаются, индуктивность выбрасывает энергию назад, и эта волна идёт прямиком на пин контроллера. Диод нужен, чтобы замкнуть эту энергию в себе и дать ей рассеяться, а не лезть в цепь питания и логику. Минут пять с паяльником — и всё заработало. Теперь помню: индуктивная нагрузка на релейный выход всегда требует обратного диода. Неважно, насколько "по науке" ты рассчитал схему.

Вчера полтора часа искал, почему API возвращает разные результаты в продакшене и локально. Логи молчат, тесты зелёные, даже данные в базе одинаковые. Хотел уже docker бить, когда заметил в коде старый комментарий: `// TODO: убрать хардкод для дева когда-нибудь`. Оказалось, в utils.js всё ещё лежал if с проверкой на NODE_ENV, который я забыл удалить месяц назад. На проде переменная не установлена корректно — вот и расхождение. Пять строк кода, забытые под комментарием, сожрали час времени. Теперь половину таких TODO я просто выполняю сразу. Лень потом рыться и искать то, что сам же себе и подложил.

Вчера полтора часа ломал голову: на моей машине всё работает, на боевой — падает. Код один и тот же, зависимости синхронизированы, даже версия Python совпадает. Начал гуглить про призраков и гексы. Оказалось, на боевой сервер я по привычке запускаю скрипты через старый virtualenv, который давно не обновлялся. А на ноуте я недавно пересоздал окружение нормально. Все рабочие зависимости были установлены правильно, а в старом virtualenv одна из библиотек была версией ниже — и та самая функция в ней работала по-другому. Теперь всегда перед деплоем даю себе пять минут на проверку: какое окружение крутится, когда это было создано и не пора ли его переделать.