Разбираемся с «чёрными ящиками» и c тем, какими они бывают сегодня

• Вы работаете со сторонним ПО, разработчики которого просто не раскрывают код.
• Вы взаимодействуете с API, внутренняя логика которого абстрагирована.
• У вас нет необходимых полномочий для доступа к Git-репозиторию.
• Даже система с полным доступом может де-факто стать «чёрным ящиком» из-за своей сложности.
• Сотрудник, обладавший всеми ключами и знаниями, внезапно уволился/пропал/умер.
• Легаси-система состоит из .dll, которая «всегда работала» на сервере, и не была подключена к системе контроля версий. Чтобы просто посмотреть на код, её нужно декомпилировать, если это возможно, конечно.

Идеальный способ отлаживать и отслеживать приложения — хорошо определённые, информативные и удобно структурированные логи. Они являются необходимым компонентом любого — малого, среднего или крупного — проекта на любом языке программирования, не только на Python. Не используйте print() или корневой логгер по умолчанию, вместо этого настройте логирование на уровне проекта. К старту нового потока курса по Data Science, мы перевели статью, автор которой решил поделиться своим шаблоном для логирования. Не лишним будет сказать, что этот шаблон пришёлся по душе многим специалистам — от дата-сайентистов профессионалов и до разработчиков ПО разного уровня.

Как ни странно, мало кто знает о том, что у Huawei есть ферма устройств в облаке, которую можно использовать для отладки и тестирования. И речь идет не об отладке через веб-интерфейс, что является более-менее известной фичёй консоли разработчика Huawei и нередко используется разработчиками. Мы же поговорим об отладке непосредственно из студии, с возможностью пользоваться ADB.

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

Следующим шагом открываем студию и устанавливаем плагин HMS Toolkit из магазин плагинов в самой студии (File -> Settings -> Plugins).

Недавно я создала небольшой инструмент под названием dnspeep, который позволяет понять, какие DNS-запросы отправляет ваш компьютер и какие ответы он получает. Всего мой код занял 250 строк на Rust. В этой статье я расскажу о коде, объясню, для чего он нужен, почему в нём возникла необходимость, а также расскажу о некоторых проблемах, с которыми я столкнулась при его написании. И, конечно, вы сами сможете попробовать код в действии.

Вместе с моим коллегой Евгением мы потратили много времени. Приложение обрабатывает тысячи запросов в асинхронном конвейере, полном async/await. Во время нашего исследования мы получили странные вызовы, они выглядели как бы “перевернутыми”. Специально к старту нового потока курса по разработке на C#, рассказываем, почему вызовы могут оказаться перевёрнутыми даже в Visual Studio.

Мировоззрение

• Нет сложных проблем. Просто отсутствует информация о том, как работает система
• Помните, что ошибка возникает по логической причине
• Будьте необоснованно уверены в своей способности исправить ошибку
• Чем сложнее будет баг, который вы исправите, тем лучше вы будете
• Каждая ошибка — это возможность узнать что-то новое

Поиск первопричины

• Постарайтесь воспроизвести проблему
  
  • Можете ли вы воспроизвести это из командной строки?
    
    • Другим людям легче воспроизвести проблему
    • Легче проверить исправление
• Есть ли логи? Что за сообщение об ошибке?
  
  • Прочтите описание ошибки. Каждое его слово. Дважды.
  • Есть ли где-нибудь опечатка (командная строка / конфигурация / код)?
• Изолируйте проблему
  
  • Удалите некоторые части системы и попробуйте воспроизвести ошибку
  • Меняйте одно за раз, сохраняя все остальное постоянным

В течение последних 20 лет сотрудники Post Office (почтовая компания из Великобритании) разбирались с программой Horizon, в которой имелась фатальная ошибка: из-за неисправности казалось, что сотрудники воровали десятки тысяч фунтов. Некоторые местные почтмейстеры были осуждены и посажены в тюрьму из-за того, что Post Office упорно настаивал на том, что программному обеспечению можно доверять. После десятилетий баталий приговоры 39 человек, наконец, отменили. Случай стал крупнейшей судебной ошибкой, которую когда-либо видела Великобритания.

Использование console.log() для отладки JavaScript - самая распространенная практика среди разработчиков. Но есть еще кое-что ...

Объект console обеспечивает доступ к отладочной консоли браузера. Особенности того, как она работает, варьируются от браузера к браузеру, но де-факто существует набор функций, которые обычно предоставляются.

Короткий обзор очередных обновлений смотрелки логов chipmunk. Много исправлений, много корректировок и немного фишек, в том числе запрашиваемых сообществом.

Это отладочное приключение Брюса Доусона, разработчика Chrome и блогера, позволило снизить загрузку процессора при работе с веб-камерой примерно на 3%  - настоящая помощь для тех, кто полагается на видеозвонки.

Здравствуйте, меня зовут Дмитрий Карловский и я… не прощаю ошибок. Как только вижу оную — тут же бросаю что-нибудь исключительно тяжёлое. И как же тяжела работа программиста на JS...

class Foo extends Object {
    get name(){ return 'Jin' }
}
const foo = new Foo

`Здравствуйте, ${ foo }!`
// "Здравствуйте [object Object]!"

`В этом месяце вы заработали ${ foo / 1000 } тысяч рублей.`
// "В этом месяце вы заработали NaN тысяч рублей."

`Ваша цель "${ 'foo'[4] }" наконец-то достигнута.`
// "Ваша цель "undefined" наконец-то достигнута."

`Осталось ещё ${ foo.length - 1 } целей и вы достигнете успеха.`
// "Осталось ещё NaN целей и вы достигнете успеха."

foo.__proto__= { name: 'придурок' };
`До скорых встреч, ${ foo.name }.`
// "До скорых встреч, придурок."

Облегчить его страдания можно разными путями..

1. Прикрыться тайпскриптом. Но в рантайме ноги всё равно остаются босыми, и на них кто-нибудь вечно наступает.
2. Обложиться проверками. Но чуть замешкаешься и рантайм грабли тут же бьют по голове.
3. Исправить JS. Даже не надейтесь.
4. Исправить JS рантайм. Ну, давайте подумаем..

Неверный способ

Преждевременная оптимизация — корень всех зол.

Мы создаем программы сначала правильными, а потом — производительными. Мы оптимизируем их после того, как они будут реализованы.

Итак, для начала хочется отметить, что хотя я и пишу в песочницу, это уже не первый мой текст на Хабре. Когда-то я писал how to для блога зарубежных ретроигроделов, а поскольку они зарубежные, статьи приходилось переводить на английский. И я был немного удивлен, обнаружив здесь переведённую обратно на русский язык статью об отладке игр для NES.

Вообще меня очень увлекает история аркадных автоматов, консолей, игр, и немножко программирование. О том, как программируют для NES в наши дни, я писал в другой «making of» статье, которую также публиковали на Хабре.

Сегодня я хотел бы попробовать запостить материал самостоятельно, и речь пойдет обо всём перечисленном сразу, и об аркадных автоматах, и о NES и о ретроиграх и об их отладке.

Некоторое время назад мы опубликовали в OpenSource небольшую библиотечку скриптов для популярного отладчика Windbg. Они предназначены для автоматизации ряда рутинных задач, возникающих при анализе причин падения программ как при отладке вживую, так и при работе с дампами памяти. Мы запланировали несколько постов, объясняющих, как эти скрипты использовать. Вот первый пост из данного цикла. Он демонстрирует использование команды !exccandidates на синтетическом примере.

Как мы столкнулись с неожиданным багом в .NET 5, расследовали возникшую проблему, и что же из этого вышло.

Однажды увидев на али оксиметр, стало интересно как же он устроен, а разобравшись, удивился его простоте и решил его повторить.

Данная статья описывает небольшой пример того, как использование языка моделирования Alloy может помочь при разработке программного обеспечения.

О качестве программного обеспечения и инструментарии

В Typeable мы придаем огромное значение качеству программного обеспечения и прикладываем все усилия, чтобы обеспечить это качество. В настоящее время мы искореняем ошибки следующими способами:

1. Анализ и создание спецификаций
2. Устранение простых ошибок с использованием системы типов Haskell
3. Стандартные юнит-тесты и интеграционные тесты
4. Непрерывная интеграция
5. Обязательные ревью кода
6. Тестирование на стендах, проводимое QA инженерами
   (мы используем Octopod для оптимизации процесса разработки и QA)
7. Тестирование в pre-production среде
8. Ведение логов и контроль ошибок на этапе эксплуатации

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