Очередной блог фрилансера » инструменты

Инструменты для тестирования и отладки в IE

dreamhelg — Fri, 26 Mar 2010 05:00:02 +0000

Очень часто, при разработке проекта, его тестирование в Internet Explorer откладывают до последнего. И это вполне нормально, если ваши проблемы в основном связаны с версткой страницы. Однако, во время разработки веб-приложения с большим количеством различных функций, вполне возможно появление другого рода проблем: постоянная отладка, производительность на клиентской стороне, проприетарные проблемы и многое другое. В любом случае, производить отладку в IE не всегда так же комфортно, как в других браузерах. В сегодняшней статье, мы рассмотрим различные наборы инструментов, которые помогут вам сделать процесс отладки и тестирования в IE, более приятным.

Сборки браузеров

В первую очередь конечно же нужно установить все популярные версии Internet Explorer (IE6, IE7, IE8). Для этого существует множество различных решений, я расскажу о четырех из них.

Internet Explorer Collection

Лично я рекомендую использовать – Internet Explorer Collection. Не пугайтесь, это очень надежный инструмент (несмотря на внешний вид их сайта). Internet Explorer Collection содержит множество версий IE, совершенно независимых друг от друга, так что их можно использовать одновременно. Я рекомендую эту сборку главным образом потому, что их браузеры весьма стабильны. Кроме того, Internet Explorer Collection содержит Internet Explorer Developer Toolbar.

BrowserSeal.BrowserPack

Если вам требуются более старые версии других браузеров, я рекомендую установить BrowserSeal.BrowserPack. Он использует, упомянутый выше Internet Explorer Collection, и кроме того, позволяет установить браузеры типа Safari3 и Opera 9. Браузеры, входящие в состав BrowserSeal.BrowserPack стабильны и не имеют никаких выявленных проблем.

IETester

IETester имеет некоторые преимущества в сравнении с другими сборками, например такие как открытие разных версий IE в табах. IETester разрабатывается командой DebugBar, которая так же предоставляет замечательные инструменты отладки DebugBar и Companion.js (оба рассмотрены в сегодняшней статье). К сожалению, IETester (версии 0.4.2) остается весьма ненадежным приложением, к тому же во время отладки находятся некоторые несоответствия. Будем надеяться, что рано или поздно эти проблемы будут исправлены, и мы сможем взять IETester на вооружение.

Microsoft Expression Web SuperPreview

Microsoft Expression Web SuperPreview – это полноценное приложение и часть продукта Microsoft Expression Web 3. Главное его назначение – это возможность сравнить одну и ту же страницу одновременно в IE6, IE7 и IE8. На мой взгляд, это приложение не предназначено для отладки и тестирования.

Основные инструменты отладки

Скорее всего, для отладки в Firefox, вы используете Firebug. И возможно, вы также слышали о Firebug Lite и даже использовали его. Далее, вы узнаете какие еще способы можно использовать для отладки кода под Internet Explorer.

Firebug Lite

Конечно же, вы уже знакомы с Firebug Lite. Если нет, читайте далее. Firebug Lite – это javascript-файл, который можно подключить к странице, чтобы получить возможность использовать некоторые функции Firebug, в других браузерах. Скажу сразу, я не являюсь большим фанатом Firebug Lite. Во-первых потому, что большинство возможностей консоли недоступны в других браузерах. Во-вторых, он не всегда хорошо работает. Мне не раз приходилось сталкиваться с рядом проблем в IE, поэтому не стоит концентрироваться только на этом инструменте.

IE Developer Toolbar

Возможно, вы знакомы с инструментами разработчика под IE8. IE Developer Toolbar – практически тот же самый инструмент для IE6 и IE7. И кроме того, он поставляется вместе со сборкой IE Collection, по умолчанию. IE Developer Toolbar прост в использовании и предоставляет широкий набор средств для отладки. По функциональности, его можно сравнить с Web Developer – дополнением для Firefox.

DebugBar

Все, чего вам не хватило в Developer Toolbar, вы найдете в DebugBar. В большинстве случаев, когда вам требуется найти что-либо за пределами документа, вам поможет DebugBar. Он очень быстрый и надежный. Если бы требовалось описать DebugBar в двух словах, то достаточно сказать “он работает!”.

CompanionJS

Companion.js интегрируется с IE, и вполне может быть назван простейшей версией Firebug. В отличие от Firebug Lite, Companion.js, имеет более удобную консоль и отчеты об ошибках. К сожалению, в Companion.js есть два серьезных недостатка: 1) он пока не поддерживает методы типа console.dir(); и 2) иногда вываливается в ошибку, при совместном использовании с другими инструментами разработчика для IE.

Инструменты тестирования производительности

Клиентское тестирование производительности и оптимизация – это практика, которая долгое время “не существовала” в веб-разработке. Я имею в виду, что ей долгое время не уделяли должного внимания. Как вам наверное известно, Internet Explorer (особенно IE6), не настолько хорош, особенно в сравнении с другими браузерами. Но, когда вы начнете тестировать производительность в IE6, вы удивитесь, насколько незначительные вещи могут влиять на скорость работы сайта. Далее рассмотрены некоторые инструменты тестирования производительности, которые можно использовать в любом браузере, не столько в Internet Exploer.

dynaTrace AJAX

Если вы используете Speed Tracer в Google Chrome, тогда вы полюбите dyna Trace AJAX. Название говорит само за себя – он используется для диагностики и отслеживания AJAX, а также проблем с производительностью клиентских скриптов. Кроме того, в дополнение, он предоставляет инструменты для отслеживания проблем рендера (отрисовки) и сетевой загрузки. dynaTrace AJAX не самый простой в использовании инструмент. Однако в их одноименном блоге, вы найдете множество полезной информации, об применении этого мощного приложения. Установите dynaTrace AJAX, и разрешите все проблемы производительности, замедляющие работу сайта в Internet Explorer.

MySpace’s Perfomance Tracker

MySpace’s Perfomance Tracker или “msfast” – это плагин для браузера, который помогает разработчикам улучшить производительность кода, путем сбора и измерения возможных “узких мест”, на веб-странице. У меня возникли небольшие проблемы, при установке бета-версии. Но после того, как была установлена альфа-версия и произведено обновление до бета-версии, все заработало.

JSLitmus

JSLitmus – это простой инструмент для создания специализированных JavaScript-тестов. Я особенно рекомендую использовать JSLitmus для тестирования производительности всего вашего JavaScript-кода. JSLitmus предоставляет дополнительные преимущества в Internet Explorer. Как известно, в IE, существуют проблемы с JavaScript, способные нанести серьезный удар по производительности. Но если вы заранее создадите несколько простых тестов, то времени на поиск и решение этих проблем уйдет гораздо меньше.

Fiddler2

Fiddler – это отладочный прокси-сервер, ведущий логи всего HTTP(S) трафика. Fiddler позволяет вам проверить весь HTTP(S) трафик, установить точки прерывания и “играть” с исходящими и входящими данными. Fiddler включает мощную скриптовую подсистему, и может быть расширен с помощью любого .NET языка. Если честно, я практически не использую Fiddler. В основном потому, что проблемы производительности связанные с трафиком сайта, всегда решаются с помощью другого инструмента (в другом браузере). Но Fiddler на самом деле дает отличное понимание того, что действительно происходит между браузером и сервером, и кроме того предоставляет большое количество настроек.

Другие ресурсы

Во время написания статьи, мне попался инструмент под названием IEInspector. Инструмент платный, но есть бесплатная демо-версия. У меня не было времени рассмотреть его подробнее, возможно вы захотите попробовать его. Кроме того, на сайте Microsoft Windows, есть список, в котором перечислены полезные инструменты для тестирования и разработки приложений под Internet Explorer 8. Существует еще множество других интересных приложений и сервисов, которые не рассмотрены в этой статье. Если вы знаете хорошие инструменты тестирования и отладки кода под Internet Explorer, оставляйте ссылки в комментариях. Перевод статьи "Debugging and Testing in Internet Explorer Made Easy", автор Samuli Hakoniemi

Меркуриал. Разрешение конфликтов

dreamhelg — Thu, 17 Dec 2009 08:12:19 +0000

В предыдущей статье, мы рассматривали совместную работу над одним проектом, изучив базовые приемы объединения двух различных репозиториев в один. В сегодняшней статье, мы рассмотрим более сложную ситуацию – разрешение конфликтующих изменений.Итак, как вы уже заметили ранее, большинство объединений выполняется очень просто, но из всякого правила бывают исключения. Иногда, вы можете столкнуться с тем, что каждая сторона изменений затрагивает одну и ту же часть, одного и того же файла. И если обе модификации не идентичны, то слияние приведет к образованию конфликта, в котором вам придется решить, каким образом «помирить» различные изменения, чтобы получить правильный результат. Рисунок 3.4. Конфликтующие изменения документа Рисунок 3.4. иллюстрирует пример двух конфликтующих изменений одного и того же документа. Мы начнем с создания первоначальной версии файла, затем произведем в нем небольшие изменения, в то время как кто-нибудь другой, изменит ту же часть текста. Наша задача в разрешении конфликтующих изменений – решить, как именно должен выглядеть наш файл после объединения. Меркуриал не имеет встроенной возможности разрешения конфликтов. Вместо этого, он использует внешнюю программу, имеющую графический интерфейс.

Рабочий пример

В разрешении конфликтующих изменений нет ничего сложного, и сейчас мы на примере разберем эту задачу. Первое, что нам понадобится – это исходный репозиторий с файлом, который мы впоследствии будем изменять. Создаем папку first, внутри которой, создаем простой текстовый файл, с именем letter.txt, с одним единственным, знакомым многим, предожением: Далее запускаем внутри папки командную строку, и поочередно выполняем следующие команды:

$ hg init

$ hg add letter.txt

$ hg commit –m “исходная версия текстового файла”

Здесь, мы сначала создаем репозиторий, затем добавляем в него наш файл letter.txt, и сохраняем его начальную версию. То же самое можно сделать с помощью графического интерфейса, через контекстное меню, доступное по правому клику мыши. Далее, клонируем репозиторий first, в репозиторий под названием first-one. Снова используем командную строку:

$ cd ..

$hg clone first first-one

Если вы все сделали правильно, у вас должна появится новая папка с именем first-one, заходим в нее и смело изменяем копию файла letter.txt: Сохраняем изменения, и создаем новый коммит:

$ cd first-one

$ hg commit –m “название булок изменено на норвежские”

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

$ cd ..

$ hg clone first first-second

Заходим внутрь только что клонированного репозитория first-second, и снова изменяем копию файла letter.txt: И снова повторяем действия второго этапа, записываем наши изменения:

$ cd first-second

$ hg commit –m “название булок изменено на австрийские”

Отлично, теперь у нас есть две копии одного репозитория, с разными изменениями одной и той же части предложения. Переходим к главной части нашего примера – к объединению. Для того, чтобы не было путаницы, создадим из репозитория first-one клон, и назовем его first-merge. Он как раз и будет содержать объединенные версии двух репозиториев.

$ cd ..

$ hg clone first-one first-merge

$ cd first-merge

$ hg pull –u ../first-second

В вышеприведенном коде, кроме того что мы клонировали новый репозиторий first-merge, мы еще затянули в него изменения из репозитория first-second, так что сейчас он содержит два набора взаимоисключающих изменений. Теперь самое интересное, нам нужно их объединить, так что смело запускаем команду: $ hg merge И перед вами должна предстать графическая утилита Kdiff3, предназначенная специально для разрешения конфликтов: Как раз, на представленном выше скриншоте, она сообщает нам, что у нас есть один конфликт, который не возможно разрешить автоматически. А нам и не нужно автоматически, поэтому жмем кнопку ОК, и внимательно смотрим на окошко: Здесь по порядку слева направо отображается:

A - набор изменений после которого началась развилка
B - набор изменений, содержащийся в репозитории first-one
C - набор изменений, затянутый из репозитория first-second.

Итак, для того чтобы разрешить конфликтную ситуацию, нам нужно решить, какое же изменение стоит использовать в конечном итоге. Предположим, что свежие австрийские булки будут гораздо лучше на вкус, чем черствые норвежские, поэтому, мы решаем использовать набор изменений C, который был получен из репозитория first-second. Для того чтобы использовать ревизию C, можно воспользоваться соответствующей кнопкой на панели инструментов, или пунктом меню «Merge – Select Line(s) from C» После этого нажимаем кнопку сохранить, и все окошко можно закрыть. И последний этап – создание коммита полученного объединения, как обычно воспользуемся привычной командой: $ hg commit –m “объединение двух версий” Теперь если воспользоваться командой контекстного меню «TortoiseHG – View Changelog», мы сможем увидеть как были объединены наши конфликтующие ветки: В данном примере мы рассмотрели простейший конфликт, однако, в процессе совместной работы над проектом, таких конфликтов может быть огромное количество. С помощью утилиты kDiff3, вы можете либо обрабатывать конфликты построчно, как мы только что сделали и для каждой строки назначать определенную ревизию, либо указать нужную ревизию для всех возникших конфликтов. В этом случае, указанная вами ревизия заменит своим содержанием все конфликтующие изменения, поэтому используйте ее аккуратно. В статье использовались материалы книги "Mercurial: The Definitive Guide", автор Bryan O'Sullivan

Создание прототипа с помощью CSS-фреймворка Grid 960

dreamhelg — Mon, 26 Oct 2009 10:55:06 +0000

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

Создание Сетки

Grid 960 работает на основе наследования классов. Этот фреймворк предоставляет две сетки: 12 и 16 колонок. Основной контейнер всегда имеет ширину 960px. Использование числа 960 позволяет применять большинство различных комбинаций колонок, без усложнения работы с ними. Для верстки этого дизайна, мы будем использовать сетку из 12-ти колонок, но мы не будем использовать все 12 колонок. Каждой ячейке сетки назначено свойство margin: 0 10px. Это создает промежуток в 20 пикселей. При создании строки, сумма ширины всех элементов добавляется к 960. Взгляните на демонстрационную страницу Grid 960. Вы увидите сетку со всеми видами комбинаций. Каждая ячейка сетки имеет класс, который определяет, какой она будет ширины. Далее представлена разбивка ширины столбцов для 12-ти колоночной сетки:

60px
140px
220px
300px
380px
460px
540px
620px
700px
780px
860px
940px

Каждая ширина соответствует имени класса, оформленного в виде: grid_X, где X это порядковый номер из представленного выше списка. Если вам нужен блок, шириной 940px, используйте класс grid_12. Откуда же Grid 960 знает, какая должна использоваться ширина? Каждый grid_X представляет собой селектор container_Y .grid_X, где значение Y равно 12 либо 16 колонок. Давайте немного рассмотрим сам код. Вот как можно создать сетку из двух строк в 12-ти колоночном контейнере. Здесь первая строка шириной 940 пикселей, и вторая строка содержит две одинаковых колонки. [html]

940px

460px

[/html] Когда вы создаете строку в сетке, убедитесь, что все дочерние номера gird_X в сумме дают число колонок, которое вы используете. Это гарантирует правильную ширину. Два дива с классом grid_6, дают в сумме 12. Вы не ограничены только этими значениями, и также можете использовать 6, 4 и 2. Вот и все, сетка готова для контента. Теперь, после того как вы узнали как работает Grid 960, давайте посмотрим как создается макет.

Макет

Визуализировать сетку дизайна довольно легко. Будет одна строка для картинки заголовка, строка для навигации, строка с двумя колонками для статьи заголовка и постера, разделитель, 4 колонки, затем подвал, состоящий из трех колонок.

После визуализации, вы должны понимать, как создать сетку макета. Используя значения ширины в имени класса, из приведенного списка, давайте вместе составим код. Помните, что необходимо добавлять очищающий div в конце каждой строки. Не забудьте включить CSS-файлы, входящие в состав Grid 960. [html]

[/html] Скелет готов. Пришло время накладывать дизайн. Зеленые панели – это просто блоки с фоновым цветом и высотой. У панели навигации высота не задана. Вместо этого, она будет контролироваться размером внутренних ссылок. Не забудьте добавить картинку заголовка. [css] div.spacer { background-color: #8FC73E; height: 1em; } div#navbar { background-color: #8FC73E; padding: 10px 0; } [/css] Применение классов для корректировки блоков grid_12 и установка ID [html]

[/html] Центральным колонкам не требуются никакие эффекты. Добавим немного текста для заполнения дизайна. Прежде, чем приступать к верхней части, взглянем на подвал. На скриншоте подвал однородного цвета. У вас не получится реализовать это с существующим кодом. Оборачивающий div, вокруг этих трех колонок решит проблему. Вы думаете, ничего страшного, просто нужно вставить div. Но этот див поломает сетку, поскольку Grid 960 основывается на родительских и дочерних элементах, при использовании стилей (вспомните селектор container_12 .grid_4 ). В данном случае, проблему поможет решить вложенная сетка, которую Grid 960 позволяет использовать. Создайте вложенную сетку, путем добавления блока grid_12, затем расположите внутри блоки grid_4. При использовании вложенных сеток, дочерние элементы должны иметь специальные классы. Первый дочерний элемент должен иметь класс «alpha», а последний дочерний блок – класс «omega». Отредактируйте разметку для внесения необходимых изменений для подвала. [html] [/html] [css] div#footer { background-color: #e5e5e6; } [/css] Прекрасно! Теперь у подвала есть заливка однородным цветом, и вы можете указать размеры колонок, если это необходимо. Добавим немного текста для колонок подвала и перейдем к панели навигации. Навигация выполнена в виде простого маркированного списка Добавим немного ссылок и соответствующих стилей. [html]

Articles
Topics
About
Editors
Contact

[/html] [css] div#navbar ul { list-style: none; display: block; margin: 0 10px; } div#navbar ul li { float: left; margin: 0 1.5em; font: bold 1em Arial; } [/css] Замечательно. Страница скоро будет готова. Все что нам нужно сделать, это создать эффекты блока в верхней секции. Это не так просто, как кажется. Прежде чем мы начнем, вы должны кое-что понять о Grid 960 и CSS-фреймворках в целом.

10 лучших CSS-редакторов

dreamhelg — Mon, 21 Sep 2009 08:01:20 +0000

CSS редакторы – это редакторы, которые предназначены только для создания Каскадных Таблиц Стилей. И хотя для этих целей можно использовать полнофункциональную среду разработки или другой редактор кода – CSS-редакторы могут [...]

Основы Меркуриала: объединение работы

dreamhelg — Thu, 03 Sep 2009 15:54:14 +0000

«Одна голова — хорошо, а две лучше». Эта пословица как нельзя лучше походит к теме сегодняшней статьи о Меркуриале. После изучения в предыдущей статье базовых приемов и команд, необходимых для [...]

WordPress. Обзор фреймворков

dreamhelg — Tue, 11 Aug 2009 04:18:31 +0000

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

Введение в Mercurial. Основы

dreamhelg — Tue, 07 Jul 2009 09:38:44 +0000

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

10 полезных расширений для улучшения Firebug

dreamhelg — Wed, 24 Jun 2009 05:11:44 +0000

Firebug – революционное расширение для Firefox, помогающее веб-разработчикам и дизайнерам тестировать и инспектировать код. Он содержит множество полезных функций, таких как консоль для отображения информации, DOM-инспектор, детальную информацию об элементах [...]

Инструменты верстальщика

dreamhelg — Tue, 16 Dec 2008 08:02:26 +0000

Не сказать что слишком долго, но определенное время я размышляла, какая же запись должна быть следующей. Можно было бы сразу пуститься во все тяжкие, и начать рассказывать всем, о том [...]