Подлипенский Павел

Думаете, вы знаете JavaScript

paul.nospam@nospam.podlipensky.com (Подлипенский Павел) — Tue, 28 Apr 2009 06:30:00 +0300

Вы бородатый веб разработчик и думаете уже видали всякие чудеса в JavaScript-коде? Хм, чтож тогда следующие задачки для вас.

1. ++Math.PI
2. (0.1 + 0.2) + 0.3 == 0.1 + (0.2 + 0.3)
3. typeof NaN
4. typeof typeof undefined
5. a = {null:null}; typeof a.null;
6. a = "5"; b = "2"; c = a * b;
7. a = "5"; b = 2; c = a+++b;
8. isNaN(1/null)
9. (16).toString(16)
10. 016 * 2
11. ~null
12. "ab c".match(/\b\w\b/)

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

Ответы и решения:

1. 4.141592653589793

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

2. false

Такой же ответ получат и Java разработчики, потому как и Java и JavaScript используют IEEE 754 числа с плавающей точкой. Более подробно об операциях с числами с плавающей точкой можно найти тутаньки.

3. "number"

Логического объяснения этому я не нашел, единственное что могу посоветовать, это стараться использовать isNaN вместо typeof SomePotentialNumber, во избежание казусов.

4. "string"

Тут все просто - первый оператор typeof вернет тип переменной в виде строки, следовательно второй оператор должен вернуть тип результата первого оператора, т.е. string.

5. "object"

Мы присвоили переменной а, объект с полем "null", значение которого null, а это в свою очередь, пусть и специфический, но объект. Другими словами мы тут имеем a.null === null.

6. 10

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

7. 7

Порядок выполнения операндов в Javascript идет слева направо, поэтому мы имеем "а увеличить на 1, а затем сложить с b".

8. false

С этим тоже, думаю, все понятно.

9. 10

toString() принимает числовой параметр (необязательный) и toString(16) означает, что число записано в шестнастеричной системе счисления, посему ответ и 10.

10. 28

016 это восьмеричное представление числа 14 в десятеричной системе счисления.

11. -1

12. [ "c" ]

Отдельно стоящий символ в той строке только один - "с", это и ищет указанное регулярное выражение.

Минимальная зарплата

paul.nospam@nospam.podlipensky.com (Подлипенский Павел) — Mon, 27 Apr 2009 01:34:00 +0300

Думаю все уже в курсе, что у нас кризис (теперь кажется финансовый), впрочем как и у всех. И каждый понимает что ничего хорошего ему это событие не принесет. А одним из "благ" кризиса является минимальная зарплата, т.е. та сумма денег, за которую и вы не против поработать и шефу увольнять вас пока нет повода. Звучит неплохо, правда? Неправда. У большинства людей хорошо развито чувство собственничества, поэтому пока это не мое, мне все равно кто этим владеет, но как только оно стало моим - хрен кто это у меня отберет! А тут такое дело - зарплату понижают! Не буду больше растекаться по древу вот вам поучительный комикс на эту тему:

4 интересных онлайн презентаций для веб-разработчика

paul.nospam@nospam.podlipensky.com (Подлипенский Павел) — Wed, 25 Feb 2009 17:47:42 +0300

1. Ajax 101 | Workshop
Автор: Bill Scott | This presentation on SlideShare
Введение в программирование с помощью Ajax. Включает XMLHttpRequest, XML, JSON, JavaScript, HTML, CSS, Dom Scripting, Event Handling с небольшими примерами на YUI.

Ajax 101 Workshop

View more presentations from Bill Scott. (tags: scripthack mashup)

2. Modular CSS
Автор: Russ Weakley | This presentation on Slide Share
Вполне доступно (даже я понял) объясняется механизм построения ~~правильного~~ модульного CSS, что позволяет прятать/показывать отдельные CSS правила для отдельных браузеров, без различного рода уловок и обходных путей.

Modular CSS

View more presentations from Russ Weakley. (tags: flexible system)

3. jQuery in 15 minutes
Автор: Simon | This presentation on SlideShare
Небольшое введение в JQuery. Функции, коллекции, работа со значениями и цепочками.

jQuery in 15 minutes

View more presentations from simon. (tags: javascript jquery)

4. JavaScript Library Overview
Автор Jeresig | This presentation on SlideShare
Интересный обзор популярных JavaScript библиотек (jquery, prototype, Scriptaculous...) для веб-дизайнеров.

JavaScript Library Overview

View more presentations from jeresig. (tags: dojo prototype)

Video: Layout Engine Internals

paul.nospam@nospam.podlipensky.com (Подлипенский Павел) — Tue, 17 Feb 2009 00:02:25 +0300

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

Скаженi кабани: Оптимизируем операции с DOM'ом

paul.nospam@nospam.podlipensky.com (Подлипенский Павел) — Mon, 16 Feb 2009 02:00:43 +0300

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

когда скрипт выполняет манипуляции с деревом объектов (создает, удаляет или изменяет часть дерева)
если скрипт "заставляет" браузер перерисовывать (redraw) или перестраивать разметку (reflow) страницы
и наконец, в случае когда скрипт "ищет" один из узлов дерева объектов (если дерево большое).

Последний пункт я уже рассматривал в одной из статей своего цикла Скаженi кабани, на примере JQuery. Поэтому сегодня мы поговорим о первых двух. Эм...на самом деле я схитрил, и первый пункт представляет собой ни что иное, как причину появления второго пункта. Тогда сразу перейдем ко второму пункту и попробуем разобраться в терминах перерисовывать и перестраивать разметку:

Перерисовка страницы браузером происходит в случае, когда что-то визуально изменилось, но разметка страницы осталась прежней. Например, изменился цвет элемента или элемент стал видимым/невидимым (с помощью visibility: [hidden, visible], так как это не повлияет на разметку). Эта операция существенно влияет на производительность веб приложения, так как заставляет браузер пройтись по дереву объектов и определить какие элементы видимы и как они должны быть отображены.

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

при первой загрузке страницы. В случае с Firefox, перестройка может происходить несколько раз, по мере докачивания контента страницы;
когда вы добавляете или удаляете элементы DOM'a. Надо сказать, тут есть одно исключение - если вы добавили/удалили объект с абсолютным позиционированием, то это может и не привести к перестройке разметки страницы, так как позиция и размеры других элементов не были изменены;
когда стиль элемента изменен и он влияет на размер и положение этого либо других объектов;
когда вы пытаетесь обратиться к свойствам, требующим вычислений со стороны браузера (например, offsetWidth, clientHeight). А также в случае попытки получить вычисляемые CSS значения (с помощью getComputedStyle() или currentStyle в IE).

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

Mozilla.org

Wikipedia

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

Теперь когда мы в курсе "почему наш сайт тормозит", рассмотрим несколько техник оптимизации работы с DOM'ом. Первое что приходит в голову, это минимизировать количество дорогостоящих операций (описанных выше). А значит, необходимо как можно больше операций совершать вне DOM'а, например используя DocumentFragment.

var products = ... //init array of products
var list = document.getElementById("myProducts"); //find list populate to
for (var i=0; i < products.length; i++){
    var item = document.createElement("li");
    item.appendChild(document.createTextNode("Product" + products[i]);
    list.appendChild(item); // AHTUNG! Operation with DOM
}

Предыдущий код можно оптимизировать следующим образом:

var products = ... //init array of products
var list = document.getElementById("myProducts"); //find list populate to
var fragment = document.createDocumentFragment(); //create document fragment
for (var i=0; i < products.length; i++){
    var item = document.createElement("li");
    item.appendChild(document.createTextNode("Product" + products[i]);
    fragment.appendChild(item); //working with fragment only, not with DOM
}
list.appendChild(fragment); //add fragment to DOM

Эта версия кода затрагивает дерево объектов только раз, в последней строчке. И так как DocumentFragment не имеет визуальной составляющей, то все операции с ним не вызывают ни перерисовки, ни изменения в разметке страницы. Но так как DocumentFragment не может быть добавлен в DOM, то операция appendChild добавит все дочерние элементы фрагмента (вместо того, чтобы добавить сам фрагмент).

Другим, более эффективным подходом, будет работать с элементом, не находящимся в дереве. К примеру, мы можем удалить наш объект из дерева перед выполнением операций над ним (removeChild() или replaceChild())

var products = ... //init array of products
var list = document.getElementById("myProducts"); //find list populate to
var parent = list.parentNode; //find parent
parent.removeChild(list); //remove list element from DOM
var fragment = document.createDocumentFragment(); //create document fragment
for (var i=0; i < products.length; i++){
    var item = document.createElement("li");
    item.appendChild(document.createTextNode("Product " + products[i]);
    list.appendChild(item);
}
parent.appendChild(list);

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

Другой причиной перерисовки или перестройки страницы служат стили и спобосы их назначения элементам. Рассмотрим следующий кусок кода:

element.style.backgroundColor = "white"; //will cause redraw
element.style.color = "red"; //will cause redraw
element.style.fontSize = "12em"; //will cause reflow
element.style.widht = "100px"; //will cause reflow

Как видите первые две строки инициируют перерисовку. Избежать этого можно, если перед изменением стилей скрыть элемент с помощью visibility:hidden или display:none (будет произведено два лишних reflow). Избежать перестройки разметки тут не получиться, но их количество можно уменьшить, если задать все изменения стилей в CSS классе.

.newClass{
	background-color: blue;
	color: red;
	font-size: 12em;
	with: 100px;
}

а затем

element.className = "newClass";

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

var posElem = document.getElementById('animation');
var calcWidth = posElem.offsetWidth;
posElem.style.fontSize = ( calcWidth / 10 ) + 'px';
posElem.firstChild.style.marginLeft = ( calcWidth / 20 ) + 'px';
posElem.style.left = ( ( -1 * calcWidth ) / 2 ) + 'px';
... other changes ...

Полезные ссылки

Notes on HTML Reflow

Dom document fragments

Efficent Javascript (from Opera)

Increasing appendChild Performance with DOM Tricks

Производительность браузеров в зависимости от верстки

paul.nospam@nospam.podlipensky.com (Подлипенский Павел) — Fri, 13 Feb 2009 09:17:04 +0300

Честно говоря раньше не придавал особого значения такой фазе веб-девелопмента, как верстка. Отчасти потому что никогда этим сам не занимался(на должном уровне), отчасти от того, что недопонимал некоторые аспекты веб-разработки. Недавно наткнулся на интересную статью Сергея Чикуенока (из команды никому не известного Артема Лебедева). Суть этой статьи сводится к следующему: если клиентский код работает медленно - убейте дизайнера, верстальщика или кто этим у вас там занимался. Потому как разметка влияет на скорость работы веб-приложения. Кому интересно почитать детали можно в оригинале статьи, а я лишь процитирую выводы:

Для интерактивных элементов лучше использовать position: absolute.
Большое количество элементов на странице может снизить производительность, но не стоит увлекаться их сокращением в ущерб надежности макета.
Не надо делать очень глубоких вложенных структур элементов.
Прежде чем начинать верстку макета, следует узнать, какие интерактивные механизмы там должны быть — это избавит от многих проблем уже на начальном этапе работы над проектом.
Не надо загонять себя в угол глупых стереотипов: «валидность» и «семантичность» никому, кроме самих разработчиков, не нужна.
Не стоит без надобности растягивать картинки. Если это необходимо сделать, следует воспользоваться canvas.
Как правило, img-элемент будет работать гораздо быстрее, чем CSS-свойство background-image.
Помните главное правило: оптимизировать нужно то, что требует оптимизации.

Вот так-то господа, веб разработчики...

Небольшой LINQ пазл

paul.nospam@nospam.podlipensky.com (Подлипенский Павел) — Wed, 11 Feb 2009 10:25:00 +0300

Почему следующий кусок кода генерирует StackOverflowException?

IEnumerable<int> q = new int[] { 1, 2 };

q = from x in new int[] { 1, 2 }

    from y in q

    select x + y;

q.ToArray();

С предложениями, как это исправить - прошу в комментарии ;)

Письмо архитектору

paul.nospam@nospam.podlipensky.com (Подлипенский Павел) — Wed, 11 Feb 2009 09:03:34 +0300

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

Уважаемый Архитектор,

Пожалуйста спланируте и построте мне дом. Я не совсем уверен, что именно мне нужно, поэтому полностью полагаюсь на вас. Тем не менее, у меня есть несколько идей, которые я бы хотел видеть реализованными в моем доме. К примеру, я бы хотел иметь 2 или 44 спальных комнаты. Спланируйте пожалуйста, так чтобы эти комнаты можно было потом легко убрать или добавить, потому что я приму окончательное решение только тогда, когда увижу чертежи. А также оцените финансовые затраты на каждый вариант, чтобы я мог принять правильное решение.

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

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

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

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

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

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

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

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

Заранее неуверен в успехе,

Заказчик

P.S.

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

P.P.S.

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

Все вышенаписанное было создано по мотивам схожего романа и моего личного опыта.

Скаженi кабани: Повышение производительности в браузерах

paul.nospam@nospam.podlipensky.com (Подлипенский Павел) — Tue, 10 Feb 2009 09:01:00 +0300

John Resig, создатель JQuery, совсем недавно провел небольшую презентацию в Гугле. Темой встречи были улучшения производительности в браузерах(в ближайших релизах), некие новшества в Javascirpt движках, новые способы работы с DOM и изумительные эффекты с помощью CSS стилей. Но обо всем по порядку.

Количество процессов на браузер

Одним из интереснейших нововведений в IE8 и Chrome стало то, что теперь вкладки разделены на несколько процессов. Это дает огромное преимущество в производительности, так как теперь различные веб страницы могут загружаться и исполняться параллельно, не отнимая машинных ресурсов друг у друга. В тоже время такие браузеры как FF, Opera и более старые версии IE загружают/исполняют несколько страниц в одном процессе (различные страницы выполняются отдельными потоками).

Позвольте я поясню, каким же образом происходит разделение вкладок на процессы в Internet Explorer 8. Но для начала давайте вспомним модель процессов IE7:

Как видите, каждое окно браузера (UI Frame) находиться в отдельном процессе. Хотя, надо сказать, тут есть одно исключение - если вы нажмете CTRL+N, то новый UI фрейм создастся в том же процессе. Закладки, расширения браузера (toolbar extensions), вспомагательные объекты и ActiveX контролы находятся в том же процессе, что и UI фрейм. Проблема такой модели в том, что любая фатальная ошибка (например stack overflow) в одной из закладок приведет к закрытию всех закладок в этом процессе.

Рассмотрим модель процессов в IE8:

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

И так как закладки изолированы от UI фрейма, то фатальная ошибка в одной из закладок приведет к закрытию всех закладок в этом процессе, но окно браузера останется открытым. Зачем нам это нужно? А для того, чтобы браузер (UI Frame) имел возможность восстановить закрытые вкладки. Но вернемся к разделению вкладок на процессы. Как вы наверное уже успели заметить закладки разделяются на процессы по принципу принадлежности к одной из моделей безопасности (medium IL или low IL). Это накладывало некоторые ограничения на процесс(окно браузера) и когда вы, например, открыли Интранет страницу в одной вкладке, а затем пытались открыть Интернет страницу в другой, то браузер вам сообщал: "Internet Explorer needs to display this webpage in a new window". Это происходило по той причине, что данный процесс(а следовательно и данное окно браузера) имело определенные security-ограничения в отношении страниц, которые он отображал. Теперь, вы можете открывать страницы с разными уровнями безопасности в одном окне.

Боюсь ввести вас в заблуждение, что и Chrome работает по тому же принципу, что и IE 8 (раз эта фича была объявлена для обоих браузеров в одном предложении ранее). Поэтому вкратце расскажу как это происходит в гугловом браузере.

Chrome создает три типа процессов:

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

Отрисовщик (Renderer). Прости господи меня за такой перевод, но этот тип процессов действительно отвечает за обработку HTML, Javascript, CSS, картинок и много чего еще. Причем эти процессы не имеют доступа ни к вашему диску, ни к сетевым ресурсам. Все взаимодействия с пользователем, а также отрисовка на дисплее лежит на процессе типа Браузер. Такое разделение на процессы позволяет сразу убивать подозрительные процессы, которые могли быть подвержены различного рода атакам.

Плагины. Процесс браузера также создает по одному процессу для каждого типа плагина: Flash, Quicktime, Adobe Reader и тп.

Все эти процессы можно увидеть в собственном Chrome Task Managar'e:

Как только Chrome создал процесс типа Браузер, он начинает создавать по одному процессу типа Отрисовщик для каждого веб-сайта, который вы посещаете. Но тут тоже не все так просто, как кажется на первый взгляд. Ведь создавать такое количество процессов было бы весьма расточительно, учитывая то, что создание процесса это весьма трудоемкая и ресурсоемкая операция. Поэтому, если вы открываете новую закладку используюя JavaScript, или если вы открываете страницу с того же сайта, но в новой закладке, то эти закладки будут находиться в одном процессе (типа Отрисовщик). Это позволяет этим страницам на разных вкладках общаться посредством JavaScript и разделять общие закэшированные объекты. Но даже при таком подходе в группировке вкладок в процессы, существует риск создать слишком много процессов и "повесить" систему. Поэтому разработчики ввели ограничение на количество процессов, это число зависит от ресурсов вашей машины, но в среднем оно не превышает 20.

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

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

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

Полезные ссылки

IE8 and Loosely-Coupled IE (LCIE)

IE8 and Reliability

Группировка вкладок в IE8

Multi-process Chrome Architecture

NHaml. Что это такое и с чем его едят.

paul.nospam@nospam.podlipensky.com (Подлипенский Павел) — Sun, 08 Feb 2009 23:17:17 +0300

NHaml это .NET реализация популярного Rails Haml. Поэтому, сначала давайте попробуем понять что такое Haml. Расшифровывается он как XHTML Abstraction Markup Language, то есть это язык разметки для упрощёной генерации XHTML. В нашем арсенале уже имеются средства для достижения подобных целей: XSLT, ASP.NET Web Forms или даже лучше ASP.NET MVC и др. NHaml предоставляет альтернативный способ построения разметки ваших страниц, причем если сам XHTML весьма многословный язык, то NHaml пронизан духом лаконичности. Сокращения, ключевые слова, обозначение блоков — все направлено на сокращение объема кода при максимальном сохранении его ясности. Давайте рассмотрим следующий кусок кода:

ASP.NET MVC (винегрет из кода и html)

<%@ Page Language="C#" MasterPageFile="~/Views/Shared/Site.Master" AutoEventWireup="true"
    CodeBehind="List.aspx" Inherits="MvcApplication5.Views.Products.List" Title="Products" %>
<asp:Content ContentPlaceHolderID="MainContentPlaceHolder" runat="server">
<h2><%= ViewData.CategoryName %></h2>
<ul>
    <% foreach (var product in ViewData.Products) { %>
      <li>
        <%= product.ProductName %>
        <div class="editlink">
          (<%= Html.ActionLink("Edit", new { Action="Edit", ID=product.ProductID })%>)
        </div>
      </li>
    <% } %>
</ul>
<%= Html.ActionLink("Add New Product", new { Action="New" }) %>
</asp:Content>

Эту же разметку (причем сохранив логику ее построения) можно написать и так:

NHaml

%h2= ViewData.CategoryName
%ul
  - foreach (var product in ViewData.Products)
    %li
      = product.ProductName 
      .editlink
        = Html.ActionLink("Edit", new { Action="Edit", ID=product.ProductID })
= Html.ActionLink("Add New Product", new { Action="New" })

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

%one
    %two
      %three Hey there

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

  <one>
    <two>
      <three>Hey there</three>
    </two>
  </one>

Можно по-разному относиться к Python’овскому стилю обозначения блоков, но нельзя не признать, что этот способ гораздо удачнее, чем закрывающие теги, используемые в HTML. Во-вторых, первый символ (не считая отсупов) может описывать способ обработки этой строки. К примеру, символ "%" указывает на то, что это XHTML тег. Эти директивы называются правилами разметки и почти совпадают с подобными правилами в родном Haml. Радует и то, что практически все директивы состоят из одного символа (%, =, -, ., #) и во многом похожи(по назначению) на аналогичные CSS директивы, что упрощает освоение языка. А любители верстки div-ами могут наслаждаться тем, что div является тегом по умолчанию, например #header и %div#header - одно и тоже.

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

Таким образом, проблема продуктивного создания HTML-кода является одной из ключевых проблем повышения продуктивности веб-разработки вообще. Не уверен, что NHaml сейчас имеет смысл использовать в коммерческих проектах, так как это еще молодая технология (родилась она где-то в 2007 году). И, как свойственно молодым технологиям (тому же Silverlight), Nhaml довольно радикально меняется от версии к версии. Но, тем не менее, я полагаю, что существует четкая тенденция развития языков разметки в сторону упрощения чтения и редактирования человеком. И хотя, предсказание будущего — штука неблагодарная, особенно в области высоких технологий, осмелюсь сделать ставку на эту (или весьма похожую) технологию построения разметки страниц.

Полезные ссылки

Introducing MonoRail NHAML

Using NHaml, from Source

Use the NHaml View Engine

Блог одного из разработчиков этой технологии

Как отключить JQuery анимацию одним ударом

paul.nospam@nospam.podlipensky.com (Подлипенский Павел) — Fri, 06 Feb 2009 09:04:00 +0300

Вчера набрел на настройку jQuery.fx.off в соотв. документации. Эта штука позволяет отключить любую анимацию jQuery на всей странице. Выглядит это примерно так:


jQuery.fx.off = true;

$("input").click(function(){

$("div").toggle("slow");

});

После нажатия на кнопочку, ваш div появиться/спрячется незамедлительно, без какой либо анимации.

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

Как не забыть об console.log?

paul.nospam@nospam.podlipensky.com (Подлипенский Павел) — Thu, 05 Feb 2009 16:05:00 +0300

Одной из моих излюбленных фич в Firebug является console.log. Полагаю, у меня есть единомышленники. И мы (я и мои единомышленники) часто забываем в коде, на продакшин серверах, наши излюбленные console.log. А пользователи, не поставившие себе Firebug, лицезреют некоторые Javascript ошибки... Решением данной проблемы могут быть либо таблетки от склероза (если такие уже придумали) или иммитация console объектов и методов. Выглядит это примерно следующим образом:


if (!window.console || !console.firebug)
{
var names = ["log", "debug", "info", "warn", "error", "assert", "dir", "dirxml",
"group", "groupEnd", "time", "timeEnd", "count", "trace", "profile", "profileEnd"];
window.console = {};
for (var i = 0; i < names.length; ++i)
window.console[names[i]] = function() {}
}

Этот код можно смело копировать в ваши javacript библиотеки и просто куски кода. Также можно просто сослаться на


<!-- graceful degradation of firebugs console obj -->
<script type="text/javascript" src="http://www.getfirebug.com/firebug/firebugx.js"></script>

После чего можно смело писать так


console.error('an error'); 
console.warn('a warning');

Или даже так:


console.dir({thanks:'for', reading:'that', cool:function(){ alert('being cool'); }});

P.S.

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

Полезные ссылки

http://getfirebug.com/console.html

Google Code - Fun with Firebug

Дорогие мои подписчики...

paul.nospam@nospam.podlipensky.com (Подлипенский Павел) — Tue, 20 Jan 2009 16:26:00 +0300

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

Убей Javascript - спаси Киловатт

paul.nospam@nospam.podlipensky.com (Подлипенский Павел) — Tue, 30 Dec 2008 09:12:00 +0300

Не знаю, то ли под влиянием финансового кризиса, то ли из-за нехватки керосина для своих компьютеров, но амеры посчитали сколько электроенергии уходит на просмотр веб-страниц. Причем калькулировали с учетом браузеров и технологий, используемых на странице. В среднем просмотр одной страницы без Flash, Javascript и Silverlight обходиться ближайшей электростанции в .382 Ампер (45.076 Ватт). А вот какое безобразие твориться, если смотреть полноценные страницы с рекламой и всякими финтифлюшками:

Browser	Amperage	Watts
Average across entire Alexa 100 in Internet Explorer 7.0	0.414	48.852
Average across entire Alexa 100 in Firefox 3.0.4	0.406	47.908
Average for top 10 power abusers in Internet Explorer 7.0	0.474	55.932
Average for top 10 power abusers in Firefox 3.0.4	0.481	56.758
Average for top 10 power abusers in Firefox 3.0.4 with NoScript and Adblock Plus	0.382	45.076

Также было подсчитано, что на сэкономленные фаерфоксом(за счет отключенного JavaScript и Flash) 0,1 Ампер и почти 11 Ватт, можно зажечь флюоресцентную лампочку!

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

Скаженi кабани: GridView vs Response.Write

paul.nospam@nospam.podlipensky.com (Подлипенский Павел) — Mon, 29 Dec 2008 09:04:00 +0300

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

Что-то случилось...

... понял я, когда в час ночи зазвонил мой телефон. Сквозь сон я выслушал все новогодние "пожелания" заказчика и краткое описание проблемы - "Страница медленно работает". Затем пока нашел штаны, пока нашел где у меня ноги, пока оделся и, спустя часы, я оказался на работе. Нагрузочное (или даже стресc-тестирование) показало, что страница действительно забирает 90% процессорного времени при больших объемах данных на ней. После небольшого разбирательства выяснилось, что показания %Time in GC счетчика производительности меньше оптимальных. После чего наш консилиум заключил, что приложение нерационально использует оперативную память сервера.

MSDN говорит:

.NET CLR Memory\% Time in GC

Threshold: This counter should average about 5 percent for most applications when the CPU is 70 percent busy, with occasional peaks. As the CPU load increases, so does the percentage of time spent performing garbage collection. Keep this in mind when you measure the CPU.

Significance: This counter indicates the percentage of elapsed time spent performing a garbage collection since the last garbage collection cycle. The most common cause of a high value is making too many allocations, which may be the case if you are allocating on a per-request basis for ASP.NET applications. You need to study the allocation profile for your application if this counter shows a higher value.

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

Пути решения

Байндить коллекции сразу GridView, без конвертации в DataTable
Создавать DataTable сразу из XML файла, минуя коллекции во избежания больших циклов и конвертации типов
Использовать XSLT для трансофрмации XML в HTML таблицу (нафиг тогда вообще ASP.NET?)
Использовать Response.Write(), как это предлагает сделать Майкрософт

Решили попробовать последнее.

В результате получили следующее:

GridView	Response.Write()

Интересные результаты, неправда ли? И хотя мы выиграли в производительности мы проиграли как минимум в удобстве и безопасности: GridView не просто рендерит таблицу, а и реализует некий функционал для управления и взаимодействия с данными в ней. А также делает проверки на cross-site scripting и другие виды атак. Так, что настаивать на Response.Write не буду. Решение использовать зависит от конкретной ситуации и пожеланий вашего заказчика.

Полезные ссылки

Improving ASP.NET Performance

Measuring .NET Application Performance

Code Review: .NET Application Performance