
Наверняка у каждого бэкендера или девопса была такая ситуация:
Нужно срочно посмотреть, что случилось на проде. Вы скачиваете server.log, по привычке кликаете на него в VS Code... и всё.
Читать полностью »

Наверняка у каждого бэкендера или девопса была такая ситуация:
Нужно срочно посмотреть, что случилось на проде. Вы скачиваете server.log, по привычке кликаете на него в VS Code... и всё.
Читать полностью »
Эта история — небольшая попытка восстановить рабочие рефлексы инженеров, которые решали реальные задачи с минимальными инструментами, и показать, как эти приемы работают в современных проектах. Статья для тех, кто хочет прокачать интуицию в отладке и научиться мыслить в условиях ограничений, а не только в облаке и на CI.
«Программирование микроконтроллеров — это не только головой, но и руками. Не только руками, но и головой.»
Пролог
Так вышло, что до разработки автомобильной электроники я варил прошивки для infotainment аудиосистем. Поэтому на новые задачи я смотрю через призму прошлого опыта.
Как оказалось при разработке электроники часто приходится работать с CAN шиной. Это не только автомобилестроение, но и электронная начинка для лифтов, поездов, кораблей, космических аппаратов и прочего тоже использует CAN шину для общения между агрегатами.
В девяностых код писали иначе. Без систем контроля версий, без удобных IDE, без привычных методологий. Программисты строили проекты на интуиции, инстинктах и личной дисциплине. В этой статье — живая реконструкция той культуры: от стиля кода и комментариев до методов отладки и документирования. Без романтизации, но с уважением к эпохе, которая воспитала инженеров, умеющих думать головой, а не кнопками.

Привет! Я — Александр Дудукало, автор базового курса по JavaScript. В этой статье мы продолжим изучение работы с данными в JavaScript. Если в прошлом Читать полностью »
Почему-то не нашёл с первой попытки здесь на Хабре какого-нибудь демо или инструкции по использованию этой старинной, но милой тулы из стандартной поставки DOS. Давайте быстренько это исправим. Как легко догадаться из названия - DEBUG.EXE предполагается использовать для отладки. Мы же напишем в ней несколько коротких ассемблерных программ "с нуля" - это не займет много времени, а притом даст лёгкое ощущение магии!
Представьте типичный workflow DevOps-инженера с AI-ассистентом:
# Человек копирует в Cursor:
$ kubectl get pods -n production
NAME READY STATUS RESTARTS AGE
api-service-7d4b5c6-x2kl9 1/1 Running 0 5h
api-service-7d4b5c6-m3nq2 0/1 Pending 0 2m
worker-5f6d7c8-p4rs5 1/1 Running 3 12h
# Cursor: "Вижу проблему с подом api-service-7d4b5c6-m3nq2..."
# Человек: копирует describe
# Cursor: "Проверьте events..."
# Человек: копирует events
# И так 10 раз...
Боль очевидна: ручное копирование, потеря контекста, невозможность автоматизации. Можно потратить до 40% времени на такой "ручной debugging" с AI.

Пожалуй, самые неприятные баги – те, что воспроизводятся один раз из ста. Их не пощупать, не продебажить и даже не проверить результат.
Так и тут прилетает мне баг от тестировщика с описанием: