Любые программные системы включают в себя нужные и не очень нужные пакеты. Получается огромный объём кода (для одного несложного сайта npm list -a выдаёт список из 4256 зависимостей). А так как «весь код — это ваш код», то такие зависимости надо тестировать. И регулятор требует, да и просто собственные продукты хочется защитить от вторжений, утечек и других неприятностей.
Critique и Gerrit
У Google есть два собственных инструмента для ревью кода: Critique, используемый большинством инженеров, и Gerrit, — опенсорсный, который продолжают применять в публичных проектах.
(Вы можете сами поэкспериментировать с Gerrit в опенсорсных репозиториях Chromium и Android.)
Дэшборды
Когда инженеры логинятся с утра или когда устраивают перерыв для ревью пул-реквестов, внутри Google называемых change list, или CL, и в Critique, и в Gerrit они работают с дэшбордами, в которых можно легко вкратце просмотреть все актуальные изменения (это похоже на окно пул-реквестов репозитория GitHub, только более сложное и информационно насыщенное).
В дэшборде Gerrit есть единичный поиск, извлекающий такую информацию, как размер изменения и более подробные сведения о статусе CL (три столбца справа).
Материал подготовлен на основе выступления с CppCon 2015 "Greg Law: Give me 15 minutes & I'll change your view of GDB" (доступно по ссылке ). Многие моменты я изменял и корректировал, поэтому учтите, что перевод достаточно вольный.
И да, вынесем за скобки вопрос о том, насколько GDB в целом удобная или неудобная программа, и что в принципе лучше использовать для дебаггинга: в данной статье будет рассматриваться именно работа с GDB.
В статье будет рассматриваться отладка кода на C в ОС Linux.
Колесо крутится, но хомячок подписки помер. Оно просто крутится.
В начале я хотел бы сказать, что описанные в статье практики очень плохи и неправильны (с тех пор мы добавили надёжные юнит-тесты и интеграционные тесты, а также систему алертов/логирования), что их следует избегать и в первую очередь это человеческие ошибки, которые задним умом кажутся очевидными.
Описанные в статье события произошли в условиях сильного дефицита времени на очень ранних этапах работы компании (первые несколько недель). По большей мере я публикую это как забавную историю с уникальными условиями, связанными с воспроизводимостью бага в продакшене (тоже из-за нашей собственной глупости). Пожалуйста, помните об этом, читая текст.
Впервые мы включили монетизацию нашего стартапа в мае прошлого года. Мы не ожидали многого, но были приятно удивлены тем, что меньше чем за час после запуска у нас появился первый клиент. Это был волшебный момент. Мы отправили ему благодарность, произнесли всей командой тост и пошли спать, ведь на подготовку мы потратили две ночи.
Проснувшись утром, мы увидели больше сорока уведомлений Gmail с жалобами пользователей. Похоже было, что за ночь поломалось всё. Никто из пользователей не мог подписаться. И мы понятия не имели, почему.
Все мы сталкиваемся с багами, фиксим их, и по новой тестируем наш код.
Давайте попробуем сделать работу с багами чуть проще и прозрачнее. Разберем как можно их находить и с ними справляться. Разберем: IDE, изоляции, консоль браузера, console.log(), Try-Catch и т.д.
Вообще наша компания занимается разработкой смартфонов и софта к ним для слепых и слабовидящих. Но порой возникают ситуации, когда приходится отлаживать не только свои приложения, но и разбираться с чужими. Обычно это происходит в случае, когда приложение глючит или не работает вовсе именно на наших телефонах. Поскольку наша аппаратная платформа не похожа на традиционные Android-смартфоны да и сам код фреймворка доработан рашпилем, мы готовы к подобным сюрпризам. Так случилось и в этот раз. Клиент жаловался, что у него есть проблемы с login-ом в одну из online-библиотек с аудио-книгами через Android-приложение. Поддержка попросила меня разобраться, есть ли в этом наша вина, или же нет.
О процессе отладки я буду рассказывать в хронологической последовательности, как она происходила в жизни, а не с "точки зрения вечности". Надеюсь, это поможет читателю лучше понять историю моих озарений и провалов. Заранее предупрежу, что я пытался двигаться к цели не углубляясь в причины неудачи тех или иных шагов. Если подход "в лоб" в каком либо варианте не срабатывал, я откладывал этот вариант, и переходил к другому. Название каждого раздела соответствует трудности, с которой я столкнулся. Итак, начнем.
Привет, Хабр.
Скорее всего то, о чем я сейчас расскажу, уже было реализовано и не единожды.
Но пусть это все равно лежит здесь, возможно эта статья будет кому-то полезна в качестве методического материала или HOWTO. Все, сказанное ниже является продуктом моего текущего опыта разработки и не претендует на идеальное решение.
Наш браузер Ladybird неплохо справляется с качественно отформатированным веб-контентом, но я решил, что будет полезно проверить его инструментами для исследования безопасности. Поэтому сегодня мы воспользуемся Domato 🍅 — DOM-фаззером из Google Project Zero, чтобы провести стресс-тест Ladybird и устранить найденные в процессе ошибки.
Работает это следующим образом: Domato генерирует рандомизированные веб-страницы со множеством по большей части валидного, но странного HTML, CSS и JavaScript. Я загружу эти страницы в отладочную сборку Ladybird и посмотрю, что получится.
Wch-link является программатором для ARM, RISC-V микроконтроллеров. По возможностям это аналог St-link, JLink и прочих. По сравнению с st-link он поддерживает контроллеры не только фирмы STM. А по сравнению с JLink стоит намного дешевле и не имеет проблем с лицензиями, которые могут встречаться у дешевых клонов JLink. Также плюсом идет поддержка набирающих популярность контроллеров от китайской компании WCH.
Есть несколько вариантов этого отладчика, я буду говорить о версии Wch-linkE rev 1.3.
При запуске новых плат и устройств с PCIe-соединениями недостаточно просто вставить карту в слот. Нужно так настроить эквалайзеры, редрайверы, пресеты и ретаймеры, чтобы на каждой полосе «поднялся линк», то есть установилось соединение. Это значит, что приемопередатчики на обоих концах распознали друг друга, договорились о кодировке и скорости передачи.
Долгое время без специального дорогостоящего инструмента нельзя было убедиться в устойчивости линка: что он не пропадает при малейших воздействиях температуры, влажности или любопытных лапок. То есть нелегко было узнать количественный запас по уровню сигнала, насколько он близок к границе потери различимости физических уровней — а значит, и разрыва соединения. Эта безнадежная ситуация изменилась с появлением четвертого поколения стандарта PCIe.
Я достаточно давно решил ознакомится с ассемблером архитектуры 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: Данная заметка написана в ознакомительных целях и не является руководством к действиям. Хотя, понимая всю безвыходность данной ситуации, как временное решение имеет право на жизнь, но решать только вам. Статья написана как туториал, поэтому постараюсь детально описать все шаги поиска нужных мест в программе.
