Я достаточно давно решил ознакомится с ассемблером архитектуры Arm. По большей части для ознакомления и понимания внутренних процессов архитектуры. Чем больше я изучал литературу и различные источники, тем больше я понимал, что нужна практика. Я решил вспомнить ассемблер для x86-х машин и заодно потренироваться на архитектуре Arm.
Но как всегда для практики надо быть подготовленным, а как оказалось, я был не подготовлен...
Данная статья является переводом видеоролика с канала Мэтта Вулфи, который в основном посвящен теме искусственного интеллекта.
В данном видео Мэтт Вулфи обсуждает вопрос, который волнует многих: сможет ли искусственный интеллект заменить программистов? Он рассматривает текущее состояние дел и будущие возможности ИИ в программировании.
Основные моменты видео:
Разногласия в части темы замены программистов Искусственным Интеллектом.
Автоматизация задач с помощью ИИ: написание и отладка кода.
Влияние ИИ на участие разработчиков в процессе.
Необходимость наличия связующего звена между ИИ и конечными пользователями.
А также много другое и капелька теории!
Для достижения высокого качества программного продукта, как тестирование, так и отладка играют решающую роль. Каждый из этих процессов вносит свой вклад в итеративный цикл улучшения программного продукта, обеспечивая его надежность, стабильность и соответствие требованиям пользователей.
Значение тестирования
1. Обеспечение соответствия требованиям: Тестирование помогает убедиться, что программное обеспечение соответствует всем функциональным и нефункциональным требованиям, выдвигаемым заказчиками или пользователями продукта. Это обеспечивает, что программное обеспечение выполняет только необходимые функции и работает в соответствии с ожиданиями.
2. Выявление дефектов: Через процессы тестирования обнаруживаются ошибки и дефекты, которые могут быть пропущены разработчиками во время программирования. Раннее выявление этих проблем снижает стоимость их устранения и способствует повышению качества продукта.
Решил потренироваться на ассемблере под x86 и выбор мой пал на KolibryOS. Ведь как-никак это ОС была написана на ассемблере и для использования ассемблера. И я хотел именно из самой KolibriOS писать код. Но... Наверное, зря я это всё затеял.
Как оказалось, примеров кода не мало и не много. А так как я привык к Dos, Windows или Linux, то и ожидал что-нибудь в этом роде. Код, код и ещё раз код. Макросы не так часто встречаются. Ну и уж точно не весь код из одних макросов (утрирую).
Пример кода из «официального источника» вносит больше сумятицы, чем понимания, что происходит в данном коде. И... там нет никакого объяснения этим «буквенным значениям». Есть только то, что ссылаются на файл «macros.inc». Если просматривать источники интернета, то где‑то более понятно написано и даже рассказывают, что взять «macros.inc» (и многие другие файлы можно на SVN KolibriOS и, как оказалось, ещё можно на GitHub (дублируется?).
Покопавшись в файле «macros.inc», а так же на просторах интернета и найдя пример (смотрите код Fasm), я понял, что всё становится на свои места и более‑менее проясняется.
Поиск ошибок в программах дело творческое и интересное. Чаще всего мы ищем ошибки в своём коде, чтобы его починить. Кто-то может искать ошибки в чужом коде, чтобы его сломать или поучастовать в баунти-программе.
А вот где именно искать ошибки? Какие функции тестировать? Хорошо, если программа полностью ваша. Но что если вы занимаетесь тестированием, а эти программисты постоянно придумывают что-то новое? Никаких рук не напасёшься.
Предыстория
В сфере АСУ ТП инженерам по работе приходится не только писать ПО, но и использовать готовое ПО от производителей оборудования. В связи с санкциями, многие поставщики покинули РФ, а оборудование и ПО необходимо продолжать эксплуатировать дальше.
В данной статье будет расмотрена WinFXNet - программа производителя Schneider Electric (ESMI) для конфигурирования станций пожарной сигнализации серии Esmi FX. К сожалению, из-за санкций, ключ USB Esmi FX FFS00393016 приобрести нельзя, а он, в свою очередь, имеет встроенный таймер, который настроен на 4-летний период. У многих данный ключ по времени уже закончился, плюс скоро закончится и лицензия на само ПО (файл формата lic). Поэтому достаем дизассемблеры и посмотрим, можно ли обойти данную защиту.
Disclaimer: Данная заметка написана в ознакомительных целях и не является руководством к действиям. Хотя, понимая всю безвыходность данной ситуации, как временное решение имеет право на жизнь, но решать только вам. Статья написана как туториал, поэтому постараюсь детально описать все шаги поиска нужных мест в программе.
Привет! Меня зовут Алексей Маряхин, я работаю разработчиком на Oracle и пишу много, очень много кода. И когда программа ведёт себя не так, как ожидалось, на помощь приходит отладка.
Не так давно выяснил, что не все разработчики владеют функционалом отладки или знают её фичи. А если код сложный и баги искать всё равно надо? Литературы на русском языке про отладку практически нет.
Тогда я собрал подробный гайд для коллег и провёл внутренний семинар по обмену опытом. Материал получился настолько подробным и полезным, что решил поделиться им с сообществом программистов. На примере инструментов для работы с СУБД Oracle, которые используются у нас в компании, посмотрим, как работает отладка, сравним их в теории и узнаем, что внутри.
В серии из двух статей подробно расскажу о способах, инструментах и нюанса отладки кода PL/SQL. Первая часть — про инструмент PL/SQL Developer. Поехали!
С++ видится мне огромным франкенштейном: очень уж много разнообразных способов описать свои намерения. В добавок к этому язык пропагандирует политику zero-cost abstractions, из которой следует (помимо прочего), что программист в ответе за все свои действия. Однако, работая с большими кодовыми базами, становится крайне тяжело держать в уме различные тонкости языка, которые держать в уме нужно — иначе Undefined Behavior.
В данной статье хочу рассказать о трех интересных случаях UB, с которыми столкнулся при разработке на С++. Не думаю, что опытным разработчикам примеры из статьи будут полезны, но, полагаю, что начинающим разработчикам смогу показать на своем примере, как не стоит писать код на C++.
Давайте рассмотрим, как вы можете реализовать обработку ошибок, используя IExceptionHandler в .NET Core 8.0. Этот подход следует похожим паттернам предыдущих методов обработки ошибок в ASP.NET Core, но добавляет дополнительную возможность внедрения вашей собственной логики обработки исключений в exception handling middleware.
Привет, я руководитель проектов (ВКС, мультимедиа, телефония) в компании "Максофт" Денис Быстров. Маркетологи назвали бы эту статью "кейсами", а мы называем "сначала не поняли, а потом как поняли". Четыре истории про телефонию, посмотрите, вдруг у вас тоже так бывало?
Всем привет!
В рамках программы Google Summer of Code 2023 мы с моим студентом разработали плагин для Intellij IDEA, который является аналогом Parallel Stacks из Visual Studio, CLion и Rider для Kotlin coroutines. Плагин анализирует стек трейсы каждой корутины в приложении и строит граф, объединяя общие наборы стек фреймов в вершины. Таким образом, во время отладки вашего приложения вы можете проанализировать
потоки выполнения всех корутин в вашей программе.
Вроде бы отладка это очевидное свойство тестирования, но мне часто встречались ситуации когда разработчик видел в написании тестов только необходимость самого тестирования. Unit-тесты позволяют также упростить процесс отладки ситуаций, для которых необходимо выполнять много предварительных действий, чтобы дойти до отлаживаемого места в коде. По опыту это особенно актуально для embedded проектов, где тратиться куча времени на то, чтобы воспроизвести один единственный кейс.
В программировании микроконтроллеров регулярно приходится занимаются починкой bug(ов).
При этом все bug(и) уникальные. Поиск причины каждой конкретной осечки это скорее искусство. Починка программ сродни работы детектива.
Есть ли универсальные приемы того как искать причину программных ошибок?
Считаю, что да. Подробности в тексте...
Бывает ситуация, когда вот стоит нормальный, не ветхий дом с жильцами, с работающими коммуникациями. И простоял бы он так еще много лет. Но принято решение проложить новую магистраль и дом ей мешает. Можно снести дом, недалеко построить новый и жильцов туда переселить. А можно переместить в нужное место сам этот дом прямо вместе с жильцами и тараканами.
Такая аналогия приходит на ум после принятия решения о переходе с платформы Windows на пока единственную сертифицированную альтернативу – ОС Астра Линукс. Как жильцы гипотетического дома не могли отменить решение о магистрали, так и мы не можем отменить это решение. Придется переходить. Однако легко сказать «перейти». Когда я познакомился с IBM-PC/XT, какой-нибудь Торвальдс еще школу не кончил. За эти годы (чего уж там годы - десятилетия) появилось много привычек, приемов, навыков. Жалко все это оставлять ради принудительного перехода в другую среду. И приходит мысль – попытаться переехать, так сказать, всем домом, а не строить новый.
Я программист, а то что я еще и реверсер - ну... так совпало. И как любому из людей занимающимся реверсом мне всегда не хватает функционала отладчика. Постоянно приходится допиливать под конкретную задачу какие-то утилитарные вещи и однажды...
Однажды я решил - хватит, каждый раз пилить новое достаточно утомительно, а что если взять и объединить все наработки в один инструмент и пользоваться именно им!
Это будет скорее рекламный пост - но не спешите минусовать, возможности утилиты, о которой пойдет речь, а называется она Process Memory Map, весьма обширны, и возможно вам понравится :)
Итак - что это такое? Она похожа на всем известный инструмент от Марка Руссиновича VMMap (которая кстати частично основана на коде Джефри Рихтера), её задача проанализировать сторонний процесс и вытащить из него максимум данных, о которых она знает.
Когда на нашей рабочей системе происходит какая-либо ошибка, нам хочется, чтобы логи содержали всю необходимую информацию о том, из-за чего она произошла. На достаточно сложных системах это приводит к сбору большого количества данных: какие этапы обработки были выполнены, с какими аргументами вызывались те или иные методы, что вернули запросы к внешним системам и т. д. Проблема заключается в том, что эту информацию нам приходится собирать даже в случае, если никакой ошибки не произошло. А это приводит к росту объёма наших логов, за который нам приходится платить деньги.
Уровни логирования (error, warning, information, ...) здесь помогают мало. Обычно для приложения выставляется некий целевой уровень (например, information). Это означает, что все записи с уровнем выше или равным данному попадают в логи, а менее значимые выбрасываются. Но в тот момент, когда происходит ошибка, для нас наибольший интерес представляют именно записи debug-уровня, которые обычно и выбрасываются. Хорошо, если ошибка встречается довольно часто. В это случае можно временно опустить целевой уровень логирования системы, собрать информацию об ошибке, а потом вернуть уровень назад. Таким образом объём собираемых логов возрастёт только временно. Если же ошибка встречается достаточно редко, такой подход хоть и возможен, но не очень удобен, поскольку приводит к значительному росту объёма логов.
Можно ли как-то улучшить сложившуюся ситуацию? Я думаю, что можно. Сразу оговорюсь, что в этой статье я предлагаю не готовое решение, а скорее пожелание к существующим системам логирования, поскольку реализация этого подхода по-видимому потребует внесения изменений в их исходный код.
Всем привет! Сегодня я хочу рассказать о Mock Service Worker — технологии, которая позволяет эмулировать поведение бэкенда в ситуациях, когда по каким-то причинам невозможно использовать реальный бэкенд для полноценной разработки фронтенда, а также когда необходимо изолированно протестировать различные пользовательские сценарии. Тем более, что совсем недавно вышла новая мажорная версия библиотеки msw, и в ней достаточно много важных обновлений.
