Блог Конфуция

Ручное наследование в яваскрипте

2011-04-06T00:00:00-07:00

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

Просто класс #


function A () {}

var a = new A()

Да, как не удивительно, класс — это просто функция.

Безымянный класс #


var o = new function () {}

Классом может быть любая функция. Даже безымянное замыкание право имеет.

Класс с методом #


function A () {}
A.prototype =
{
	method: function () {}
}

var a = new A()
a.method()

Методы добавляются с помощью прототипов. Про прототипы мы всё уже знаем.

«Статический» метод #


function A () {}
A.staticMethod = function () {}
A.staticMethod()

В экземплярах staticMethod доступен не будет.

Наследование в вакууме #


function A () {}


function B () {}
B.prototype = new A()

Да, именно prototype = new A(), а не просто prototype = A().

Небесполезное наследование #


function A () {}
A.prototype =
{
	methodA: function () {}
}


function B () {}
B.prototype = new A()

var b = new B()
b.methodA()

Получили в экземпляре класса B полезный methodA() от класса A.

Добавление метода #


function A () {}
A.prototype =
{
	methodA: function () {}
}


function B () {}
B.prototype = new A()
B.prototype.methodB = function () {}

var b = new B()
b.methodA()
b.methodB()

Теперь в экземпляре класса B есть оба полезных метода.

Добавление кучи методов #


function A () {}


function B () {}
B.prototype = new A()

var methodsB =
{
	methodB1: function () {},
	methodB2: function () {},
	methodB3: function () {}
}

Object.extend(B.prototype, methodsB)

var b = new B()
b.methodB1()
b.methodB2()
b.methodB3()

Object.extend(dst, src) просто копирует свойства из src в dst. Если договориться с санитарами, можно заменить Object.extend() на цикл for in ;)

Замена метода #


function A () {}
A.prototype =
{
	methodA: function () {}
}


function B () {}
B.prototype = new A()
B.prototype.methodA = function () { alert(42) }

var b = new B()
b.methodA()

Вылетит алерт.

Конструктивное наследование #


function A ()
{
	this.array = []
}


function B ()
{
	A.apply(this)
}
B.prototype = new A()

var b1 = new B()
var b2 = new B()
console.log(b1.array == b2.array)
//>>> false

Если бы не выполнили A.apply(this), то array был бы один на все экземпляры B.

Суперметод попроще #


function A () {}
A.prototype =
{
	methodA: function () {}
}


function B () {}
B.prototype = new A()

B.prototype.superMethodA = B.prototype.methodA
B.prototype.methodA = function ()
{
	this.superMethodA()
}

var b = new B()
b.methodA()

Прекрасно работает в простых случаях.

Суперметод посложнее #


function A () {}
A.prototype =
{
	methodA: function () {}
}


function B () {}
B.prototype = new A()

B.prototype.methodA = function ()
{
	A.prototype.methodA.apply(this)
}


function C () {}
C.prototype = new B()

C.prototype.methodA = function ()
{
	B.prototype.methodA.apply(this)
}

var c = new C()
c.methodA()

Прекрасно работает во всех случаях.

Суперметод пошустрее #


function A () {}
A.prototype =
{
	methodA: function () {}
}


function B () {}
B.prototype = new A()

var superMethodA = A.prototype.methodA
B.prototype.methodA = function ()
{
	superMethodA.apply(this)
}

var b = new B()
b.methodA()

Работает пошустрее, но сломается, если кто-то изменит A.prototype.

Полезный суперметод #


function A () {}
A.prototype =
{
	setPosition: function (x)
	{
		this.x = x
	}
}


function B () {}
B.prototype = new A()

B.prototype.setPosition = function (x, y)
{
	A.prototype.setPosition.call(this, x)
	this.y = y
}


function C () {}
C.prototype = new B()

C.prototype.setPosition = function (x, y, z)
{
	B.prototype.setPosition.call(this, x, y)
	this.z = z
}

var c = new C()
c.setPosition(1, 2, 3)

В результате скрытого от нас последовательного вызова A#setPosition() и B#setPosition() внутри C#setPosition(), мы получим объект с данными {x: 1, y: 2, z: 3}.

Ах, да!

Все кусочки кода, конечно же, обернуты в (function(){ … })().

Тесты тут.

Произвольный линукс в контейнере

2010-11-28T00:00:00-08:00

Началось все с того, что техподдержка мастерхоста отказала в установке операционки на наш выбор. А разрешается на их виртуальные серверы ставить только дебиан 5, федору 7 и центос 5. Пятый дебиан полностью устроил бы, если бы в нем уже был апстарт, а будет апстарт только в шестой версии. И без него никак. А так как операционки на наших старых серверах уже давно устарели (Ubuntu 6.10 последовательно обновленная до 8.04), пришла пора все менять.

У нас в офисе уже полтора года вертится несколько OpenVZ-контейнеров. Для домашних нужд все подходит просто прекрасно. Вдобавок, из экспериментов с OpenVZ удалось вынести несколько полезных наблюдений. Вот они, кстати. Чистый виртуозный контейнер — это всего-лишь небольшая папочка да один конфиг. Готовых контейнеров с разными дистрибутивами линукса пруд пруди. Всей виртуализации в OpenVZ, по большому счету: изоляция файловой системы, разделение памяти и процессора, да айпишников. Ядро одно на всех, тип файловой системы — один, и никакой магии с виртуализацией устройств. А еще свою виртуалку внутри контейнера не запустишь (если только полноценный эмулятор запустить). Итого, с одной стороны — никакой тонкой настройки под железо, а с другой — никакого геморроя с этим железом. Вдобавок, возможен интересный трюк, о котором эта статья.

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

Подготовительный этап

делаем полный бекап контейнера (лучше создайте новый и мучайте его);
заходим под рутом по SSH;
создаем папочку new-system там, где вам удобно;
скачиваем в new-system образ новой оси (у меня это ubuntu-10.04-x86.tar.gz);
заходим в new-system и распаковываем образ (tar xzf ubuntu-10.04-x86.tar.gz).

В итоге, папочка new-system (у меня /root/new-system) содержит структуру каталогов новенькой операционки. На следующем шаге мы заменим текущую операционку новой. Только, вот один важный момент. В данном примере новая система родственна старой (сестрички Ubuntu 10.04 и Debian 5.0), поэтому надо будет заменить всего несколько папок, оставив остальные нетронутыми. Если вы собираетесь менять федору на генту, будьте готовы немного поэкспериментировать.

Заеняем системные файлы

Для того, чтобы сократить период перехода системы из одного состояния в другое, не стоит сразу удалять папки старой системы. Достаточно переименовать их, а на их место переместить новые. Так как мы заменяем все привычные программы, типа mv, rm, mkdir, придется делать все вручную прямо из sftp-клиента.

переименовываем эти папки новой системы: bin, dev, etc, lib, sbin, usr, var, во что-то типа bin1, dev1, etc1 и т.д.;
перемещаем переименованные папки из new-system в корень, они встанут бок о бок с папками текущей оси;
одну за другой переименовываем получившиеся пары по такому шаблону bin ⟶ bin0, bin1 ⟶ bin.

Перезагружаемся. Запустится новая система. Так как мы развернули кем-то заранее подготовленный образ, в нем уже будет запущен sshd. Только вот пароль рута будет другой. Если вы обновляли контейнер на хостинге с контрольной панелью (которая, на 4643-м порту), то можете смело менять его оттуда. Можно схитрить и сохранить файл /root/.ssh/authorized_keys от старой системы. Тогда нас пустят по ключу, и можно будет спокойно менять пароль рута через passwd. Теперь оставшиеся от старой системы папки можно спокойно удалять (или архивировать на память).

П.С. У нас контейнеры такие: Linux vXXXX.vps.masterhost.ru 2.6.18-028stab070.7 #1 SMP Fri Oct 1 13:53:00 MSD 2010 i686 GNU/Linux.

Про заголовки в энжи

2010-05-14T00:00:00-07:00

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

Хитрые строки против склеивания массива

2010-02-05T00:00:00-08:00

Почитывая рассылку v8-users, заметил интересную тему про оптимизации, специфичные для v8. Особенно интересным показалось сообщение о ConsStrings (cons в словаре). И вот, собственно, об этих «составных строках» мне и хочется рассказать. Так как восторг! :)

Загадка

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

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

Разгадка

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

Судя по сообщению в рассылке, в v8 конкатенация строк построена как раз по такому принципу (в перле, помнится, это тоже уже давно есть). Цитирую это сообщение Эрика Кори: «Когда вы используете +=, V8 создает структуру типа ConsString, это узел дерева, который занимает 20 байт на 32-х разрядных машинах или 32 байта — на 64-х разрядных. Это относительно быстрая операция. Как только вы пытаетесь использовать строку для чего-то отличного от конкатенации, она превращается в простую «плоскую» строку похожим способом, как бы это сделал join (имеется ввиду Array#join()). Узел ConsString становится мусором, который мы можем собрать довольно быстро. Алгоритм, по которому должен работать join, описан в крайне загадочных спецификациях (например, работа с разреженными массивами), потому join — это не совсем простая операция…».

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

Тестим

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


// испечем массив исходных строк
// обязательно разных и обязательно честных,
// иначе будем мерить неизвестно что
function bake (arr, prefix, count)
{
	console.time('bake')
	var rex = /xxx/
	for (var i = 0; i < count; i++)
		arr[i] = prefix + i,
		rex.test(arr[i]) // «собираем» строку
	console.timeEnd('bake')
}

var count = 100000, // сколько строк
	rex = /^\w/ // тестовый рекс

;(function(){
	var src = [], prefix = 'testA'
	bake(src, prefix, count)
	
	// берем самый неприятный случай,
	// когда мы не знаем сколько будет строк
	var joiner = []
	
	console.time('join()')
	for (var i = 0; i < count; i++)
		// а еще мы не можем использовать конструкцию joiner[i] = …
		// так как в реальной задаче у нас может не быть цикла
		joiner.push(src[i])
	
	var res = joiner.join('')
	var test = rex.test(res)
	console.timeEnd('join()')
	
	console.log(test, 'regexp test')
	console.log(res === src.join(''), 'index of prefix')
})();

;(function(){
	var src = [], prefix = 'testB'
	bake(src, prefix, count)
	
	var joiner = ''
	
	console.time('+=')
	for (var i = 0; i < count; i++)
		joiner += src[i]
	
	var res = joiner // дублируем, чтобы быть честными
	var test = rex.test(res)
	console.timeEnd('+=')
	
	console.log(test, 'regexp test')
	console.log(res === src.join(''), 'index of prefix')
})();

Тестю все на том же стареньком интеловском маке.

Результаты вполне ожидаемые. В Хроме простая конкатенация строк в два раза быстрее, чем склеивание массива строк. В Сафари строго наоборот: массив в два раза быстрее строк. Фаерфокс показывает противоречивые результаты: в 3.0 и 3.5 строки процентов на 15% быстрее, чем склейка массива, а в 3.6 наоборот — строки немного отстают. Пока сошлюсь на погрешность измерений. В Опере картинка поинтереснее, все оперы складывают строки до нескольких раз раз быстрее, чем склеивают массив (зачет!). В эксплорере тоже не все печально: шестой делает join() в 50 раз быстрее конкатенации, седьмой — так же и за то же время, а вот восьмой складывает строки примерно в два раза быстрее, чем склеивает массив, да еще делает любое из этих действий в 100 раз быстрее чем шестой или седьмой на том же железе.

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

Ветвисто

2010-02-02T00:00:00-08:00

Еще один пост во славу гита! Вот такая картина веток образовалась сегодня. Как бы мы жили с ЭссВэЭном? А как оно все пулью работает.

Вычисление констант на этапе компиляции

2010-02-02T00:00:00-08:00

Решили сортировать объекты по новизне. Если объект создан не позже чем полгода назад, то его считаем новым. «Полгода» решили хранить в количестве секунд: 3600 * 24 * (366 / 2) * 1000. Из этого выражения сразу видно, что за полгода мы берем половину високосного года, не учитывая никаких високосных минут или секунд.

И вот, так как мы на скорости повернутые (а иначе Иншейкер бы и не завелся), решили узнать, что быстрее: вычислить самим и зашить в код число 15811200000, или же оставить вычисления на совести машины. Под «чем быстрее», конечно, не стоит понимать выигрыш нескольких наносекунд. Дело в принципе: умеют ли современные интерпретаторы яваскрипта сворачивать такие выражения еще на этапе компиляции. Мало ли когда пригодится ;)

Получился небольшой тестик (полная версия):


console.time('1 + 1 + … + 1')
var sumA = 0
for (var i = 0; i < 100000; i++)
	sumA += 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 +
			1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 +
			// and ~100 lines more
			1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1
console.timeEnd('1 + 1 + … + 1')
	
var sumB = 0
console.time('+ 2430')
for (var i = 0; i < 100000; i++)
	sumB += 2430
console.timeEnd('+ 2430')

А вот и результаты. Фаерфокс умеет это с незапамятных времен. То есть все доступные мне версии (1.5, 2.0, 3.0, 3.5, 3.6) выполнили оба цикла меньше чем за 10 миллисекунд. Хром (4.0) и Сафари (4.0) тоже свернули сумму, на сколько можно об этом судить по времени выполнения в одну миллисекунду. Оперы никакие (9.2, 9.5, 9.6, 10, 10.5) этого не умеют. Больше того 9.2 думала над первым циклом 10 секунд, 9.5, 9.6 и 10 по две секунды, а Опера 10.5 не смогла скомпилить (баг) столь длинное выражение из сумм. Эксплореры ушли не дальше Опер: ни один из них (6, 7, 8) не смог угадать маневр, и все они потратили на первый цикл по три секунды. Второй цикл все версии всех браузеров прокрутили в пределах 10-20 миллисекунд.

UPD 2010-02-02: Если в середину этой кучи суммирования вставить одну единственную переменную, то все браузеры сдаются и начинают честно считать сумму в рантайме. А Хром отказывается парсить тест, ссылаясь на переполнение стека вызовов («Maximum call stack size exceeded», баг).

Старый добрый перл умел такие оптимизации когда еще и браузеров-то не было ;)

Пуст ли объект?

2010-01-29T00:00:00-08:00

Сколько способов проверить объект (хеш) на пустоту?


var hash = {}
JSON.stringify(hash) === '{}'
Object.equals(hash, {}) // for in comparision
Object.keys(hash).length === 0
Object.isEmpty(hash) // for (var k in hash) return false

Потестим…


Object.equals = function (a, b)
{
	for (var k in a)
		if (!(k in b) || a[k] !== b[k])
			return false
	
	for (var k in b)
		if (!(k in a) || a[k] !== b[k])
			return false
	
	return true
}

Object.keys = function (s)
{
	var r = []
	for (var k in s)
		r.push(k)
	return r
}

Object.isEmpty = function (s)
{
	for (var k in s)
		return false
	return true
}

var hash = {},
	count = 10000

console.time('JSON')
for (var i = 0; i < count; i++)
	JSON.stringify(hash) === '{}'
console.timeEnd('JSON')
//=> 61ms

console.time('equals')
for (var i = 0; i < count; i++)
	Object.equals(hash, {})
console.timeEnd('equals')
//=> 49ms

console.time('keys.length')
for (var i = 0; i < count; i++)
	Object.keys(hash).length === 0
console.timeEnd('keys.length')
//=> 44ms

console.time('isEmpty')
for (var i = 0; i < count; i++)
	Object.isEmpty(hash)
console.timeEnd('isEmpty')
//=> 38ms

console.time('isEmpty inlined')
for (var i = 0; i < count; i++)
{
	for (var k in hash)
		false
	true
}
console.timeEnd('isEmpty inlined')
//=> 26ms

Тестил на самом старом интеловском маке (2 ГГц) в фаерфоксе 3.6.

Раскрашиваем яваскрипт

2010-01-28T00:00:00-08:00

Осилил, наконец, полноценную раскраску для яваскрипта. В хайлайтере уже была поддержка яваскрипта, но простенькая. А мне хотелось, чтобы все было так же, как в текстмейте, да еще с такими же точно цветами. И вот, на основе стиля sunburst с парочкой добавлений, и с полностью переделанными правилами раскраски получилась это:

А вот тестовая страничка с кучей хитрого яваскрипта, откуда и была сфоткана картиночка выше.

Для того, чтобы надежно распарсить регулярки (они внизу тестовой странички), которые очень похожи на оператор деления и на комментарии («Регэкспы и деления»), пришлось чуть-чуть пропатчить хайлайтер. Надеюсь, Иван скоро примет патч, или придумает красивый способ объяснить парсеру нужные яваскрипту тонкости.

Если вам тоже хочется такую раскраску, милости прошу: модуль с правилами javascript-tm.js и пропатченный highlight.js.

RuTils String#translify() и String#dirify() JavaScript port

2009-12-11T00:00:00-08:00

Да, это именно то, что написано в заголовке.

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


// ported from rutils.rb
;(function(){

var LOWER =
{
	"і":"i","ґ":"g","ё":"yo","№":"#","є":"e",
	"ї":"yi","а":"a","б":"b",
	"в":"v","г":"g","д":"d","е":"e","ж":"zh",
	"з":"z","и":"i","й":"y","к":"k","л":"l",
	"м":"m","н":"n","о":"o","п":"p","р":"r",
	"с":"s","т":"t","у":"u","ф":"f","х":"h",
	"ц":"ts","ч":"ch","ш":"sh","щ":"sch","ъ":"'",
	"ы":"yi","ь":"","э":"e","ю":"yu","я":"ya"
}

var UPPER =
{
	"Ґ":"G","Ё":"YO","Є":"E","Ї":"YI","І":"I",
	"А":"A","Б":"B","В":"V","Г":"G",
	"Д":"D","Е":"E","Ж":"ZH","З":"Z","И":"I",
	"Й":"Y","К":"K","Л":"L","М":"M","Н":"N",
	"О":"O","П":"P","Р":"R","С":"S","Т":"T",
	"У":"U","Ф":"F","Х":"H","Ц":"TS","Ч":"CH",
	"Ш":"SH","Щ":"SCH","Ъ":"'","Ы":"YI","Ь":"",
	"Э":"E","Ю":"YU","Я":"YA"
}

var undef, myName = 'RuTils', Me = self[myName] = 
{
	// Заменяет кириллицу в строке на латиницу. Немного специфично потому что поддерживает
	// комби-регистр (Щука -> Shuka)
	translify: function (str)
	{
		var res = []
		
		for (var i = 0; i < str.length; i++)
		{
			var c = str.charAt(i), r
			
			if ((r = UPPER[c]) !== undef)
			{
				if (LOWER[str.charAt(i+1)] !== undef)
					r = r.toLowerCase().capitalize()
			}
			else
			{
				r = LOWER[c]
				if (r === undef)
					r = c
			}
			
			res[i] = r
		}
		
		return res.join('')
	},
	
	dirify: function (s)
	{
		return s.translify()
				.replace(/(\s&\s)|(\s&\s)/g, ' and ')
				.replace(/\W/g, ' ')
				.replace(/^_+|_+$/g, '')
				.replace(/^\s+|\s+$/g, '') // trim
				.translify() // yes, second
				.replace(/[\s\-]+/g, '-')
				.toLowerCase()
	}
}

// log("Щука".trans() == 'schuka')
// log("апельсиновый сок".trans() == 'apelsinovyiy-sok')

String.prototype.translify = function ()
{
	return Me.translify(this);
}

String.prototype.trans = function ()
{
	return Me.dirify(this);
}


})();

Управление яваскриптовой памятью в энжинксе

2009-12-03T00:00:00-08:00

Пишем сценарий

UPD 2010-06-08: Внимание! С тех пор модуль оченно уложнился и точек входа в яваскрипт стало гораздо больше. Теперь каждая обертка укоренняется и связывается с нативным запросом сразу же после оборачивания.

UPD 2011-04-08: А теперь еще и устройство SpiderMonkey поменялось целиком, и поди разберись, как оно там теперь работает ;)

Когда только задумался, а не встроить ли яваскрипт в энжинкс, все казалось легко. Достаточно обернуть нативный энжинксовский запрос в объект и передать в яваскриптовый движок. А что там с ним дальше будет — не моя забота, ведь, в яваскрипте есть автоматическая сборка мусора. Оказалось все не так уж и просто. Есть как минимум три разных сценария обработки запроса, каждый из которых требует вдумчивого анализа.

Первый, и самый простой, тип. Пришел запрос, обернули его в яваскриптовый объект, передали назначенному в конфиге обработчику (обычная яваскриптовая функция, то есть замыкание) и получили ответ. Собственно все. Дальше нам не нужна ни структура запроса в памяти энжинкса, ни объект-обертка в памяти cпайдерманки. Надо только передать текст ответа дальше энжинксу и можно идти спать.

Второй сценарий посложнее. Начало такое же как и у первого. Запрос → обертка → обработчик. Дальше в развитие событий врывается самая клевая штука во всем этом яваскриптовом встраивании — сохранение запроса в глобальном объекте, чтобы его не съел уборщик. После того, как яваскрипт вернет нам управление, мы уже не сможем просто забыть об объекте-оберке. Это потому, что энжинкс и слыхом не слыхивал о сборке мусора в яваскрипте: он просто освободит память из пула запроса и отдаст ее другому запросу, а то и хуже — под данные чьих-нибудь буферов :) Следовательно, почти сразу после сохранения, объект-обертка начинает указывать в пустоту. А это значит что энжинкс упадет тоже сразу (или хуже того — не сразу) после того, как кто-то в яваскрипте попробует обратиться к сохраненному запросу. Например, кто-то решит собрать статистику по запросам и станет складывать их в какой-нибудь массив, чтобы потом за один раз посчитать к каким локациям обращались чаще всего. Тут-то все и рухнет, так как ни одного их этих запросов уже нет, а память совсем не похожа на то, что там было в момент сохранения объекта-обертки в массиве. Да, вот так закручено, люблю этот мир ;)

Третий тип запросов еще хитрее, если такое вообще возможно. Начало опять простое: запрос к энжинксу → обертка → вызов яваскрипта. И тут в развитие событий врывается вторая суперудобная и обалденная штука из мира динамических языков — замыкания. Кто-то в яваскрипте решает выполнить подзапрос или поставить таймер. При таких делах яваскрипт сохранит объект-обертку так же, как и во втором ходе событий, и нам придется решать все те же проблемы. Но само замыкание для нас никто не сохранит, а это значит, что когда подзапрос выполнится или таймер сработает, уже не будет ни объекта-обертки, ни замыкания — их всех удалит сборщик мусора — останутся просто указатели в пустоту. То есть этот тип развития событий подразумевает взаимные ссылки: яваскрипта на энжинкс, а энжинкса на яваскрипт.

О скорости

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

Энжинкс славится своей скоростью и малым потреблением ресурсов. Ну, собственно одно из другого следует. И раз он так хорош, то не стоит его совсем уж портить этим медленный SpiderMonkey (в сравнении с Google v8 и SquirrelFish Extreme — да, ключевики всё же должны встречаться в теле страницы). Так вот, если все делать по третьему варианту, то для каждого, даже, малюсенького запросика мы должны проделать кучу работы по управлению памятью. И если научиться определять, по какому пути пошел процесс, то можно изрядно сэкономить. Один момент. Второй вариант — это когда яваскрипт куда-то складывает запросы — совершенно неопределим для спайдерманки (или v8) без запуска полного цикла сборки мусора. А это просто сказочно медленно. Таким образом, мы избавляемся от одной из веток развития событий. Итак, их осталось две: простая, когда можно забить на мусоросборщик почти совсем; и сложная, когда надо везде все запомнить и всячески перестраховаться.

Запросов первого типа будет подавляющее большинство. Это могут быть запросы к кешу, к статусу какого-нибудь процесса, или запросы типа «запланируй вот это, а я пока погуляю». Поэтому, стоит научиться определять их быстро. В энжинксе, начиная с версии 0.8 (не помню точно с какой подверсии) появился счетчик ссылок на запрос. Да, как в перле — reference counting. ИМХО, просто, понятно и относительно надежно. Нам, скриптерам (а я далеко не один такой — чего только в энжинкс не страивают), этот счетчик вообще незаменим, и не только для решения этой задачи. Так вот, его-то мы и используем для разделения задачи на две, обозначенные выше. Если r->main->count больше единицы, то у нас ситуация, когда запрос будет жить дольше, чем выполняется наш обработчик. Если же равен единице, то можно на все забить и все выкинуть (ну, почти). Если меньше единицы, значит мы где-то накосячили, и стоит ждать сегфолта. Научившись быстро определять, какие задачи надо решить в конкретном случае, пора уже начать решать эти задачи.

Решаем проблемы

В первом варианте задач никаких и нет. Вновь созданный объект-обертка сразу же передается функции внутри яваскрипта в виде параметра (или инвоканта), что защищает его от уничтожения, пока эта эта функция не завершится. А завершится она как раз тогда, когда этот объект становится нам больше не нужен. Надо только не забыть выставить указатель на нативный запрос в ноль. Здесь могут быть мелкие неприятности, типа того, что спайдерманки решит начать уборку как раз между созданием объекта и передачей его в функцию. Это возможно в многопоточных приложениях и для борьбы с такими неприятностями есть функции входа и выхода в «неубираемую» область (JS_EnterLocalRootScope() и JS_LeaveLocalRootScope()). А еще, из неприятностей, могут взять и отменить защиту от сборки для параметров, переданных извне. Но это все мелочи и они решаются легко и быстро.

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

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

Итак по порядку.

1. Инвалидация указателя

Избавиться от ссылки на запрос энжинкса (это такая большущая многоярусная структура) вообще-то нельзя. То есть пока обертка плавает где-то в памяти яваскрипта, она будет ссылаться куда-то. То есть, через час после запроса мы все-таки можем вызвать r.sendHeaders(200, "Content-type: plain: encoding=utf-8"). Важно как-то понять, что этого делать нельзя и сообщить об этом скрипту. Тут все очень просто: достаточно сказать объекту-обертке, что теперь он указывает на NULL, а при каждом обращении к свойствам или методам проверять, не равен ли NULL, случайно, наш обернутый запрос. В том случае, если уже нал (нулл, нил, нуль, ноль, зеро), то выбросить исключение и вернуть пользователю красивую ошибку 500. Это, прямо скажем, очень здорово, если сравнивать с падением всего рабочего процесса, обслуживающего в этот момент тысячу—другую невинных клиентов.

Как же выставить указатель на оборачиваемый объект в NULL? Спасибо Игорю, это очень просто. Достаточно подписаться на событие уничтожения запроса, и в обработчике этого события выставить указатель в ноль. Просто, быстро и надежно, как сам нжинкс.

2. Защита от уничтожения — корни

Защитить объект от уборки (на рабочем столе и по дому, a еще разрешить ему посуду не мыть) можно как угодно легко. Можно присвоить его глобальной переменной или свойству другого защищенного объекта (global. requests. push(r)). Можно записать его в слот защищенного объекта (JS_SetReservedSlot()), а можно сделать его самого защищенным, назначив корнем (JS_AddRoot()). Сборщик мусора начинает помечать нужные еще объекты с таких корней. Глобальный объект, например, является именно таким корнем. В данном случае, мы создадим в структуре запроса энжинкса специальный указатель (jsval), который попросим назначать корнем всякий объект, на который он указывает. И, да, именно, запишем туда над объект-обертку. Все, его не уничтожат до тех пор, пока мы не уничтожим корень. А корень мы уничтожим там же, где выставляли NULL — в обработчике события уничтожения запроса. Но об этом далее.

3. Защита от уничтожения — слоты в корнях

Защитить функции (они же замыкания, или, почти, как функторы) можно теми же методами, что и сам объект-обертку. Собственно, год назад я так и поступил: добавлял для обработчика тела новый корень, а потом его удалял. Теперь же добавились таймеры и подзапросы. Клепать корни для всех этих товарищей в глобальном пространстве не хочется, так как запросов будут тысячи. Нам хватит нагрузки от создания корней для самих этих тысяч запросов. К тому же создание корня (как сейчас видно из исходников спайдерманки) — это добавление ключа в хеш по значению указателя. И чем больше мы туда запихнем, тем хуже для нас. Кстати, как раз для того, чтобы разгрузить этот хеш мы тут и затеяли все эти выкрутасы с разделение запросов на два типа, из чего теперь получился целый здоровенный пост (вы читать не устали?).

Так вот, вместо корней лучше используем слоты. Они тоже не быстрые (судя по исходникам спайдерманки там нет ничего быстрого), но это хотя бы не поиск в таблице из тысяч записей. А еще слоты хороши тем, что их можно потом не стирать. То есть объект-обертка когда-нибудь будет убран а вместе с ним и все эти функции со своими локальными и замкнутыми переменными. Для v8 это вообще подарок с его поколениями переменных. Этот подход позволяет обработчику запроса энжинкса отцепить объект-обертку и одним махом избавиться ото всех его паразитов.

4. Освобождение памяти

Правильно отцепить объект-обертку — дело не хитрое. Отцепим его там же, где помечали его пустым, в обработчике уничтожения запроса. Ах, как же я был рад, когда нашел его в исходниках энжинкса! Тут достаточно вызвать JS_RemoveRoot() и все в порядке.

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

Послесловие

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

Где исходники? Они — на гитхабе. Скоро поставлю красивые гитхабовские ссылочки на строчечки (обожаю гитхаб!).

Ого, а хотел в пару абзацев уложиться.

Немного о работе

2009-11-14T00:00:00-08:00

Наш любимый коктейльный сайт — и, в частности, я сам — нуждается в ежедневной хорошо оплачиваемой поддержке людей, программирующих на яваскрипте. Мы, даже, сделали секретную страничку специально для них. Она маленькая и очень оптимистичная ;)

Статистика от Google Analytics для amCharts через XSLT

2009-10-26T00:00:00-07:00

Сделал новую статистику посещаемости для Иншейкера. Рисуется она, как и прежняя, с помощью amCharts. Но теперь все действия по выкачиванию и преобразовыванию данных выполняются простым bash-скриптом и стандартной утилитой xsltproc. Думаю, bash и xsltproc есть у всех.

Дело делают всего два скрипта: login.sh и update.sh. Первый логинится в гугл, используя мыло и пароль из переменных окружения (нечего им в коде делать). Гугл в ответ отдает авторизационный токен, который, согласно документации, можно использовать около двух недель. Второй скрипт выкачивает статистику в формате Atom, расширенном гуглом. На этом программирование на баше заканчивается, и начинается XSLT.

Скрипты со стилями положил на гитхаб в analytics-xslt.

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

GitX

2009-10-10T00:00:00-07:00

Выбросил дорогущий Versions.app вслед за эсвээном. Теперь обожаю бесплатный GitX. Thanks a lot Pieter!

Array#sort()

2009-09-02T00:00:00-07:00

Так как во время сортировки массива (а также обращения) яваскрипт не создает его копию, сортировать числа можно очень быстро. И это здорово — но скучно.

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

Многообразие

Предположим, что нам нужно отсортировать массив объектов {x: число, y: число, z: число} сначала по x, потом по y потом по z. Есть как минимум три очевидных способа.

Каскадный:


array.sort(byZ).sort(byY).sort(byX)

Так можно делать, когда интерпретатор поддерживает «stable sort» и сортировки не связаны (тут так и есть).

Одиночный:


array.sort(function (a, b) { return byX(a, b) || byY(a, b) || byZ(a, b) })

UPD 2010-01-12: Конструкция хитрая, но работает. В яваскрипте (и еще, как минимум, в перле, руби, питоне и Си) оператор || не приводит аргументы к булеву типу, что позволяет клеить такие цепочки хоть до посинения.

Раскрытый (он же «inlined»):


array.sort(function (a, b) { return a.x - b.x || a.y - b.y || a.z - b.z })

В хороших и зрелых браузерах они все работают быстро и сортируют одинаково правильно (ага!). Но в нехороших браузерах, что-то подтормаживает, а что-то даже и не сортирует.

Кросбраузерность и скорость

Каскадный способ очень красив и даже не очень тупит, но не работает в Опере (включая зарелизенную десятку) и в Хроме (включая альфы четверки, они об этом знают). В третьем фаерфоксе, во всех ИЕ, а также в сафари три типа сортировки дают правильный порядок элементов. То есть придется париться с обертками.

Тесты показывают, что одиночный sort() почти в два раза быстрее каскадного. Раскрытый — еще быстрее раза в полтора-два-три (даже в хроме с его мегаумным В8). Забавно, что каскадный и одиночный способы сортировки дают одинаковые результаты в ИЕ 6 и 7 (в восьмом картина такая же как и в других браузерах).

Тестим

var messed =
[
	{x: 2, y: 0, z: 0},
	{x: 2, y: 0, z: 1},
	{x: 2, y: 0, z: 2},
	{x: 2, y: 1, z: 0},
	{x: 2, y: 1, z: 1},
	{x: 2, y: 1, z: 2},
	{x: 2, y: 2, z: 0},
	{x: 2, y: 2, z: 1},
	{x: 2, y: 2, z: 2},
	
	{x: 0, y: 0, z: 0},
	{x: 0, y: 0, z: 1},
	{x: 0, y: 0, z: 2},
	{x: 0, y: 1, z: 0},
	{x: 0, y: 1, z: 1},
	{x: 0, y: 1, z: 2},
	{x: 0, y: 2, z: 0},
	{x: 0, y: 2, z: 1},
	{x: 0, y: 2, z: 2},
	
	{x: 1, y: 0, z: 0},
	{x: 1, y: 0, z: 1},
	{x: 1, y: 0, z: 2},
	{x: 1, y: 1, z: 0},
	{x: 1, y: 1, z: 1},
	{x: 1, y: 1, z: 2},
	{x: 1, y: 2, z: 0},
	{x: 1, y: 2, z: 1},
	{x: 1, y: 2, z: 2}
]

var sorted =
[
	{x: 0, y: 0, z: 0},
	{x: 0, y: 0, z: 1},
	{x: 0, y: 0, z: 2},
	{x: 0, y: 1, z: 0},
	{x: 0, y: 1, z: 1},
	{x: 0, y: 1, z: 2},
	{x: 0, y: 2, z: 0},
	{x: 0, y: 2, z: 1},
	{x: 0, y: 2, z: 2},
	
	{x: 1, y: 0, z: 0},
	{x: 1, y: 0, z: 1},
	{x: 1, y: 0, z: 2},
	{x: 1, y: 1, z: 0},
	{x: 1, y: 1, z: 1},
	{x: 1, y: 1, z: 2},
	{x: 1, y: 2, z: 0},
	{x: 1, y: 2, z: 1},
	{x: 1, y: 2, z: 2},
	
	{x: 2, y: 0, z: 0},
	{x: 2, y: 0, z: 1},
	{x: 2, y: 0, z: 2},
	{x: 2, y: 1, z: 0},
	{x: 2, y: 1, z: 1},
	{x: 2, y: 1, z: 2},
	{x: 2, y: 2, z: 0},
	{x: 2, y: 2, z: 1},
	{x: 2, y: 2, z: 2}
]

function byX (a, b) { return a.x - b.x }
function byY (a, b) { return a.y - b.y }
function byZ (a, b) { return a.z - b.z }
function single (a, b) { return byX(a, b) || byY(a, b) || byZ(a, b) }
function combined (a, b) { return a.x - b.x || a.y - b.y || a.z - b.z }

var m = messed.slice()
console.time('multiple')
for (var i = 0; i < 1000; i++)
{
	m.sort(byZ),
	m.sort(byY),
	m.sort(byX)
}
console.timeEnd('multiple')

var s = messed.slice()
console.time('single')
for (var i = 0; i < 1000; i++)
{
	s.sort(single)
}
console.timeEnd('single')

var c = messed.slice()
console.time('combined')
for (var i = 0; i < 1000; i++)
{
	c.sort(combined)
}
console.timeEnd('combined')

Кастомные события

2009-07-27T00:00:00-07:00

Во всех браузерах, кроме сами знаете какого, можно играться с событийным движком браузера, как душе угодно. Гибкость дается наравне с нативными событиями: можно называть их как угодно, настраивать всплываемость и отменяемость, добавлять свои свойства и методы. Такие трюки удобны для создания виджетов со своей моделью событий; и для имитации полезных событий браузера там, где их не поддерживают (типа, onready или onhashchanged); а еще для расширения базовой логики приложения кем-то третьим (например, события hide/show для отключения анимации в скрытых нодах); да мало ли для чего еще могли бы пригодиться свои собственные события. Но не в IE.

Событийную модель можно реализовать на яваскрипте, и воспользоваться всеми этими прелестями. Но только не для нод в дереве документа, а для простых обектов (тут ничего нового — очередная реализация интерфейса EventTarget). А ведь хочется вешать обработчики именно на ноды, документ, окно… на аяксовый запрос, наконец!

Решили научить IE распространять по документу выдуманные типы событий и посмотреть, что из этого выйдет. У этой задачи есть простое решение: достатачно на яваскрипте повторить движок браузера для подписки/отписки и распространения событий. Код получается интересный, так что это решение вполне приемлемо. С другой стороны, зачем дублировать то, что уже реализовали нативно, а значит быстро. Надо всего-то чуть-чуть допилить браузер.

В этом случае можно выбрать некоторое событие как транспорт. Это событие должно по умолчанию всплывать и не иметь никаких встроенных обработчиков. Поискав немного, нашел oneditfocus. Мы его нигде не используем, а по параметрам он подходит как раз. На нем, пока, и остановился — самое сложное позади. Далее дело техники: научить addEventListener и dispathEvent понимать, какие события обрабатывать как есть, а какие оборачивать в oneditfocus. Здесь тоже ничего сложного: ищем событие в списке нативных и, если не нашли — оборачиваем.

В итоге, за наши труды получаем такой код, без проблем работающий в IE 6-7-8:


window.addEventListener("ready", function (e) { alert("got an event type " + e.type) }, false)
var ready = document.createEvent("Event")
ready.initEvent("ready", true, true)
window.dispathEvent(ready)
//=> got event type ready

Конечно, IE не поддерживает ни addEventListener, ни dispathEvent, но их поддержку нетрудно добавить.

UPD: Дин Эдвардс сделал работающую модель событий для IE в своей библиотеке Base2. Она показалась мне громоздкой и сумбурной. Да и стиль кодирования Дина меня тоже не особо прет: все эти точки с запятой, бее ;)

Закрывающий крестик

2009-07-15T00:00:00-07:00

Во всплывающем окошке принято делать закрывающий крестик. Его можно сделать картинкой. Можно — буквой «X». А можно заюзать символ «×», который красивый и отлично видимый везде.

Как-то так:

Вы все еще пишете  ? — Тогда мы идем к вам!

git filter-branch

2009-07-11T00:00:00-07:00

Завтра переписывал историю. Понравилось.

Напишу тут немного про git filter-branch потому, что ничего внятного ни на русском, ни на аглицком нагуглить не удалось. Повторять мои ошибки вам будет дороговато, так как более менее сложное отфильтровывание истории — штука скучная и затяжная.

Не забудьте забекапить папочку .git из вашего репозитория.

Раздвоение

Если у вас больше одного бранча (а как же иначе?), то, судя по названию команды, отфильтровать получится историю только текущего бранча. И вы получите раздвоение репозитория. А это значит, что лучше всего сначала смерджить все в мастер, и только потом начинать творить все эти противоестественные вещи. Даже больше. Если вы работате в команде (а как же иначе?), то важно всем все смерджить в свои мастеры, а потом смерджить все мастеры у кого-то одного, и только потом запускать git filter-branch на его компе. Иначе, получив новый репозиторий с абсолютно иными именами коммитов, вы замучаетесь мерджиться друг с другом. Еще хуже то, что новая история будет только у того, кто ее себе смастерил. Остальные перцы (включая боевые сервера, если вы храните на них репу целиком) получат из новой истории только последний комит, а впридачу всю его новую историю в качестве багажа. Повторим. Сначала слейте все в один репозиторий, потом максимально упростите его структуру, а потом уже издевайтесь над ним. В случае, если не удается смердить все в мастер, запустите фильтр сначала в мастере, а потом в каждом из оставшихся бранчей. Чтобы не тратить время на переписывание тех коммитов, которые общие у мастера и у текущей ветки, воспользуйтесь опциями для выделения отрезка истории, описанными в руководстве. Мужайтесь. После того, как вы перелопатили историю на одном из компьютеров, знайте, что это практически новый репозиторий. А это значит, что его надо всем заново склонировать (не забудьте про боевые и сборочные сервера). Чтобы быстрее заливалось, запустите git gc --aggressive, и гит аккуратненько уложит все объекты в один файл.

Редактируем авторов

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

Чтобы исправить эту досадную ошибку и заменить логин в системе на свое имя, а кривой адрес — на прямой, запускайте:

git filter-branch --env-filter \
'
if [ "$GIT_AUTHOR_NAME" = "user123" ];
then
  export GIT_AUTHOR_NAME="User Name"
fi

if [ "$GIT_AUTHOR_EMAIL" = "user123@host.local" ];
then
  export GIT_AUTHOR_EMAIL="user@name.ru"
fi
'

Выбрасываем мусор

Как-то давно, мы решили хранить псдшники и видео в репозитории. Наверное заболели. Вот лекарство от файлов *.flv, *.mp3 и *.psd (нужное подчеркнуть):

git filter-branch --tree-filter 'find . \( -name "*.flv" -o -name "*.mp3" -o -name "*.psd" \) -exec rm -rf {} \;'

Если не получается

Повторно запускать фильтр гит откажется, предупреждая о том, что придется затереть бекап. Вылетит со словами «Cannot create a new backup. A previous backup already exists in refs/original/». Настоять на своем можно, указав ключ -f или вручную стерев папочку refs/original/. Кстати, да, всего несколько файликов в этой папочке и есть весь «бекап». Дело в том, что гит очень умный, и он не удалит старое пространство объектов, пока вы его явно об этом не попросите (git gc --prune=now). Именно поэтому, пока в папке refs/ есть ссылки на старое дерево, ничего не удалится. В общем, стандартный сборщик мусора, знакомый нам по яваскрипту.

Если вы переписывали историю для того, чтобы выбросить из нее мусор, а по окончании мучений репа стала даже чуть больше, не отчаивайтесь. Дело как раз в бекапе. Чтобы стопроцентно очистить репозиторий, надо склонировать этот репозиторий в другое место и запустить там git gc --prune=now. Не очень красиво, но так официально советуют делать.

Знаю по опыту, что гит ошарашивает своей гибкостью и многословием. Поэтому — спрашивайте, если что-то не получается. Было бы мне у кого спросить, замучал бы его совсем :)

Многоточие

2009-07-08T00:00:00-07:00

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

Красивый пример можно посмотреть на нашем восхитительном Иншейкере в разделе событий.

Белый фон

2009-07-08T00:00:00-07:00

Нужна была консольная утилита добавляющая в png-файл поле с белым цветом фона по умолчанию (bKGD chunk). Было это нужно, чтобы при распечатке коктейлей в IE6 не было противного серого фона (AlphaImageLoader при печати не пашет). Изобретать велосипед не хотелось, поэтому нашел статью, где чувак подробно рассказывает, как добавить подобную функциональность в программу на C#. Самое полезное там — это объяснение того, что чанк с цветом фона можно добавить прямо перед первым чанком с данными. Но у него все на микрософтовском сишарпе, а мы-то сидим на маках с линуксами. Погуглив еще минутку, нашел и остальное. Все, что связано с PNG, как ни странно, вполне доступно изложено на W3C: и про фон, и про формат вообще.

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

UPD (02.12.2009): если обработать один файл дважды, то туда попадут два чанка с бекграундом, от этого картинка сломается в IE. Все дело в этих байтах: 00000006624B474400FF00FF00FFA0BDA793, сотрите их и все будет норм :) А еще утилитка composite (из ImageMagick) добавляет свой чанк с бекграундом — будте осторожны, не сломайте картинки (как сломал я)!

Блог Паши Корнилова

2009-07-08T00:00:00-07:00

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

Рассказывает про PNG. Являет скрытое. Выступает. Снова выступает. Фигачит Jotsky.com. Пишет про меня.

С днем рождения, Паша!

Весь интерфейс в одной картинке

2009-07-08T00:00:00-07:00

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

Все бы хорошо, если бы правка таких упакованных файлов не была жутким геморроем. Нужно же сначала сохранить измененную картинку в PNG, потом вставить новую версию в спрайт. Если она на свое место не помещается, то весь спрайт надо переделывать. А это значит, что и часть CSS тоже нужно обновлять: лазить по спрайту с нереальным зумом и вычислять позиции каждой картиночки. Кошмар.

Потом еще добавляются муки с повторяющимися фонами. Они бывают вертикальные и горизонтальные, ограниченные и безграничные, полупрозрачные и нет. Бардак.

Ну и напоследок. IE6 не поддерживает смещение полупрозрачных фонов, хакнутых через AlphaImageLoader. Значит, в нем все это вообще невозможно. Абзац.

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

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

Главную проблему (гемор при обновлении) решили хитро: перенесли весь дизайн иконок, кнопок, плашек и других элементов интерфейса со всеми слоями в один файл. Теперь ни дизайнеру, ни верстальщику не надо париться в поисках актуальной версии какой-нибудь зеленок кнопки с белыми буковками. Когда надо обновить спрайт мы просто сохраняем его как картинку. Затем, чтобы помочь верстальщику с вычислением позиций, мы разделили файл на квадраты по 50 пикселей. Каждый элемент спрайта занимает свой квадрат (или несколько квадратов) и картинка начинается в левом верхнем углу этого квадрата. Таким образом смещение фона можно узнать на глаз, вообще не открывая фотошоп.

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

С эксплорером обошлись наиболее жестоко: забили на него. Не совсем, конечно, но выкручиваться со скриптованием всех элементов ради полупрозрачного фона не стали. Просто сделали восьмибитную версию спрайта для шестого ИЕ. Получили отсутствие полупрозрачных фонов с градиентами, а также ожидаемые зазубренные края, как в девяностые. А чего еще ждут от этого браузера его пользователи? К моменту запуска сайта, шестой ИЕ составлял всего 12% аудитории, и мы решили, что они ничего не заметят, а мы сэкономим кучу времени и эмоций для более перспективных задач.

И вот что получилось (темный фон для наглядности).

24 бита (16,2 Кб):

8 бит (7,3 Кб):

Все издевательства выносил сайт РитейлСтарса. Там всего две картинки: спрайт отвечает за интерфейс, а джипег — за фон. Все максимально облегчено. Даже фотки, кстати, грузятся по мере пролистывания.

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

IE в VirtualBox

2009-06-10T00:00:00-07:00

Для тестирования сайтов в ИЕ использую VirtualBox. На новых маках виртуалбокс просто летает (UPD: на самых старых интеловских — тоже) и всего за три секунды восстанавливает и сохраняет состояние машины. То есть эксплорер стал просто еще одиним браузером для мака, в котором можно тестить все без тормозов.

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

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

Вот что получилось: .

Да, после серьезных изменений в верстке, всегда прогоняю эти 12 браузеров (Safari 4, Chromium 3, Firefox 2, 3, 3.5, IE 6, 7, 8-8, 8-7, Opera 9.2, 9.5, 9.6, 10). А если будут силы, то еще и в виндовых версиях хороших браузеров.

Вот мой набор приложений с иконками: virtualbox-ie678-apps.zip. Чтобы эти аппы запускали ваши виртуальные машины, необходимо в файликах Contents/MacOS/VirtualBoxVM (простые bash-скрипты) заменить все UUID на ваши. Эти уиды можно посмотреть через VBoxManage list vms или с помощью команды ps -A | grep startvm, предварительно запустив интересующие машины.

Округляем

2009-06-05T00:00:00-07:00

Сколько способов отбросить дробную часть числа есть в яваскрипте?


var t = 36.6
Math.floor(t)
parseInt(t)
t - t % 1
t & -1
+/^-?\d+/.exec(t)
+t.toFixed()
t >> 0
//=> 36

UPD 2009-09-23: Александр Тармолов подзсказал метод Number#toFixed(), огромное ему спасибо — буду тестить :)

UPD 2010-01-14: придумалось еще t >> 0

Для отрицательного числа floor() подходит не очень, а & -1 — для чисел больше десяти миллионов. Но в том-то и прелесть, что всегда можно выбрать подходящий вариант.

Тестим

Интересно, а как сильно тормозит каждый из вариантов?


(function(){
console.time('empty')
for (var i = 0.5; i < 100000; i++);
console.timeEnd('empty')
})();
//=> 1ms


(function(){
var f = Math.floor
console.time('floor')
for (var i = 0.5; i < 100000; i++)
	f(i)
console.timeEnd('floor')
})();
//=> 1ms (round() и ceil() дают то же)

(function(){
console.time('Math.floor:Math.ceil')
for (var i = 0.5; i < 100000; i++)
	i >= 0 ? Math.floor(i) : Math.ceil(i)
console.timeEnd('Math.floor:Math.ceil')
})();
//=> 36ms


(function(){
var f = Math.floor, c = Math.ceil
console.time('var floor:ceil')
for (var i = 0.5; i < 100000; i++)
	i >= 0 ? f(i) : c(i)
console.timeEnd('var floor:ceil')
})();
//=> 1ms


(function(){
console.time('parseInt')
for (var i = 0.5; i < 100000; i++)
	parseInt(i)
console.timeEnd('parseInt')
})();
//=> 162ms


(function(){
var f = parseInt
console.time('var parseInt')
for (var i = 0.5; i < 100000; i++)
	f(i)
console.timeEnd('var parseInt')
})();
//=> 1ms


(function(){
console.time('%')
for (var i = 0.5; i < 100000; i++)
	i - i % 1
console.timeEnd('%')
})();
//=> 3ms


(function(){
console.time('&')
for (var i = 0.5; i < 100000; i++)
	i & -1
console.timeEnd('&')
})();
//=> 1ms


(function(){
console.time('>>')
for (var i = 0.5; i < 100000; i++)
	i >> 0
console.timeEnd('>>')
})();
//=> 1ms


(function(){
var rex = /^-?\d+/
console.time('toFixed')
for (var i = 0.5; i < 100000; i++)
	+i.toFixed()
console.timeEnd('toFixed')
})();
//>>> 83ms


(function(){
console.time('rex')
for (var i = 0.5; i < 100000; i++)
	+/^-?\d+/.exec(i)
console.timeEnd('rex')
})();
//=> 1100ms


(function(){
var rex = /^-?\d+/
console.time('cached rex')
for (var i = 0.5; i < 100000; i++)
	+rex.exec(i)
console.timeEnd('cached rex')
})();
//=> 1111ms

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

Ах, да, результаты для фаерфокса 3.5.7 на Core 2 Duo 2,66 ГГц 6 Мб.

Юнит-тесты для nginx

2009-05-18T00:00:00-07:00

UPD 2011-04-08: Внимание! Всё это старье, и лежит здесь только для истории.

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

df и du

2009-05-07T00:00:00-07:00

UPD: Как сделует из объяснения citrin'а, место освободилось потому, что пока техподдержка тянула с ответом, сервак перезагрузился и высвободил безымянное пространство. Все починилось само, а вовсе не от того, что мастерхост что-то сделал. Они, конечно, не виноваты, и мне очень стыдно ;) Но даже не знаю, радоваться такому молчанию или нет :)

Люблю поочищать сервак от всего лишнего. Делаю это с помощью ручного хождения по директориям и запуска в них du -xh --max-depth=1.

И тут недавно прошерстил весь сервер, а места, по показаниям df, освободилось — чуть. Запустил du в корне: 1.4Гб. В свою очередь df все так же показывает показывает 3.0Гб. Именно эти завышенные показания df используются мастерхостом в качестве оценки занятого места на сервере.

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

Через час показания сошлись на 1.7Гб (за это время сервер действительно прибавил 300 метров), но от мастерхоста объянений так и не дождался. Интересно, кто скушал наше место? И если бы оно так совсем кончилось на сервере, нас бы отрубили или сначала удалили бы свою темную материю?

Mac OS Leopard + launchd + VBoxHeadless

2009-04-28T00:00:00-07:00

Вот и мы решились, наконец, поиграть в виртуализацию. Поставили Ubuntu в VirtualBox на леопарде, а в убунте настроили OpenVZ. Все это крутится на мак мини с 4-мя гигами оперативы. Мак тут, конечно, не особо нужен, но покупать здоровенный сервак или проводастый писюк совсем не хотелось.

Все это добро (Mac mini MB463LL/A, Ubuntu 8.04, VirtualBox 2.2, OpenVZ kernel 2.6.24-23-openvz) завелось с полоборота. Линукс совершенно не напрягает мак мини своим присутствием. Из отведенного гига для виртуальной машины реально расходуется чуть больше 300. Мак летает, линукс летает, контейнеры тоже летают. Все прекрасно. Пока не настает время перезагружаться.

Ясное дело, после загрузки виртуалбокс не запускает никакие машины. Это грустно, но не смертельно. В комплекте виртуалбокса есть консольная утилита для запуска виртальных машин без привязки к пользовательскому интерфейсу. Пользоваться ей очень просто: VBoxHeadless -startvm $VMID. Идентификатор виртуальной машины узнать нетрудно: эта команда покажет подробный список машин VBoxManage list vms.

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

Для начала скажу, что мы запускаем VBoxHeadless с помощью встроенного в макос launchd. Он умеет перезапускать процесс, если тот накернился. launchd умеет выдерживать паузы, запускать задания с определнным интервалом, при подключении диска. Да он, вообще, много чего умеет. В этом ему близок полюбившийся мне UpStart.

Чтобы виртуальная машина запускалась при старте, необходимо положить следующий скрипт в папку /Library/LaunchDaemons:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>RunAtLoad</key>
  <true/>
  <key>KeepAlive</key>
  <dict>
    <key>SuccessfulExit</key>
    <false/>
  </dict>
  <key>Label</key>
  <string>ubuntu-openvz</string>
  <key>ProgramArguments</key>
  <array>
    <string>VBoxHeadless</string>
    <string>-startvm</string>
    <string>XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX</string>
  </array>
  <key>Nice</key>
  <integer>3</integer>
  <key>GroupName</key>
  <string>staff</string>
  <key>UserName</key>
  <string>someuser</string>
</dict>
</plist>

Вместо иксов нужно подставить ид машины, которую будем запускать. И еще надо сменить владельца этого файла на рута. Назвать файл можно как вам удобно, но принят формат домен.задача. Например, ru.company.virtualbox.ubuntu-vz.

А проблема со свзякой ланчд+виртуалбокс в том, что при перезагрузке ланчд шлет процессу виртуалбокса простой SIGTERM. После чего виртуальная машина ресетится и отключается. Состояние линукса внутри виртуалбокса не сохраняется никаким образом. Линукс даже не узнает, что машина скоро погаснет.

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

Сначала заменим в ланчдемонском конфиге эти строки:

  <array>
    <string>VBoxHeadless</string>
    <string>-startvm</string>
    <string>XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX</string>
  </array>

на эти:

  <array>
      <string>/usr/local/bin/vboxheadless-wrapper</string>
      <string>b25ac594-9b5e-4ac7-bc38-c105947bf2ad</string>
  </array>

Внутри vboxheadless-wrapper написано следующее:

#!/usr/bin/env perl
use strict;

my ($vm) = @ARGV;
our $stopping = 0;

$SIG{TERM} = sub { stop($vm); };

start($vm);
exit 0;


sub start
{
	my $vm = shift;
	# waiting for VB drivers to load
	sleep 1 while scalar(grep { /org.virtualbox/ } `/usr/sbin/kextstat`) < 3;
	my $res = system "/usr/bin/VBoxHeadless -startvm $vm";
	# sleeping until exit()
	unless ($res) { sleep while 1 };
}

sub stop
{
	return if $stopping;
	$stopping = 1;
	my $vm = shift;
	exit system "/usr/bin/VBoxManage controlvm $vm savestate";
}

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

Все это на самом деле очень просто. Но эта конструкция все равно не заработала. А из-за того, что ланчд запускал наш скрипт еще до того, как ядро макоса загружало дрова виртуалбокса. Как раз от преждевременного запуска нас спасает строка sleep 1 while scalar(grep { /org.virtualbox/ } `/usr/sbin/kextstat`) < 3;. Тут перл ждет, пока не загрузится хотя бы три драйвера с именем, содержащим org.virtualbox. В моем случае это были следующие кексты: org.virtualbox.kext.VBoxDrv, org.virtualbox.kext.VBoxUSB, org.virtualbox.kext.VBoxNetFlt.

После этого, виртуальной машиной можно управлять с помощью ланчд:

launchctl start ubuntu-openvz
launchctl stop ubuntu-openvz

Эх, люблю потанцевать! Особенно проникновенными считаю танцы с бубном :)

Самый кайф в том, что можно подключиться по ссш, запустить, например, ping или ab, перезагрузить железку, и процесс пойдет дальше. При этом ab, пережив перезагрзку компа, не сообщил ни об одной ошибке. Состояние виртуальной машины сохраняется за 4 секунды. Восстанавливается — за 3. Восстановить виртуальную машину можно уже на другом компе, не потеряв ни одного соединения. Горячий перенос, кстати, умеет как сам виртуалбокс, так и опенвз внутри него :)

Удачной виртуализации!

Стокгольм

2009-04-23T00:00:00-07:00

На сайте мастерхоста написано, что у них канал до Стокгольма шириной в 10 Гбит/с. Для сравнения скорость связи с Голден-Телекомом всего 1 Гбит/с. То есть у них канал до Швеции (из Зеленограда) в десять раз шире, чем до отдельно взятого провайдера в Москве. В сумме-то все равно шире до Москвы, но до посетителя сайта трафик, скорее всего, пойдет по проводам только одного из провайдеров.

Пошел проверить, как открывается сайт их партнера в Швеции, и… моментально! Если они не схитрили, поставив зеркало у себя в датацентре, то это просто прекрасно (тот, кто хостился в Америке, поймет).

Это заставило провести еще более глубокое расследование (sic!) и протестить скорость из дома (net-by-net/utech) и из офиса (RMT) до этого чудо-сервера в Швеции. Получилось 1,8 Мбит/с из дома и 5,3 Мбит/с из офиса. До сервера програмики для сравнения: 6,4 Мбит/с и 3,5 Мбит/с. То есть из офиса быстрее связь с далеким шведским сервером, чем с сервером в подмосковном мастерхосте.

После этого, решил протестить линк из самого мастерхоста. С сервера програмики (VPS) Швеция открывается просто молниеносно: 35 Мбит/с (сам с себя сервер сливает на скорости 200 Мбит/с).

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

Такая возможность сама по себе очень романтична: мы живем в России, они — в Голландии, и мы можем делать дело бок о бок, не замечая границ, благодаря простому проводу. Мир становится меньше. Скорей бы уж и мгновенная телепортация изобрелась…

UPD: Ах, да. Тестил в час ночи по Москве.

Дырявая песочница

2009-04-09T00:00:00-07:00

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

Добиться такой изоляции несложно. Достаточно вызвать evalcx(), передав первым параметром код, который нужно выполнить под присмотром. Функция вернет результат выполнения, как обычный eval(). Такой способ подходит, если созданное в результате окружение нас не интересует. Можно, конечно, вернуть из кода глобальный объект и возиться уже с ним. Но это не наш метод.

Для того, чтобы создать изолированное пространство имен, нужно вызвать evalcx() с пустой строкой в качестве первого параметра: evalcx(""). Так мы получим полностью независимое окружение со своим набором глобальных переменных и классов. Полученный таким хитрым способом объект нужно передавать вторым параметром в evalcx(), а впоследствии использовать повторно или с пользой проанализировать.

Если выполнить evalcx('String.abc = 123', {}), то код сможет изменить наш объект String (или любой другой), а этого делать не следует.

Штука хитрая и полезная, но, конечно, не панацея. Так что использовать для запуска чего-то чужого не рекомендую.

Конкуренты

2009-04-03T00:00:00-07:00

За последние три месяца обнаружил на просторах интернета два проекта по снабжению нжинкса яваскриптом. Один из энтузиастов пошел схожим путем и решил встроить SpiderMonkey. Другому, видимо, ближе C++, и он решил обратиться к прекрасному созданию гугла — движку V8. Оба разработчика скоро разочаровались в своих проектах (насколько можно судить по интенсивности коммитов). Но мне важным показалось другое.

Задачей, которую поставили себе эти ребята, стала поддержка запуска нжинксом яваскриптовых файлов (например, встроенных в HTML-код). В принципе, это было бы интересно, если бы нжинкс уже не поддерживал перл с его прорвой библиотек. А найти применение клону ПХП, но на яваскрипте (учитывая, что серверные программеры его просто ненавидят) и без библиотек не ручаюсь совсем.

UPD: Был неправ, исправляюсь. Второй парень (японец, скрывающийся под псевдонимом rykomats) оказался не так прост. Он тоже сделал небольшую обертку к структуре запроса, и передает пришедший запрос в функцию из заранее загруженного яваскрипта (на сколько можно понять этот кошмарный C++). Такая конфигурация работает быстро и понятно.

Согласен, обе технологии (spidermonkey & nginx) просто сахарные, и, полюбив их по отдельности, начинаешь подумывать об объединении возлюбленных. Но зачем же все так пошло?

Кстати говоря, если сделать на яваскрипте не обработчик (хендлер) локейшна, а фильтр, то можно распрекрасно и быстро реализовать, например, легко расширяемый клон SSI, но на яваскрипте. А можно встроить пакер Дина Эдвардса, и минифаить яваскрипт налету. Можно даже простенький шаблонизатор для джейсона накатать. Но вот делать простую запускалку яваскрипта — этого понять невозможно.

UPD2: Вот еще дядька американец встраивает эрланг. Хакеры нжинкса всех стран, обединяйтесь! :)

Сказочно медленный className

2009-04-03T00:00:00-07:00

Как выяснилось, лучше выполнить кучу предварительных проверок в яваскрипте, и только потом, при крайней необходимости, трогать className. Дело в том, что это свойство затратно не только записать, но и прочитать. Тормозить будет даже в том случае, когда фактическое значение не меняется (node.className = node.className).

Почему так происходит, легко понять из кода, которым обвязывается каждое обращение к свойству оборачиваемого объекта (в данном случае обернут элемент DOM-дерева). Такая обвязка, как правило, состоит из внушительного куска кода, который выясняет, какое именно свойство вызвано, а потом ищет, как это свойство прочитать или записать. Поиск чаще используется простой, перебором. Затем, управление передается дальше. Наверняка, это будет вызов некоторого метода. Метод сделает что-то свое (возможно, просто возвратит строку, а может и другие методы повызывает). И напоследок, результат работы метода необходимо обернуть в подходящий яваскриптовый объект. В нашем случае это строка. А строку еще надо создать, выделить память под символы (предварительно посчитав, сколько байт нужно), скопировать в нее данные, вернувшиеся из метода (почти наверняка, перекодировав в UTF-16), и только потом возвратить управление яваскрипту.

Пример грустный от того, что в нем перечислена куча действий, от которых можно отказаться. Однако, отказаться от них очень непросто, и это потребует от разработчиков браузера много терпения и желания сделать людям быстро. Такие оптимизации как раз ведут к тому, что называется быстрым ДОМом (faster DOM).

Мы можем немного помочь разработчикам браузеров, если научим свою страничку кешировать значение className. Таким образом, этот код в фаерфоксе будет быстрее:


cache = 'a'
cache = className = cache + ' b'

чем этот:


className += ' b'

Когда появится свободное время, дополню пост парой бенчмарков, а пока, остается верить мне на слово ;)

Идет кругом голова…

2009-03-24T00:00:00-07:00

IE 6, 7, 8 как 8, 8 как 7.
Фаерфокс 2, 3, 3.5.
Опера 9.2, 9.5, 9.6, 10.0.
Сафари 3, 4, мобайл.
Хром 1, 2.

И умножим на Виндоуз, Линукс и Мак Ос. И добавим Виндоуз Мобайл, айФон Ос, Симбиан и Андроид.

Искренне желаю удачи Джону в рубке гордиева узла.

Вредный гиф

2009-03-06T00:00:00-08:00

В нашем новом проекте очень много графики, а именно больших фотографий. Раньше так делать было нельзя — большие изображения магически тормозили всю страницу, но теперь эти времена ушли. Уши, но не для винды. Если задать фоном у достаточно большой картинки маленький анимационный, то под виндой одно ее спокойное лицезрение будет стоить вам 100% ресурсов процессора. У нас такое наблюдалось в IE7 и FF3.

— Что-то у тебя сайт медленно работает!
— Так это картинки тормозят, картинки…

Гиф тот показывал индикатор загрузки — картинки-то большие ;)

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

GitHub — моё всё

2009-03-01T00:00:00-08:00

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

UPD 2011-01-10: теперь и весь блог лежит на гитхабе.

О минифае

2009-02-09T00:00:00-08:00

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

Чтобы избежать всех этих неэффективностей, можно выработать такой стиль программирования, при котором код и жмется хорошо, и исполняется быстро ;)

Можно начать с кеширования значений, которые часто используются в функции, но их получение из внешнего мира затратно. Здесь налицо выгода при сжатии: минифаер поймет, что переменная локальная и сожмет ее имя в один символ. Интерпретатор при исполнении такого кода будет точно знать, что используется локальная копия далекого объекта. А локальная копия гораздо быстрее ветвистых поисков в объектах и массивах. Например,


var name = this.conf.name, defs = this.defs
this.save(defs[name] || (defs[name] = {}))

немного лучше чем


this.save(this.defs[this.conf.name] || (this.defs[this.conf.name] = {}))

Первое пожмется в


var n=this.conf.name,d=this.defs;this.save(d[n]||(d[n]={}))

а второе в


this.save(this.defs[this.conf.name]||(this.defs[this.conf.name]={}))

то есть не пожмется вообще. Можно еще this закешировать, и будет еще на два байта меньше:


var t=this,n=t.conf.name,d=t.defs;t.save(d[n]||(d[n]={}))

но это мы предоставим гзипу — он автоматический :)

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


this.conf.name.first = "Vasya"
this.conf.name.second = "Poupkine"

преобразуется в


var name = this.conf.name
name.first = "Vasya"
name.second = "Poupkine"

и, соответственно, сжимается в


var n=this.conf.name;n.first="Vasya";n.second="Poupkine"

Подобные оптимизации совсем не обязательны и могут отвлекать от процесса творческого программирования. Но если привыкнуть к ним и начать думать как оптимизатор кода (в яваскрипте же его нет), то писать такой код можно уже без напряжения. Если ваш код будет использоваться часто и интенсивно, но изменен будет нескоро, то такая оптимизация как раз для вас. Можно, конечно, подождать многопроходного компилятора с оптимизатором и кроссбраузерного байткода, да когда они еще будут-то…

Такие разные removeClassName'ы

2009-02-02T00:00:00-08:00

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

Вот как у прототайпа 1.6:


removeClassName: function(element, className) {
  if (!(element = $(element))) return;
  element.className = element.className.replace(
    new RegExp("(^|\\s+)" + className + "(\\s+|$)"), ' ').strip();
  return element;
},

Тут мы видим два дополнительных вызова внешних функций: $(element) и .strip(). А еще строка собирается для каждого обращения. И еще регексп компилится каждый раз и при выполнении запоминает и заполняет $1 и $2. А зачем?

А вот так у джейквери:


remove: function( elem, classNames ) {
	if (elem.nodeType == 1)
		elem.className = classNames !== undefined ?
			jQuery.grep(elem.className.split(/\s+/), function(className){
				return !jQuery.className.has( classNames, className );
			}).join(" ") :
			"";
},

Этот код пожестче. Здесь и split с join'ом, и поиск className в jQuery, а в className'е потом поиск has. Ну, а про вызов замыкания на каждый имеющийся класс вообще умолчим. Задача укорачивания строки решена максимально помпезно.

В обеих библиотеках эти функции оборачиваются во что-то еще. Так, в коде джейквери прямым текстом написано «internal only, use removeClass("class")». Такой подход действительно полезен, когда к библиотеке пишут плагины и расширения. Хуков можно надобавлять, потрейсить, попрофайлить или еще что-нибудь побочное прикрепить.

На наших сайтах добавление и удаление классов происходит очень часто, а иногда очень-очень часто для целой кучи элементов (где именно? — как зарелизим — покажу; UPD 03.01.2009: показываю). Когда пишешь такой код, не хочется думать о том, что вызов removeClassName() может быть дорогим. Хочется простой и быстрый метод. Например, такой:


var rexCache = {}, R = RegExp
Element.prototype.removeClassName = function (cn)
{
	return this.className = this.className.replace
	(
		rexCache[cn] ||
		(rexCache[cn] = new R('(?:^| +)(?:' + cn + '(?:$| +))+', 'g')), ' '
	)
	.replace(/^\s+|\s+$/g, '')
}

Тут мы убрали все, что смогли, и ничего лишнего не добавили. Даже кеш, и тот закеширован в локальной переменной. Ах да: вы только, пожалуйста, не используйте эту функцию, не протестировав ее хорошенько на своих проектах. То, что она работает у нас, еще ничего не значит. Мы же не Резиг, и не мощная тусовка рельсовиков. Мы просто Иншейкер (а как же без ссылки на мой любимый коктейльный сайт).

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

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

JSON для Ruby

2009-01-25T00:00:00-08:00

Для руби есть три библиотеки работы с JSON. Быстрая JSON, в которой критичные по производительности части написаны на C. Медленная json/objects целиком на руби. А еще есть ActiveSupport::JSON, которая, видимо, является развитием «json/objects» в мире рельс. Первая библиотека действительно в несколько раз шустрее остальных, но она не умеет отключать перевод юникодных символов (то есть всех наших с вами родных букв) в последовательности \uXXXX. Вторая библиотека по умолчанию их не экранирует, но тормозит. А третья экранирует, тормозит, и это тоже не отключается. В общем поддержка JSON в руби, на мой вкус, сыровата.

Меньше всех не понравилась первая библиотека. Она хотя бы шустрая. А отключить экранирование помог патч (UPD 2011-01-10: который я посеял).

Главное — не дублировать

2009-01-22T00:00:00-08:00

Издалека

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

У нас есть исходник нжинкса, который, строго говоря, доступен только для чтения. Но это не беда, так как Игорь выбрал для нжинкса микроядерную архитектуру, которая ведет к постоянному развитию API. Таким образом практически вся функциональность нжинкса разделена между модулями. Эван Миллер сравнивает нжинкс с Бэтменом, а модули нжинкса с поясом Бэтмена, в котором всегда все есть.

Так, например, все фильтры являются самостоятельными модулями. Есть относительно простые модули, например, ngx_http_addition_filter_module, сложные, как ngx_http_gzip_filter_module и модули сравнимые по сложности со всем нжинксом, это, конечно, ngx_http_ssi_filter_module.

С другой стороны выступает яваскриптовый движок. Мозила его обкатала на множестве своих проектов и его API, на мой взгляд, тоже хорошо спроектирован. А также написано достаточно документации для того, чтобы быстро и удобно добавить скриптов в любое большое приложение.

Что надо знать, перед тем, как встаивать скриптовый движок? В принципе, ничего кроме того, какие именно задачи вы хотите перенести на скрипты. Если это ресурсоемкие вычисления, или работа с большим количеством логики поверх сложных абстракций, или большие и очень большие куски бизнес-логики, или еще что-то большущее, то скриптовый движок тут не поможет. Яваскрипт не сможет показать себя с хорошей стороны. Все функции, которые так или иначе связаны со скриптами, будут потихоньку начинать тупить. Приложение за счет гибкости языка разрастется очень быстро, и управлять им станет заметно сложнее, чем казалось вначале. Для больших проектов лучше подходят строгие и очень строгие языки, такие как Java, С++ или С. Они станут мешать вам сразу после начала работы, и вы привыкнете к этому. А яваскрипт (а так же руби, питон, перл и другие) не станут этого делать, и после будет очень обидно получать синяки и шишки работая с уже полюбившемся инструментом. Для быстрого нжинкса важно, чтобы яваскрипт тоже оставался быстрым и легким. Не мне вас учить выбирать технологи, но предупрежден — значит вооружен!

К делу

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

Для начала было бы неплохо генерить простые ответы на простые запросы. Без парсинга данных форм, принятия файлов, и уж тем более без запуска CGI-скриптов или обращений к базе. Здесь SpiderMonkey нас сам и ограничит, так как модулей промышленного качества для него очень мало, и вся доступная функциональность будет предоставлена нжинксом.
На второе подойдет работа с локальными файлами, чтобы иметь возможность что-нибудь сохранить. Правда, это не очень здорово, так как асинхронно работать с диском сложно. Гугловский браузер Chrome, например выносит весь файловый ввод/вывод в отдельный поток, чтобы интерфейс не тупил, и все обращения к диску работают через него.
В качестве компота, будут подзапросы. Собственно говоря, это самый оптимальный способ получать содержимое файлов, так как нжинкс умеет кешировать дескрипторы файлов и читает их максимально быстро. Все это не надо изобретать для использования внутри яваскрипта, а достаточно сделать обертку для функций нжинска.
Для обеспечения связи с внешним миром, пришлось еще учить SpiderMonkey читать переменные окружения. Это оказалось очень просто, так как решение идет вместе с исходниками яваскриптового интерпретатора.

Для начала этого вполне достаточно. Основная идея ясна — не дублировать функционал нжинска, а наоборот, описать его в терминах яваскрипта.

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

Обновляем виртуозную убунту

2009-01-06T00:00:00-08:00

UPD: Умные вещи про бэкпортинг.

< strong >UPD: При обновлении до харди не обязательно проходить всю цепочку edgy → feisty → gutsy → hardy (так как это уже невозможно), достаточно сразу записать в /etc/apt/sources.list везде hardy. Если будет ругаться на что-то связанное с tzdata (например, Could not perform immediate configuration (2) on tzdata), то достаточно удалить этот пакет: apt-get remove tzdata. Он потом все равно установится в процессе обновления.

Решил переехать со старой ubuntu 6.10 (можно было и с 6.06, но уже поздно) на новую ubuntu 8.04 внутри контейнера Virtuozzo на мастерхосте. Конфигурация, как видите, мудреная, и без эксцессов не обошлось.

Сначала проапгрейдил систему через смену репозиториев, запуская для каждого apt-get update и apt-get dist-upgrade. Это рисковано, но сработало. Перезагрузив VPS, обнаружил, что он не запускается и висит на стадии запуска klogd. Поговорил с техподдержкой, и это, как ни странно, помогло: пока мы болтали с тетей из мастерхоста, сервак загрузился. Он, оказывается, не висел, а просто долго чего-то ждал. После отключения /etc/init.d/klogd система стала стабильно загружаться за несколько секунд.

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

Как же это здорово, подумалось мне тогда. Вот сейчас заиспользую этот чудесный апстарт. Но не тут-то было. Он при апгрейде не установился. Команда cat /etc/issue пишет Ubuntu 8.04 \n \l, а апстарта нету. Как же так?

Ну, ничего. Мы же на каникулах — сейчас и апстарт поставим.


apt-get install startup-tasks system-services \
    upstart-compat-sysv upstart-logd

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

Как отлаживать такой черный ящик — непонятно. Выход нашелся очень забавный. Если VPS выключен, то через панель управления смотреть и править его файлы нельзя. Режима восстановления у мастерхостовского виртуоза нету. Однако, если в начале файла /etc/init.d/rc поставить sleep 600, то можно 10 минут спокойно лазить по файлам на еще не загруженном сервере. Не очень удобно, но уже что-то. Дальше обнаружилось, что до сбоя логи не пишутся никакие, хотя, процессы инициализации запускаются.

С помощью метода научного тыка, строки echo OK > my-debug.log и моральной поддержи кота Шарика (в пять утра не спит только кот и его программист) обнаружил, что сервак убивает одна единственная строка kill -USR1 1 в /etc/init.d/mountall.sh. Видимо, новая версия апстарта из моего сервера от такой грубости падала, и виртуоз решал, что пора сервер выключать, раз инит уже свалился. Повторю, мастерхостовский виртуоз делал все это очень быстро и очень молча. Хитрец такой.

Если вы знаете быстрый, надежный и не очень недорогой VPS-хостинг с адекватными версиями линуксов и возможностью отладки, поделитесь со мной пожалуйста… ну, пожалуйста, пожалуйста, пожалуйста, пожалуйста ;)

noscript

2008-12-18T00:00:00-08:00

Прикольно написать посетителю, что у него отрублен яваскрипт. Особенно, если без яваскрипта все сразу рушится. Но еще прикольнее отправить несчастного на специальную красивенькую страничку. Там можно написать всяческие извинения, мол, прости, нам без яваскрипта никак. Или наоборот — угрозы, типа, влючай яваксрипт, мы тебя запомнили!

Сделать это проще простого. Создайте отвечающую вашему стилю ведения бизнеса страничку, а в <head> остальных страниц добавьте <noscript> с <meta> внутри. Примерно вот так:


<head>
    <noscript>
        <meta http-equiv="refresh" content="0;url=/noscript.html"/>
    </noscript>
</head>

Правильная дата

2008-12-17T00:00:00-08:00

Создавая дату с помощью new Date(…), мы всегда получим новый объект даты. Если проверить его на истинность, результатом будет true. А как тогда проверить, не ошиблись ли мы, и верна ли дата?

Есть множество способов. Мне понравился этот: !isNaN(+date). Конструкция работает очень просто: приводит дату к числу унарным плюсом и проверяет число на равенство NaN. Для удобства этот код можно завернуть в метод самой даты:


Date.prototype.isValid = function ()
{
    return !isNaN(+this)
}

Есть только одна проблема. Получить невалидную дату в опере (9.2, 9.6) крайне сложно. Для этого необходимо дать на вход просто совершеннейший бред, иначе опера будет усердно угадывать дату даже там, где ее нет. Например, new Date('1 2 3') вернет дату «Mon, 01 Dec 2008 04:57:00 GMT+0300». Как? — не понятно.

Чаще всего в реальной жизни не бывает валидных дат, которые превращаются в 0 (то есть 1 января 1970 в 0 часов и 0 минут: new Date(0)). Поэтому можно обойтись простой проверкой:


alert(+date ? 'валидна' : 'невалидна')

Однако, в сафари NaN почему-то есть истина, и в нем без isNaN не обойтись. Спасибо вам, если вы учитываете особенности сафарьки при разработке сайтов ;)

UPD: Ура! В четвертом сафари NaN стал чушью! Опс, то есть стал ложью ;)

Быстрый ответ

2008-12-15T00:00:00-08:00

UPD 2011-04-08: Внимание! Эта статья хоть и стара, но еще очень даже ничего..

Если генерировать ответ постепенно, не зная заранее его размер, то нжинкс попытается отдать его клиенту чанками. Если клиент не поддерживает HTTP/1.1, то нжинкс откажется от кипэлайва. Это совсем не здорово, так как после отправки придется разорвать соединение и устанавливать новое.

Конечно, яваскрипт может перед отправкой заголовков сложить все данные в одну строку, вычислить длину строки и передать ответ. Проблема заключается в том, что string.length вернет именно длину строки, а не количество байт в ней. Чтобы узнать длину той строки, которую нжинкс будет реально передавать, надо сначала попросить SpiderMonkey сконвертировать внутреннюю строку (UTF-16) в обычную (ASCII, UTF-8), а затем уже вычислить ее длину. К этой работе добавляется манипуляция заголовками из яваскрипта. Это еще один вызов метода и несколько проверок входных/выходных параметров.

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

Вот пример яваскрипта:


function processRequest (r)
{
	r.sendString("Привет, Девелопер!")
	return Nginx.OK
}

Эта функция умеет отдавать строку «Привет, Девелопер!» 15 000 раз в секунду. Без кипэлайва будет всего около 6000. Если попытаться еще немного соптимизировать, можно кешировать и ascii-строку и ее длину между обращениями к sendString(). Строки в яваскрипте изменять нельзя, поэтому такое кеширование легко реализовать. Для длинных строк это может быть очень полезно.

Простейший cgi-скрипт

2008-12-09T00:00:00-08:00

Ненадолго отвлекусь от устройства нжинкса. Решил, шутки ради, проверить, как быстро основные скриптовые языки умеют запускаться внутри cgi-скриптов. CGI — это уже старо, совсем не модно, но зато стабильно.

Сравнил статический файл, скомпиленный C, перл, руби, питон и яваскрипт (SpiderMonkey). Ясное дело, что от языка тут зависит немного. Время в основном уходит на создание пайпа, выставление переменных окружения и форк. Затем каждый интерпретатор выставляет свои глобальные переменные, классы. И только потом уже собственно парсит и выполняет скрипт. Для C это неактуально, но все равно интересно было на него посмотреть.

Вот результаты забега. Для сравнения: статический файл отдается 5201.02 раза в секунду, а встроенный в нжинс яваскрипт — около 15 000;

С: 600,07;
перл: 419,53;
руби: 271,65;
питон: 32,45;
яваскрипт: 403,00.

Питон, как видно, я готовить не умею. На самом деле он крутой, быстрый, и тут что-то не так. В остальном, все говорит в пользу кеширования. Бинарник на C, конечно, заметно шустрее, но не принципиально. Легко подобрать задачу под один из языков, и справится он лучше других.

Тестил на рабочем компе: Intel Core 2 Duo, 2.16 ГГц, 4 Мб L2, 2 Гб оперативки. Mac OS X 10.5.5 (9F33), Darwin 9.5.0.

Версии интерпретаторов/компиляторов:

JavaScript-C 1.7.0 2007-10-03
ruby 1.8.6 (2007-03-13 patchlevel 0) [i686-darwin8.9.1]
python 2.5.2
perl 5.8.8 (darwin-2level)
gcc version 4.0.1 (Apple Inc. build 5488)

ngx_http_js_module-0.1

2008-12-07T00:00:00-08:00

UPD 2011-04-08: Внимание! Всё это старье, и лежит здесь только для истории.

Подготовка

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

последний стабильный нжинкс (у меня был nginx 0.6.34)
релиз SpiderMonkey (на этот момент версия 1.7.0)
свежая версия NSPR (здесь использовалась 4.7.3)
и собственно ngx_http_js_module версии 0.1 (UPD: теперь и на ГитХабе по тегу 0.1)

Собираем SpiderMonkey с поддержкой файлов

Сначала скомпилим и установим NSPR. Без него у нас не будет поддержки класса File внутри SpiderMonkey.


cd nspr-4.7.3/mozilla/nsprpub/
./configure
make
sudo make install

Затем скомпилим и установим SpiderMonkey. Официальный способ сборки требует для конфигурации autoconf версии 2.13 от 1999 года (говорят, версия 2.50 и выше не подойдет). Скажу честно, собрать SpiderMonkey официальным способом так и не получилось. Да еще в мануале не пишут, как здесь включить поддержку файлов. Но, на всякий случай, вот этот способ:


cd js/src
autoconf-2.13
./configure
make
sudo make install

Если все собралось и установилось — прекрасно. Но файлов не будет, а без них нельзя.

Нам достаточно собрать SpiderMonkey по старинке:


cd js/src
JS_HAS_FILE_OBJECT=1 \
CFLAGS="-I/usr/local/include/nspr" \
OTHER_LIBS="/usr/local/lib/libnspr4.dylib" \
make -f Makefile.ref

Вам, возможно, надо заменить значения переменных CFLAGS и OTHER_LIBS на значения принятые в вашей системе.

Теперь проверим наличие рабочего класса File:


echo "print (new File('.').parent)" | ./Darwin_DBG.OBJ/js
#=> /Users/developer/Downloads/js/src

И установим SpiderMonkey. Так как не работает make install, придется самим раскладывать все файлы по своим местам. На моем компе это делается так:


# внутри js/src
OBJ="Darwin_DBG.OBJ"
sudo cp $OBJ/js /usr/local/bin
sudo cp $OBJ/libjs.a /usr/local/lib
sudo cp $OBJ/libjs.dylib /usr/local/lib

sudo mkdir -p /usr/local/include/js
sudo cp $OBJ/*.h /usr/local/include/js
sudo cp *.h /usr/local/include/js
sudo cp *.tbl /usr/local/include/js

Замените Darwin_DBG.OBJ на то, что получилось у вашего компилятора. Исходники SpiderMonkey нам больше не нужны, их можно убрать, чтобы не мешали.

Собираем nginx c ngx_http_js_module

Распакуем nginx_http_js_module.tgz. Для удобства предположим, что у нас есть директория /stuff и в ней лежит папка с нашим модулем: /stuff/ngx_http_js_module.

Сконфигурируем и скомпилируем нжинк с яваскриптом:


cd nginx-0.6.34
./configure --add-module=/stuff/ngx_http_js_module
make

Если у вас уже установлен нжинкс той версии, которую мы собрали, то выполнять make install не нужно. При запуске нжинкс будет искать mime.types и другие файлы в своей директории /usr/local/nginx/. Если вы уже ставили нжинкс, то эта директория существует и в ней есть все необходимые файлы. Если нет, то после make выполните make install.

Потестим

Запустим:


# внутри nginx-0.6.34
sudo mkdir -p /usr/local/nginx/js
sudo cp /stuff/ngx_http_js_module/js/* /usr/local/nginx/js/
export JSLIB="/stuff/ngx_http_js_module/lib"
./objs/nginx -c /stuff/ngx_http_js_module/nginx.conf

Опросим:


curl http://localhost:8080/
#=> ... Welcome to nginx! ...
curl -v http://localhost:8080/test/page
#=> Привет, Девелопер!
#=> Ты вызвал страницу /test/page, методом GET, с IP 127.0.0.1

И небольшой тест на скорость:


ab -kc 10 -n 500 http://127.0.0.1:8080/test/page


Concurrency Level:      10
Time taken for tests:   0.075 seconds
Complete requests:      500
Failed requests:        0
Write errors:           0
Keep-Alive requests:    0
Total transferred:      127000 bytes
HTML transferred:       58500 bytes
Requests per second:    6668.53 [#/sec] (mean)
Time per request:       1.500 [ms] (mean)
Time per request:       0.150 [ms] (mean, across all concurrent requests)
Transfer rate:          1654.11 [Kbytes/sec] received

Тестил на первом поколении интеловских маков: Intel Core Duo 2 ГГц, 2 Мб кеша второго уровня, 1 Гб оперативки.

Ура!

Яваскрипт оказался очень шустрым. Два месяца назад тестовая сборка дала всего около 3000 запросов в секунду. Сегодняшняя версия дала 6600. Тестировал на одном и том же маке. Могу найти только два объяснения: либо нжинкс так прибавил в скорости, либо SpiderMonkey серьезно вырос за последнее время. Возможно, и то и другое. Получается, что используя фаерфокс, мы не только укрепляем клиентскую сторону веба, но и заглядываем в будущее серверной стороны. Как-то так.

Что дальше?

Расскажу, как устроен модуль внутри. Как он крепится к нжинксу, и как нжинкс обменивается данными с яваскриптом. Это, на мой взгляд, будет самое интересное. Архитектура нжинкса захватывает сложностью. Яваскрипт очень элегантен в своей простоте. Они такие разные.

Если не заводится

Иногда бывает так, что используешь указанные в руководстве версии, все делаешь правильно, а ничего не получается. Вот и со мной так было со SpiderMonkey 1.7.0. Скачал для написания поста новый архив, версия не изменилась, а содержимое архива изменилось. И не завелось. Чтобы уберечь вас от этих проблем, припас именно те файлики, которыми пользовался сам. Предлагаю в случае чего скачивать вот эти архивы:

Смотрите также

Искать описание структур и функций удобно на lxr Эмиллера.
Интересная статья Робина Миллза о том, как собрать SpiderMonkey с поддержкой класса File. Ее лучше читать с отключенными стилями и картинками ;)
Думаю, пригодятся доки по классу File.
Может понадобиться и другая версия доков про File.
Firefox на сервере: Aptana Jaxer. Впечатлил, но о нем потом.

nginx.js

2008-11-30T00:00:00-08:00

UPD 2011-04-08: Внимание! Всё это старье, и лежит здесь только для истории.

На работе мы используем по большому счету только javascript и nginx (еще немножко ruby, но об этом в следующий раз). И мне всегда хотелось посмотреть, как они устроены внутри. Но достойной задачи не находилось, и пришлось ее придумывать. Что может быть лучше в данном случае, чем написать модуль для нжинкса по встраиванию яваскрипта? И правда, оказалось очень интересно. Сразу скажу, что практического применения связке nginx+js найти пока не удалось.

nginx

Стабильной версией нжинкса на данный момент является 0.6.34. В качестве мануала был выбран другой модуль: ngx_http_perl_module. Встроить перл у меня однажды получилось — правда, с трудом — и этот модуль показался самым лучшим примером. Никакое другое руководство мне бы не помогло так, как помог исходник перлового модуля. Вот она сила опенсорса! Чуть позже встретилось «Руководство Эмиллера по разработке модулей для Nginx». Это руководство мне очень понравилось. Оно дает общее представление о нжинксе и его механизмах. Я даже перевел половину на русский.

javascript

В качестве представителя яваскрипта был выбран SpiderMonkey. Потому, что мне нравится файрфокс, и у них еще на рино сил хватает. Сначала почитал как его компилить, потом как его встраивать, а затем погрузился в апи. Механизмы в этих текстах изложены вполне доступно, так что страх перед неизведанным быстро пропал. Встраивался именно SpiderMonkey 1.7.0. Мозила готовит ему на смену TraceMonkey и обещает, что сохранит обратную совместимость. Верю им: Firefox 3.1 уже вовсю использует TraceMonkey, значит и нжинкс сможет. А это уже JIT.

nginx+javascript

Так как SpiderMonkey не несет с собой библиотеки модулей (как перл, руби или питон), все придется писать с нуля. Это тоже очень интересно. Так же есть возможность прикрутить поделки немногочисленных отважных джедаев. В случае нашего модуля научить яваскрипт удалось немногому: выводить сообщения в лог и отвечать на простые GET запросы. Никаких инструментов для парсинга простых POST-запросов или, тем более, мультипартов на яваскрипте мной не написано. Даже файл открыть нельзя. Не удивляйтесь, это концепт, и нужен он пока только мне одному.

nginx.js

Итак, что мы умеем. Вот пример функции, которая отвечает на HTTP-запрос:


function processRequest (r)
{
    r.sendHttpHeader('text/html; charset=utf-8')
    r.printString("Привет, Девелопер!\n")
    r.printString("Ты вызвал страницу " + r.uri
        + ', методом ' + r.method + ', с IP ' + r.remoteAddr)
    return Nginx.HTTP_OK
}

Небольшое пояснение:: r — это объект запроса, созданный внутри нжинкса;; r.sendHttpHeader(ctype) — это метод отправляет заголовки клиенту, попутно устанавливая Content-type в значение ctype;; r.printString(str) — метод копирует значение строки str в очередь на отправку;; r.uri, r.method и r.remoteAddr — геттеры для соответствующих полей запроса;; Nginx.NGX_HTTP_OK — константа равная 200.

А вот отрывок файла конфигурации, который загружает nginx.js и устанавливает хендлер processRequest():


http
{
    js_require 'nginx.js';
    # ...
    server
    {
        # ...
        location /test
        {
            js processRequest;
        }
    }
}

В общем, все скопировано с ngx_http_perl_module.

Итог

Скоро должна накопиться критическая масса желающих использовать javascript как язык общего назначения. Они принесут с собой новые полезные модули, портируют уже существующие модули для похожих языков (например, модули для руби). И все станет еще интереснее. Но уже сейчас легкий и быстрый скриптовый язык внутри нашего любимого нжинкса выглядит интересно. Посмотрим что еще из этого получится.

Смотрите в следующих сериях

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

Versions.app зарелизили

2008-11-24T00:00:00-08:00

Больше полугода пользовался бетами Versions.app, а теперь они выпустили релиз. Продают его за 49$, чему я очень рад, так как именно столько и готов отдать за клевый svn-клиент.

UPD 2009-10-10: как же теперь жаль эти баксы ;)

UPD 2010-11-29: как же теперь жаль годы, потраченные на SVN ;)

String.interpolateJS()

2008-11-22T00:00:00-08:00

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


"Welcome to ${company}!".interpolateJS({company:'Programica'})
//=> "Welcome to Programica!"

"Your name is ${name}.".interpolateJS({name:prompt('What is your name?')})
//=> "Your name is Dima."

// tru javascript inside :)
"Your name is ${prompt('What is your name?')}.".interpolateJS({})
//=> "Your name is Dima."

"${this.interpolateJS({})}".interpolateJS({})
// too much recursion

("${another = 'another', 'Just'} ${another}"+
    " ${'tpircSavaJ'.split('').reverse().join('')}"+
    " ${[\"hacker\"] || ''},").interpolateJS({another:1})
//=> "Just another JavaScript hacker,"

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

Чтобы получить закешированную функцию по строке, обратитесь к объекту String.prototype.interpolateJS.cache:


var string = "${x} + 2 = ${ x + 2 } :)"
string.interpolateJS({x:2})
//=> "2 + 2 = 4 :)"

String.prototype.interpolateJS.cache[string]
//=> function ($_$h) { with ($_$h) { return x + $_$s[1] + (x + 2) + $_$s[2]; } }

Исходник в библиотеке.

Серенькие подсказки в текстовых инпутах

2008-11-14T00:00:00-08:00

Кладем инпут в лейбл. Кидаем <small> с подсказкой в лейбл. Лейблу делаем position: relative. Располагаем смол над инпутом. Делаем цвет смола прозрачным или просто сереньким.

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

Чтобы все было красиво, надо чтобы подсказка пряталась сразу после появления текста в инпуте. Сделать это не так просто, как кажется. Если подписаться на keydown , то мы не сможем узнать, какой текст сейчас в инпуте. Если подписаться на keypress или keyup, то мы сможем спрятать тип только после небольшой, но заметной задержки.

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

Работает очень простой финт. Подписываемся на keypress, откладываем событие с помощью setTimeout(), и производим все проверки в отложенной функции, когда инпут уже определиться со своим состоянием.

Руководство Эмиллера по разработке модулей для Nginx

2008-09-09T00:00:00-07:00

Оригинал Emiller's Guide To Nginx Module Development, черновик от 14 июля 2008 г. (изменения). Автор: Эван Миллер, перевод Петра Леонова.

Брюс Уэйн: Что это?
Люциус Фокс: Бэтмобиль? Ох… лучше вам не знать.

Чтобы лучше разобраться в Nginx'е, web-сервере, надо сначала понять Бэтмена, персонажа комиксов.

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

Но кем бы был Бэтмен без своего Пояса.

Рисунок 1: Пояс Бэтмена, в обнимку с пузом Кристиана Бэйла.

В любой момент в Поясе Бэтмена может найтись набор отмычек, пара бумерангов, бэт-наручники, бэт-маячок, бэт-дротик, прибор ночного видения, термитные гранаты, дымовая завеса, фонарик, обруч из криптонита, паяльная лампа или iPhone. Если Бэтмену надо кого-то усыпить, ослепить, оглушить, выследить, пристукнуть, притормозить, довести до слез или заэсэмэсить насмерть, то он тянется к своему Поясу. Для Бэтмена он так много значит, что он скорей забыл бы одеть штаны, чем пояс. А у Бэтмена штанов и нет, вместо них ему приходится носить резиновые бронеритузы (рис. 1).

Вместо Пояса Бэтмена у Nginx имеется свой набор модулей. Когда нужно сжать запрос или передать его по частям, Nginx запускает соответсвующий модуль. Когда Nginx блокирует доступ с какого-либо IP адреса или проверяет данные HTTP-авторизации, на самом деле это делает один из модулей. Если Nginx подсоединяется к Memcache или FastCGI-серверу, то именно модуль связывает их.

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

Рисунок 2: Брюс Уэйн (он же Бэтмен) со своим инженером Люциусом Фоксом.

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

Но кто говорил, что создавать бэт-штуковины будет легко?

Содержание

Для начала
Устройство модулей в первом приближении
Компоненты модуля Nginx
Обработчики, фильтры и балансировщики нагрузки
1. Устройство обработчиков (не проксирующих)

Для начала

Вы должны неплохо знать Си. Не просто его синтаксис, а то, как работать со структурами и не бояться указателей и ссылок на функции. А также иметь представление о препроцессоре и макросах. Если вам надо немного освежить знания, то ничто не сможет сравниться с K&R(англ.).

Полезно понимать основы HTTP. Мы же, вообще-то, собираемся работать с web-сервером.

Пригодятся знания структуры конфигурационного файла Nginx'а. Вот основные моменты: существуют четыре контекста (называеются они main — главный, server — сервер, upstream — апстрим, и location — локейшн) в которых могут быть директивы с одним и более параметрами. Директивы в главном контексте применяются ко всему-всему; директивы из котекста сервера применяются к конкретному хосту/порту; директивы в апстриме описывают набор бэкендов; а директивы в контексте локешна применяются к разным путям запроса (например, "/", "/images" и т.д.) Локешн наследует конфигурацию содержащему его серверному контексту, а сервер наследует главному контексту. Контекст апстрима не наследует никому, у него собственные директивы, которых больше нигде не используются. Я буду иногда упоминать эти четыре контекста, так что… не забывайте про них.

Ну что же, начнем!

1. Устройство модулей в первом приближении У модулей Nginx'a могут быть три роли, которые мы рассмотрим:

обработчики обрабатывают запрос и генерируют данные ответа
фильтры обрабатывают данные, полученные от обработчика
балансировщики выбирают бэкенд, которому передать запрос, если определено несколько бэкендов

Модули делают реальную работу, которую обычно делают web-серверы: когда Nginx отправляет файл или проксирует запрос к другому серверу, то это делает модуль-обработчик. Когда Nginx гзипит данные или обрабатывает SSI-директивы, он делает это с помощью модуля-фильтра. Ядро Nginx'а берет на себя работу с сетью и реализацию протоколов, а также запускает модули, которые необходимы для обработки запроса. Децентрализованная архитектура позволяет нам создавать отдельные компоненты, которые делают что-то, что нам нужно.

Замечание: в отличие от модулей Apache, модули Nginx'а не подгружаются динамически (другими словами, модули вкомпилированы прямо в бинарник Nginx'а).

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

Если обработчик является реверс-прокси, то ему понадобится помощь балансировщика нагрузки. Балансировщик получает запрос вместе с набором бэкендов и принимает решение, какому серверу передать запрос. Nginx поставлется с двумя модулями балансировки: round-robin, который выбирает серверы по очереди, и модуль с методом хеширования IP адреса, который гарантирует, что запрос конкретного клиента каждый раз будет передаваться одному и тому же бэкенду.

Если обработчик не вернул ошибку, управление перейдет к фильтрам. Один локешн могут фильтровать несколько модулей, так, например, ответ может быть сжат, а потом выдаваться chunk'ами. Порядок запуска фильтров определяется на этапе компиляции. Фильры используют классический паттерн «цепочка обязанностей»: запускается один фильтр, делает свою работу, потом запускается второй, и так далее, пока не выполнится последний фильтр, и Nginx завершит обработку запроса.

Самая вкусная особенность цепочки фильтров заключается в том, что один фильтр не должен ждать, пока другой завершит свою работу целиком. Можно начать обрабатывать результат работы предыдущего фильтра по мере поступления, почти как птоки (пайпы) в юниксе. Фильры оперируют буферами, размер которых, обычно, равен размеру страницы (4 Кб), но размер всегда можно задать в nginx.conf. Это означает, например, то, что что модуль может начать сжимать ответ и отправлять его клиенту еще до того, как бэкенд полностью передат данные ответа. Чудесно!

Чтобы увидеть картину в целом, рассмотрим типичный цикл обработки запроса:

клиент посылает HTTP-запрос;
Nginx выбирает подходящий обработчик на основе конфига;
балансировщик (если необходимо) выбирет бэкенд;
обработчик делает свое дело и передает каждый буфер с данными результата первому фильтру;
фильтр передает результаты второму фильтру;
второй — третьему, третий — четвертому, и так далее;
получившийся ответ отправляется клиенту.

Я сказал «типичный» цикл потому, что обработку в Nginx'е можно настраивать как угодно. Определить когда и как должен запускать модуль может оказаться непростой задачей для разработчика (я бы сказал очень даже не простой задачей). Настройка модуля проходит в следствии вызова ряда колбеков, и их не так уж мало. Конкретно, можно определить функцию, которая будет запущена:

Прямо перед чтением конфигурационного файла
Для каждой директивы конфигурации локешна или сервера по мере их поступления
Когда Nginx инициализирует главную конфигурацию
Когда Nginx инициализирует конфигурацию сервера (хост/порт)
Когда Nginx мерджит конфигурацию сервера с главной конфигурацией
Когда Nginx инициализирует конфигурацию локешна
Когда Nginx мерджит конфигурацией сервера с вложенной конфигурацией локешна
Когда запускается главный процесс Nginx'а
Когда запускается новый рабочий процесс
Когда рабочий процесс завершается
Когда главный процесс завершается
Для обработки запроса
Для фильтрации заголовка ответа
Для фильтрации тела ответа
Для выбора бэкенда
В момент инициализации запроса к бэкенда
В момент переинициализации запроса к бэкенду
Для обработки ответа от бэкенда
В момент завершения работы с бэкендом

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

2. Компоненты модуля Nginx

Как я уже сказал, в вашем распоряжении огромный запас гибкости для разработки модуля для Nginx'а. В этом разделе те части, которые есть практически в любом модуле. Это моможет нам лучше понять устройство модуля. А так же вы сможете оценить, когда можно будет перейти к написанию собственного модуля.

2.1. Структуры конфигурации модуля Модуль можно описать с помощью трех разных конфигурационных структур, по одной для главного контекста, контекста сервера и контекста локешна. Большинству модулей достаточно конфигурации локешна. Для структур принято такое именование: ngx_http_<название_модуля>_(main|srv|loc)_conf_t. Вот пример, взятый из модуля dav:



typedef struct {
    ngx_uint_t  methods;
    ngx_flag_t  create_full_put_path;
    ngx_uint_t  access;
} ngx_http_dav_loc_conf_t;

Заметьте, что в Nginx'е используются специальные типы данных (ngx_uint_t и ngx_flag_t). Это просто алиасы для простых типов данных, которые мы все знаем и любим (см. core/ngx_config.h, если есть сомнения).

Элементы конфигурационной структуры заполняются значениями, описывающими модуль.

2.2. Директивы модуля

Директивы описыватся в статическом массиве элементов типа ngx_command_t. Вот пример того, как их определять (взят из маленького модуля, который я написал):



static ngx_command_t  ngx_http_circle_gif_commands[] = {
    { ngx_string("circle_gif"),
      NGX_HTTP_LOC_CONF|NGX_CONF_NOARGS,
      ngx_http_circle_gif,
      NGX_HTTP_LOC_CONF_OFFSET,
      0,
      NULL },

    { ngx_string("circle_gif_min_radius"),
      NGX_HTTP_MAIN_CONF|NGX_HTTP_SRV_CONF|NGX_HTTP_LOC_CONF|NGX_CONF_TAKE1,
      ngx_conf_set_num_slot,
      NGX_HTTP_LOC_CONF_OFFSET,
      offsetof(ngx_http_circle_gif_loc_conf_t, min_radius),
      NULL },
      ...
      ngx_null_command
};

А вот определение структуры ngx_command_t (той, что мы сейчас заполняем), оно взято из файла core/ngx_conf_file.h:



struct ngx_command_t {
    ngx_str_t             name;
    ngx_uint_t            type;
    char               *(*set)(ngx_conf_t *cf, ngx_command_t *cmd, void *conf);
    ngx_uint_t            conf;
    ngx_uint_t            offset;
    void                 *post;
};

На первый взгляд слишком много, но у каждого поля свое назначение. В name хранится имя директивы, обязательно без пробелов. Используется тип ngx_str_t, значение которого чаще всего создаются с помощью макроса ngx_str("proxy_pass"). Замечание: структура ngx_str_t состоит из поля data, которое содержит саму строку, и поля len, в котором хранится длина строки. В большинстве случаев Nginx использует эту структуру взамен обычных строк. Значение type задается с помощью набора флагов, которые определяют, где можно использовать эту директиву, и сколько она принимает параметров. Значение получается с помощью бинарного или:

NGX_HTTP_MAIN_CONF: разрешает использовать директиву в главном контексте
NGX_HTTP_SRV_CONF: в контексте сервера (хоста)
NGX_HTTP_LOC_CONF: в контексте локешна
NGX_HTTP_UPS_CONF: в контексте апстрима

NGX_CONF_NOARGS: сообщает, что директива не принимает аргументы
NGX_CONF_TAKE1: принимает ровно 1 аргументы
NGX_CONF_TAKE2: принимает ровно 2 аргумента
…
NGX_CONF_TAKE7: принимает ровно 7 аргументов

NGX_CONF_FLAG: тип аргумента должен быть булев??? ("on" или "off")
NGX_CONF_1MORE: директиве принимает 1 или более аргументов
NGX_CONF_2MORE: директиве принимает 2 или более аргументов

Есть еще несколько опций, спотрите core/ngx_conf_file.h. В элементе структуры set хранится указатель на функцию, вызываемую для настройки какой-то части модуля; обычно, эта функция преводит данные из аргументов в удобный формат и сохраняет их в соответстующей структуре конфигурации модуля. Функция принимает три аргумента:

указатель на структуру ngx_conf_t, которая содержит переданные директиве аргументы
указатель на текущую структуру ngx_command_t
указатель на собственную структуру конфигурации модуля

Функция будет вызвана тогда, когда соответствующая директива будет встречена в конфигурационном файле. Nginx предосталяет набор функций для перевода разных типов параметров в структуру для последующей обработки. Среди этих функций хочу виделить следуюющие:

ngx_conf_set_flag_slot: переводит "on" или "off" в 1 или 0
ngx_conf_set_str_slot: певодит строку параметра в ngx_str_t
ngx_conf_set_num_slot: парсит число и возвращает его как int
ngx_conf_set_size_slot: парсит размер ("8k", "1m" и т.д.) и возвращает его как size_t

Есть еще несколько функций, и они тоже очень удобны (посотрите core/ngx_conf_file.h). Модули могут описывать здесь и свои функции, если по каким-то причинам не достаточно встроенных. Откуда эти функции узнают, куда сохранять данные? В этом им помогают следующие два свойстваструктуры ngx_command_t: conf и offset. conf указывае Nginx'у куда сохранить данные: в главную, серверную или конфигурационную структуру локешна (задается с помощью NGX_HTTP_MAIN_CONF_OFFSET, NGX_HTTP_SRV_CONF_OFFSET, or NGX_HTTP_LOC_CONF_OFFSET). offset указывает в какую часть структуры записать значение. И,наконец, post это еще одна штукенция, которая может пригодится модулю на этапе конфигурации. Чаще всего равна NULL. Набор директив заканчивается ngx_null_command.

2.3. Контекст модуля

Это статическая структура типа ngx_http_module_t, в которой определяются несколько указателей на функции для создание трех конфигураций и сливания их вместе. Называют ее ngx_http_<имя_модуля>_module_ctx. Вот назначение этих функций по порядку:

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

Функции принимают разные аргументы в зависимости от своего назначения. Вот описание этой структуры, взятое из http/ngx_http_config.h, в котором видны разные сигнатуры функций-колбеков:



typedef struct {
    ngx_int_t   (*preconfiguration)(ngx_conf_t *cf);
    ngx_int_t   (*postconfiguration)(ngx_conf_t *cf);

    void       *(*create_main_conf)(ngx_conf_t *cf);
    char       *(*init_main_conf)(ngx_conf_t *cf, void *conf);

    void       *(*create_srv_conf)(ngx_conf_t *cf);
    char       *(*merge_srv_conf)(ngx_conf_t *cf, void *prev, void *conf);

    void       *(*create_loc_conf)(ngx_conf_t *cf);
    char       *(*merge_loc_conf)(ngx_conf_t *cf, void *prev, void *conf);
} ngx_http_module_t;

Указатели на те функции, которые вам не пригодятся, можете заполнить NULL, и Nginx сделает вид, что не заметил их. Большинство обработчиков используют только две последние: чтобы выделить память для структуры конфигурации (называется ngx_http_<имя_модуля>_create_loc_conf), и слить ее с конфигурацией выше (называется ngx_http_<имя_модуля>_merge_loc_conf). Функция, сливающая вместе конфиги, также может вернуть ошибку, что остановит загрузку сервера. Вот пример пример структуры контекста модуля:


static ngx_http_module_t  ngx_http_circle_gif_module_ctx = {
    NULL,                          /* перед конфигурацией */
    NULL,                          /* после конфигурации */

    NULL,                          /* создание главной конфигурации */
    NULL,                          /* инициализация главной конфигурации */

    NULL,                          /* создание конфигурации сервера */
    NULL,                          /* сливание ее с главной конфигурацие */

    ngx_http_circle_gif_create_loc_conf,  /* создание конфигурации локешна */
    ngx_http_circle_gif_merge_loc_conf /* сливание ее с конфигурацие сервера */
};

Пришло время разобраться со всем этим подробнее. Эти конфигурационные колбеки очень похожи во всех модулях и используют одну часть Nginx API, так что их надо хорошо знать.

2.3.1. create_loc_conf

Вот так выглядит минимальная реализация функции create_loc_conf, взятая из моего модуля circle_gif (за подробностями прошу в исходник). Она получает структуру (ngx_conf_t) и возвращает вновь созданную структуру конфигурации модуля (в этом примере ngx_http_circle_gif_loc_conf_t).

static void *
ngx_http_circle_gif_create_loc_conf(ngx_conf_t *cf)
{
    ngx_http_circle_gif_loc_conf_t  *conf;

    conf = ngx_pcalloc(cf->pool, sizeof(ngx_http_circle_gif_loc_conf_t));
    if (conf == NULL) {
        return NGX_CONF_ERROR;
    }
    conf->min_radius = NGX_CONF_UNSET_UINT;
    conf->max_radius = NGX_CONF_UNSET_UINT;
    return conf;
}

Прошу заметить важную особенность управления памятью в Nginx'е: он сам позаботится о вызове free только тогда, когда для выделения памяти вы используете ngx_palloc (умную обертку для malloc) или ngx_pcalloc (умную обертку для calloc). Возможными вариантами задания UNSET являются: NGX_CONF_UNSET_UINT, NGX_CONF_UNSET_PTR, NGX_CONF_UNSET_SIZE, NGX_CONF_UNSET_MSEC, и для всех случаев NGX_CONF_UNSET. UNSET показывает функции сливания конфигов, что это значение надо переопределить.

2.3.2. merge_loc_conf

Вот так выглядит функция сливания конфигов в модуле circle_gif:

static char *
ngx_http_circle_gif_merge_loc_conf(ngx_conf_t *cf, void *parent, void *child)
{
    ngx_http_circle_gif_loc_conf_t *prev = parent;
    ngx_http_circle_gif_loc_conf_t *conf = child;

    ngx_conf_merge_uint_value(conf->min_radius, prev->min_radius, 10);
    ngx_conf_merge_uint_value(conf->max_radius, prev->max_radius, 20);

    if (conf->min_radius < 1) {
        ngx_conf_log_error(NGX_LOG_EMERG, cf, 0,
            "min_radius должен быть больше или равен 1");
        return NGX_CONF_ERROR;
    }
    if (conf->max_radius < conf->min_radius) {
        ngx_conf_log_error(NGX_LOG_EMERG, cf, 0,
            "max_radius должен быть больше или равен min_radius");
        return NGX_CONF_ERROR;
    }

    return NGX_CONF_OK;
}

Приятной особенностью Nginx'а является набор функций для сливания разных типов данных (ngx_conf_merge_<тип_данных>_value); их аргументами являются

значение текущего локешна
значение, задаваемое, если #1 не установлено
задаваемое по умолчанию, если не установлено ни #1, ни #2

Результат будет записан в первый аргумент. Примерами таких функций являются ngx_conf_merge_size_value, ngx_conf_merge_msec_value и другие. Обратитесь к core/ngx_conf_file.h за полным списком.

А вот вопрос: как же этим функциям удается записать данные в первый аргумент, если он передается по значению? Ответ прост: это макросы (они разворачиваются в несколько конструкций if).

Интересно так же то, как эти функции обрабатывают ошибки. В случае неудачи в лог выводится сообщение, и функция возвращает NGX_CONF_ERROR. В этом случает запуск сервера прекращается. Так как сообщение выводится с уровнем NGX_LOG_EMERG, оно будет продублировано в поток ошибок. Кстати, core/ngx_log.h содержит полный список уровнй вывода.)

2.4. Описание модуля

Теперь добавим еще один уровель абстракции, структуру ngx_module_t. Переменную назовем ngx_http_<имя_модуля>_module. В ней описываются указатели на контекст и директивы модуля вместе с остальными колбеками(завершение треда, завершение процесса и т.д.). Определение модуля иногда используется, чтобы найти какие-либо данные, связанные с этим модулем. Определение модуля часто выглядит так:


ngx_module_t  ngx_http_<имя_модуля>_module = {
    NGX_MODULE_V1,
    &ngx_http_<имя_модуля>_module_ctx, /* контекст модуля */
    ngx_http_<module name>_commands,   /* директивы модуля */
    NGX_HTTP_MODULE,               /* тип модуля */
    NULL,                          /* инициализация мастера */
    NULL,                          /* инициализация модуля */
    NULL,                          /* инициализация процесса */
    NULL,                          /* инициализация треда */
    NULL,                          /* завершение треда */
    NULL,                          /* завершение процесса */
    NULL,                          /* завершение мастера */
    NGX_MODULE_V1_PADDING
};

…замените <имя_модуля> на что-нибудь полезное. Модули погут определять колбеки для моментов создания и уничтожения процессов и тредов, но большинство модулей стараются не усложнять себе жизнь. Чтобы посмотреть список аргументов, обратитесь к core/ngx_conf_file.h.)

2.5. Установка модуля

Модули устанавливаются двумя способами: обработчики чаще всего устанавливаются колбеком директивы, а фильтры устанавливаются в постконфигурационном колбеке в структуре контекста модуля. Наконец, мы собираемся указать Nginx'у, где искать наш код. Балансировщики в этом вопросе особенные, их мы рассмотрим позже в разделе Устройство балансировщиков нагрузки.

2.5.1. Установка обработчика

Обработчики устанавливаются с помощью кода внутри колбеков, вызываемых директивами, которые относятся к модулю. Например, моя структура ngx_command_t из модуля circle_gif выглядит примерно так:


    { ngx_string("circle_gif"),
      NGX_HTTP_LOC_CONF|NGX_CONF_NOARGS,
      ngx_http_circle_gif,
      0,
      0,
      NULL }

Третьим аргументом как раз является колбек, в примере это ngx_http_circle_gif. Вспомним, что аргументами этого колбека являются: структура директивы (ngx_conf_t, в кторой сохранены параметры из конфигурационного файла), соответствующая структура ngx_command_t и указатель на структуру конфигурации модуля. В моем модуле circle_gif эта функция выглядит так:


static char *
ngx_http_circle_gif(ngx_conf_t *cf, ngx_command_t *cmd, void *conf)
{
    ngx_http_core_loc_conf_t  *clcf;

    clcf = ngx_http_conf_get_module_loc_conf(cf, ngx_http_core_module);
    clcf->handler = ngx_http_circle_gif_handler;

    return NGX_CONF_OK;
}

Она выполняет работу в два этапа. Во-первых, получает внутреннюю структуру описывающую этот локешн. Во-вторых, устанавливает в ней обработчик (тоже колбек). Просто, не правда ли?

2.5.2. Установка фильтра

Фльтры устанавливаются на этапе постконфигурации. Бывает два типа фильтров: фильтры заголовков которые обрабатывают HTTP-заголовки, и фильтры тела ответа, которые обрабатывают собственно данные. Мы устанавливаем оба за один раз. В качестве простого примера посмотрим на chunked-фильтр, его контекст выглядит так:


static ngx_http_module_t  ngx_http_chunked_filter_module_ctx = {
    NULL,                                  /* preconfiguration */
    ngx_http_chunked_filter_init,          /* postconfiguration */
  ...
};

Вот что происходит в ngx_http_chunked_filter_init:

static ngx_int_t
ngx_http_chunked_filter_init(ngx_conf_t *cf)
{
    ngx_http_next_header_filter = ngx_http_top_header_filter;
    ngx_http_top_header_filter = ngx_http_chunked_header_filter;

    ngx_http_next_body_filter = ngx_http_top_body_filter;
    ngx_http_top_body_filter = ngx_http_chunked_body_filter;

    return NGX_OK;
}

Что это значит? Если вы помните, фильтры работают по принципу цепочки обязанностей. Когда обработчик сгенерирует ответ, он вызывает две функции: ngx_http_output_filter, которая вызывает глобальную ngx_http_top_body_filter; и ngx_http_send_header, вызывает другую глобальную ngx_top_header_filter. Функции ngx_http_top_body_filter и ngx_http_top_header_filter являются гловными в цепочках фильтров соответственно заголовка и тела ответа. Каждое звено в цепи содержит ссылку на следующее звено (ссылки называются ngx_http_next_body_filter и ngx_http_next_header_filter). Когда фильтр закончит выполнение, он просто вызывает следующий, пока не будет вызван специальный фильтр, который уже заворачивает данные в HTTP-ответ. Все что делает функция filter_init, это добавляет свой модуль в обе эти цепи. Эта функция сохраняет ссылку на бывший первым фильтр в своей собственной переменной и определяет свои колбеки, как первые в цепочках. Цепочка действует по принципу LIFO (Last In Frist Out): последним добавлен — первым обработан.

Заметка на полях: а как точно это работает? Каждый фильтр возвращает либо ошибку, либо результат специального выражения: return ngx_http_next_body_filter(); Таким обазом, если очередь в цепочке фильтров дошла до последнего («специального») фильтра, просто возвращается "OK", но если проихошла ошибка, оставшаяся цепочка пропускается и Nginx выводит соответствующее сообщение об ошибке. Это простой однонаправленный список с бастрой обработкой ошибок, выполненный в виде указателей на функции. Превосходно.

3. Обработчики, фильтры и балансировщики нагрузки

Теперь рассмотрим пару простейших модулей под микроскопом и разберемся как они работает

3.1. Устройство обработчиков (не проксирующих)

Обработчики, обычно, выполняют четыре шага: получают конфигурацию локешна, генерируют соответствующий ответ, отправляют заголовки и отправляют тело ответа. Хентдлер получает один аргумент: структуру запроса. В структуре запроса хранится много молезной информации о запросе клиента. Такой как, метод запроса, URI и загловки. Мы рассмотрим эти четыре шага один за другим.

3.1.1. Получение конфигурации локейшна

Это простая часть. Все, что надо сделать, это вызвать ngx_http_get_module_loc_conf и передать параметрами текущий запрос и описание модуля. Вот соответствующая часть хендлера из моего модуля circle_gif:


static ngx_int_t
ngx_http_circle_gif_handler(ngx_http_request_t *r)
{
    ngx_http_circle_gif_loc_conf_t  *circle_gif_config;
    circle_gif_config = ngx_http_get_module_loc_conf(r, ngx_http_circle_gif_module);
    ...

Вот так я получил доступ ко всем переменным, сохраненным на этапе сливания конфигов.

3.1.2. Генерация ответа

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


typedef struct {
...
/* пул памяти, используемый в функциях типа ngx_palloc */
    ngx_pool_t                       *pool;
    ngx_str_t                         uri;
    ngx_str_t                         args;
    ngx_http_headers_in_t             headers_in;

...
} ngx_http_request_t;

uri это путь запроса, например "/query.cgi". args содержит нераспарсенные параметры запроса (идущая за знаком вопроса часть), например "name=john". headers_in хранит много полезной информации, такой как куки и информация о браузере, но большинству модулей эти данные не пригождаюися. Посмотрите http/ngx_http_request.h, если интересно. Этого вполне достаточно, чтобы смочь составить какой-нибудь полезный ответ. Полное описание структуры ngx_http_request_t можно найти в http/ngx_http_request.h.

3.1.3. Отправка заголовков

Заголовки ответа живут в структуре называемой headers_out. Она в свою очередь хранится в структуре запроса. Обработчик хапроса выставляет те заголовки, которые ему надо и вызывает ngx_http_send_header(r). Вот некоторые из самых полезный элементов headers_out:

typedef stuct {
...
    ngx_uint_t                        status;
    size_t                            content_type_len;
    ngx_str_t                         content_type;
    ngx_table_elt_t                  *content_encoding;
    off_t                             content_length_n;
    time_t                            date_time;
    time_t                            last_modified_time;
..
} ngx_http_headers_out_t;

Остальное можно найти в http/ngx_http_request.h. Так, например, если модуль должен выставить Content-Type в "image/gif", Content-Length в 100 и вернуть код ответа 200 OK, то следующий код поможет ему сделать это:


    r->headers_out.status = NGX_HTTP_OK;
    r->headers_out.content_length_n = 100;
    r->headers_out.content_type.len = sizeof("image/gif") - 1;
    r->headers_out.content_type.data = (u_char *) "image/gif";
    ngx_http_send_header(r);

Большинство стандартных загловоков HTTP доступны (где-либо) для изменения вами. Однако, некоторые хаголовки задать немного сложнее чем те, которые вы видели выше. На пример, content_encoding имеет тип (ngx_table_elt_t*), поэтому модуль должен сам выделить память для этого заголовка. Это можно сделать с помощью функции ngx_list_push, которая принимает ngx_list_t (похож на массив) и возвращает указатель на вновь созданный элемен в этом списке (типа ngx_table_elt_t). Код ниже устанавливает заголовок Content-Encoding в значение "deflate" и отправляет заголовки:


    r->headers_out.content_encoding = ngx_list_push(&r->headers_out.headers);
    if (r->headers_out.content_encoding == NULL) {
        return NGX_ERROR;
    }
    r->headers_out.content_encoding->hash = 1;
    r->headers_out.content_encoding->key.len = sizeof("Content-Encoding") - 1;
    r->headers_out.content_encoding->key.data = (u_char *) "Content-Encoding";
    r->headers_out.content_encoding->value.len = sizeof("deflate") - 1;
    r->headers_out.content_encoding->value.data = (u_char *) "deflate";
    ngx_http_send_header(r);

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

3.1.4. Отправка тела ответа

Теперь, когда модуль сгенерировал ответ и записал его в память, ему необходимо присвоить овет специальному буферу и затем, передать буфер в специальное звено чепочки, а потом вызвать «отправку ответа» на этом звене. Зачем нужна звенья и цепочка? Nginx позволяет обработчикам генерировать (а фильтрам обрабатывать) ответ по одному буферу за раз. Каждое звено цепи хранит ссылку на следующие звен или NULL если оно последнее. Чтобы не усложнять пример, предстваим, что у нас есть только один буфер (и одно звено цепи). Сначала модуль должен объявить буфер и звено цепи.


    ngx_buf_t    *b;
    ngx_chain_t   out;

Следующим шагом надо выделить память для буфера и добавить его в данные ответа:


    b = ngx_pcalloc(r->pool, sizeof(ngx_buf_t));
    if (b == NULL) {
        ngx_log_error(NGX_LOG_ERR, r->connection->log, 0,
            "Не удалось выделить буфер ответа.");
        return NGX_HTTP_INTERNAL_SERVER_ERROR;
    }

    b->pos = some_bytes; /* позиция первого байта в блоке данных */
    b->last = some_bytes + some_bytes_length; /* последняя позиция */

    b->memory = 1; /* данные храняться в памяти только для чтения */
    /* (то есть фильтры должны скопировать эти данные перед обработкой, вместо того, чтобы изменять их) */

    b->last_buf = 1; /* буферов в запросе больше не будет */

А здесь модуль присваивает буфер звену цепи:


    out.buf = b;
    out.next = NULL;

И наконец, мы отправляем ответ и возвращаем статут вызова отправки за один раз:


    return ngx_http_output_filter(r, &out);

Цепочки буферов — это критически важная часть модели ввода/вывода в Nginx'е, так что вы должны ими хорошо овладеть.

Очевидный вопрос: зачем буферу флаг last_buf, если мы можем определить, что он последний проверив "next" на NULL? Ответ: цепь может быть незавершенной, то есть состоять из множества буферов, не не все буферы уже подготовлены в запросе или ответе. Таким образом, некоторые буферы будут в конце цепи, но не в конце запроса. И это приводит нас к…

3.2. Устройство апстримов (они же прокси)

Продолжение следует.

CMS Builder жив

2008-09-06T00:00:00-07:00

По запросу «cms builder» держу 4, 5 и 7 места в гугле , и второе в яндексе. И люди ходят даже. Приятно, что кто-то еще не забыл нашего гиганта. Полезный был. Мы Builder сейчас нигде не используем. Мы и CMS вообще не используем :)

Однако, что-то из билдера все-таки пригодится еще, чует мое сердце…

UPD 2010-11-29: пока пригодился только опыт серверного программирования вообще.

highlight.js как расширение для Firefox

2008-09-05T00:00:00-07:00

Около года назад заинтересовался библиотекой highlight.js, написанной Иваном Сагалаевым. Да так заинтересовался, что решил обернуть highlight.js в расширение для фаерфокса. Пусть она озаряет код на непросвещенных сайта, подумалось мне тогда. Спустя год вышел Firefox 3.0, который весь чуть-чуть другой. Многие расширения в нем сломались, в том числе и это.

Основное различие между версиями расширения для Firefox 2.0 и 3.0 в том, как подключаются стили и библиотека. Подключать к страничке файлы по протоколу chrome:// теперь нельзя, а надо использовать новый способ с протоколом resources://. Это должно укрепить безопасность, стабильность и вообще. А еще встраивать highlight.js стало значительно удобнее, так как Иван сделал его самостоятельным модулем. Подробнее можете посмотреть в исходниках.

Новое расширение highlighter-4.2.1.xpi для Firefox 3.0.

Старое расширение highlighter-3.5.xpi для Firefox 2.0.

Новенькое в Google AJAX API

2008-09-03T00:00:00-07:00

Теперь можно загружать любой апи по желанию на любом этапе работы скриптов: Dynamic Loading. Раньше можно было только в head, на этапе загрузки (если не подхачить маленько). Даже загрузку самого загрузчика можно отложить.

А еще появилась (UPD 2011-01-10: и куда-то пропала) возможность узнать географическое расположение клиента. Приблизительно, конечно, но зато просто, быстро и бесплатно.

Замена meta imagetoolbar

2008-09-03T00:00:00-07:00

Не хотите ставить meta http-equiv="imagetoolbar" content="no" на всех страницах? Не срабатывает set_header? Тогда поможет экспрешн.


img
{
  scrollbar-highlight-color: expression
  (
    (runtimeStyle.scrollbarHighlightColor = "transparent"),
    (this.galleryImg='no')
  )
}

Ключевой момент — это this.galleryImg='no'. По строкам я разбил для красоты, перед использованием их надо объединить в одну.

MSDN про galleryImg

XHTML шепчу…

2007-10-12T00:00:00-07:00

Сегодня утром вернулся к выводу RSS-ленты на сайте Програмики. И обнаружил, что innerHTML меня не спасает. Что же делать? Решение есть, но сначала хорошенько опишу проблему.

XHTML

С недавних пор мы решили верстать сайты в XHTML. Затея не нова, скажете вы, — сейчас каждый уважающий себя верстальщик все делает по стандартам и о валидности не забывает. Однако, как мы можем узнать из статьи Ивана Сагалаева «XHTML, говорите?», не все так просто, и многие разработчики не подозревают, что верстают вовсе не в режиме XHTML, а в старом добром HTML–режиме. Дело в HTTP-заголовке Content-type, и вся свистопляска начинается только тогда, когда вы вместо привычного text/html дадите браузеру нюхнуть application/xhtml+xml. Или text/xml на худой конец. Браузер сразу обнаружит, что вы, наконец, одумались и выбрали самый современный отформатированный формат документов и сопутствующие ему самые стандартные стандарты. Однако прежней свою страницу вы не увидите. Делов-то, сейчас слеши в конце <br> и <img> поставим, и все. А не все. Когда вы начнете программировать, предварительно исправив разметку, указав пространство имен и разобравшись с кодировкой, вас настигнут бонусные неприятности с передовым форматом. Самое время вернуться к теме поста.

Классическим примером разницы в движках HTML и XHTML было отсутствие у XHTML-элементов свойства innerHTML. То есть загрузить что-то аморфное аяксом и вывести в div стало нельзя. Свойство присваивается, JavaScript ведь этого не запрещает, но реакции никакой нет. Народ стал мучаться с интерфейсами DOMParser и DOMSerializer, чтобы эмулировать любимое свойство. И, честно говоря, некоторый успех был. Позже браузеры научились и сами имитировать innerHTML в режиме XHTML (вероятнее всего тем же способом) и сейчас можно не опасаясь писать нечто вроде $('content').innerHTML = '<h1>Сильно <i>лень</i> городить createElement() и appendChild()</h1>'. Хотя свойство и называется innerHTML на самом деле HTML ему скормить нельзя. Это скорее innerXHTML. То есть такое дело не пройдет: mailDiv.innerHTML = '<p>забудем закрыть "p", поставим неразрывный пробел, а еще картинку вставим <img alt="постринке">'. И что произойдет? В обычном режиме браузер напряжет свои HTML-извилины и догадается о том, что вы имели ввиду. В новом мире XML умен должен быть не браузер, а мы. А сам браузер, как ему и положено, откажется парсить такую гадость и выбросит исключение.

Вот какие исключения бывают:: Firefox 2: An invalid or illegal string was specified; Firefox 3: Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIDOMNSHTMLElement.innerHTML]; Safari 3: NO_MODIFICATION_ALLOWED_ERR: DOM Exception 7

Opera 9 умеет парсить HTML сама. За что нижайший ей поклон.

Великий браузер

Первое решение, которое пришло мне на ум, это поправить разметку простенькими регулярками.


rex = /<(img|br|hr|link|input)(.+?)\/?>/g
markup = markup.replace(rex, '<$1$2/>').replace(/(&nbsp;)/g, ' ')

После этого чать кода заработала. Потом из любопытства поглядел на список сущностей в HTML. А потом попался фрагмент кода с перемешанными тегами. Писать парсер перехотелось. Помучавшись в раздумьях, решил попробовать распарсить HTML на сервере, а потом выдать его как HTML. Идея мне понравилась, по натуре я серверный программист и раньше воспринимал браузер только как дисплей. Потом, правда, одумался.

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

Отступлю немного и отвечу на вопрос, ответ на который вас, возможно, интересует. Почему у меня HTML весь такой кривой и неправильный. Ответ прост как шланг — на нашем блоге мы решили парсить сырую RSS-выдачу. А получаем мы очень вольно составленный HTML.

Так вот. Где же cпрятан парсер HTML, когда у нас все кругом в XHTML? Сегодня получить парсер в лисе, скриптом невозможно. Про вебкит и оперу по запросу "new HTMLDocument()" тоже ничего найти не удалось (искал, правда, спустя рукава — любимчик-то мой уже облажался). XMLParser, как видно из названия, парсит только XML (правда это может быть и XUL, и MathML, и SVG и…). Создать новый HTML-документ с помощью document.implementation.createDocument(…) можно, но будет он XHTML. Конструкция (new DOMParser()).parseFromString("...", "text/html") не сработает, так как DOMParser не поддерживает text/html. Прямо так и пишет: not implemented.

Промучавшись полдня с «крутыми» технологиями, решил попробовать самую простую — спрятать iframe и в него загрузить html-файл. Как мы и рассчитываем window.onload срабатывает когда все загрузится, в том числе и фрейм. Добавлять фрейм можно динамически, но тогда onload может произойти раньше, чем iframe будет готов. Так как я успел и не забыл, браузеры меня вознаградили. Наградой явился объект document, который умеет парсить HTML. Ура!

Как это выгладит в коде? Как всегда было в HTML:


var html = $('htmliframe').contentDocument.firstChild
html.innerHTML = '<div>' + markup + '</div>'

Родные, милые черты...

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


// почистим ноду назначения
while (destination.firstChild)
  destination.removeChild(destination.firstChild)
// склонируем HTML-дерево (в нашем случае див с детьми)
clone = html.firstChild.cloneNode(true)
// вставим див куда надо
content.appendChild(clone)

В будущих версиях браузеров, возможно, надо будет адаптировать ноды clone = document.adoptNode(clone), но пока они на adoptNode ругаются.

Итог

HTML парсится и выводится в Firefox 2, 3 и Safari 3. Opera 9 все умеет сама. IE и Safari 2 не умеют XHTML совсем, но все же умеют клиентский XSL через xml-stylesheet. Получается, мостик между HTML и XML переброшен.