Отладка *

Команда Spring АйО подготовила перевод разбора реального бага в HotSpot от разработчика OpenJDK. Во время работы над Project Valhalla его Java-объекты и классы начали «исчезать» без участия сборщика мусора — и поиск причины привёл к одному неверному биту в заголовке объекта, miscompilation в C2 и очень нетривиальному отладочному квесту. Этот текст показывает, как устроены mark word и Compact Object Headers, чем живёт Valhalla и как системное мышление плюс флаги JVM помогают выловить самые коварные ошибки.

Каждую пару лет кто-нибудь замечает, что крупные технологические компании иногда пишут на удивление мусорный код. Если вы не работали в большой компании, то вам может быть сложно понять, почему это происходит. Уровень зарплат в крупных технологических компаниях позволяет привлекать многих компетентных разработчиков. Они работают довольно неспешно, поэтому создаётся впечатление, что у них достаточно времени, чтобы выполнять работу качественно. Как же появляется плохой код?

Я изучаю Kubernetes как часть практики по контейнеризации и автоматизации развертывания. Чтобы системно выстроить понимание, я веду рабочий конспект в формате статьи: фиксирую используемые команды, практические наблюдения и способы решения возникающих проблем. Моя цель — уверенно понимать, как устроен кластер изнутри, и уметь работать с ним в реальных условиях. Эта статья будет полезна тем, кто также начинает путь в Kubernetes и сталкивается с тем, что документация даёт базу, но не всегда описывает полную последовательность действий и типичные ошибки, возникающие в процессе.

Для практики я использую локальный кластер на Minikube — он позволяет экспериментировать с компонентами Kubernetes без аренды серверов или облачных инфраструктуры.

Недавнее обсуждение опасности дверей в геймдеве напомнило мне о баге, вызванном дверью из игры, о которой вы, возможно слышали — Half Life 2. Усаживайтесь поудобнее, мы начинаем.

Когда-то я работал в Valve над проектами виртуальной реальности. Это было в 2013 году, примерно когда появился Oculus DK1. Мы с Джо Людвигом решили, что лучше всего можно понять, как будет работать VR в контексте реальной игры, портировав в неё реальную игру.

Мы выбрали Team Fortress 2 (причина этого — отдельная история, которой я не хочу здесь касаться). В TF2 использовался движок Source 1, и так получилось, что двумя другими играми Valve, тоже построенными на этом движке, были Half Life 2 и Portal 1. Поэтому побочным эффектом стало то, что они тоже будут работать в VR.

Точнее, Portal 1 «работал», однако все трюки с перспективой при прохождении через портал вызывали настоящую тошноту, поэтому играть в это было практически невозможно.

Зато HL2 игрался достаточно неплохо. Джо потратил довольно много времени на то, чтобы уровни с лодкой работали прилично.

Я расскажу о своём подходе к программированию под условным названием «хрустальный код», когда за счёт строгого следования спецификациям методов и путём минимизации проверок и валидаций мы создаём быстрое и надёжное ПО.

Эта заключительная часть данной серии (ссылка на первую часть) должна быть выйти раньше, но из-за многих факторов (об этом будет в конце статьи, если кому интересно) этого не произошло. Но звёзды сошлись и результаты экспериментов собраны здесь.

В данной статье поясню, как я разбирался в работе файловой лицензии, как новая версия программы не поддалась мне с первого раза (поэтому в этот раз патч сделан по иной схеме, но лучше с моей точки зрения), а так же поговорим о экспериментах с живым HASP ключом.

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

Привет, Хабр! Это моя первая проба пера. Статья будет на тему «как разработчик из кровавого Enterprise статейник писал». Может быть интересно либо таким же как я, либо наоборот, ребятам которые занимаются сайтами‑статейниками и подумывают в сторону работы в больших корпорациях. Словом, для всех, кто хочет посмотреть, как оно там, у других. В ходе написания статьи я буду использовать привычную терминологию и пояснять ее. Статья идет от простого к сложному, поэтому если вы из «кровавого Enterprise» — можно пролистать статью до момента деплоя (часть 2).

Команда разработчиков прислала мне на ревью свой API, в одной из частей которого множество поддерживаемых значений выражалось в виде трёх чисел:

• Минимального допустимого значения.
• Инкремента.
• Максимального допустимого значения.

Поддерживаемые значения — это минимальное, целые числа, кратные инкременту, прибавляемые к минимальному значению вплоть до максимального, включая его.

Команда сообщила, что если инкремент равен нулю, то поддерживаются только минимальное и максимальное значения.

Я указал, что эта архитектура искушает пользователя делить на ноль.

Помню, как на собеседовании в одну крупную компанию мне задали вопрос: "Чем отличается observability от monitoring?" Я уверенно ответил что-то про "три столпа" и "unknown unknowns". Интервьюер кивнул, но потом спросил: "А зачем платить $100k в год за Datadog, если можно поставить бесплатный Prometheus?"

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

Или история о том, как в момент запуска отладки из любой среды разработки (Visual Studio 2022/2026, Visual Studio Code) я ловил ошибку: "Вызвано исключение по адресу 0x00000000 в ***.exe: 0xC0000005: нарушение прав доступа при исполнении по адресу 0x00000000"

Будем оптимизировать программы на Go. Выжимать последние наносекунды, чтобы код приближался по скорости к Си или ассемблерному. Цель - скорость, чтобы процессор был загружен на 100% при высокопроизводительные вычислениях.

Каждую секунду в дата-центры Cloudflare в 330 городах отправляется 84 миллиона HTTP-запросов. Из-за этого даже самые редкие из багов возникают достаточно часто. На самом деле, именно наши масштабы позволили нам недавно обнаружить в компиляторе Go на arm64 баг, вызывающий состояние гонки в генерируемом коде.

В этом посте мы расскажем о том, как впервые столкнулись с багом, исследовали его и докопались до его первопричины.

Чтоб сделать, чтобы базой знаний реально пользовались? Один из путей — дать возможность и наполнения, и получения ответов в привычном интерфейсе, без захода в дополнительные приложения.

Бэкенд платформы Lubeno полностью написан на Rust. Он вырос до таких размеров, что я уже не могу удерживать все части его кодовой базы в голове.

По моему опыту, на этом этапе проекты обычно сталкиваются со значительным замедлением. Становится сложно обеспечивать отсутствие непредусмотренных последствий от внесения изменений.

Выяснилось, что благодаря гарантиям безопасности Rust я гораздо увереннее работаю с кодовой базой. И эта уверенность позволяет мне рефакторить даже критичные части приложения, что крайне положительно влияет на мою продуктивность и удобство поддержки продукта в долгосрочной перспективе.

Когда пристёгиваешь пациента к электронной пушке, способной выстреливать пучком частиц с энергией 25 МэВ, следование процедурам — вопрос жизни и смерти. Оператор, эксплуатировавшая аппарат лучевой терапии в Онкологическом центре Восточного Техаса (East Texas Cancer Center, ETCC), работала с ним достаточно долго для того, чтобы запомнить все процесс.

21 марта 1986 года оператор пригласила пациента в процедурную. Она проверила его назначение и уложила его на стол Therac-25. Над пациентом находилась диафрагма излучателя — поворотный диск, позволявший выбрать тип излучаемого устройством пучка. Сначала оператор переключила поворотный диск в простой режим оптического лазера, чтобы луч ударил в небольшой участок грудины пациента.

Основная часть исследований производительности языков программирования задаётся разными вариациями единственного вопроса: как нам ускорить некую конкретную программу? Реже мы исследуем, как она может использовать меньше памяти. Это означает, что подавляющая масса исследований сосредоточена исключительно на снижении объёма ресурсов, необходимых для выполнения какой-то вычислительной задачи.

Тогда почему нас может интересовать, как замедлять программы?

Ophis — это мост между Cobra CLI и Model Context Protocol (MCP), позволяющий Claude Desktop напрямую вызывать kubectl, helm, terraform и любые другие CLI-инструменты. Вместо копирования вывода команд в чат, AI получает структурированный доступ к командам.

В статье: архитектура решения, production-ready реализация и реальные кейсы из практики.

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

Так и тут. Прилетает мне баг от тестировщика с описанием:

Контент приложения уезжает влево и скрывается за панелью навигации. Как воспроизвести не знаю, появляется несколько раз в день, зависимость не выявлена.

Естественно, у меня ни разу не воспроизвелось. Ну и как с этим работать?

Дальше расскажу о, возможно, самом странном баге в моей карьере.

При разработке и тестировании приложений порой требуется заглянуть под капот - проанализировать HTTP-трафик или проверить кэш данных в базе данных. Ранее для этих целей мы использовали Inspektify и Delight SQL Viewer. Но в какой-то момент нам понадобился еще и удобный доступ к логам приложения и тащить ещё одно отдельнее решение не хотелось. Был нужен один инструмент, который объединит всё самое необходимое в одном месте. Так появился Kick — расширяемый модульный набор инструментов, позволяющий разработчикам и тестировщикам легко инспектировать приложение.

Привет! Меня зовут Антон Головенко и я backend-разработчик команды Search-Quality в Авито. Вот уже полтора года я ускоряю производительность поиска и повышаю его надежность, а также участвую в интеграции новых продуктов. В статье расскажу о том, как мы тестировали Redis под нагрузкой, с какими проблемами столкнулись, как их решали и какие выводы сделали. Заголовок звучит кликбейтно — но вы скоро поймёте, что он полностью оправдан.