Ошибки на веб страницах и как их искать и исправлять. Управление несколькими точками останова с помощью вкладки "Точки останова". Неправильная обработка кода HTML-страницы

Много существует статей на Хабре, описывающих интересные и сложные аспекты веб-разработки, но много существует читателей, которые, находясь в начале своей карьеры веб-разработчика, хотели бы видеть материал, который позволил бы сделать первый шаг от «PHP за 24 часа» до разработки на серьезном уровне, и я хотел бы поделиться своим опытом в этом деле.

Особенности веб-приложения делают его разделенным на две части: клиентскую и серверную. На стороне клиента работает код на JavaScript (может быть, где-то можно найти и VBScript, но мы, пожалуй, не будем рассматривать этот случай), на серверной же - много что, в принципе, но мы рассмотрим PHP, наиболее популярный язык для серверной части веб-приложений. Так же интересно было бы поговорить об отладке и профилировании Flash-приложений на клиентской стороне, но затронутая тема и так обширна, так что пока оставим это.

Так же можно отнести к задачам отладки клиентского кода анализ и валидацию HTML кода. Это, вроде бы, задача не совсем из области программирования, но также немаловажная.

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

Отладка и профилирование клиентского кода «Классическим» способом отладки кода на JavaScript является использование функции alert и ее производные. Помнится, в начале своей карьеры лично я написал функцию print_r для JavaScript, так как не видел возможности для вывода отладочной информации по массивам и объектам. Выглядело это примерно так:
function print_r(variable) { if (variable instanceof Array || variable instanceof Object) { var key; for (key in variable) alert(key + " => " + variable); } else { alert(variable); } }

О каком-либо профилировании речи, конечно, не велось совсем.

При таком подходе даже информация об объекте console производит революцию.

Специфика клиентской стороны веб-приложения требует отладки кода во всех популярных браузерах. Конечно, чаще всего хватает и отладки в Internet Explorer"е и любом нормальном другом браузере, но мы рассмотрим все варианты.

Mozilla Firefox Наверно, именно Firefox можно назвать пионером отладки клиентского кода. Долгое время его указывали как браузер, наиболее подходящий для разработки, а все благодаря расширению Firebug , которое содержит, наверно, все нужные возможности, кроме валидации HTML кода.

Так же, начиная с версии 4, появилась встроенная Веб-консоль, которая реализует часть функций вкладки «Консоль» и «Сеть» Firebug"а, а так же некоторые возможности по отладке CSS.

Начиная с версии 6, появился Простой редактор JavaScript, который так же реализует одну из функций Firebug"а, и позволяет писать и выполнять код прямо в браузере.

Начиная с версии 10 появился Инспектор страниц, который позволяет изучать HTML код и CSS свойства, то есть, реализует функции вкладки «HTML».

За валидацию HTML кода как правило отвечает расширение Html Validator . Как раз его иконку, указывающую на количество ошибок на главной странице сайта habrahabr.ru, можно видеть в правом нижнем углу браузера на картинке с Инспектором страниц.

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

Google Chrome и Safari Эти браузеры, основанные на WebKit, обладают встроенным инструментом разработки Web Inspector, который очень хорошо развит и реализует практически те же функции, что и Firebug. При этом, надо отдать ему должное, он не замедляет работы браузера, что водится за «старшим братом».

В Chrome он может быть вызван по нажатию клавиш Ctrl+Shift+I или просто по F12 . В Safari он хорошо спрятан, и для его использования нужно включить возможности разработки в настройках браузера. Позже инструменты разработчика станут доступными из пункта «Разработка» главного меню или по сочетанию клавиш Ctrl+Alt+I .

Для валидации HTML кода так же нужно устанавливать сторонние расширения. К примеру, для Chrome, это может быть Validity . Для Safari пока не удалось подобрать ничего подходящего.

Opera Opera так же имеет встроенный инструмент для разработчиков, который называется «Opera Dragonfly», и может быть вызван в любой момент по сочетанию клавиш Ctrl+Shift+I . Он похож на то, что нам представляет WebKit, и имеет подобные возможности и плюсы, хотя, на мой лично взгляд, менее удобен.

Отладка и профилирование серверного кодаXdebug Как мы договорились в начале, мы рассматриваем случай, когда на сервере используется PHP. Тут «классическим» методом отладки являются echo , print_r и var_dump , но есть так же и средство для отладки, как в лучших домах - Xdebug . Лично для меня, в связи со спецификой обучения в институте, это выглядело «прямо как в Delphi».

Расширение xdebug позволяет как минимум прогонять код по шагам и просматривать значения переменных, что поднимает программирование на PHP на новый уровень. О тонкостях работы с xdebug была соответствующая . XDebug обычно доступен в репозиториях GNU/Linux, в Windows его так же не слишком сложно установить, скопировав dll файл.

При использовании этого расширения, с сервера на компьютер разработчика поступает входящее соединение (по умолчанию на порт 9000), которое он должен обработать. Для этого необходимо соответствующим образом настроить свою IDE.

Кстати говоря, использование IDE так же является непременным условием движения вперед. Некоторые программисты считают, что разницу между программированием в блокноте с подсветкой кода и в IDE можно увидеть только на крупных проектах, но лично я придерживаюсь мнения, что разница видна даже на программе «Hello world!» - одна автоподстановка имен и аргументов стандартных функций чего стоит.

XHProfО расширении Да, xdebug предоставляет возможности по профилированию, но разработка Facebook"а для этих целей, XHProf , лично мне больше нравится. Я, сказать честно, не проводил никаких тестов, но считается, что данное расширение гораздо лучше подходит для production-серверов и для профилирования при реальных нагрузках.Установка К сожалению, это расширение не входит ни в какие репозитории. Оно входит в PECL, но по какой-то причине его установка штатным путем часто вызывает проблемы. По этой причине приходится проводить установку из исходников.

# Получаем исходники wget http://pecl.php.net/get/xhprof-0.9.2.tgz # Распаковываем исходники tar -xvf xhprof-0.9.2.tgz # Переходим в каталог, где содержится код расширения cd xhprof-0.9.2/extension/ # Проводим компиляцию и тест phpize ./configure make make test # Проводим установку цивилизованно checkinstall
Файл конфигурации xhprof.ini предоставляет нам примерно такие возможности:

extension=/usr/local/lib/php/extensions/no-debug-non-zts-20090626/xhprof.so
; Каталог для логов
xhprof.output_dir="/var/log/xhprof/"

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

Приведем пример профилирования. В код приложения нужно включить следующие элементы:
// Начало скрипта, включаем профилирование // как нагрузки на процессор, так и на память xhprof_enable(XHPROF_FLAGS_CPU + XHPROF_FLAGS_MEMORY); /* * Основной код приложения */ // Конец скрипта, завершаем профилирование, // записываем результат в лог $xhprofData = xhprof_disable(); include_once XHPROF_DIR."/xhprof_lib/utils/xhprof_lib.php"; include_once XHPROF_DIR."/xhprof_lib/utils/xhprof_runs.php"; $xhprofRuns = new XHProfRuns_Default(); $namespace = "some-unique-name"; $runId = $xhprofRuns->save_run($xhprofData, $namespace); echo "\n";
Здесь константа XHPROF_DIR указывает на каталог, куда мы распаковали скачанный архив.

Для анализа результатов нужен тот самый веб-интерфейс. Его можно взять в каталоге $XHPROF_DIR/xhprof_html/ - условно обозначим его так. К примеру, мы расположили его в доступном веб-серверу месте, и он доступен по адресу example.com/system/xhprof/ , тогда для анализа результата работы нам нужно обратиться к нему следующим образом:

Example.com/system/xhprof/?run=%runId%&source=%namespace%

Мы получим подобный результат:

Профилирование можно включать в код приложения на постоянной основе или, например, сделать так, чтобы оно запускалось случайно с определенной вероятностью или по наличию определенного условия. Например, так:

$needProfiler = (mt_rand(0, 100) < 10 or isset($_COOKIE["xhprof"])); if ($needProfiler) xhprof_enable(XHPROF_FLAGS_CPU + XHPROF_FLAGS_MEMORY);
В таком случае можно, имея жалобы от клиентов или подозрения, обратиться к результатам профилирования за определенный временной промежуток. С помощью параметра namespace можно определить, какая именно часть приложения (какой скрипт, контроллер, экшн) профилировались.

Профилирование SQL запросов Как правило, именно работа с базой данных является узким местом в приложении. По этой причине рекомендуется проводить профилирование запросов. К примеру, рассмотрим часть класса, являющегося оберткой вокруг функций расширения mysql. Да, я знаю, что это расширение не очень любят и желают ему смерти не меньше, чем старому-доброму IE6. Я не призываю его использовать, просто именно такой класс есть у меня под рукой.

/** * Запрос * @param string $sql Запрос * @param array $params Параметры * @param string $query Скомпилированный запрос * @return array Результат */ public function query($sql, array $params = array(), &$query = "") { $start = microtime(TRUE); // Проведение запроса, включая "защиту" параметров $stop = microtime(TRUE); $time = $stop - $start; $this->_addProfilerData($sql, $time); // Возврат результата } private function _addProfilerData($query, $time) { if (is_array(self::$profilerData)) { self::$profilerData = array("query" => $query, "time" => $time); } } public function __destruct() { if (is_array(self::$profilerData)) { $this->_writeProfilerData(); self::$profilerData = FALSE; } // Отключение от БД } private function _writeProfilerData() { $values = array(); foreach (self::$profilerData as $row) { $query = mysql_real_escape_string($row["query"], $this->con); $time = (float)$row["time"]; $hash = crc32($row["query"]); $values = "($hash, "$query", $time)"; } if ($values) { $strValues = implode(", ", $values); $sql = "INSERT DELAYED INTO `profiler_queries` (`query_hash`, `query`, `work_time`) VALUES $strValues"; @mysql_query($sql, $this->con); } }
Здесь данные профилирования запросов хранятся в таблице profiler_queries . Эта таблица может иметь тип MyISAM или Archive, так как они предоставляют возможность совершать отложенные вставки, что не создает излишней задержки ответа при профилировании. Так же для лучшего поиска запросов в таблице лучше создать столбец типа INT , куда будет писаться crc32-хеш запроса, по которому нужно создать индекс.

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

Есть, конечно, и другие - о них я обязательно упомяну.

Firebug для Firefox

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

Firebug - это дополнение для Firefox, а значит его надо скачать с сайта Firefox add-ons и установить.

Для того, чтобы вызвать файербаг, достаточно нажать F12.

Возможности этого дополнения:

• Инспектирование и редактирование динамически изменяемого HTML;
• Редактирование CSS на лету;
• Отладка JavaScript, командная строка для выполнения скриптов;
• Мониторинг сетевых запросов - можно увидеть размеры и время загрузки файлов и скриптов, заголовки запросов;
• Анализатор DOM.

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

Кроме самого firebug’a вам может пригодится полезная примочка к нему - FireCookie , c помощью которой (сюрприз:-) можно просматривать и изменять куки.

WEB Developer Toolbar для Firefox

Еще одно полезное дополнение к Огнелису. Выглядит оно так:

Разберем по пунктам.

Disable

Позволяет выключить JavaScript, запретить использование кэша, что очень полезно при разработке (позволяет быть уверенным, что страница загрузилась вместе с последними обновлениями), отменить цвета, используемые на странице и заменить их стандартными, запретить отправление в заголовке реферера (страница, с которой был переход).

Cookies

Полезная опция для работы с куками: их можно просматривать, удалять, запрещать и добавлять.

CSS

Это меню хранит самую крутую фичу Developer Toolbar’a - редактирование CSS на лету. Кроме этого есть возможность просматривать css, запрещать и так далее, и тому подобное. На мой взгляд здесь очень полезно наличие быстрых клавиш (CTRL+SHIFT+C, к примеру, позволяет сразу перейти к просмотру стилей страницы)

Forms

Все для работы с формами: показывать пароли, показывать информацию о формах, конвертировать методы форм (GET » POST и наоборот) и многое другое. Полезная функция «Populate Form Fields» для автоматического заполнения полей формы (например, при тестировании сайта, когда функция запоминания паролей в отключена. В остальном не вижу в этом пункте ничего полезного.

Images

Здесь есть полезная функция отключения изображений - чтобы посмотреть как выглядит ваш сайт без картинок. Картинки можно обвести, показать их размеры, показать alt-атрибуты.

Information

В этом меню очень много опций. Может быть полезной функция отображения атрибутов class и id на странице. Кроме этого интересен пункт «View Color Information» - чтобы быстро получить информацию о цветах, которые используются на странице. «View document size» - просмотр размера страницы. «View Response Headers» - просмотреть заголовки страницы.

Miscellaneous

Самая часто используемая функция - очистка кэша. Кроме этого здесь доступны функции «Page ruler» - линейка, «Page Magnifier» - лупа и «Line guides» - несколько линий, которые могут быть полезны чтобы подровнять шаблон.

Outline

Выделение разных элементов страницы - таблиц, заголовков, ссылок, фреймов, блоков. Resize позволяет изменять размер окна браузера под какие-либо стандартные расширения экранов. Tools здесь хранятся фичи для валидации страниц. Как локальных, так и внешних. Удобный и быстрый доступ к валидации HTML, CSS, и прочего. Для валидации HTML можно использовать клавосочетание CTRL+SHIFT+H.

View Source

Просмотр исходного кода. Возможность просмотра в внешнем приложении, просмотр сгенерированного кода.

То, что находится в правом углу мне нравится больше всего. Это быстрый валидатор HTML, CSS и индикатор ошибок JavaScript. Если проблем никаких нету - значок зеленый , а если есть проблемы - красный .

Internet Explorer Developer Toolbar

Начиная с 8.0 debug ошибок встроен уже в этот браузер. Вызывается он легко по клавише F12 . Правда он убогий как программа 90 годов.

Но есть куда круче инструмент для этого браузера, так называемый Internet Explorer Developer Toolbar скачать можно по ссылке.

С виду этот тулбар, конечно, похож на firebug, но, увы, до него еще не дорос. Хотя, с другой стороны в нем есть некоторые возможности, которых нету у файербага. Я бы назвал Internet Explorer Developer Toolbar неким гибридом Firebug’a и FireFox WEB Developer Toolbar’a.

Как и в firebug здесь есть возможность инспектировать элемент простым кликом. Но, если в мы сразу можем увидеть padding’и и margin’ы, то здесь такой возможности нету.

Кроме того Internet Explorer Developer Toolbar не обновляет дерево элементов динамически, как это делает Firebug. То есть, если мы изменим что-нибудь на странице средствами js, с помощью этого тулбара мы ничего не увидим.

Из того, чему можно порадоваться - изменением CSS на лету (легкий способ найти, что хакать:), возможности запретить CSS и изображения, возможность быстро очистить кэш и поиграть с печеньками, быстрый доступ к валидации.

Самое вкусное: здесь есть встроенный color picker, который позволяет получить любой цвет со страницы с помощью пипетки. (для ff есть отдельный плагин ColorZilla).

Debug DebugBar для Internet Explorer

DebugBar для Internet Explorer скачать можно по указанной ссылке.

По своему интересное расширение. Устанавливается как дополнительная панель к браузеру:

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

Кроме этого имеется инспектор:

Способ испектирования кликом или наведением разработчиков не устроил: они придумали штуку поинтереснее. В DebugBar’e надо перетащить прицел на нужный элемент, чтобы увидеть его в дереве. Возможности редактировать CSS нету. Зато есть валидатор и встроенная консоль js.

А если покопаться в настройках можно найти и такое:

И смешно и грустно.

Известно, что в восьмой эксплорер будет встроен Developer Toolbar. Он будет похож на тот, который описывался в третьем пункте, но надеемся, что будет лучше.

Debug DragonFly для Opera

DragonFly встроен в Оперу, начиная с версии 9.5, поэтому устанавливать не надо. Для того, чтобы активировать Драгонфлай переходим в Инструменты → Дополнительно → Средства для разработчиков. А если по английски, то Tools → Advanced → Developer Tools.

Сразу предупрежу, что DragonFly находится в стадии Alpha2, этим объясняются многие его глюки.

Возможности списком:

• DOM инспектор;
• Инспектирование кликом (опять-таки, мы не увидим отступов, как в FireFox);
• Редактирование ;
• Быстрый доступ к консоли ошибок.

DF - что-то вроде отдельной страницы во фрэйме. Если вы его открыли, оно будет открыто для всех вкладок (в отличие от firebug’a). Поэтому перед инспектированием элемента надо выбрать из списка страницу, которую мы хотим просмотреть.

К сожалению здесь, как и в Internet Explorer Dav Toolbar не отображаются динамически создаваемые элементы. И вообще, когда мы инспектируем страницу, никакой JavaScript не запускается: ссылки и кнопки не нажимаются. Будем надеяться, что когда DragonFly подойдет к релизу, мы увидим все эти возможности.

Debug WEB Inspector в Safari

Сразу скажу, что про браузер Safari информацию свистнул, поэтому за адекватность материала, как говориться, не отвечаю.

Для того, чтобы включить в меню Сафари пункт «Разработка», необходимо в настройках (закладка «Дополнительно») включить соответствующий пункт:

В меню «Разработка» нам доступны следующие функции:

Давайте рассмотрим в деталях WEB инспектор:

По умолчанию инспектор открывается в режиме просмотра HTML . Но его можно переключить в режим просмотра DOM. Для этого на верхней плашке имеется переключатель. При наведении на элемент в инспекторе, он будет подсвечен на самой странице. Увидеть отступы, изменить разметку или CSS на лету или увидеть динамические изменение в DOMe на лету, как в FireBug нельзя. Зато, согласитесь, выглядит весьма мило.

Если есть желание работать с инспектором в окне браузера, можно нажать на кнопочку в нижнем левом углу.

Еще в сафари доступна такая функция, как «Шкала времени сети», (кнопка «Network» в инспекторе):

Наглядно можно увидеть, когда и как долго грузятся файлы. Также можно просмотреть заголовки запросов, но само содержимое просмотреть, к сожалению, нельзя.

Debug для разработчиков в Google Chrome

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

• DOM Inspector;
• Отладчик javascript;
• Консоль JavaScript.

Для того, чтобы проинспектировать какой-либо элемент, на него надо нажать правой кнопкой и в контекстном меню выбрать «Просмотр кода элемента»:

Функционал тот же, что и в Сафари: элементы подствечиваются при наведении, но не доступны редактирование CSS и HTML, не отслеживаются изменения в DOM. Вот только, кнопка в левом нижнем углу, которая должна прикреплять инспектора к окну браузера не работает.

В закладке «Resources» мы можем увидеть следующее:

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

В этой статье я рассмотрел наиболее известные расширения и встроенные средства для браузеров.

Есть и другие, например:

• Internet Explorer WEB Development Helper - хороший помощник для ASP.NET разработчиков (Internet Explorer);
• WEB Developer Toolbar - тулбар для Internet Explorer и FireFox. Есть несколько полезных функций;
• WEB Accessibility Toolbar - тулбар для Internet Explorer. Ничего интересного.

Если есть дополнения, о которых я не упомянул, а стоило бы, или есть функции у упомянутых расширений, которые я упустил, пишите.

Пользуйтесь на здоровье!

Написать HTML - здорово, но как понять, где ошибка, когда что-то не работает? В этой статье описаны несколько инструментов, которые помогают искать и исправлять ошибки в HTML.

Отладка - это не страшно

Во время написания какого-нибудь кода, обычно все идет хорошо, пока не появляется тот момент, когда вы совершаете ошибку. Итак, ваш код не работает, или работает не так, как вы задумывали. Если вы попытаетесь скомпилировать неработающую программу на языке Rust , компилятор укажет на ошибку:

В данном случае, сообщение об ошибке понять относительно просто - "unterminated double quote string". Если вы внимательно посмотрите на println!(Hello, world!"); , то заметите, что здесь отсутсвует двойная кавычка. Разумеется, сообщения об ошибках могут становиться куда более сложными для понимания по мере роста вашего кода, и даже самые простые случаи могут показаться пугающими для тех, кто ничего не знает о Rust.

Но не бойтесь отладки! Чтобы комфортно писать и отлаживать любой код, нужно понимать язык и его инструменты.

HTML и отладка

HTML не так сложен к пониманию, как Rust. HTML не компилируется в какую-либо другую форму перед тем, как браузер проанализирует это и покажет результат (он является интерпретируемым, а не компилируемым). Синтаксис HTML элементов намного понятнее, чем у "настоящих языков программирования", таких как Rust, JavaScript , или Python . Способ, которым браузеры читают HTML более толерантен , чем у языков программирования, интерпретирующих свой код строже. Это одновременно и плохо, и хорошо.

Толерантный код

Так что же означает толерантный? В общих чертах, когда вы напортачили в коде, есть два типа ошибок, с которыми вы столкнетесь:

• Синтаксические ошибки (Syntax errors) : Это ошибки в правильности написания, как это было выше, в примере с Rust. Такие обычно легко исправлять, в той мере, в какой вы знакомы с синтаксисом языка и знаете, что означают сообщения об ошибках.
• Логические ошибки (Logic errors) : Это ошибки, появляющиеся в том случае, если синтаксис корректен, но код не выполняет своего предназначения, то есть программа выполняется неверно. Такие исправлять сложнее, чем синтаксические, поскольку не выводится сообщений, указывающих место, где вы ошиблись.

HTML не страдает от синтаксических ошибок, потому что браузер читает код толерантно, в том смысле, что страницы могут отображаться даже если синтаксические ошибки присутсвуют. Браузеры имеют встроенные правила по интерпретации неверно написанной разметки, и вы можете запустить что-либо, даже если вы имели в виду другое. Это может стать настоящей проблемой!

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

Активное обучение: Знакомство с толерантным кодом

Время изучить природу толерантного кода в HTML.

Для начала, скачайте наш пример отладки и сохраните локально. Эта демонстрация намеренно написана с ошибками, которые нам предстоит обнаружить.

Далее, откройте её в браузере. Вы увидете нечто вроде этого:

Сейчас документ выглядит не особо хорошо; Давайте посмотрим в код и выясним почему (Показано только тело документа): HTML debugging examples

What causes errors in HTML?

• Unclosed elements: If an element is not closed properly, then its effect can spread to areas you didn"t intend
• Badly nested elements: Nesting elements properly is also very important for code behaving correctly. strong strong emphasised? what is this?
• Unclosed attributes: Another common source of HTML problems. Let"s look at an example: не закрыт, и сообщение указывает прямо на открывающий тег.
• "End tag strong violates nesting rules": Элемент неправильно вложен - на этом уровне нет парного открывающего тега.
• "End of file reached when inside an attribute value. Ignoring tag": Загадочное сообщение. Дело в том, что где-то (скорее всего, в конце документа) неправильно прописано свойство элемента, и конец файла оказался внутри этого свойства. В браузере не видно ссылки - скорее всего, проблема рядом с ней.
• "End of file seen and there were open elements": Файл закончился, но некоторые элементы не закрыты. Сообщение указывает на конец файла, в данном случае не закрыт элемент example: