Поговорим о случае, когда нужно автоматизировать запуск тестов и сбор статистики покрытия, к примеру, для гипотетической клиентской JS библиотеки. Задача не совсем тривиальна, поскольку для нормальной работы библиотеки требуется полноценный браузер — библиотека является визуальной оберткой над стандартными компонентами формы. Библиотека должна быть написана так, чтобы все взаимодействие с ее объектами можно было производить с помощью методов, которые они предоставляют, а не только через непосредственные манипуляции с DOM (т.е. любое действие юзера может быть запущено не только событием, допустим, клика по чему-то, но и руками через метод). Но тем не менее, надо этот DOM иметь, чтобы результаты работы методов помимо изменения внутреннего состояния объектов также отображались и в DOM. В целом напоминает приложения на Sencha (ExtJS).

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

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

Настала пора мысленно вернуться на четыре с небольшим года назад ко блогозаписи «Simple “Class” Instantiation» из блога Джона Резига, прославленного создателя необыкновенно удобной библиотеки jQuery. И вернёмся.

Однако же, так как я вовсе не вижу её в результатах поиска на Хабрахабре по слову «Resig», то поневоле приходится думать, что эту полезную блогозапись никто не удосужился перевести (или хотя бы пересказать) за четыре прошедших года — мне придётся, стало быть, самостоятельно пересказать блогозапись Резига прежде, чем я исполню моё главное намерение: поразмыслить вслух, почему же предложенный Резигом способ решения указанной им проблемы так и не сделался общераспространённым. И перескажу. (Сам этот пересказ ужé был бы полезен читателю, даже кабы я к нему ничего от себя не прибавил. А я прибавлю.)

---

Шестого декабря 2007 года Резиг рассмотрел, что получается, когда в джаваскрипте используется операция «new» для создания объекта (в языках с классами мы сказали бы «экземпляра класса»):

function User(first, last){
   this.name = first + " " + last;
}

var user = new User("John", "Resig");

Резиг справедливо подметил, что для начинающих программистов на джаваскрипте не вполне очевидно, что появление «this» в коде функции указывает на то, что перед нами конструктор объекта. (Я от себя в скобках прибавлю: если функция находится в недрах некоторой библиотеки, то это обстоятельство нуждается также и в документировании — а не то пользователь библиотеки не многим будет отличаться от новичка: исходный код с телом функции читают не все, тем более что он нередко применяется в минифицированном, не читаемом виде.)

Поэтому, рассудил Резиг, рано или поздно кто-нибудь попробует вызвать «User()» без «new» и тем получит на свою голову сразу две неприятные проблемы. Во-первых, переменная «user» останется неопределённою: функция «User()» задумана ведь как конструктор, а значения она никакого не возвращает. Во-вторых, что ещё хуже, попытки обращения к «this» изнутри такого (некорректно вызванного) конструктора неизбежно приведёт к засорению глобального пространства имён — а это чревато зловещими и трудноуловимыми последствиями. Обе проблемы Джон Резиг продемонстрировал на примере:

var name = "Resig";
var user = User("John", name);
// здесь переменная «user» не определена
// БОЛЕЕ ТОГО: значение «name» теперь ужé не «Resig»!
if ( name == "John Resig" ) {
   // фигассе!…
}

Я хочу описать простой минималистский подход к разработке сложных JavaScript приложений. Из внешних библиотек будут использоваться только jQuery и мой js-шаблонизатор, причём из jQuery используются только $.ready(), $.ajax() и $.proxy() — т.е. суть не в библиотеках (их тривиально заменить на предпочитаемые вами), а в самом подходе.

В основе подхода лежат две идеи:

1. JavaScript виджеты — небольшие модули, каждый из которых «владеет» определённой частью веб-странички (т.е. всё управление этой частью странички происходит исключительно через методы этого модуля, а не через прямую модификацию DOM — инкапсуляция). Виджет отвечает исключительно за функциональность, но не за внешний вид; поэтому прямая модификация части DOM, которым «владеет» виджет, снаружи виджета допускается — но только для чисто дизайнерских задач (для архитектуры и общей сложности приложения нет принципиальной разницы между коррекцией внешнего вида через CSS или jQuery).
2. Глобальный диспетчер событий. Взаимодействие между виджетами осуществляется путём посылки сообщений глобальному диспетчеру (слабая связанность, паттерн Mediator/Посредник), а уже он принимает решение что с этим сообщением делать — создать/удалить виджеты, дёрнуть методы других виджетов, выполнить дизайнерский код, etc. В отличие от динамического подхода к обработке событий (когда обработчики конкретного события добавляются/удаляются в процессе работы) статический диспетчер сильно упрощает понимание и отладку кода. Безусловно, есть задачи, для которых нужны именно динамические обработчики событий, но в большинстве случаев это избыточное усложнение, поэтому всё, что можно, делается статическими обработчиками.

Если вы знаете о том, что WebKit умеет изменять вид тэга SPAN на кнопку, или на поле ввода, или если вы знаете каким свойством можно диктовать поведение элемента в момент тапа по нему, то вам не сюда.

Американская компания Bocoup, как и многие другие веб-разработчики, постоянно использует в работе известный «пуленепробиваемый» шаблон для создания HTML5-сайтов HTML5 Boilerplate. Однако, сотрудники Bocoup решили не только пользоваться, но внести свой вклад в общее дело и выкатили для всеобщего пользования не менее концептуальную вещь — Backbone Boilerplate, набор лучших средств и приёмов для создания приложений Backbone.js.

Прямо из коробки мы получаем:

• Backbone, Underscore и jQuery, всё это на базе HTML5 Boilerplate.
• Инструмент Windows/Mac/Linux для прекомпиляции шаблонов, связывания и минификации всех библиотек, кода приложения и CSS.
• Лёгкий веб-сервер node.js.
• Многочисленные сниппеты кода для Backbone, облегчающие жизнь.

В Backbone Boilerplate логичная и элегантная файловая система (отдельно код, вспомогательные файлы, тесты, билды) и есть возможность создавать собственные классы Models/Collections/Views/Routers внутри модулей.

Разработчики говорят, что проект появился в результате их долгих попыток работать с другими шаблонами: оказалось, что в одних нет процесса сборки, другие налагают излишние ограничения. Новый Backbone Boilerplate призван исправить ситуацию и вполне может стать каноническим, каким стал тот же HTML5 Boilerplate.

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

В этом уроке я покажу как создать кнопку с изюминкой, используя только якорный тег и мощь CSS.

Более месяца назад в статье FAQ по JavaScript: задавайте вопросы был задан вопрос «Подскажите примеры хорошего подхода организации JS кода к сайту на достаточно высоком уровне. Как можно узнать подробнее практики реализации например gmail?».

Пришло время ответить на данный вопрос. Я немного затянул т.к. хотел рассказать доклад на одноименную тему на Я.Субботнике. Доклад был очень коротким многие важные моменты пришлось выкинуть. Статья — более-менее полная версия.

Эта статья о том, как сделать крупное веб-приложение расширяемым и поддерживаемым: архитектура, подходы, правила.

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

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

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

Примечание: ниже перевод статьи «How JavaScript is Slowing Down the Web (And What To Do About It)», посвященной, в основном, работе с виджетами: характерные проблемы и методы их решения.

Одна строка JavаScript является основой большинства текущих технологий, которые используют авторы блогов. Виджеты, средства (фото-/видео-)обмена, отслеживание посетителей, рекламные объявления. Во многих случаях единственная строка JavaScript — это все, что нужно автору, чтобы добавить в своей блог что-то новенькое. Проблемы начинаются тогда, когда много-много этих самых строчек собирается вместе...

читать дальше на webo.in →

Примечание: ниже находится перевод двух близких статей («Delay loading your print CSS» и «JS includes — the saga continues…») по оптимизации загрузки страницы при наличии нескольких файлов стилей или скриптов.

У вас есть два вызова CSS-файлов на странице, например:

<link type="text/css" rel="stylesheet" href="screen.css"
      media="screen" />
<link type="text/css" rel="stylesheet" href="print.css"
      media="print" />

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

читать дальше на webo.in →

Примечание: ниже перевод статьи «Presentation Layer Performance Tuning», в которой затрагиваются основные аспекты оптимизации загрузки веб-приложений и предлагаются некоторые практические советы.

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

Эти процессы, однако, только частично затрагивают то время, которое клиент тратит на ожидание загрузки страницы в окне своего браузера. Большая часть времени тратится на загрузку, кеширование и отображение JavaScript, CSS и картинок (прим.: не-HTML файлов). Оптимизация производительности уровня представления (presentation layer) веб-приложений, на самом деле, сводится к двум простых условиям:

• Меньше данных
• Меньше запросов

читать дальше на webo.in →

Примечание: ниже перевод статьи «Event delegation without a JavaScript library», посвященной обзору методов по назначению обработчиков событий в JavaScript и их возможной оптимизации, она дополнена моими комментариями и практической частью.

Большинство статей и примеров, которые я видел в последнее время по переопределению событий, основывались на какой-либо распространенной библиотеке. Например, в своей хорошо известной статье Chris Heilmann применяет YUI-библиотеку, а в прошлом месяце Dan Webb в своей презентации на media использовал prototype.

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

читать дальше на webo.in →

Примечание: ниже представлен перевод двух последовательных статей «The window.onload Problem — Solved!» и «window.onload (again)», посвященных оптимизации исполнению скриптов при загрузке страницы, эта проблема была предварительно затронута в статье: «Как JavaScript тормозит Веб (и что с этим делать)?»

Для начала определимся с самой проблемой. Событие window.onload используется программистами для старта их веб-приложения. Это может быть что-то довольно простое, например, выпадающее меню, а может быть и совсем сложное, как пример, запуск почтового приложения. Суть проблемы заключается в том, что событие onload срабатывает только после того, как загрузится вся страница (включая все картинки и другое бинарное содержимое). Если на странице много картинок, то можно заметить некоторую задержку между загрузкой страницы и тем моментом, когда она начнет фактически работать. На самом деле, нам нужно только узнать способ определить, когда DOM полностью загрузится, а не ждать еще и загрузку картинок.

читать дальше на webo.in →

Примечание: ниже находится перевод статьи «Client Side Load Balancing for Web 2.0 Applications», в которой затрагиваются вопросы балансировки нагрузки между несколькими серверами и рассматривается решение, обеспечивающее балансировку такой нагрузки прямо на компьютере клиента.

Сервер обрабатывает HTTP (HyperText Transfer Protocol) запросы со стороны браузеров. Если вы введете в адресной строке URL, например, www.digital-web.com, то ваш компьютер отправит поисковый запрос для определения, какие именно сервера будут обрабатывать ваш запрос и пересылать данные. Техника обработки таких запросов для кластера веб-серверов называется балансировкой нагрузки.

Балансировка нагрузки для веб-приложений

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

• Распределять нагрузку внутри кластера рабочих серверов.
• Корректно обрабатывать отказ одного из рабочих серверов.
• Весь кластер должен существовать для конечного пользователя как одна-единственная машина.

читать дальше на webo.in →

Примечание: ниже частичный перевод статьи «Compress JavaScript and CSS without touching your application code», в которой описывается статичное сжатие CSS- и JS-файлов на сервере и корректная выдача их затем клиенту. Далее даны мои комментарии с более комплексным решением. Приношу извинения, если для кого-то тема будет слишком знакома или неинтересна: в Рунете нормальной статьи на данную конкретную тематику обнаружить не удалось.

Для обеспечения корректного архивирования вашего веб-контента, по-видимому, наиболее общий подход будет заключаться в выполнении по порядку следующих пунктов:

• Проверить, умеет ли клиент принимать файлы в формате gzip-encoded.
• Обеспечить соответствующий вывод на стороне сервера через gzip-функции, либо уповать на то, что всем этим займется непосредственно Apache.
• Поиграться с .htaccess, чтобы обеспечить корректный content type.

читать дальше на webo.in →

Сейчас уже много где написано и упомянуто про технику CSS sprites (aka CSS Image Maps). Я не буду открывать Америку и рассказывать о ней дотошно еще раз, а просто хочу привести несколько примеров и полезных ссылок. И пару советов из собственной практики.

Сама техника заключается в том, что мы создаем комбинированное изображение, из которого затем «вырезаем» с помощью свойств background-position нужный нам в данном случае кусок. На текущем уровне поддержки браузерами (я полагаю, что 99,9%) оно является просто must-have для любого уважающего себя интернет-ресурса (ибо позволяет сократить число запросов к серверу, отделить поведение от представления, возложить труд по анимации на CSS-движок браузера, а не на JS-движок, т.е. это будет работать даже с выключенными скриптами, и много-много прочих «вкусностей»). Но обо всем по порядку. Поехали.

читать дальше на webo.in →

Примечание: ниже находится перевод статьи «CSS Expression Optimization», в которой автор немного освещает использование и проблематику динамических свойств в CSS (aka CSS expressions). Также автор предлагает способ их оптимизации (исполнение один-единственный раз вместо постоянного выполнения). Далее приведены несколько тезисов с ClientSide'2007 по заявленной тематике. Мои комментарии даны курсивом.

CSS expressions были впервые представлены в Internet Explorer 5.0, который позволял назначать JavaScript-выражение в качестве CSS-свойства. Например, следующий код позволит разместить элемент в зависимости от того, какого размера окно браузера.

#myDiv {
   position:   absolute;
   width:      100px;
   height:     100px;
   left:       expression(document.body.offsetWidth  - 110 + "px");
   top:        expression(document.body.offsetHeight - 110 + "px");
   background: red;
}

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

читать дальше на webo.in →

После публикации статьи на тему архивирования JS/CSS-файлов для последующей выдачи клиенту, я задумался на тему, какой же метод минимизации (minify) следует использовать. В докладе на конференции ClientSide'2007 не удалось установить четкого критерия, чем и как лучше всего сжимать JavaScript-файлы. Данная заметка посвящена рассмотрению как раз этой проблемы.

Задача

В качестве цели исследования был закреплен анализ всех известных средств статической минимизации JavaScript-кода, после чего нужно было ответить на три основных вопроса:

• Имеет ли смысл пользоваться каким-либо минимизатором JS-кода?
• Есть ли среди них универсальное средство, показывающее лучшие результаты в подавляющем большинстве случаев?
• Если такого средства нет, то каковы критерии использования набора инструментов?

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

читать дальше на webo.in →

Примечание: ниже приведен перевод заметки из блога разработчика YUI-утилит Julien Lecomte «Running CPU Intensive JavaScript Computations in a Web Browser», в которой автор рассматривает выполнение «тяжелых» вычислений в веб-браузере и приводят ряд методов для их «оптимизации». Мои комментарии даны курсивом.

Введение

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

Наиболее существенным препятствием для выполнения в веб-браузере «тяжелых» вычислений является тот факт, что весь интерфейс пользователя в браузере останавливается и ждет окончания исполнения JavaScript-кода. Это означает, что ни при каких условиях нельзя допускать того, чтобы для завершения работы скрипта требовалось более 300 мс (а лучше, если горадо меньше). Нарушение этого правила неминуемо ведет к плохому восприятию ресурса пользователем (bad user experience).

К тому же в веб-браузерах у JavaScript-процесса имеется ограниченное время для завершения своего выполнения (это может быть как фиксированное число — в случае браузеров на движке Mozilla — или какое-либо другое ограничение, например, максимальное число элементарных операций — в случае Internet Explorer). Если скрипт выполняется слишком долго, то пользователю выводится диалоговое окно, в котором запрашивается, нужно ли прервать скрипт.

читать дальше на webo.in →