Недавно у меня была итерация тестирования. Задача — проверить функционал, для которого нужно было создать 50+ сущностей. Однотипных, с разными названиями.
Обычно такое делаю через интерфейс. Открываю форму, заполняю поля, сохраняю. Потом ещё раз. И ещё. Пятьдесят раз. Я замерял: на одну сущность уходит примерно 20 секунд. Умножаем на 50 и получается больше 15 минут однотипных действий. А времени на итерации всегда мало.
Мы много разрабатываем с помощью coding agents: веб‑приложения, MCP‑серверы, пайплайны обработки данных, системы из нескольких агентов. И чем лучше становилась инфраструктура вокруг агентов, тем больше в ней появлялось инструкций, проверок, субагентов и автоматики. По идее, разработка должна была становиться дешевле. А расход контекста рос.
Первое подозрение было очевидным: слишком раздутые промпты. Мы искали не там.
Агент закончил изменение и запустил тесты. 178 тестов, все зелёные. На stdout прилетело 38 365 байт TAP:
# Subtest:...
ok 1 ‑...
‑-
duration_ms:...
type: 'test'
..
Аналоги умеют мигать рамкой вокруг обновившегося компонента. Этого хватает, чтобы заметить проблему, но не чтобы её починить: остаётся вопрос «а что вообще изменилось?».
Оказалось, Vue знает ответ и отдаёт его сам — просто этим почти никто не пользуется. Под катом: как устроен хук renderTriggered, почему сырое событие из него нечитаемо, и три способа уронить прод‑сборку чужого приложения дев‑инструментом, который в проде вообще не должен работать.
Есть Vue DevTools с галкой «Highlight updates». Есть react‑scan в соседней экосистеме. Оба показывают одно и то же: вот этот компонент перерисовался.
В домашней инфраструктуре у меня крутится десяток сервисов: Grafana, Zabbix, n8n, Navidrome, ollama, БД, пара дашбордов и тестовых API. Каждый раз, когда нужно было выставить новый сервис наружу, я открывал дашборд Cloudflare и руками проходил один и тот же путь: создать туннель, прописать ingress‑правило, добавить DNS записи, настроить Zero Trust Access. Минут пятнадцать, если без ошибок. С ошибками — больше, потому что один неверно скопированный tunnel ID ломает всю цепочку и приходится откатывать вручную.
На какой‑то раз стало понятно, что это рутина, которую можно свернуть в одну команду. Так появился cfzt — CLI на Go, который сейчас умеет:
zt up grafana 3000
У любой удобной штуки есть момент, когда она начинает раздражать.
С Codex у меня это случилось, когда аккаунтов стало больше одного. Один рабочий, один личный, один запасной. И дальше начинается обычная бытовая возня: то не тот auth.json, то уже кончился лимит, то вообще непонятно, под каким профилем сейчас запущен CLI.
Можно, конечно, хранить несколько файлов и копировать их руками:
cp auth-work.json ~/.codex/auth.jsonНо это ровно тот способ, который сначала кажется нормальным, а потом внезапно бесит каждый день.
Я в итоге написал маленький bash-скрипт codex-auth, который делает три простые вещи:
Эпоха комфортного программирования подходит к концу. Пока программисты ваших конкурентов потягивают тыквенный латте и вяло ждут окончания медленных пайплайнов, GitCrab превращает ваш репозиторий в суровую экосистему, где выживает только сильнейший.
Большинство CI/CD инструментов помогают вам деплоить. GitCrab заставляет вас бороться.
Современный frontend давно перестал быть страницей, которую можно объяснить через DOM, сетевые запросы и консоль браузера. Значительная часть поведения интерфейса рождается уже после загрузки: внутри состояния приложения, реактивных зависимостей, цепочек computed-логики, store, runtime-обновлений и внутренних связей между компонентами. При этом основной QA-инструментарий во многих сценариях остаётся почти тем же, каким был в эпоху, когда большая часть логики ещё находилась снаружи.
Network показывает транспорт.
DOM показывает результат.
Console показывает ошибки.
Всем привет! Я около 10 лет в разработке и последние 5 лет полностью живу в экосистеме JetBrains. За это время у меня накопилось порядка 150 репозиториев — рабочие проекты, личные эксперименты, демо, инфра. Всё это, конечно, аккуратно разложено по папочкам, помечено тегами в Finder и добавлено в быстрый доступ.
И долгое время этого хватало.
Я работаю с несколькими клиентами. Активных проектов обычно около 25 штук. С таким количеством стандартный Recent Projects в IntelliJ IDEA справляется прекрасно: быстро ввёл название сервиса в поиск — быстро открыл. Никаких проблем.