Казалось бы ничего криминального здесь нет, чтобы получить во внутренней функции указатель this, вводим дополнительную переменную “that” и благополучно используем ее в функции. Но есть одно “но”, иногда this.title и that.title воспринимаются как две разные переменные и в результате появляются ошибки.

Работая с фреймворком ExtJS, я обратил внимание, что часто в исходниках ExtJS вместо указателя this используется переменная “me“, которая является указателем на this . Т.е. фактически this используется только один раз - при определении переменной me, а потом (в пределах функции) уже не используется.

Думаю что, по задумке разработчиков это решение используется с целью экономии, ведь me на целых два байта короче чем this. Но кроме экономии есть еще один плюс, который возникает при работе с замыканиями - независимо от того где пишется код во внешней или внутренней функции у программиста переменная “me” четко ассоциируется с внешней функцией и шансов сделать ошибку (как в случае с this и that) становится меньше.

Вот как это выглядит в ExtJS:

Мне интересно, что скажет общественность, по этому поводу. Возможно мои умозаключения - не более чем бред кодо-параноика, который видит смысл там где его нет :-)?

Проблема заключается в том, что при выполнении foreach у нас в элементе $item хранится указатель на указатель текущего элемента в DirectoryIterator. Получить этот указатель можно с помощью функции $dirTree->current(). Таким образом, при изменении этого самого внутреннего указателя изменяется и результат выполнения команды getFilename. А так как после выполнения Foreach указатель смотрит на несуществующий (null) элемент итератора, то getFilename возвращает пустое значение.

Пока я ничего лучше не придумал, чем копировать $item с помощью метода clone:

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

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

Для проверки я написал простенький скрипт:

function a() {
        for (var i = 0; i < 100000; i++) {
                var n = parseInt('AAAA');
                isNaN(n); // true
        }
}

function b() {
        for (var i = 0; i < 100000; i++) {
                var n = parseInt('AAAA');
                'NaN' == n.toString() ; // true
        }
}

a();
b();

Чтобы не заморачиваться на измерение скорости средствами JavaScript использовал профилирование встроенное в плагин FireBug.

После проведение замеров FireBug показал следующее:

 функция b() - 32 мс
 функция a() - 13 мс.

Получается, что isNaN() работает быстрее более чем в два раза!

Ради справедливости стоит отметить,что в других браузерах результаты могут быть иными, возможно даже в более старой версии FireFox-а выигрыш будет на стороне toString(). Но в FireFox 3.6 ситуация такая как я описал выше.

Если кто-то может привести данные о времени работы аналогичного кода для Оперы и IE милости прошу отписаться в комментариях.

Из сказанного выше, можно сделать вывод, что для работы в FireFox лучше использовать функцию isNaN. Но значит ли, что не существует другого более быстрого способа проверить число на NaN?

Чтобы ответить на данный вопрос, я решил провести еще пару экспериментов.

Первое, что пришло мне на ум — это изменить способ перевода числа в строку, для этого я заменил код n.toString() == ‘NaN’ на n + ” === ’NaN’; в результате функция b(); стала выполняться на 5мс быстрее. Но функция isNaN() все равно работала значительно лучше.

Второе решение, я нашел в интернете и заключается оно в том, чтобы проверить равно ли число само себе, а точнее не равно ли оно само себе:

var n = parseInt('AAAA');
 n != n // true

Я уже писал об особенностях числа NaN одно из которых заключается в том, что NaN не равно самому себе, таким образом сравнение n != n будет истинным только в случае когда n равно NaN.

Чтобы проверить указанный метод. Я заменил проверку toString() на n != n и запустил профилирование повторно. В результате были получены следующие значения:

 функция a() - 13 мс
 функция b() - 8 мс (!)

Таким образом, на сегодняшний день самый быстрый способ (известный мне) проверить число на значение NaN — это выполнить проверку n != n.

Например, в JS есть такое значение — NaN расшифровывается как Not A Number. Обычно это значение возвращается при ошибке выполнения операций с числами.

parseInt('AAAA'); // NaN
parseInt('1'); // 1
parseInt('16 somthing else'); // 16 — неожиданно, правда?

В данном примере, при выполнении первой операции функция parseInt не смогла преобразовать строку в число и поэтому вернула значения NaN. А вот в 3-ей строке, все прошло успешно, что кажется мне не совсем логичным.

Другие фокусы, которые выкидывает JavaScript хорошо демонстрирует следующий пример:

NaN == NaN; // false
NaN != NaN; // true
NaN > NaN; // false
NaN < NaN; // false

typeof NaN === 'number';  // true

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

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

function sum(a, b) {
        a = parseInt(a, 10);
        b = parseInt(b, 10);
        if (a == NaN || b == NaN) {
                alert('Ошибка');
                return 0; 
        }
        return a+b;
}

sum('1', 'bbbb');  // NaN

Причина, в том, что сравнение a == NaN || b == NaN — всегда будет возвращать false, даже если a или b будут иметь значение NaN.

Для того, чтобы узнать содержит ли переменная значение NaN используется функция isNaN:

isNaN(NaN); // true
isNaN('AAAA'); // true
isNaN('0'); // false

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

function isNum(v) {
        return typeof v === 'number' && isFinite(v);
}

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

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

var a
var b

Во время выполнения он будет преобразован к следующем виду:

var a;
var b;

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

Для примера возьмем следующий код:

function a() {
return 
        false;
}

Не трудно догадаться, что в данной ситуации программист хотел чтобы функция возвращала значение «false». Но на самом деле она возвращает значение «undefined». И это вполне закономерно, потому что реально исполняется совсем другой код:

function a() {
return ; // Обратите внимание JS сам доставил «недостающий» знак точки с запятой
        false;
}

Самое простое, что можно сделать для избежания проблем с Semicolon insertion — это не разрывать строки на две подстроки. Но и этого будет недостаточно, для написания абсолютно безопасного кода.

Синтаксис JavaScript очень похож на синтаксис языка «Си». Например, для выделения блоков когда в JS как и в «Си» используются фигурные скобки.

Обычно программисты предпочитают один из двух вариантов оформления.

Первый — это когда открывающая фигурная скобка находится на одном уровне с конструкцией к которой она относится:

function a() {
        return {
                value: false
        }
}

Второй - когда открывающую скобку помещают на уровень ниже

function a() 
{
        return 
        {
                value: false
        }
}

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

function a() 
{
        return ;
        value: 
                false;
}

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

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

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

В плане размера все браузеры показали примерно одинаковые результаты - 4096 симовлов (это включая знак равенства и имя самой куки). Что касается количества, то тут результаты разные:

 FireFox 3 - 50 куков на домен;
 Opera 9 - 30 куков на домен;
 InternetExplorer - 50 куков на домен. (напомню, что в IE6 можно было хранить не более 20 куков на домен)

Затем, мне стало интересно, а что будет если количество куков, полученных от сервера, превысит указанные ограничения. Логично предположить, что в таком случае браузер удалит самую старую куку и добавит одну из новых. Данное предположение оказалось истинным только для IE8 и Opera 9, а вот FireFox повел себя странным образом начав удалять куки в произвольном порядке.

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

Прежде чем я приведу результаты проверки, пара слов о том как я ее проводил. Для имитации большого числа различных доменов, я внес в файл хостов (hosts) порядка 30 тыс. доменов, следующего вида “www.dXXXXX.ru”, где вместо XXXXX - указывается порядковый номер домена. Затем, с помощью небольшого скрипта на JS, загруженного в браузере, я последовательно обошел все домены и установил максимально разрешенное количество куков. После чего, другим скриптом проверил какие куки были сохранены.

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

 FireFox 3 - 3000 куков;
 Opera 9 - 65535 куков;
 InternetExplorer - неограниченное число куков (мне надоело проверять после того как были успешно установлено 150 тыс. куков).

Честно говоря, меня очень разочаровал показатель полученный в FireFox, ведь при установке 50 куков на один домен можно хранить информацию только от 60 сайтов, а это мало. С другой стороны, на практике даже скромного значения в 3000 куков оказывается вполне достаточно. Главное понимать для чего нужны куки и как их правильно использовать.

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

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

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

После недолгих изысканий выяснилось, что для указания таблицы с данными используется специальная переменная $useTable. Если значение переменной не задано (равно null), то фреймворк подставляет его самостоятельно. В случае, если имя таблицы в базе отлично от имени самого модуля, необходимо самостоятельно задать значение переменной $useTable. Если таблицы нет, то нужно присвоить переменной значение false.

Важный момент, при создании модуля через “CakePHP console” невозможно создать модуль без привязки к таблице. Точнее возможность есть, только реализована она некорректно. Поясню более детально. Допустим мы создаем модуль “test”, тогда в консоли будет задан следующий вопрос:

Given your model named ‘test’, Cake would expect a database table named tests
Do you want to use this table? (y/n)

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

What is the name of the table (enter “null” to use NO table)?

Если при ответе на данный вопрос ввести “null” (как сказано в подсказке), то в модуль будет добавлена следующая строка:

Что CakePHP понимает как необходимость обратиться к таблице с именем “null”, такой таблице в базе, естественно нет, в результате выдается ошибка.

Или вот еще одна особенность, связанная с привязкой модуля к контроллеру. Контроллер автоматически пытается найти принадлежащий ему модуль, но тут есть одна деталь, если имя контроллера заканчивается на ’s’, то CakePHP обрежет эту букву и получившееся имя будет воспринимать как название модуля. Например: если имя контроллера - blogs, то имя модуля - blog. Чтобы указать имя модуля в явном виде, нужно в контроллере задать переменную $uses и присвоить имя нужного модуля.

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

Например, на то, чтобы понять, почему модуль созданный чере “CakePHP console”, категорически отказывается работать, у меня ушло больше половины рабочего дня. А всего-то надо было заменить $useTable = ‘null’; на $useTable = false;.

Так что пока CodeIgniter как-то ближе, и намного понятнее!

На самом деле очень забавно пытаться придумать красивое доменное имя на родном языке. При этом стараться не строить описательные имена, а вместо этого найти короткое словечко, бьющее прямо в цель. В итоге я остановился только на двух именах “баг.net” и “веб-программирование.com”, которые благополучно скупил.

Уже в процессе покупки мне пришло в голову, что если запомнить такие доменные имена несложно, то вводить в строку браузер информацию на двух языках неудобно - имя вводишь на русском, а зону “COM” или “NET” на английском (где-то читал про алиасы с com на ком, но есть ли такое на самом деле не знаю). Я успокоил себя мыслю, что в большинстве случае никто вручную не вводит адреса сайтов. А если и вводят то делают это не так часто чтобы запариться.

Еще не понравилась цена 600р. - для COM и 450р. - для NET. Я уже давно покупаю домены за 110р. у Саши Гоголева. Поэтому, жаба немного зажала. Так что если знаете дешевых регистраторов русскоязычных доменов милости прошу в комментарии.

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

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