Отладка *

От переводчика: сегодня публикуем для вас статью опытного геймдев-тестировщика Ричарда Тейлора. Статья будет полезна как начинающим, так и опытным разработчикам, — обсудить тут точно есть что.

Я создал множество игр. Обычно завершающий этап разработки весьма болезненный. Ведь именно в конце мы сталкиваемся с багами, и лишь после этого можно уже окончательно наводить лоск на продукт. Ситуация ухудшается, когда у разработчика есть минимум времени на завершение проекта. Работать приходится быстро, и баги в этом случае — частые гости. Как можно справиться с ними? Очень просто: допускать меньше ошибок, только и всего (это ирония автора — примечание переводчика).

Добрый день, сегодня предлагаю вам ознакомиться с переводом статьи об отладке iOS приложений при помощи LLDB.

Одна из самых интригующих частей презентации WWDC 2018, Xcode и продвинутая отладка в LLDB была представлена инженерами Apple. Они дали несколько полезных советов о том, как использовать точки остановки (breakpoints) в Xcode и низкоуровневый дебаггер (LLDB) для оптимизации процесса отладки багов, где бы разработчик их не поймал.

Статья состоит из трех частей, мы пройдемся по основным тезисам, что были сказаны на WWDC. Я создал демо проект специально для того, чтобы тщательнее разобраться как использовать различные типы точек остановки (breakpoints) совместно с LLDB для поимки и отладки багов в вашем приложении.

Ошибки — это хорошо. Автор материала, перевод которого мы сегодня публикуем, говорит, что уверен в том, что эта идея известна всем. На первый взгляд ошибки кажутся чем-то страшным. Им могут сопутствовать какие-то потери. Ошибка, сделанная на публике, вредит авторитету того, кто её совершил. Но, совершая ошибки, мы на них учимся, а значит, попадая в следующий раз в ситуацию, в которой раньше вели себя неправильно, делаем всё как нужно.



Выше мы говорили об ошибках, которые люди совершают в обычной жизни. Ошибки в программировании — это нечто иное. Сообщения об ошибках помогают нам улучшать код, они позволяют сообщать пользователям наших проектов о том, что что-то пошло не так, и, возможно, рассказывают пользователям о том, как нужно вести себя для того, чтобы ошибок больше не возникало.

Я несколько раз упоминал на Хабре программу «Check Point Security Academy»: суть её в том, что фирма Check Point летом объявила конкурс в формате «Capture the Flag», где не важен прошлый опыт участника, а важны только его способности к распутыванию кибер-головоломок. По результатам этого конкурса фирма набрала двадцать участников на трёхмесячный профессиональный курс по кибер-безопасности, и все участники с самого начала курса получают полную зарплату специалиста по КБ, под обязательство отработать в фирме два года после окончания курса.


В соревновании CTF флаг может быть даже картинкой, например такой.

Отбор участников завершился в августе, но сайт конкурса продолжит действовать до следующего лета, и я приглашаю желающих зарегистрироваться и попробовать свои силы ради спортивного интереса. Конкурс состоит из 12 головоломок различной сложности, оцененных от 10 до 150 очков.
Здесь я хочу разобрать головоломку «Test My Patience» из категории «Surprise». Она средней сложности (50 очков), и вот её полный текст:

Hi there,
We found This executable on the local watchmaker's computer.
It is rumored that somehow the watchmaker was the only person who succeeded to crack it.
Think you're as good as the watchmaker?
Note: This file is not malicious in any way

По ссылке — 32-битный бинарник для Windows, на который ругаются некоторые антивирусы, но если его всё же запустить, то выглядит он так:



Внутри бинарник зашифрован; запускаться под отладчиком он отказывается; если к нему к запущенному попытаться подключить отладчик — он моментально завершается. Вероятно, специалисты из Check Point обернули свою головоломку в крипто-пакер, позаимствованный у какой-то малвари.

Как же будем угадывать число, загаданное часовщиком?

От переводчика: Джордж Алан Хеймел в своей статье делится собственным опытом и говорит о том, чем должен руководствоваться разработчик в процессе отладки.

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

От переводчика. Отладка ПО для многих кодеров — скучное и рутинное занятие. Но все же обойтись без дебагинга просто невозможно. Этот пост — перевод оригинальной статьи Ника Карника, в которой он делится собственными наблюдениями об ошибках и недочетах в отладке, которые встречаются не только у начинающих программистов, но и у профи.

Все мы пишем код, который иногда, к сожалению, отказывается работать. Это нормально, просто часть процесса разработки. Если программа выдает ошибку, иногда вы просто не знаете, что делать дальше и как ее исправить. Не переживайте — все проблемы решаются, а ошибки бывают даже у самых опытных кодеров.

Существует мнение, что разработка занимает около 10% времени, а отладка — 90%. Возможно, это утверждение утрировано, но любой разработчик согласится с тем, что отладка — крайне затратный по ресурсам процесс, особенно в больших многопоточных системах.

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



Сергей Щегрикович (dotmailer) на конференции DotNext 2018 Piter предложил взглянуть на отладку как на процесс, который может быть описан и оптимизирован. Если вы до сих пор не имеете четкого плана поиска багов — под катом видео и текстовая расшифровка доклада Сергея.

(А еще в конце поста мы добавили обращение Джона Скита ко всем дотнетчикам, обязательно посмотрите)

Доброго времени суток, Хабр!

Еще год назад мой процесс отладки кода в PHP заключался в двух строчках:

var_dump($variable);
die();

Периодически, конечно, приходилось использовать более «сложные» конструкции:

console.log(data);

echo json_encode($variable, JSON_UNESCAPED_UNICODE);
exit();

Нет, что вы! Я знал — в наше время не подобает культурному программисту заниматься этим


Но, честно говоря, я всегда боялся того, что не понимаю. В том числе и принтеров xDebug, в особенности, как все это дело настроить. В один прекрасный день у меня получилось это сделать на своей машине и в локальном проекте — радости не было предела. Спустя много месяцев я столкнулся с новой проблемой, как заниматься отладкой в PHPstorm через xDebug, если проект собирается удаленно докером через CI.

Если Вы так же, как и я, испытываете трудности с настройкой разных штук, добро пожаловать под кат, я расскажу о своем опыте настройки окружения отладки с такими страшными словами, как Docker, xDebug, CI.

UFW (Uncomplicated Firewall) – это интерфейс iptables, предназначенный для упрощения процесса настройки брандмауэра. Инструмент iptables надёжный и гибкий, но новичку будет непросто настроить его самостоятельно. Я как раз новичок в этом деле.

По умолчанию в iptables включена политика ACCEPT и выглядет это так:

Вам больше не нужно ставить Log.d() в каждой строке кода!

Функциональные тесты — вещь полезная. Поначалу много времени они не занимают, но проект растёт, и тестов нужно всё больше и больше. Терпеть замедление скорости доставки мы не были намерены и, собравшись с силами, ускорили функциональные тесты в три раза. В статье вы найдёте универсальные советы, однако, особый эффект вы заметите именно на больших проектах.

Это хитрость, о которой я узнал совсем недавно у Senior Android разработчика в моей компании, и теперь я чувствую себя несчастным, сожалея о времени, которое я провел в ожидании сборки Gradle, чтобы проверить свои изменения при написании Android приложений.

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

Aliens: Colonial Marines была проблемной по многим причинам, но быстро стала всеобщим посмешищем, когда появились подобные виральные клипы, в которых ксеноморфы бессмысленно бродят по уровням. В этом месяце разработчик модов обнаружил, что причиной глупейшего поведения ИИ «чужих» стала одна ошибка в коде игры. (Об этом была статья на Хабре.) Упс. Но это не единственный случай за этот год, когда игра оказывалась унижена из-за упущенной клавиатурной опечатки. В начале 2018 года фанаты обнаружили, что ИИ Civilization VI подозрительно ударяется в религию: дело оказалось в том, что слово «yield» в коде было написано как «yeild».

Поэтому неудивительно узнать, что в разработке игр полно таких моментов.

Леа Миллер несколько лет работала дизайнером в бывшем разработчике MMO-игр Mythic Entertainment. Она занималась сценариями, дизайном контента и систем для Dark Age of Camelot и Warhammer Online: Age of Reckoning. В момент выпуска студия стала получать от фанатов жалобы: игра казалась медленной и малоотзывчивой. Игроки не могли определить, в чём конкретно была причина.

В Voximplant мы используем WebRTC с момента ее появления: сначала как альтернативу Flash для голосовых и видеозвонков, а затем как полную замену. Технология прошла долгий и болезненный путь развития, только недавно ее стали поддерживать все основные браузеры, есть сложности с передачей экрана, нескольких видеопотоков, а иногда браузер падает просто если выключить и включить видеопоток. Накопленный опыт позволяет переводить для Хабра интересные статьи, и сегодня мы передаем слово Ли Сильвестру из Xirsys, который расскажет про отладку (видео)звонков в Chrome, Firefox, Safari и Edge. Отлаживать WebRTC непросто, у нас даже есть специальные инструкции по снятию логов в популярных браузерах. А что есть у Ли – вы узнаете под катом (спойлер: много всего, включая WireShark).

Мне сообщили, что на новых компьютерах некоторые регрессиионные тесты стали медленнее. Обычное дело, такое бывает. Неправильная конфигурация где-то в Windows или не самые оптимальные значения в BIOS. Но в этот раз нам никак не удавалось найти ту самую «сбитую» настройку. Поскольку изменение значительное: 9 против 19 секунд (на графике синий — это старое железо, а оранжевый — новое), то пришлось копать глубже.

Это не руководство, какие символы нужно ввести в редакторе кода, чтобы получились модульные тесты. Это — пища для ума, которую необходимо употребить до того, как предпринимать упомянутые действия.

Тема модульного тестирования не так проста, как может показаться. Многие из нас, разработчиков, приходят в модульное тестирование под давлением клиентов, сотрудников, коллег, своих кумиров и так далее. Мы быстро понимаем его ценность, и, закончив технические приготовления, забываем об общей картине, если вообще когда-либо её понимали. В этой статье я вкратце расскажу о том, чем является и чем не является модульное тестирование как в целом, так и в PHP, а заодно опишу, какое место занимает модульное тестирование в сфере QA.

Материал, перевод которого мы сегодня публикуем, посвящён обработке JS-ошибок с помощью window.onerror. Это — особое событие браузера, которое вызывается при появлении неперехваченных ошибок. Здесь мы поговорим о том, как перехватывать ошибки с помощью обработчика события onerror, и о том, как отправлять сведения о них на сервер разработчика веб-сайта. Этот обработчик можно использовать в качестве основы собственной системы сбора и анализа информации об ошибках. Кроме того, он является одним из важнейших механизмов, применяемых в библиотеках, ориентированных на работу с ошибками, таких, как raven-js.

Простой в отладке код — это код, который не дурачит вас. Труднее отлаживать код со скрытым поведением, с плохой обработкой ошибок, с неопределённостями, недостаточно или избыточно структурированный, или находящийся в процессе изменения. В достаточно больших проектах вы в конце концов сталкиваетесь с кодом, который не можете понять.

Если проект относительно старый, то вы можете встретить код, про который вообще забыли, и если бы не журнал коммитов, то поклялись бы, что эти строки писали не вы. По мере разрастания проекта становится всё труднее запоминать, что делают разные куски кода. И ситуация усугубляется, если код делает не то, что, вроде бы, должен делать. И когда нужно изменить код, который вы не понимаете, приходится разбираться жёстко: отлаживать.

Умение писать код, который легко отлаживать, начинается с понимания, что вы ничего не помните о ранее написанном.

Как известно, совместимость с инструментарием GNU и поддержка GDB делают практически любую популярную среду разработки пригодной для отладки широкого спектра встраиваемых платформ, чаще всего бесплатно и легально. В теории.

Что получается на практике при попытке подружить STM32 и NetBeans, и возможно ли в принципе получить работоспособную систему с поддержкой новейших камней — под катом.