Изначально вторая главазадумывалась только, как шпаргалка по работе из оперативной памяти, но делать и разбираться в этом не очень трудно. Основная "запара" может настигнуть несведущего именно при работе с прерываниями. Собсна, решено объединить.
Во первых строках сего письма хочется сказать, что идея написать эту статью пришла из-за того, что волею судьбы мне пришлось работать с микроконтроллерами компании Миландр. Помимо того, что информации по сети не так много, она еще и достаточно разрознена. И все бы ничего - кто ищет, тот найдет. Но пришлось (за неимением ничего другого под рукой) отлаживать программы при помощи эмулятора от Olimex. Тут стало тяжелее и было решено хоть как-то систематизировать знания для таких же зеленых бедолаг, как я, которые, возможно, столкнутся с подобными проблемами.
Ваша винда не работает как хотелось бы? Все советы из поисковика перепробовали установили Linux, а оно всё равно не работает? Вы реверс-инженер или кто вообще, ну в самом деле!? Применим свои навыки владения отладчиком, поможем Шиндовс нормально (по мере её сил) работать!
На написание данной статьи меня подтолкнула злость. Злость на поделие от индусских говнокодеров под названием Windows, на то, что гугол выдаёт мне абсолютно нерабочие решения столетней давности. И вот, когда даже обновление до 11-й винды (с сохранением всех настроек и программ), а потом ещё и установка её же поверх себя не помогли, я решил, что нужно подойти с другой стороны - не как пользователь, а как реверс-инженер.
Для опытных разработчиков информация статьи может быть очевидной и если вы себя таковым считаете, то лучше добавьте в комментариях полезных советов.
По опыту работы с начинающими разработчиками, я сталкиваюсь с тем, что поиск ошибок порой занимает слишком много времени. Не из-за того, что они глупее более опытных товарищей или не разбираются в процессах, а из-за отсутствия понимания с чего начать и на чём акцентировать внимание. В статье я собрал общие советы о том где обитают ошибки и как найти причину их возникновения. Примеры в статье даны на JavaScript и .NET, но они актуальны и для других платформ с поправкой на специфику.
До текущего момента, отладка С кода для ZX Spectrum была возможна только в некоторых эмуляторах. В предыдущей статье описан процесс написания отладчика, который использовал цепочку gdb-клиент (z88dk) <-> gdb-протокол <-> gdbserver (эмулятор Fuse).
В этой статье описан процесс написания "железного" отладчика для ZX Spectrum, то есть такого, в котором и непосредственно целевой код и код отладчика выполняет один и тот же z80. Как и в случае с эмулятором, используется сетевой протокол gdb, для этого требуется сетевой адаптер Spectranet, который постепенно собирает вокруг себя значительное (англоязычное) сообщество.
Также в статье описана реализация "точек останова" — механизма, без которого не может обойтись ни один отладчик.
На работе я занимаюсь созданием PCIExpress устройств на ПЛИС. Некоторые из ПЛИС имеют встроенное PCIExpress ядро, позволяющее работать с этим интерфейсом на уровне пользовательского приложения. ПЛИС серии ECP5UM фирмы Lattice использует Soft-IP Core для реализации протокола, написанный на языке HDL, а в микросхему лишь встроен блок, отвечающий за работу физического уровня. Мне пришла в голову идея попробовать сделать PCIExpress анализатор на базе этой микросхемы.
Цены на профессиональные анализаторы не доступны простому разработчику, да и зачастую неподъёмны даже для небольших фирм. Хотя для целей диагностики и обучения возможно создание бюджетного прибора, который хоть и будет уступать профессиональному устройству, но при этом будет выполнять основные функции анализатора, удовлетворяющие большинству потребностией в вопросах отладки протокола.
В данной статье я предлагаю описание первого устройства, созданного для проверки концепции. В ней содержится краткое описание архитектуры PCIExpress, общая идея проекта, результаты реализации и тестирования первого прототипа.
Простые числа, согласно известному определению – такие числа, которые делятся только на 1 и само себя. Иначе, число считается составным, и его можно разложить на произведение простых чисел. Единица формально соответствует определению простого числа, но это число принято не относить ни к простым, ни к составным.
Как искать простые числа? Можно действовать напрямую, применяя определение: просто делить каждое данное число N подряд на все числа m<N.Такая стратегия тоже имеет смысл, и ее можно обсуждать, и даже думать о том, как ее совершенствовать, но сегодня у нас будет другая история.
Приветствую, хабраюзер! Эта история началась со странного падения Python приложения. Сначала я не придал внимания данной проблеме: приложение запущено в Openshift и периодически падает. К такому поведению может приводить всякое, например, иногда ноды обновляют, а иногда случаются аварии и тогда одну или несколько нод выводят из эксплуатации. Однако со временем проблема стала регулярной и начала проявляться некоторая закономерность. При этом в Sentry не было каких-либо ошибок. Я был полностью уверен, что это какая-то типовая проблема и ее можно быстро решить, но как же я ошибался.
Привет, Хабр. Хочу поделиться своим решением одной из проблем использования корутин в Kotlin.
Корутины в Kotlin - одна из значимых фич языка, которая позволяет писать асинхронных код в синхронном стиле. Корутины прекрасны во всём, до тех пор пока не возникает необходимость их дебажить.
Правильный процесс ревью кода — это процесс итеративного улучшения продукты и контроля.
Контроля того, что:
1) Cоблюдены общие правила и договорённости
2) Решение не избыточное и масштабируемое.
3) Решение покрывает все критерии приемки указанные в описании к задаче
Для начала будет хорошо задать в своей команды такие вопросы:
1) Сколько времени занимает ревью кода для средней (сферической в вакууме) задачи
2) Как вы минимизируете время ревью?
3) Как вы определяете, что ревью конкретной задачи сделано правильно?
Отладка в контейнерной среде – дело не самое простое, поэтому разработчики зачастую прибегают к неэффективным методам локализации ошибок на этапе развертывания. Быстрее и красивее будет использовать отладчик на удаленном сервере, задав точки останова для поиска причин неполадок.
Именно этот вариант мы рассмотрим сегодня и покажем, как запускать отладчик на кластере Kubernetes через IDE-среду Visual Studio Code (VS Code). В качестве приложения у нас будет программа на Go, но всё изложенное вполне применимо и к другим языкам программирования и отладчикам.
Привет! Я Антон Антонов, Full Stack Developer из Plarium Krasnodar. Расскажу, что помогает мне исправлять ошибки в коде.
Ошибки есть в каждом коде. Мы перевели гайд разработчика Айо Исайя, в котором он рассказывает о системе ошибок и о том, как их устранять.
Прошло уже достаточно времени с момента релиза Python версии 3.10. Самым главным и самым ожидаемым было введение оператора match/case (он же pattern matching).
Однако далеко не всем разработчикам из комьюнити зашел данный оператор. Свидетельствуют этому даже комментарии под статьями на хабре (статья 1, статья 2), которые были посвящены match/case.
На мой взгляд, новый оператор упрощает жизнь разработчикам, принимая на себя работу с проверкой типов данных или принадлежность определенному классу. Но, как мы все знаем, зачастую за крутые фичи, введенные в язык, программисту приходится платить. В данной статье я хотел бы осветить тему производительности оператора match/case и сравнить его с обычным if/else.
В заключительной части разберём, как добавить точку останова с условием, использовать console.log, не используя console.log, что делать, если хочется глубже погрузиться в отладку JavaScript, и даже как принять участие в разработке браузера.
Привет, Хабр!
В октябре мы провели онлайн-митап по тестированию, в котором спикеры из Badoo, Skillbox, Почтатех и SuperJob поговорили о своем опыте перехода от ручного тестирования к автоматизации, рассказали о подходах к стабилизации тестов для мобильных приложений и многом другом. Встречу посетили более 600 участников, а QA Lead SuperJob Антон Шкредов получил столько интересных вопросов, что мы решили сделать отдельный пост в блоге. Итогами разбора делимся под катом.
Запись митапа доступна по ссылке, а если смотреть неудобно, то главные тезисы доклада Антона можно почитать на Хабре.
В третьей части ищем ошибку при удалении задачи из списка дел, и попутно путешествуем во времени разбираемся со стеком вызовов в отладчике.
В жизни каждого инженера может произойти ситуация, когда процесс его приложения «завис» и не выполняет ту работу, которую должен. Причины могут быть разные и чтобы узнать их, нужно заглянуть во внутренности процесса и расследовать, что же там происходит. Для этого, можно снять дамп и проанализировать его. Каждый такой случай уникальный, но подходы к анализу дампов — общие. В этой статье я покажу, как расследовал одну из подобных ситуаций и пришёл к неожиданным выводам.
