Advanced Programming Features

proto для стандартных конструкторов

2012-01-21T07:12:00.000-08:00

Сегодня слушателями курса по JavaScript сподвигли меня на написание очередной заплатки для IE. В статье "__proto__ во всех браузерах" я уже приводил код для вставки ссылки __proto__ в любой объект. Теперь настала пора вспомнить о стандартных конструкторах JavaScript - у них соответствующие ссылки так же должны вести в правильные места:

if (!Object.hasOwnProperty('__proto__')) {
 Object.prototype.__proto__ = null;
 Object.__proto__ =
 Function.__proto__ =
 Date.__proto__ =
 Number.__proto__ =
 String.__proto__
 Boolean.__proto__ = Function.prototype;
}

Только не спрашивайте, зачем это может быть нужно в реальном проекте - не знаю. :)

Задержка выхода второй версии библиотеки Drag&Drop

2011-11-22T06:58:00.001-08:00

Извиняюсь за задержку с выходом второй версии библиотеки - знаю, что обещал, знаю, что моя вина. Но поймите и Вы меня - дело в том, что когда я уже вносил в неё последние штришки, готовясь сегодня-завтра опубликовать проект, случайно услышал о HTML5 Drag&Drop`е. В итоге я встал перед дилеммой - добивать эту версию со своим собственным интерфейсом, или переделывать её для того, что бы она поддерживала стандартный, но пока ещё мало где (по утверждению W3Schools, пока только в Chrom`е и Safari) реализованный интерфейс HTML5 Drag&Drop. После некоторых колебаний я решил, что теперь, после появления этой спеки, библиотека с собственным интерфейсом для Drag&Drop мало кого заинтересует, так что я решил выбрать последнее.

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

Так же для пользователей первой версии библиотеки, возможно, будет нужна обратная совместимость - поддержка интерфейса первой версии, благо реализовать её не сложно, а так же с помощью Google Closure Compiler`а выкинуть её в случае необходимости не представляется сложным, просто подложив другие экстерны.

К сожалению, работа отнимает довольно много времени. Похоже, успею выпустить библиотечку не раньше февраля. За то она будет HTML5-совместима! :)

Коллекции в JavaScript - допиливаем setAddEventListener

2011-11-10T01:51:00.000-08:00

Иногда Java-программистам в JavaScript`е не хватает коллекций. Давайте разберёмся - как можно в JavaScript без написания громоздких тяжеловесных решений обойти ситуацию, для которой нам могла бы понадобиться коллекция?

Итак, в Java есть три типа коллекций - List, Set и Map.

Эмулируем List

Строго говоря, как таковая эмуляция List`а в JavaScript нам в общем-то и не нужна - по сути ей и является массив (Array). Собственно, List`ы и в Java-то нам были нужны лишь исключительно по той причине, что массивы в Java имеют чёткий заранее определённый размер, который не может быть изменён, а по задаче мы не всегда можем сказать, массив какого размера нам понадобится. Т.к. в JavaScript такой проблемы нет - нет и необходимости создавать этот тип коллекций специально.

Эмулируем Set

Множество (Set) уникальных значений в JavaScript можно составить на основании того же массива (Array) с добавлением метода, который проверял бы уникальность добавляемого значения:

/** Определяет индекс элемента в массиве.
 * @param {Object} value
 * @return {number} индекс переданного объекта, если тот содержится в массиве.
 * Если он в нём отсутствует, возарвщается -1. */
Array.prototype.indexOf = function(value) 
{
 var /** @type {number} */ length = this.length;
 for (var /** @type {number} */ i = 0; i < length; i++)
  if (this[i] == value)
   return i;
 return -1;
};
/** Определяет, содержит лимассив переданный объект.
 * @param {Object} value
 * @return {boolean} */
Array.prototype.contains = function(value) 
{
 return this.indexOf(value) === -1;
};

Теперь достаточно просто перед добавлением элемента проверять его методом contains - для простых зазачь этого вполне хватит.

Эмуляция Map

С коллекциями типа map будет немного сложнее. В принципе, для наиболее частого случая, когда в качестве ключей нас устроят строки, решение тривиально - это Object. Т.е. создаём объект - он и есть наша карта. Его свойства - это ключи, а их значения - это значения полей коллекции.

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

Пример эмуляции Map

Например, в одной из недавних статей, где я рассматривал шаблон "Заплатка", я писал о методе создать на основе механизма навешивания слушателей в IE6-8 (attachEvent) стандартный механизм навешивания слушателей (addEventListener). Решение, напомню, было таким:

function setAddEventListener()
{
    if ('attachEvent' in this && !('addEventListener' in this))
        this.addEventListener = function(eventName, handler, isCapturing) {
            if (isCapturing)
                throw new Error("We are in IE, so we haven`t way to set event listener on capturing phase of any event to any of HTML-elements");
            attachEvent("on" + eventName, handler);
        }
}
setAddEventListener.call(document);//Для document`а, например, вызываем так

Однако, если подходить серьёзно, то с этим решением в реальном проекте будет некоторое количество проблем. Первая из них - неполная совместимость IE`шного объекта Event и стандартного. Путь для решения этой проблемы я уже демонстрировал в статье про pattern "Enrichment". Напомню, что там получилось:

/** Конструктор, служащий для придания не совместимым с W3C DOM level 3 объектам
 * Event стандартного поведения.
 * @constructor
 * @extends Event */
function EventW3C() {
    /** Отменяет поведение браузера для данного события по-умолчанию. */
    this.preventDefault = function() {
        this.returnValue = false;
    };
    // Выставление других стандартных свойств

    return this;
}
function setAddEventListener()
{
    if ('attachEvent' in this && !('addEventListener' in this))
        this.addEventListener = function(eventName, handler, isCapturing) {
            if (isCapturing)
                throw new Error("We are in IE, so we haven`t way to set event listener on capturing phase of any event to any of HTML-elements");
            attachEvent("on" + eventName, function() {
                handler(EventW3C.call(event) //Здесь используется pattern "Enrichment"
            });
        }
}

Вторая проблема - ссылка this. В обработчик IE6-8 по ней не передаётся элемент, с которым связано событие. Решение простое - запомнить ссылку на элемент в отдельной переменной в замыкании и передать её в качестве ссылки this обработчику при помощи метода call объекта Function:

function setAddEventListener()
{
    if ('attachEvent' in this && !('addEventListener' in this))
        this.addEventListener = function(eventName, handler, isCapturing) {
            if (isCapturing)
                throw new Error("We are in IE, so we haven`t way to set event listener on capturing phase of any event to any of HTML-elements");

                //Запоминаем элемент
                var /** @type Element */ that = this;

                this.attachEvent(
                    'on' + eventName, function() {
                        handler.call(that, EventW3C.call(event));//Правильно вызываем обработчик
                    }
                );
        }
}

При этом приёме, правда, как утверждает Д.Флэнаган, есть проблема с утечкой памяти в ранних версиях IE, но это сейчас out of scope. И, наконец, третья проблема - всплывает, когда мы попытаемся рассмотреть применение механизма удаления обработчика IE6-8 detachEvent для эмуляции стандартного removeEventListener. Дело в том, что т.к. мы используем не сам handler, а функцию, которая его вызывает, то и detach`ить нам нужно её, а не изначальный handler. Соответственно, для удаления нам где-то нужно её найти, так? Но в стандартный метод removeEventListener будет передаваться лишь сам handler. Значит, нам нужно по handler`у найти настраивающую его функцию. Тут-то нам и понадобится коллекция типа Map.

Итак, есть соответствие двух функций и по ключу - одной функции мы должны найти значение - другую функцию, что бы её удалить из обработчиков данного события. Т.к. Map мы эмулируем на основе Object`а, у которого в качестве имён полей, т.е. ключей, традиционно выступают строки, то нам, очевидно, нужен метод, который преобразует объект в уникальную для него строку. В общем случае эта задача не является тривиальной, но в нашем конкретном - какая удача! - для функций, т.е. для объектов Function, этот метод уже есть! И называется он - ни за что не догадаетесь! - toString()! :)))) Этот метод по сути возвращает представление данной функции в виде многострочного текста её определения. Очевидно, что текст определения функции не меняется никогда и он соответствует критерию уникальности для каждой функции, а для одной и той же функции всегда будет возвращать одинаковый результат.

Так что вот какое компактное решение получаем в данном случае:

/** Конструктор, служащий для придания не совместимым с W3C DOM level 3 объектам Event стандартного поведения.
 * @constructor
 * @extends Event */
function EventW3C() {
    /** Отменяет поведение браузера для данного события по-умолчанию. */
    if (!('preventDefault' in this))
        this.preventDefault = function() {
            this.returnValue = false;
        };

    if (!('stopPropagation' in this))
        this.stopPropagation = function(){
            this.cancelBubble = true;
        };

    // Выставление других стандартных свойств

    return this;
}

(/** IE patch for addEventListener and removeEventListener methods. */
function setAddEventListener() {
    if (!('addEventListener' in this))
        if ('attachEvent' in this) {
            var /** Объект-карта всех слушателей данного объекта
                 * @type Object<Object<Function>> */
                fnMap = {};
            this.addEventListener = function(eventName, handler) {
                if (!(eventName in fnMap)) //Если для данного события ещё нет коллекции обработчиков...
                    /**@type Object<Function> */ fnMap[eventName] = {}; //...создаём её
                var /** @type Element */ that = this; //Запоминаем элемент
                this.attachEvent('on' + eventName,
                    fnMap[eventName][handler.toString()] = function() {
                        handler.call(that, EventW3C.call(event));//Правильно вызываем обработчик
                    }
                );
            };
            this.removeEventListener = function(eventName, handler) {
                if (eventName in fnMap && handler.toString() in fnMap[eventName]) {
                    this.detachEvent(
                        'on' + eventName,
                        fnMap[eventName][handler.toString()]
                    );
                    delete fnMap[eventName][handler.toString()];
                }
            };
        }
})(); // Вызываем для window сразу
setAddEventListener.call(document);//Для document`а, например, вызываем так

Браузерные войны – 2 или нас ждёт JSON-Hibernate?

2011-11-09T07:24:00.000-08:00

Прошло примерно полтора года после (первой) публикации мной статьи «Браузерные войны» с анализом рынка развития приложений. Тогда я описал ситуацию такой, какой увидел её на момент начала 2010 года. Теперь, в середине 2011-го, она во многом качественно изменилась. Что же произошло?

Internet Explorer 9 и стандарты W3C

Явно не по доброй воле, хотя маркетологи компании в этом и не признаются, Microsoft всё-таки сделала шаг в сторону реализации стандартов от W3C и ECMA, приведя свой Internet Explorer (IE) в 9-й версии в некоторое соответствие со стандартами. Конечно, о полной победе говорить пока рано. Например, тест ACID3 IE9 проходит лишь на 95%, но, безусловно, это просто несравнимо с 20% от IE8. А учитывая, что даже Mozilla Firefox проходит его лишь на 97%, думаю, можно открывать шампанское!

Правда есть один неприятный момент - IE9 доступен только пользователям Windows Vista и Windows 7. А вот огромной армии пользователей Windows XP, не признающих альтернативных браузеров (а таких "консерваторов" немало), так и придётся сидеть в лучшем случае под IE8.

Просто монополия Microsoft`а имеет одну особенность - эта компания конкурирует сама с собой. Точнее, "Microsoft сегодняшняя" жестоко конкурирует с "Microsoft вчерашней", поскольку главный конкурент новой версии Windows - это старая версия Windows, которая уже куплена громадным количеством пользователей. При этом многие из них резонно сомневаются в том, нужно ли им платить за переход на новую, если их и так всё устраивает? И Windows XP оказался для них очень мощной преградой хотя бы потому, что обладает преимуществами в быстродействии. Это в свою очередь делает его более предпочтительным для многих пользователей с относительно-слабыми машинами. При этом все приложения на данной системе прекрасно выполняются. Никаких проблем нет, если не считать проблемой трудности Microsoft по продвижению Windows 7 на рынок. Microsoft до сих пор не может закрыть поддержку этой системы. А под давлением общественного мнения (думаю, что под ним понимаются не столько простые пользователи, сколько крупные частные корпорации, государственные компании и, главное, военные организации самих США) вынуждена была несколько раз несмотря на свои попытки остановить её, объявить о продлении поддержки (последний раз была обещана поддержка до 2014 года). До сих пор в магазинах компьютерной техники можно купить нетбуки с предустановленной Windows XP.

Так что выпуск IE9, который будет работать только под Vista и Windows 7 - это, по-видимому, шаг в направлении, призванном заставить пользователей перейти на одну из последних версий Windows, приплатив Microsoft`у ещё немного денег - другого объяснения я не вижу. Конечно, Microsoft в этом не признаётся, утверждая, что Windows XP морально устарел и не поддерживает тех высоких технологий, которые были использованы в супер-совершенном браузере IE9. Однако Google Chrome, Mozilla FireFox, Apple Safari и Opera прекрасно поддерживают стандарты W3C и ECMA, которые поддерживает IE9, при этом отлично работают под Windows XP...
Могу лишь предположить, что маркетологи Microsoft почему-то думают, что Web-разработчики на радостях от того, что Microsoft поддержала стандарты, сейчас навояют кучи сайтов под них (которые будут смотреться только в IE9). Потом же огромная масса пользователей, уныло наблюдая, как эти сайты у них глючат, от безысходности поковыляет в сторону магазинов покупать Windows 7, чтобы не потерять для себя "ускользающую красоту" интернета. На мой же взгляд, даже если это произойдёт, таким пользователям будет значительно проще и, главное, дешевле поставить себе какой-либо из бесплатных браузеров, поддерживающих стандарты (Chrome, FireFox, Opera или Safari), чем обновлять ОС.
Но этого, очевидно, не будет. Я уже писал и повторюсь снова: рынок разработки сайтов в высшей степени конкурентен, и заказчики тут определяют значительно больше, чем разработчики. А если коммерческий успех им всё-таки нужен, то при заказе сайтов у дизайн-студий или одиночек-freelancer`ов они будут ориентироваться на статистику использования браузеров пользователями и в соответствии с ней будут определять приоритеты.

Кстати, о статистике. Сбор адекватной статистики в последнее время становится всё более и более сложной задачей. Если раньше основной массой пользователей интернета были представители среднего класса, то сейчас в него активно вливаются и люди достаточно бедные. Интернет действительно постепенно расслаивается на сегменты, соответствующие различным слоям общества. Точнее, не интернет расслаивается, а разные слои общества проникают в интернет. Если даже 2-3 года назад приходилось слышать высказывания медийщиков (например, гл. редактор Russia.Ru), что Internet – это media для среднего класса, и тогда это походило на правду, то теперь мне всё ближе утверждение А.Лебедева о том, что социальные сети – это «Internet для бедных» (такое мнение было недавно высказано им в программе «Бизнес-секреты с Олегом Тиньковым» 21.02.2011).
По-этому если раньше можно было приблизительно ориентироваться на общую статистику использования браузеров в зоне runet`а, то сейчас всё чаще приходится слышать о том, что бы проводить исследования чуть ли не под каждый проект, что бы понять, какими браузерами в основном пользуется target group, на которую этот проект нацелен. И если в первом случае можно найти десяток сайтов, которые дадут более или менее реальную картину, то во втором – это платное исследование, которое часто получится не рентабельным. По хорошему, нужно было бы более или менее рассортировать интернет-пользователей на группы, примерно соответствующие уровню доходов, и определить, какие их доли используют какие браузеры. Тогда для каждой группы можно было бы описать статистику используемых ими браузеров, что бы каждый, кто делает сайт именно для этой группы, мог ориентироваться на неё. Но сайтов с такой стстистикой я, к сожалению, не знаю...

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

В общем, радость, конечно, не полная, но это всё-таки радость. По большому счёту, поддержка стандартов будет, ибо рано или поздно, на IE9 перейдут все пользователи IE. А требование обратной совместимости не позволит Microsoft`у отказаться от поддержки стандартов на том уровне, на котором это реализовано в IE9. Это, кстати, и подтверждает IE10 Tech Preview (уровень поддержки стабилен - ACID3 проходится на 95%, хотя отдельные нововведения, в основном из категории HTML5, постепенно вводятся - их просто ещё не успели внести в тест ACID).

Так же среди изменений за эти полтора года следует отметить резкий рост популярности коммуникаторов и планшетных компьютеров, прежде всего, на базе IPhone OS и Google Android. Ваш покорный слуга уже использует вместо телефона Samsung Galaxy Tab и находит это весьма удобным. Эти устройства так же здорово влияют на рынок и, что весьма приятно, их браузеры изначально ориентированы на поддержку стандартов, т.е. проблем при совместимой разработке под них сайтов особых нет.

Перспективы

И вот, когда я в последнее время думаю о перспективах развития RIA (Rich Internet Applications), SaaS и Облаков, меня всё чаще посещает мысль о том, что в ближайшем будущем клиентская часть Web-приложения могла бы полностью взять на себя выполнение бизнес-логики.
Конечно, у такого перехода будет масса проблем, прежде всего - безопасность и производительность. Ведь у JavaScript даже в последней реализации ECMAScript v.5 существует масса проблем с этим, главным образом потому, что этот язык по-прежнему остаётся интерпретируемым, а значит его алгоритмы легко вскрыть и внедриться в их работу. Однако в последнее время наблюдается настойчивая попытка разработчиков разнообразного инструментария решить все эти проблемы и, надо думать, им это со временем как-нибудь удастся. Ведь за этим стоят не только open-source`ники, в отношении которых скепсис ещё был бы хоть как-то уместен (даже несмотря на вполне достойные продукты типа Lunux`а, PostgreSQL`я, Eclipse`а и JBoss`а), но и такие гиганты индустрии, как Google и Yahoo!.

Почему мне так кажется? Для такой ситуации я вижу несколько предпосылок:

С одной стороны, мы имеем устойчивую тенденцию перехода к модели сервисов, которая, напомню, состоит в том, что персональный компьютер представляет собой лишь терминал, связывающий пользователя с сервером, и все сервисы пользователь через него получает от сервера.
При этом мощности компьютеров падать явно не собираются. Даже специально разработанные для Google Chrome OS ноутбуки (chromebook`и) достаточно мощны (4ГБ ОЗУ, 1,5ГГц`овые AMD-процессоры), не говоря уже о других нетбуках и ноутбуках.

Думаю, последнее обстоятельство связано с тем, что ситуация на рынке производства компьютеров (во многом "благодаря" застою в области web, организованного Microsoft`ом в течение последних 10 лет), уже прошла ту самую "точку невозврата". То есть технологии переразвиты по сравнению с потребностями, а экономия на масштабе для производителя стала перевешивать даже отсутствие реального спроса на вычислительные мощности. Таким образом, мы имеем ситуацию, когда человеку нужен маломощненький компьютер, но он не может его найти на рынке, поскольку произвести такой оказывается чуть-ли не дороже, чем значительно более мощный, запущенный в массовое производство. Так что даже если мощный компьютер будет немного дороже, оказывается проще купить его, чем искать дешевле тот, который нужен, т.е. которого будет достаточно для задач пользователя. А пользователь просто купит, чтобы было "с запасом". Такие явления на рынке называют "экономикой изобилия", в которой спрос уже является не столько источником, сколько следствием предложения, являясь скорее предметом роскоши, нежели необходимости.

Хотя возможно, я ошибаюсь, отводя Microsoft главную роль в этом процессе. Ведь всем известно, что исторически гонка мощностей персоналок по крайней мере у домашних пользователей обеспечивалась, прежде всего, развитием компьютерных игр, всегда столь жадных до вычислительных ресурсов в погоне за реалистичностью, красотой и скоростью отображения виртуальной реальности. Возможно, главную роль в этом процессе сыграли именно они, а, может быть, и что-то третье - тут уже, что называется, можно спорить, но следствие налицо: какими бы ни были причины, мы видим, что не смотря на развитие SaaS и "Облаков", рынок производства более мощных персональных компьютеров набрал слишком большую инерцию, что бы останавливаться и поворачивать вспять. А корпорации-производители железа будут землю рыть, чтобы искать возможности продолжать развитие этого рынка и дальше, ведь ресурсов у них для этого много.

Не исключаю даже, что они давили на Google с его проектом Google Chrome OS, и эта корпорация была вынуждена идти на уступки, что фактически теперь ставит под вопрос судьбу проекта – по крайней мере, по первым отзывам пользователей можно судить, что энтузиазм у людей поугас. Дело-то нешуточное, миллиарды долларов на кону! Было бы наивным полагать, что такой проект, который фактически угрожает привести к значительному сокращению производства компьютеров, так просто дадут осуществить даже такой компании, как они...

И по развитию рынка мобильных телефонов, смартфонов и планшетников мы видим в целом отсутствие минималистических тенденций - те самые игрушки здесь тоже играют если не ведущую, то заметно-важную роль. Несмотря на то, что лидирующие платформы Android и IPhone OS резко теряют преимущества при отсутствии возможности постоянного доступа в Internet (т.е. по сути в них сделано всё, чтобы просто-таки маниакально зависеть от сервисов интернета), мы наблюдаем лишь рост, а отнюдь не падение мощностей всё новых и новых устройств, выбрасываемых на рынок и, главное, пользующихся спросом!

Т.е. идея того, что рынок аппаратных мощностей клиентов сожмётся, в то время как мощности перекочуют на рынок серверов посредством облаков и SaaS - на поверку оказывается не верна. Подъём идёт по обоим этим направлениям. Почему? Я вижу лишь одно объяснение - привычка пользователей работать с шикарными интерфейсами. Эта идея в архитектуре enterprise-систем известна, как подход REST. За неё-то, скорее всего, и постараются ухватиться производители железа!

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

В случае успеха мы с Вами будем наблюдать, как уровень логики на стороне сервера сожмётся до минимума, подвергнется стандартизации и зафиксируется в некоторой спецификации API тех сервисов, которые будет предоставлять для логики клиентской и речь пойдёт о переходе к новой двухзвенной архитектуре. Почему двухуровневой? smile;) Потому, что уровень данных, т.е. БД, никуда, конечно же, не денется. Т.е. у нас снова будет клиент, содержащий всю логику и сервер, содержащий данные.

Даже с учётом наличия в последних браузерах гораздо более мощных средств для хранения данных на стороне клиента - таких, как userData в IE и SharedObject подключаемого Flash-модуля (про несчастные cookies умолчу) - у нас всё равно остаётся вопрос обмена данными с сервером для синхронизации различных web-клиентов между собой. Ведь мы говорим о распределённых приложениях.Конечно, теоретически, механизм синхронизации данных различных web-клиентов может происходить практически без участия сервера, с использованием механизма пиринговых сетей, но разработка механизмов такой синхронизации представляется на сегодняшний день крайне фантастичной и серьёзно об этом говорить, конечно же, слишком рано в силу огромного количества проблем с ними. Думаю, это вопрос даже не ближайшего десятилетия, так что оставим его фантастам. :)

Таким образом, Базы на стороне сервера даже в достаточно длительной перспективе не отомрут, в то время как на серверную логику Web-приложений я бы стратегическую ставку делать не стал. С другой стороны, если ставить вопрос таким образом, то на стороне клиента (т.е. в JavaScript`е) придётся писать большое количество кода для правильного доступа к данным на сервере, управлении транзакциями и прочего, что представляется крайне трудным для этого языка. Поэтому логику работы с данными нужно будет сильно адаптировать для эффективной работы из Web-клиента, максимально её упрощая.

JavaScript-приложения сейчас получают данные в форматах JSON, JSONP и JSONPP, так что, надо думать, интерфейс такой БД должен будет предоставлять данные в одном из этих форматов, либо будет разработан другой, более удобный формат на их основе. Он будет отражать структуру данных, т.е. прототипную реализацию ООП, коя реализована в JavaScript. Т.е. по сути сервер для приложения должен быть ORM Tools`ой на манер Hibernate, только выдавать объекты должен в JSON-подобном формате.

Впрочем, это станет реальным, если победит подход HTML5/SVG/JavaScript, который пока доминирует для RIA. Пока ему не хватает только грамотной поддержки 3D - VRML бесславно сошёл с арены, теперь идёт борьба между X3D от ISO, O3D от Google`а и Universal 3D от ECMA при поддержке ряда корпораций, в числе которых Adobe и HP. Если же победят технологии плагинов типа Silverlite`а или Adobe Flash, то технологически картина будет несколько иной, хотя суть от этого, мне кажется, не сильно изменится - в любом случае производители железа будут гнать нас в русло RIA, иначе им самим несдобровать...

Браузерные войны

2011-11-09T04:18:00.000-08:00

Примерно полтора года назад мной была написана статья, первоначально озаглавленная "Мечты web-разработчика" ( http://se-la-vy.livejournal.com/53173.html ). Немного позже я опубликовал её на сайте AV-School.ru - учебного проекта "Лаборатории Касперского", в которой тогда работал (там материал был скромно озаглавлен "Попытка анализа Браузерных войн" - http://av-school.ru/article/a-152.html ). В этой статье рассматривалась история "Браузерных Войн" и последовавших за ними событий с позиции разработки Web-клиентов (или Web-интерфейсов, что, на мой взгляд, является уже несколько устаревшим названием) в попытке объяснить логику происходивших процессов прежде всего влиянием в целях отстаивания своих интересов на рынке компании Microsoft.
Сейчас я наблюдаю, что ситуация на рынке (главным образом в связи с выходом IE9, а так же с взрывным ростом продаж планшетных компьютеров и коммуникаторов от Apple и на базе Android) частично переломилась и проблема, на которой я заострял внимание, во многом разрешена, хотя выход из этой ситуации создал принципиально-новую конфигурацию рынка c интересными тенденциями, которую я не мог до конца предвидеть полтора года назад.
В связи с этим настало время написать продолжение этой статьи, сделав в ней анализ того, что произошло за эти полтора года и представить картину такой, какой я вижу её в данный момент.Эта статья будет написана и опубликована в ближайшие дни и, учитывая мой переход на работу в Luxoft Training, я решил опубликовать её в этом блоге. Для тех же, кто не читал первой статьи и интересуется развитием рынка RIA (Rich Internet Applications), будет полезно для начала ознакомиться с первоначальной статьёй, каковую я и представляю на Ваш суд...

Существует 2 вида программистов:
те, которые ненавидят Windows и программируют под Unix,
и те, которые ненавидят Windows и программируют под Windows
В.Пелевин

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

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

Тенденции

Примерно 15-20 лет назад наиболее продвинутые, думающие вперёд игроки IT-рынка стали укрепляться в подозрениях о том, что офисные приложения с Web-интерфейсом имеют огромный потенциал для вытеснения с рынка локальных приложений. Это касается доступа к документам, лёгкости их передачи и коллективного их редактирования. Кроме того, логика на стороне сервера разгружает клиентскую машину и она может быть менее мощной, а мощность, сконцентрированная таким образом на сервере даёт экономический выигрышь, т.н. "экономию от масштаба", что было бы весьма ценно для рынка.

Например, практически все приложения, входящие в пакет Microsoft Office, могли бы быть заменены сервисами Internet`а. И так со многим другим - более 70% программ, которыми активно пользуются люди локально, почти ничего не потеряют, за то немало приобретут, будучи перемещёнными в интернет и реализованными как интернет-сервисы.

А лет 10 назад это стало очевидно практически всем серьёзным участникам рынка.

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

Конечно, речь в обозримом будущем не идёт о переносе вообще всех программ в браузер. Например, практически невозможно представить реализацию графических пакетов (таких как Adobe Photoshop), программ работы с 3D-графикой (3D MAX, не говоря уже о Maya), Архитектурных (ArchiCAD) в Web`е. Да что там такие высоты! Есть даже большие сомнения в возможности эффективного переноса разработческого инструментария (Visual Studio, IntelliJ IDEA, Eclipse, Enterprise Architect) в Web.

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

Браузерные войны

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

Примерно в середине-конце 90-х она, обладая монополией на рынке операционных систем (ОС) под клиентские машины (в отличие от рынка ОС для серверов, где рынок ОС намного разнообразнее), вдруг начинает предпринимать действия, которые быстро получили в работах аналитиков рынка название "браузерной войны". Заключались они в том, что они внезапно включились в активную конкурентную борьбу с господствовавшим в середине 90-х интернет-браузером Netscape Navigator (NN). Свой Internet Explorer (IE) у них, конечно, уже был - 3 версия, но никто из участников рынка не рассматривал его всерьёз. Это была фактически маловажная заплатка - должны же они были в состав операционной системы включить хоть какой-никакой браузер! Не было смысла его делать хорошим - просто хоть что-то сделать, что бы как-то худо-бедно отображало текст - и довольно. По сравнению с Netscape Navigator на тот момент он был как Paintbrush по сравнению с Adobe Photoshop, как велосипед по сравнению с автомобилем. Не удивительно, что в то время практически все, кто активно пользовался интернетом, использовали именно NN - в то время это было общей нормой, фактически - стандартом де-факто.

Но уже в IE 4-й версии Microsoft реализовала массу нововведений, традиционно присутствовавших в NN, реализовала стандарты, использующиеся на тот момент в этой отрасли и в придачу к ним реализовала массу дополнительных возможностей, отсутствовавших в стандартах и спорящих с расширениями NN. IE из примитивной игрушки для любителей вдруг превратился в передовой браузер! Полноценный конкурент NN, он его, конечно, не превосходил, но и существенно ему не уступал. Практически все web-разработчики признают, что 4-й и 3-й IE - это просто небо и земля!

Дизайн-студии тут же разделились на два лагеря сторонников NN против сторонников IE и наполнили интернет сайтами, которые на первой странице писали, что "этот сайт рекомендуется просматривать в Netscape Navigator" или, наоборот - "Эта страница лучше смотрится в Internet Explorer" - и рядышком помещалась ссылочка для скачки и последующей бесплатной установки.

И всё бы было хорошо, если бы конкуренция между браузерами была честной и, соответственно, по законам рынка это приводило бы к ускорению развития этой отрасли, но Microsoft использовала в этой конкурентной борьбе один грязный приём, живо поставивший их конкурента на колени. Воспользовавшись своим господством на рынке операционных систем, она прибегла к тому, что в маркетинге называется "пакетной продажей". Она просто включала Internet Explorer в состав операционной системы при её выходе, сделав вид, что он бесплатен. Многие забывают, что бесплатен он только при покупке отнюдь не бесплатной лицензионной Windows, в цену которой на самом деле и входит реальная цена всех имеющихся в её составе программ и уж какая часть цены на Windows является ценой на Internet Explorer - можно только предполагать, однако это не имеет особого смысла, поскольку мы всё равно не можем купить Windows без Internet Explorer`а...

Никто не предлагает вам купить лицензионный Windows без IE и потом, при первой попытке выйти в интернет, скачать какой-нибудь браузер - NN, IE, Opera, Safari или какой-либо другой. Нет, наоборот, если пользователю кто-то со стороны специально не расскажет про то, что есть другие браузеры, он даже не будет знать, что есть что-то другое для хождения в интернете, кроме Internet Explorer`а. По-этому как только к этому прибавляется то качество, что этот самый IE не лучше, но и, в общем-то, не хуже других браузеров - выбор подавляющего большинства очевиден - зачем мне другой браузер, если этот у меня уже есть?

Netscape`у, конечно, ничего больше не оставалось, кроме как объявить в ответ на это свой браузер бесплатным и искать иные способы получения прибыли. Руководству Netscape быстро стало ясно, что при прочих равных Microsoft их вытеснит. Они признали, что это не честная борьба и противопоставить MS`у они могли только на порядок более высокое качество своего продукта.

Антимонопольный комитет

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

Да и что может на самом деле антимонопольный комитет, если даже правительства независимых стран ничего не могут сделать против MS? В качестве примера можно привести поведение MS на рынке ЕС. В начале 2000-х годов правительство ЕС озаботилось аналогичной пакетной продажей на своей территории - MS Windows продавался в комплекте с MediaPlayer`ом и тем самым выдавливал с рынка компании, разрабатывавшие свои проигрыватели музыки. Решением суда Microsoft обязали продавать версию Windows без MediaPlayer`а на территории стран ЕС.

И MS даже выполнила это решение. Она действительно стала продавать Microsoft Windows без Media Player`а на территории стран ЕС! Казалось бы, производители проигрывателей музыки должны были плясать от счастья, но они быстро окончательно разорились и плясать стало некому, кроме хитрой Microsoft, ведь на прилавках европейских магазинов с программным обеспечением рядом продавались две коробки. На одной было написано, что это - Windows без MediaPlayer`а, а на второй - что это Windows с Media Player`ом (ведь речь шла о предоставлении возможности покупателям не покупать MediaPlayer`а вместе с Windows!). И обе эти коробки продавались по одинаковой цене! :)

Вот сами представьте себя европейцем, которому нужна Windows - вы приходите в магазин ПО, и видите Windows с MediaPlayer`ом и без него по одинаковой цене - что вы купите? :)

Вопрос о том, почему антимонопольный комитет так неэффективно сработал в этом случае - вопрос на самом деле интересный. Лично мне сложно это объяснить, не прибегая к пресловутой "теории заговора". Единственное объяснение, которое приходит на ум - в работу антимонопольного комитета по этому делу вмешались люди из правительства США. Ведь Microsoft - одни из крупнейших налогоплательщиков и так как его бизнес носит во многом и международный характер, то и налоги эта компания платит из доходов, получаемых в том числе на рынках Европы, Азии и Южной Америки. Следовательно, монополия на этом рынке обеспечивает правительству весьма немалый доход в виде налогов. Стремление же создать справедливый и честный рынок браузеров запросто могло привести к потере этой монополии и появлению сильных игроков на рынке, например, Европы, с которых налоги будет получать уже Европейский Союз и они будут идти мимо кошелька США. А если они ещё и захватят рынок США, так и вообще - деньги США начнут утекать из этой страны и оседать в карманах европейских корпораций и правительств.

К тому же так удобно всегда иметь под рукой справедливый повод придраться к такой крупной корпорации, что бы время от времени заставлять её идти на некоторые уступки, если вдруг её действия не понравятся политикам из Вашингтона... :)

Окончание браузерных войн

Поняв всё это, руководство Netscape в целях резкого повышения качества своего браузера принимает решение, ставшее для них роковым - решение переписать свой браузер полностью, с нуля. Теперь во многих статьях и книгах по управлению IT проектами это решение приводится как иллюстрация того, как не надо делать - переписывание заняло 2 года, в течении которых был выпущен Internet Explorer 5 (и даже, если не изменяет память, 5.5), последняя же версия Netscape 4.01 в течении этого времени безнадёжно устарела, после чего все пользователи перешли на Internet Explorer, а за ними и разработчики (многие - нехотя) окончательно переориентировались на него.

Microsoft тогда даже учудила такой проект, как Internet Explorer для Macintosh`а, где традиционным браузером был Safari (более того - сама компания Apple в течении 5 лет ставила IE для Macintosh`а как браузер по умолчанию). Аргументация была примерно такая: раз многие дизайн-студии разрабатывают и тестируют свои сайты в IE, то, что бы не напрягать пользователей Apple Macintosh, им тоже нужно дать возможность смотреть сайты такими, какими они разрабатывались и тестировались (правда, и здесь не обошлось без "у-у-упс!" со стороны MS - далеко не все технологии, поддерживаемые в IE для Windows были реализованы в тех же версиях для Mac).

Выход Netscape Navigator`а 6-го состоялся (5-ю версию они пропустили), но фурора не вызвал - качественно он не превосходил Internet Explorer, да и его интерфейсных идей никто толком не понял. Для подавляющего большинства пользователей интернета этот выход прошёл незамеченным, даже бывшие пользователи NN уже окончательно забыли про этот браузер, не говоря уже о новых пользователях компьютеров и, всеми забытая и брошенная, компания была вынуждена бесславно уйти с рынка, передав все новёхонькие исходные коды своего некогда лидировавшего браузера разработчикам программ с открытым исходным кодом.

Эра Open Source

Разработчики программ с открытым исходным кодом обрадовались такому повороту дел и принялись дорабатывать и раскручивать этот браузер. Тогда проект получил название Mozilla и быстро стал стандартом де-факто среди пользорвателей Linux, но у него была версия и для Windows-платформы. Через некоторое время, отчасти из маркетинговых соображений, а отчасти и по технологическим причинам проект создания браузера был выделен из остальных появившихся приложений Mozilla (таких, как, например, почтовый клиент Thinderbird, система контроля версий BugFox и некоторых других) и получил название Mozilla FireFox (FF) и полностью сменил имидж - иконка динозавра была заменена на иконку лисы и т.д.

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

По-этому, как говорится, "не было бы счастья, да несчастье помогло" - по факту в качестве детальных инструкций на разработку в open source`ных проектах выступают спецификации стандартов, что очень удобно. :) Это коммерческие компании могут не сильно торопиться за стандартами - у них есть своё видение, свои маркетинговые и прочие соображения, которые могут накладывать отпечаток на скорость реализации того или иного стандарта. А у open source`а такого нет - но есть необходимость разработчикам-энтузиастам со всего мира иметь чёткие инструкции, понимание в деталях что и как нужно делать, что бы эффективно кооперироваться. Вот и получается, что FireFox быстро стал лидером в аспекте поддержки стандартов и заслужил по-этому безмерную любовь разработчиков сайтов и Front-end`ов (интерфейсов) корпоративных приложений, ведь в нём ничего правильно (т.е. в соответствии со стандартами) написанное, не глючило и исправно работало. :)

Последствия поражения

Но для массового Internet-пользователя ситуация уже была безнадёжно запущена. Напрасно разработчики FireFox с помпой праздновали переход через 10% барьер (т.е. момент времени, когда по оценкам ряда популярных интернет-порталов, следивших, за какими браузерами сидят их пользователи, пользователей FF стало более 10%), напрасно считали, сколько миллионов раз был скачен дистрибутив FF 3-ей версии за первый день с момента выпуска - всем реальным игрокам рынка разработки сайтов было и до сих пор остаётся очевидно, что максимум, чего теперь можно добиться - это процентов 15, не больше. 15%, на которых бизнес не сделаешь.

Пляска Microsoft на могиле Netscape

Впрочем, на рынке IT было много и оптимистов-идеалистов. Были люди, которые утверждали, что победа IE в "браузерной войне" рынку в целом - на руку, мол, кто сумеет сделать лучший браузер, чем имеющая для этого все условия Microsoft? У кого ещё достаточно ресурсов для того, что бы разрабатывать новые технологические новинки и подходы в области web?

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

Вот только действия MS по факту говорили скорее об обратном. Развитие IE, шедшее до поры - до времени семимильными шагами, вдруг по непонятной причине забуксовало. Постепенно застопорилась поддержка новых выходящих стандартов. Перспективные технологии HTA и HTC и вовсе были кинуты на полпути, явно не доведены до логического конца. Фактически, с версии 5.5 не создано ничего нового.

Организация World Wide Web Consorcium (W3C) продолжала выпускать новые и новые стандарты - CSS 3 (в IE и то частично реализована версия 2), XHTML 2.0 (поддерживается, да и то с "косяками", XHTML 1.0), XSLT 2.0 (в IE реализована лишь поддержка 1.0), XPath 2.0 (для xml-документов реализована поддержка 1.0, для html - вообще не реализована), DOM Level 3 (В IE даже DOM Level 1 реализован не полностью, плюс реализованы отдельные, точечные технологии, аналоги которых присутствуют в DOM Level 2), на фоне этого ряд мелких несоответствий со стандартом ECMA Script (такие, как разрешение использования ряда зарезервированных слов в качестве идентифткаторов и утечки памяти при использовании замыканий в работе с DOM-объектами) является сугубой мелочью. Ну и я уж не говорю про поддержку стандарта E4X или тега Canvas, давно реализованных во всех маломальски-популярных браузерах, кроме IE.

Кроме того, у Internet Explorer`а не реализовано достаточно удобной и незаметной системы обновления версий, в связи с чем в куче государственных компаний, а так же интернет-кафе, в почтовых отделениях и т.д., а вместе с этим - и у многих неопытных домашних пользователей и даже в конторах с консервативными системными администраторами до сих пор стоят старые версии Internet Explorer, не давая разработчикам сайтов пользоваться даже теми технологиями, которые предоставляет последняя версия IE, потому что при этом они вынуждены всегда оглядываться на "отстающих" - пользователей IE 7 и 6 (слава богу, хоть 5.5 уже ушёл в лету).

Загадка

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

Всё это сначала погрузило оптимистов в недоумение, кто-то из них пытался найти какие-то мутные оправдательные доводы - мол, это всё сложно (при том, что open source`ники без копейки денег прекрасно справляются!), что на Microsoft огромная ответственность (а open source`ники, под решениями которых работает весь Linux-мир, значит, безответственные?). В общем, наводят туману.

Скептики говорят о банальном рыночном законе спроса и предложения - мол, нет конкуренции - нет и развития. Но зачем же тогда вообще Microsoft`у было ввязываться в это противостояние с Netscape? Почему бы было не оставить этот рынок в покое, как они оставили, скажем, рынок интернет-общалок - ведь ICQ точно так же можно было выдворить с рынка общалок своим Messenger`ом, как Netscape - c рынка браузеров для интернета. Да и PaintBrush довести до профессионального уровня и потеснить Adobe Photoshop на рынке программ для обработки графики. Вообще, используя "пакетную продажу", можно выдавливать с рынка коробочных софтверных продуктов кого угодно.

Так почему - именно браузеры?
Ведь денег на браузерном рынке не так уж много - Netscape, скажем, была не очень-то богатой конторой, бравшей денег лишь с корпоративных клиентов-пользователей своего браузера. Да и было в общем-то очевидно, что подними они плату слишком высоко - компаниям проще было бы проплатить создание open-source`ного браузера и использовать его.

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

Разгадка

Для того, что бы понять действия MS, давайте порассуждаем о её бизнесе и о его потенциальной судьбе. Дело в том, что большую часть доходов Microsoft получает с продажи лицензионных копий своей операционной системы Windows.

При разработке этой операционной системы главный ориентир был - простота интерфейса и обратная совместимость. Рынок операционных систем для персональных компьютеров был наиболее чувствителен именно к этому. Они писали эту систему для домохозяек и их главной целью было создание системы, для работы с которой было бы достаточно как можно меньшего уровня технической компетенции пользователя. И они добились этой цели - на наиболее распространённой в мире платформе процессоров Intel (и совместимых с ними) у них фактически нет конкурентов. Чего стоит хотя бы заявление из стана их формальных врагов - от одного из замов президента компании Red Hut (одной из лидирующих компаний, специализирующихся на выпуске коммерческих Linux-дистрибутивов) в начале 2000-х годов о том, что в качестве операционной системы для персональных компьютеров они рекомендуют ставить Windows (это, конечно, было до появления Ubuntu - версии Linux`а, ориентированного на персональные компьютеры).

Их монополия настолько безальтернативна, что я даже встречал версию, высказываемую отнюдь не последними людьми нашего IT-бизнеса о том, что они (Microsoft) не просто не опасаются, а даже тайно поддерживают такие проекты, как Ubuntu Linux, т.е. проекты, которые пытаются дать альтернативу персональным пользователям - лишь для того, что бы сделать вид перед антимонопольным комитетом и клиентами, что конкуренция на этом рынке - есть! :)

С другой стороны, с точки зрения критериев качества серверных операционных систем Windows, мягко говоря, не блещет. Дело в том, что системные администраторы и разработчики сайтов, а так же программисты распределённых интернет-приложений - это совсем не домохозяйки. Они имеют высокий уровень технической компетенции и далеко не так чувствительны к простоте интерфейса (когда он излишне упрощён - это их часто даже раздражает), за то имеют повышенные требования к надёжности, качеству внутреннего API и быстродействию, с которыми у Windows, стремившейся к простоте интерфейса в ущерб всему остальному, дела, соответственно, обстоят далеко не так хорошо, как у тех, кто изначально ориентировался на серверный рынок. И тут явное лидерство принадлежит системам на базе Unix и его многочисленных модификаций (бесплатный - Linux, а так же Sun Solaris и ряд других). На этом рынке, насколько я помню, пару лет назад, их доля Windows Server оценивалась довольно скромно - примерно в 20% рынка. Думаю, что с тех пор она подросла и сегодня может быть 30-35%, не больше.

Что, конечно, далеко от практически 100%`оного доминирования на персоналках.По-этому переезд сервисов на серверную платформу с персоналок и упрощение операционной системы до уровня браузера означает для Microsoft, что их 99% рынка размениваются на 30-35% рынка серверов, на которых впредь всё и будет развиваться в то время, как рынок персональных операционных систем сжимается раза как минимум в 3. В итоге MS становится весьма заурядной конторкой - конечно, первой величины, но уже не качественно превосходящей конкурентов. И стоит ли удивляться, что Microsoft не желает себе такого падения доходов?

Понимая неминуемость такого финала, признавая, что прогресс неумолим, Microsoft лезет из кожи вон, что бы не потерять контроля за подавляющим большинством пользователей. Они предпринимают колоссальные усилия, пытаясь влезть на рынок распределённых интернет-приложений и корпоративных информационных систем, выпустив инструментальную платформу ".NET" с явным желанием вытеснить с рынка господствовавшую на рынке сайтов технологию PHP и господствовавшую на рынке создания крупных распределённых корпоративных приложений платформу Java EE.

Но для того, что бы максимизировать свою долю на рынке корпоративных и интернет-серверов, кроме денег, нужно ещё и время, а его нет. По популярности у Java и .NET`а пока примерный паритет (последняя оценка, которую я слышал, 40% Java EE, 50% - .NET и 10% все остальные платформы, при чём следует особо учитывать, что крупный бизнес охотнее работает с Java EE - решениями и только средний предпочитает .NET), а о вытеснении технологией ASP.NET технологии PHP на рынке разработки сайтов вообще говорить рано, даже не все провайдеры в принципе предоставляют услугу ASP-хостинга, при том, что без хостинга PHP никто даже не рискует выйти на этот рынок.

При этом рынок уже явно перегрет, широкие массы уже готовы пересаживаться на интернет-сервисы, будь они качественными, а доля MS от этого рынка даже не достигла половины. Понятно, что с нынешними финансовыми ресурсами Microsoft для них эта задача в принципе выполнимая, но нужно время. Как его выиграть?

Вот где собака-то и зарыта! Вот для чего им и нужен был контроль за браузерами. Вот для чего они в своё время последовательно выдавили с рынка Netscape - теперь они получили возможность притормаживать развитие интернет-сервисов при помощи своей монополии на браузерном рынке, как бы между прочим ставя много мелких палок в колёса развитию Web.

Что имеем сейчас

Конечно, когда я говорю о том, что развитие IE полностью остановилось, я слегка преувеличиваю - кое-что они всё-таки меняют. Например, в IE 7 появились долгожданные закладки, которые давным-давно были у Opera и FireFox`а, худо-бедно исправляются старые ошибки, но это происходит исключительно медленно. Когда набирается критическая масса нововведений и та или иная фишка, описанная в стандарте или реализованная в одном из браузеров, начинает создавать отток большого количества пользователей, Microsoft "прозревает" и всё-таки реализует её в следующей версии своего браузера, при чём, как правило, максимально по-своему, что бы создать как можно больше неудобств разработчикам сайтов и web-интерфейсов корпоративных приложений, которые пытаются сделать свои продукты такими, что бы они хорошо смотрелись во всех браузерах.

Показателен пример с перспективными технологиями HTA и HTC, о которых я уже упоминал. Их разработку они, было, затеяли, но они быстро зафиксировались на достигнутом явно недостаточном для нормальной работы уровне (хорошо ещё, что они вообще их не выкинули - видимо, боялись потерять обратную совместимость решений, уже на них написанных) и дальнейшего их развития не происходит. В то время, как аналогичный по направленности XUL от разработчиков FireFox уже на порядки мощнее. Казалось бы - неужели Microsoft слабее, чем какие-то несчастные OpenSource`ники? У них меньше денег? Глупые программисты? Нет, им просто не нужна конкуренция на этом рынке, потому что им не нужно развитие этого рынка, этого направления.

В итоге создание развитых интернет-сервисов, требующих хитрых web-интерфейсов, весьма осложнено. Фактически, совместимой со всеми браузерами разработкой таких сложных браузерных приложений, как GMail, сервисы Google Docs, Google Map, могут заниматься только такие богатые конторы, как Google или как минимум Yandex. Не может и речи идти о том, что бы средний провейдер нанял команду из 5-7 грамотных разработчиков и реализовал у себя сервис с интерфейсом такого уровня сложности - тем не менее, я возьмусь утверждать, что это было бы возможно для браузеров, хорошо реализующих стандарты.

Просто пока их общая доля среди интернет-пользователей составляет не более 15%, ни один инвестор, хоть как-то думающий о возврате своих денег, не профинансирует такие проекты - нет, он будет настаивать на том, что бы какой бы хитрый интерфейс ни был у вашего приложения, он бы корректно работал в первую очередь как раз Internet Explorer`е.

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

В итоге издержки разработки именно под IE съедают очень существенные ресурсы. И небольшие дизайн-студии вынуждены карабкаться на этот рынок буквально "через терни к звёздам" - весьма колючие терни Internet Explorer`а. И естественно, они в большинстве случаев могут выходить лишь с предельно-простыми c точки зрения поведения web-интерфейсами. Они так и делают - в итоге сервисы интернета развиваются в основном благодаря программированию на стороне сервера. Дисгармония просто ужасает - на сервере часто выполняются даже такие простейшие операции, как сортировка таблиц на странице или добавление новых полей формы, когда в нормальном браузере это сделать - раз плюнуть, совершенно не трогая сервера. Но это - только в нормальном браузере, а с Internet Explorer`ом придётся пободаться. Сделать можно, но придётся делать через известно что...

Разработчики коллекционируют решения большинства проблем совместимости стандартных браузеров и IE, при написании библиотек для языка сценариев JavaScript, которых развелось огромное количество - JQuery, Prototype, MooTools, Ext и многие другие, но это не решение проблем - сами эти библиотеки становятся всё более и более тяжеловесными и всё чаще из-за этого подвергаются критике со стороны разработчиков, стремящихся оптимизировать страницы, делать их легковесными.

Больше всего жаль несчастных разработчиков Opera - они с самого начала приняли, казалось бы, выигрышную стратегию - в случае конфликтов реализации IE и спецификаций W3C, реализовывать всё так, как в IE, а не так, как в стандарте. Они, очевидно, решили, что Microsoft с W3C просто разошлись во мнениях о том, в какую сторону развивать web-интерфейсы. Вот только ребята не поняли, что Microsoft не потому всё это делает, что просто видит собственный путь развития Web-технологий, отличный от того, как это видит W3C, а потому, что пытается по мере сил просто затормозить это развитие - и всё. В итоге Oper`цы оказались между двух огней - для Microsoft они - конкуренты, а для приверженцев стандартов они - жалкие трусливые отступники, как шакал Табаки в "Маугли" примкнувшие к грозному Шерхану-Microsoft`у...

Намечающаяся тенденция

К счастью, Google, прочно взявший курс на перевод сервисов в Web, на глазах всё-таки пересиливает MS даже со всеми её возможностями торможения web-разработок.

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

Да и правительство США здесь вряд ли вступится за Microsoft используя не рыночные механизмы регулирования, ведь Google - такой же налогоплательщик и точно так же зарабатывает деньги во всём мире, а налоги платит - практически исключительно в США. Но при этом Google развивает отрасль, а Microsoft - стопорит, портя имидж экономической политике правительства США - а тут подворачивается такой прекрасный шанс стать "белыми и пушистыми" в глазах представителей IT-рынка во всём мире! :) Так что для правительства США переход с отстаивания антирыночными методами интересов Microsoft на мировой арене на отстаивание интересов Google - идеальный расклад! :)

У них есть уже и браузер, страмительно набирающий пользователей, агрессивно продвигаемый на всех порталах, владельцем которых является Google (все уже заметили, например, на YouTUBE внизу ссылочку, рекомендующую поставить Chrome, поскольку в нём эта страница смотрится лучше? smile:) ) и содержащий прекрасную реализацию всех стандартов, имеющихся на сегодняшний день. Есть инструментарий Google Web Toolkit (GWT), пока достаточно тяжеловесный, но позволяющий надёжно использовать java-технологии для создания web-интерфейсов, который сам берёт на себя заботу о межбраузерной совместимости получающихся интернет-приложений.

Но это всё - полумеры. А вот настоящий финал, развязка этой борьбы уже на пороге - в середине 2010 года появятся в продаже netbook`и с операционной системой Google Chrome OS, которая реализует как раз ту идею, которая уже давно просится - операционная система, которая будет представлять собой практически голый браузер. Надеюсь, что это будет началом конца если не Microsoft вообще, то по крайней мере их политики по торможению развития web-интерфейсов! :)

Вот простой и понятный ролик о том, что такое Google Chrome OS:

Продолжение - "Браузерные войны – 2 или нас ждёт JSON-Hibernate?".

P.S. Есть ещё одна проблема со стандартизацией Web-интерфейсов, препятствующая их развитию, на которую в своё время указал Джоел Спольски - отсутствие эталонной реализации для стандартов визуального отображения документов. Дело в том, что документы W3C не достаточно хорошо описывают внешние эффекты поведения тех или иных элементов в браузере и часто разобраться, как в данном конкретном случае должен отображать документ браузер в соответствии со стандартом - весьма не простое дело. В силу чего необходима эталонная реализация браузера, про которую было бы чётко сказано стандартизирующей организацией, что все элементы этот браузер отображает правильно. Роль такой эталонной реализации выполняет, например, Tomcat для Java EE Web и Glassfish для Java EE EJB.

Боюсь загадывать, но лично мне кажется наиболее приемлемым решение признать эталонной реализацию браузера FireFox - тогда Google сможет дополнять свой браузер по мере своих возможностей, а пересмотревшая свою политику Microsoft будет пытаться догнать и перегнать его и в случае спорных моментов, протестировав свою страницу в FireFox`е, каждому разработчику станет ясно - чей это косяк. :)

P.P.S. Под конец можете послушать песенку разработчика о наболевшем:

ППКС! :)))

Уровни экспертизы

2011-11-02T04:56:00.000-07:00

Когда-то давно услышал чьё-то мнение о том, что японцы - самая художественная нация. Возник законный вопрос - почему? Ведь на вскидку почти любой образованный гражданин России, США и Европы не сможет припомнить ни одного знаменитого японского художника, хотя легко назовёт несколько великих российских и европейских художников. Выяснил, что критерий тут другой - лингвистический. Дело в том, что в японском языке присутствует самое большое количество самостоятельных слов, выражающих различные оттенки цветов. Можно долго строить предположения, с чем это связано, но пока можно заключить лишь, что на каком-то этапе развития японской культуры для них было очень важно различать большое количество оттенков цветов и для их отражения в их языке появились эти слова.

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

Часто приходится слышать размышления о "практическом" и "теоретическом" характере того или иного знания. На мой взгляд, это разделение имеет более фундаментальный характер, чем то, о чём собираюсь написать я. Не следует забывать, что все программисты - это инженеры, а не учёные. Критерии знания учёных-теоретиков отличны от наших, поскольку от инженера, в конечном итоге, всегда требуется тот или иной результат его работы. Так что это разделение мне видится условным, поскольку теоретическое знание - это скорее прерогатива учёных. Конечно, теоретическое знание необходимо и инженеру, но чаще всего оказывается, что не во всей своей полноте, а в сильно-упрощённом и сокращённом виде - часто приходится слышать о том, что та или иная теория, выдвинутая учёными, нуждается в упрощении (обычно - по закону Парето, более известному, как "Принцип 20/80") для того, что бы превратиться в удобный для работы инструмент инженера.

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

Итак, что значит - знать какой либо инструмент? По своему опыту я склонен делить знание на 3 уровня:
1. Знакомство или игровое знание. Знание, полученное в ходе игры с технологией. Знания на этом уровне достаточно для того, что бы делать интересные и в общем-то, как правило, никому, кроме автора, ненужные штуки на ней. Программисты так обычно и говорят - "поиграться" с какой-то технологией (например - "Я поигрался со Spring`ом"). Это означает, что на ней просто сделано что-то, что в принципе получилось и даже работает, но ничего полезного никому не приносит - не для этого делалось, а просто так.Кстати, знание именно на этом уровне обычно формируется в результате прохождения того или иного тренинга. В программировании людей, до конца прошедших этот уровень, обычно называют Junior Developer`ами или просто Junior`ами.

2. Навык или рабочее знание. Знание, полученное в ходе активного применения технологии в работе над каким-либо боевым проектом. Знания на этом уровне достаточно уже для того, что бы не просто делать ЧТО-ТО с помощью этой технологии, но и для того, что бы выполнять РЕАЛЬНЫЕ ЗАДАЧИ БИЗНЕСА, более или менее укладываясь в заявленные сроки. Т.е. необходим опыт применения этой технологии, достаточный для оценки рисков по срокам работ при получении задачи работником от своего менеджера проекта. Если такого опыта нет - просто ставить задачу бесполезно - человек не может оценить всех рисков и его согласие - это лишь согласие заняться этой задачей, а не принятие на себя ответственности за её решение в заявленные сроки. По-этому обычная обязанность Team-Lead`а (руководителя группы разработчиков) - брать на себя управление рисками при постановке задач Junior`ам.Обычно разработчиков, имеющих знание на этом уровне, называют либо просто разработчиками, либо Старшими разработчиками (Developer или Senior Developer).

У меня ушло очень много времени для того, что бы понять, в чём конкретно заключается разница между Senior`ом и простым Developer`ом. По сути во многих IT-организациях эти различия очень условны и на практике обычно отражают простую "выслугу лет" - например, 5 лет работал Developer`ом - после этого тебя нарекают Senior Developer`ом. Это, конечно, плохая практика с точки зрения удовлетворения карьерных амбиций - когда молодой сотрудник стремится построить свою карьеру, все его усилия сосредотачиваются на эффективном, быстром достижении каких-то целей, но когда он понимает, что цель "стать Senior`ом", фактически, является пассивно-достижимой (сама придёт к нему через 5 лет, и никак этот процесс ускорить нельзя) - это способно погрузить его в уныние.

Иногда говорят, что старшие разработчики должны дополнительно тянуть лямку обучения младших, однако на практике это требует уже следующего уровня (об этом - чуть ниже) и по-этому по факту выражается в пассивном обучении: такой старший разработчик говорит младшему примерно следующее - "Смотри на меня и делай, как я!" - и пишет при нём код, слегка проясняя какие-то моменты.Наиболее чёткий критерий я услышал от одного из крупных менеджеров Ланит`а. Он выразил мысль, что Senior - это тот, кому можно поставить задачу и не контролировать её выполнение, будучи полностью уверенным, что он уложится в срок или сам вовремя подаст сигнал о том, что не успевает или у него возникли какие-то иные трудности. А простому Developer`у нужен некоторый контроль, хотя, конечно, и не такой сильный, как за Junior`ом.

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

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

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

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

Действительно, многим из нас часто кажется, что если, как утверждают философы, "практика - критерий истины", то способность использовать знание - есть критерий его наличия. И, соответственно, если ты знаешь - то "чего такой жадный?", ведь, "От тебя не убудет?" - обучи другого, "Жалко, что ли?".

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

Нужно понимать, что когда тренер даёт знания обучающимся, обучающиеся усваивают их, применяя всё тот же закон Парето - усваивают те 20% материала, которые им (о чём они судят с высоты своего опыта), могут понадобиться, а всё остальное - "вода" или, как часто говорят, "информационный шум". Но не понятно часто другое - каждый слушатель усваивает свои 20% материала. Именно эти 20% уже после того, как "обкатываются" в реальном проекте, становятся его навыком. Т.е. понятие "информационный шум" - относительно. Так же из этого вытекает и то, что тренер должен знать массу таких вещей, которых практически никогда не будет применять на практике.

Действительно, проведите над собой эксперимент. Найдите сейчас в своём поле зрения, например, дерево и задайте себе вопрос - какое оно? Скажите, что первым придёт в голову. Потом ещё раз - какое оно кроме того, что Вы уже сказали? И так раз 5-7, запоминая порядок, в котором Вы назвали эти признаки. Что получилось? У меня вот - Круглое в обхвате, большое, высокое, раскидистое, старое, унылое, шершавое, коричневое, красивое. Каких из этих признаков вы не назвали и что назвали такого, чего нет у меня? Попытайтесь проанализировать тот порядок, в котором вы назвали эти признаки. Это - не случайная последовательность признаков - нет! Это - картина ваших приоритетов, т.е. тех качеств, которые Вы видите в деревьях в первую очередь, поскольку именно в такой последовательности они для Вас важны. То, что вы назвали в числе последних - для вас практически не важно, а вот то, что называли первым - бросилось в глаза, значит, действительно важно. Если вы через несколько дней будете вспоминать, какое это было дерево, то вспомните, вероятно, только те его качества, которые назвали первыми. Этот порядок - это и есть проявление Вашей особенности восприятия мира вокруг на примере такого объекта, как дерево.

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

Но если дать ему группу желающих научиться работать с этой технологией и попросить её обучить - получится, что то, как привык действовать он, не подходит другим людям, т.к. они мыслят по-другому. У них другие приоритеты и они, применяя принцип Парето, из общего объёма знаний отсеяли бы ДРУГИЕ 20%, нежели те, которые отсеял он, восприняв то, что знает он, как "воду", "информационный шум".

Поэтому существует 2 подхода к решению данного вопроса.

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

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

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

Вершина иерархии в JavaScript

2011-10-20T12:52:00.000-07:00

Как-то раз меня спросили о том, что является вершиной ООП-иерархии в JavaScript. От меня явно ждали простого односложного ответа и я, поколебавшись, ответил, что такой вершиной является Object. Мой ответ сочли неправильным - по мнению спрашивающего вершиной иерархии в JavaScript безоговорочно является Function. Я попытался возразить, но мне не удалось убедить его. Думаю что он до сих пор в этом уверен. Это происходило на собеседовании на одну интересующую меня тогда вакансию и очень жаль, что они предоставили мне именно такого интервьюера - впрочем, Бог ему судья.

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

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

Здесь видно, что в JavaScript существует не одно, а два дерева наследования - дерево объектов и дерево конструкторов. Т.е. хоть функции (каждая из которых технически является конструктором, несмотря на то, что не каждая используется в качестве такового) и являются объектами, но их специфика отражается на том, как проходит дерево их наследования.

Вообще, к любой реализации prototype-based ООП довольно трудно однозначно применить громкое для него слово "наследование". Что такое наследование в JavaScript изначально? По факту многие авторы популярных библиотек и framework`ов трактуют ээтот термин в применении к своему инструментарию по-своему и могут спорить друг с другом до изнеможения, доказывая если не истинность, то по крайней мере техническую целесообразность своей точки зрения. Так что, строго говоря, заранее чётко не определив данный термин, нельзя спрашивать и надеяться услышать правильный ответ о том, что является в JavaScript вершиной иерархии.

Не стану навязывать кому-то свою позицию, просто скажу, что солидарен в этом вопросе с создателями этого языка. В этом языке есть вполне чёткая конструкция - instanceof, которая как раз и возвращает true или false в ответ на переданные ей операнды. Конечно, многие критикуют оператор instanceof, призывая его не использовать, но по существу он является единственным объективным критерием того, что мы вправе называть наследованием в JavaScript - всё остальное, по сути, лишь попытки сделать вид, что это наследование.

Оператор instanceof пробегает по дереву ссылок __proto__ левого операнда и сравнивает каждый из них со свойством prototype правого операнда. Т.е. делает в сущности следующее (для наглядности представим, что это не оператор, а функция, которой оба операнда передаются в качестве первого и второго параметров):

function instanceOf(a, b)
{
    while ( (a = a.__proto__) !== null)
        if (a === b.prototype)
            return true;

    return false;
};

Как видим на картинке, "сколько верёвочке ни виться, а кончику - быть!" - в нормальной ситуации ссылка __proto__ всегда приведёт в null.

Так что давайте посмотрим на картинку в контексте вопроса о том, "кто в доме хозяин" - Object или Function?. Итак, имеем два лагеря объектов - функции и остальные объекты.

Для объектов картина однозначна - для них вершиной иерархии является Object, поскольку алгоритм прохода по ссылкам __proto__ посетит прототип ээтого конструктора последним перед тем, как упереться в null. Тут всё ясно. Язык чётко даёт нам понять, что это - так:

alert( (new Object()) instanceof Object); // true
alert((new Object()) instanceof Function); // false

Что же касается функций, то все они являются дочерними по отношению к конструктору Function, ссылаясь на прототип этой функции своей ссылкой __proto__. И, что, видимо, и сбило с толку тогда моего интервьюера, для функции Object язык (а точнее - спецификация ECMAScript) не делает в этом плане исключения - ссылка Object.__proto__ так же ссылается на Function.prototype, т.е. вроде бы как бы Object является наследником Function`а, да? ;) Но вот только штука вся в том, что сам по себе Function, как и любой другой конструктор, ссылается ссылкой __proto__ на свой prototype(в сущности для конструктора Function эти ссылки эквивалентны), а тот, в свою очередь, ссылается на Object.prototype, что прекрасно видно на приведённой картинке. Так что в итоге вершиной иерархии всех объектов, в том числе и функций, является всё-таки Object:

alert(Object.__proto__ === Function.prototype); // true
alert(Object instanceof Function); // true
alert(Function instanceof Object); // true

Путаница возникает из-за того, что многие программисты, привыкшие к наследованию в class based OOP языках программирования воспринимают конструкторы в JavaScript как классы и считают, что конструкторы участвуют в наследовании, хотя на самом деле в наследовании участвуют не конструкторы, а прототипы конструкторов!. И синтаксис оператора instanceof как бы потворствует этому заблуждению. Тем не менее, в JavaScript нет и не может быть никакого объекта, для которого бы выражение " instanceof Object" вернуло бы false, в то время, как для аналогичного выражения с конструктором Function это утверждение несправедливо - для всех объектов, не являющихся функциями, это выражение вернёт false.

Короче говоря, Object, как конструктор, является наследником Function, но сам Function - не только конструктор, но и объект, и, как объект, является наследником Object`а. Ипостась же объекта для любого конструктора всегда выше его ипостаси конструктора, т.е. любая функция - в первую очередь всё-таки объект, и уже во-вторую очередь - функция, так что объектная иерархия наследования имеет приоритет перед конструкторской.. Тем не менее, если рассматривать статические свойства (свойства функций), то конструктор Object в качестве таковых, как и все остальные конструкторы, наследует свойства прототипа Function, но и тот в свою очередь наследует свойства прототипа Object`а. Если не понятно - всматривайтесь в картинку до тех пор, пока не поймёте.

Понимать это действительно важно для программирования на JavaScript, хотя, как показала практика, и может стоить не устройства на хорошую работу - но тут уж не угадаешь :)

Обогащение (enrichment) или псевдо-конструктор (pseudo-constructor) как JavaScript-pattern

2011-10-08T15:49:00.000-07:00

Вторым открытым при разработке библеотеки Drag and Drop приёмом, который я бы назвал шаблоном, является обогащение (enrichment). Ещё я иногда про себя называю его псевдо-конструктор (pseudo-constructor), что считаю менее удачным, но так же подходящим для него названием.

Он служит для ситуаций, когда нужно придать некоторую дополнительную функциональность группе объектов одинакового вида.

Я столкнулся с этой проблемой при работе с тем же самым объектом Event для IE. Дело в том, что продемонстрированный в позапрошлой статье приём "Заплатка" (Patch) был несколько неполным. Напомню приведённый код:

(function setAddEventListener(){
    if ('attachEvent' in this && !('addEventListener' in this))
        addEventListener = function(eventName, handler, isCapturing) {
            if (isCapturing)
                throw new Error("We are in IE, so we haven`t way to set event listener on capturing phase of any event to any of HTML-elements");
            attachEvent("on" + eventName, handler);
    }
})(); //IE patch for window.addEventListener

В этом коде, к сожалению, не было учтено, что для придания стандартного поведения функции addEventListener нужно, что бы она вызывала слушателя, передавая ему объект Event, при чём это должен быть объект Event стандартного вида.

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

Имитация функциональности стандартного объекта Event на почве IE`шной реализации сама по себе является сложной задачей и у меня нет уверенности, что она действительно представляет для читателей практический интерес, так что я просто проиллюстрирую принцип, показав скелет решения, а уже "наполнение мясом", каждый может делать для себя сам - по крайней мере для меня эта задача пока не актуальна. Так что упростим задачу - возьмём лишь один аспект нестандартного поведения и его сэмулируем. Например, отмена поведения браузера по-умолчанию для данного события. В стандартном W3C`шном объекте Event это действие производится вызовом метода preventDefault, а в IE - установкой значения false в свойство returnValue этого кода.

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

/** Отменяет поведение браузера для данного события по-умолчанию. */
event.preventDefault = function(){
    this.returnValue = false;
};

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

Следующая мысль, уже более зрелая - создать отдельный конструктор, который наследовался бы от нестандартного Event`а и расширял бы его функционал стандартными свойствами и методами:

/** Конструктор, служащий для придания не совместимым с W3C DOM level 3 объектам
 * Event стандартного поведения.
 * @constructor
 * @extends Event */
function EventW3C() {
    /** Отменяет поведение браузера для данного события по-умолчанию. */
    this.preventDefault = function() {
        this.returnValue = false;
    };
};

Вызов же этого конструктора в нужном месте предполагается примерно такой:

EventW3C.prototype = event; //Сначала присваиваем правильный прототип конструктору
var w3cEvent = new EventW3C(); //Затем создаём экземпляр, который будет ссылаться ссылкой __proto__ куда надо.

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

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

Гораздо более экономным является такой вариант - можно вызвать эту функцию не при помощи оператора new, а при помощи метода call:

EventW3C.call(event);

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

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

function EventW3C() {
    /** Отменяет поведение браузера для данного события по-умолчанию. */
    this.preventDefault = function() {
        this.returnValue = false;
    };
    return this;
};

Для использования этой функции в качестве реального конструктора это ровным счётом ничего не изменит, а вот для использования её в качестве псевдо-конструктора это может сделать вызов более удобным - тогда само выражение вызова будет возвращать результат, прямо как у реального конструктора:

var w3cEvent = EventW3C.call(event);

На последок приведу полный вариант реализации pattern`а "Заплатка" ("Patch") для эмуляции addEventListener`а, который использует приведённый pattern Обогащение (Enrichment) или псевдо-конструктор (Pseudo-Constructor):

//IE patch for window.addEventListener
function setAddEventListener()
{
    if ('attachEvent' in this && !('addEventListener' in this))
        addEventListener = function(eventName, handler) {
            if (isCapturing)
                throw new Error("We are in IE, so we haven`t way to set event listener on capturing phase of any event to any of HTML-elements");
            attachEvent("on" + eventName, function() {
                handler(EventW3C.call(event) //Здесь используется pattern "Enrichment"
            });
        }
}
setAddEventListener.call(document);// Применяем заплатку для объекта document

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

P.S. Думается, что данный шаблон имеет так же большой потенциал применения для добавления свойств объектам DOM, если нужно придать им нужную функциональность. По крайней мере сейчас я прорабатываю эту идею как раз в контексте своей библиотеки - она поможет пользователям навешивать несколько обработчиков событий в ходе Drag&Drop-перемещения.

P.P.S. Пришло в голову, когда уже собирался опубликовать сообщение - а может, лучше будет назвать этот приём - Псевдо-наследование ("Pseudo-Inheritance")? Пишите в комментах Ваши версии :)

Самонастраивающаяся функция

2011-10-07T08:48:00.000-07:00

В ходе написания второй версии библиотеки для Drag&Drop`а (уже скоро выложу и опубликую, ждите - осталось недолго :) ) была найдена парочка интересных JavaScript`овых решений, которые тоже вполне могут претендовать на звание Pattern`ов. Рискуя тем, что, возможно, изобретаю велосипед, всё-таки распишу, как я их использую.

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

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

Именно с такой задачей я имел дело при написании второй версии своей библиотечки. Мне нужна была функция, которой передавался бы объект pos, имеющий два свойства - 'x' и 'y' и от неё требовалось, что бы она проставила в них значения x и y-координат курсора мыши. Я назвал её refreshMousePos.

Саму эту функцию должен вызывать обработчик того или иного события, который в W3C-совместимых браузерах получает ссылку на объект Event, соответствующий данному событию. Для вычисления координат курсора мыши этот объект нужен, так что в этом случае ссылку на него нужно передать в refreshMousePos вторым аргументом. В случае же W3C-несовместимого браузера (в основном, IE6-8), обработчику не передаётся этот объект, по-этому он и не может быть передан в функцию refreshMousePos.

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

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

Сам IE меняет в соответствии с обрабатываемым событием объект event, который всегда находится у него в глобальном контексте. И интерфейс этого объекта несколько иной, что проявляется в логике вычисления координат курсора мыши.

Так что я сделал разделение логики следующим образом:

/** Обновить координаты мыши.
 * @param {Position} pos координаты курсора мыши
 * @param {Event} [evt] объект события */
function refreshMousePos(pos, evt) {
    return (refreshMousePos = typeof evt !== 'undefined' ?
        function(pos, evt) { //W3C realization
            var body = document.body;
            pos.x = evt.clientX + body.scrollLeft - body.clientLeft;
            pos.y = evt.clientY + body.scrollTop - body.clientTop;
            return pos;
        } :
        function(pos) { //IE realization
            pos.x = event.pageX;
            pos.y = event.pageY;
            return pos;
        }
    )(pos, evt); //вызываем тот вариант функции, которую присвоили и возвращаем результат выполнения
};

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

P.S. Спросите, зачем я возвращаю объект pos, ведь его поля итак уже изменены и значит, необходимый внешний эффект достигнут? Отвечу - для того, что бы можно было после вызова функции сразу же в той же конструкции обратиться к объекту pos:

alert(
    refreshMousePos(pos, evt).x
);

"Заплатка" ("Patch") как JavaScript шаблон проектирования

2011-09-16T00:46:00.000-07:00

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

Сам я использую заплатки уже достаточно давно. Разумеется, основные заплатки ставятся на IE6-8, с которыми, по-видимому, ещё предстоит много возни, пока они, наконец, отомрут. Однако так же не помешает установить их и для старых версий иных браузеров.

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

function onLoadListener() {
    //some code...
}
if ('addEventListener' in window)
    addEventListener("load", onLoadListener, false);
else if ('attachEvent' in window)
    attachEvent("onload", onLoadListener)

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

Тем не менее, сократить эту конструкцию до стандартного кода

addEventListener("load", function() {
    //some code...
}, false);

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

Как только я в своих проектах сталкиваюсь с несовместимостью работы того или иного браузера со стандартными методами, первая мысль у меня возникает о том, что бы вынести обеспечение совместимости в отдельный от основного код, что бы он его не захламлял. У меня уже накопилось достаточно много таких заплаток, латающих различные дыры в поддержке стандартов различным браузерами - главным образом IE. Обычно я помещаю их в отдельный файл проекта, называя его "commons.js" (есть и исключения - например в случае, если это нужно только для тестирования, я считаю не зазорным вставлять такой код просто в начало тестового файла).

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

(function setAddEventListener()
{
    if ('attachEvent' in this && !('addEventListener' in this))
        addEventListener = function(eventName, handlerб isCapturing) {
            if (isCapturing)
                throw new Error("We are in IE, so we haven`t way to set event listener on capturing phase of any event to any of HTML-elements");
            attachEvent("on" + eventName, handler);
        }
})(); //IE patch for window.addEventListener

Здесь элегантно используется то обстоятельство, что ссылка this при вызове в глобальном контексте в функции указывает на объект window. По-этому сразу же после объявления функция просто вызывается.

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

Если необходима реализация парного метода removeEventListener, её легко написать по аналогии, реализовав через метод detachEvent.

Теперь другие элементы, которым так же нужно "привить" правильное поведение, могли бы обрабатываться следующим образом:

setAddEventListener.call(document.getElementById('id1'));

В статье "JavaScript: Реализация pattern`а Singleton" я уже приводил ещё одну заплатку - для безпроблемного объявления объекта XMLHttpRequest (который я нашёл в англоязычной Wikipedia):

// Provide the XMLHttpRequest class for IE 5.x-6.x:
if (typeof XMLHttpRequest == "undefined")
    /** @constructor */
    XMLHttpRequest = function() {
        try { return new ActiveXObject("Msxml2.XMLHTTP.6.0") } catch(e) {}
        try { return new ActiveXObject("Msxml2.XMLHTTP.3.0") } catch(e) {}
        try { return new ActiveXObject("Msxml2.XMLHTTP") } catch(e) {}
        try { return new ActiveXObject("Microsoft.XMLHTTP") } catch(e) {}
        throw new TypeError( "This browser does not support XMLHttpRequest." )
    };

Напоследок приведу ещё одну заплатку. Она служит для безпроблемной реализации стандартного метода window.getComputedStyle, отсутствующего в IE вплоть до 8 версии включительно. Кто не знает, это очень удобный метод, позволяющий получать ссылки на объект, содержащий информацию о "вычислимых стилях" для HTML-элемента. Вычислимым называется стиль, специально не установленный разработчиком, однако получившийся в результате вывода браузером этого элемента на странице. IE вместо него имеет свойство computedStyle, доступное у каждого элемента. К сожалению, оно не может представить вычислимый стиль для псевдоклассов, по-этому заплатку можно вставить так же, как и для addActionListener`а - лишь частичную.

Таким образом, вот как можно решить данную проблему несовместимости IE со стандартом:

//IE patch for window.getComputedStyle
if (!('getComputedStyle' in window))
    getComputedStyle = function(element, pseudoclass) {
        if (pseudoclass === null || typeof pseudoclass === 'undefined')
            return element.currentStyle;
        else
            throw new Error("We are in IE, so we haven`t way to get pseudoclass styles of element");
    };

Я скачал ЕЁ!!!

2011-07-21T06:24:00.000-07:00

Самая лучшая книга по JavaScript всех времён и народов! Лучше неё ничего нет!
O`Reilly - Девид Фленаган, «JavaScript. Definitive Guide, 6th edition»(2011) - туда вошли все новшества от HTML5 и ECMAScript 5! :))))

Вот тут она есть - http://uploading.com/files/3735d769/Oreilly.j

Фленаган пишет очень подробно, для профессионалов.

Искал в электронном виде уже месяца два, кучу времени убил – нигде не было, хотя куча вирья всякого пыталась под её видом пролезть на манер файлов «JavaScript_Definitive_Guide,6th_edition.pdf.exe» с иконкой pdf`а... И вот, наконец, она – вот она!!!)

proto во всех браузерах

2011-05-31T08:13:00.000-07:00

Ссылка "__proto__", как известно, указывает на прототип объекта в браузерах FireFox, Google Chrome и Safari. Обычно ссылку на прототип можно получить комбинацией ссылок constructor и prototype, но когда используется классическое для JavaScript наследование:

function A(){/*...*/};
function B(){/*...*/};
B.prototype = new A();
var b = new B();

, то в этом случае вызов

b.constructor.prototype

укажет на прототип конструктора A, а не на созданный объект конструктора A, который передан прототипу:

alert(b.constructor.prototype === A.prototype);//'true'

. Как же в этом случае можно обратиться именно к прототипу объекта b (естественно, не зная, каков его конструктор)? Можно переопределить ссылку constructor у объекта, созданного по конструктору A, указав ей на B:

B.prototype.constructor = B;

, но тогда мы потеряем возможность добраться до прототипа конструктора A, что может так же понадобиться.
Так что остаётся только ссылка "__proto__" - больше никак. Но этой ссылки нет в некоторых браузерах - например, в IE и в Opera`е.
Но если чего-то нету, то можно это недостающее создать самим. Для того, что бы всё заработало везде, надо вставить конструкцию

if (!this.hasOwnProperty('__proto__'))
    /** @type A */ this.__proto__ = arguments.callee.prototype;

внутрь нашего конструктора-наследничка. И тогда всё получится:

function A(){/*...*/};
function B() {
    /*...*/
    if (!this.hasOwnProperty('__proto__'))
        /** @type A */ this.__proto__ = arguments.callee.prototype;
};
B.prototype = new A();
var b = new B();
alert(b.__proto__ === B.prptotype);//'true'
alert(b.constructor.prototype === A.prototype);//'true'

Навигация в Google Cache

2011-05-31T06:56:00.000-07:00

Интернет - это целый мир. Сайты в нём как люди в реальном мире - рождаются, живут и умирают. Иногда то, что они умирают, может кому-то не понравиться. Тогда на помощь тем, кто "хотел, но не успел" сохранить те или иные материалы у себя, приходит Google Cache.
При поиске тех или иных страниц в интернете Вы наверняка замечали под каждой ссылкой с результатами поиска ссылочку "Сохранённая копия". Видели? Это и есть Google Cache. Если страницы уже и след простыл, она может всё ещё оказаться в этом хранилище.

Точно не знаю, сколько живут страницы в Кэше`e Google, прежде чем окончательно проститься с Internet`ом, но если хотелось их сохранить, то искать их можно там. Но вот незадача - отдельную страницу найти-то можно, но вот если пропал целый сайт и хочется погулять по этому сайту, покликать на ссылочки почитать много страниц в правильном порядке, то Вас ждёт неприятный сюрприз - все внутренние ссылки будут битые. Т.е. страницы-то в Google Cach`е есть, но вот навигация по ним очень неудобная - нужно каждую из них искать с помощью поисковика Google`а и переходить по ссылке "Сохранённая копия".

Буквально сегодня я столкнулся с тем, что великолепный сайт, посвящённый реальной медицине (а не этой дурацкой официальной, которая не лечит, а наоборот - медленно убивает людей) - http://www.revici.ru/ - исчез и теперь при наборе его адреса попадаешь на какую-то дурацкую рекламу фильмов.
На этом сайте было большое количество интересных материалов, соединённых ссылками. И при его сохранении из этого Кэша передо мной встала проблема перемещения по этим ссылкам.
Но, т.к. я программист, я быстро нашёл удобное решение. Дело в том, что страница из кэша google подгружается, если перед её адресом в адресной строке браузера вставить строку: "http://webcache.googleusercontent.com/search?q=cache:"
Так что я быстренько написал следующий коротенький скриптик:

javascript:
var l=document.getElementsByTagName('a'),
    e=l.length;
for(var i=0;i<e;)
    l[i].href=
        'http://webcache.googleusercontent.com/search?q=cache:'+
        l[i++].href.replace(/http:\/\//gi,'');
void(0);//Писать всё нужно в одну строчку, здесь я разбил для удобства восприятия

Вбил его в панель закладок Google Chrome`а и стал нажимать на эту кнопку каждый раз, как перейду на какую-то страницу с висящими ссылками. Всё заработало! Теперь спокойно могу гулять по ссылкам и сохранять страничку за страничкой :)

Список используемых программ, которые нужно купить

2011-05-05T01:25:00.000-07:00

Приветствую!

Как и многие другие, грешен: пиратствую. Не во всём, конечно - Windows давно лицензионный (а Вы попробуйте сейчас купить ноутбук без лицензионной Wind`ы!), от MS Office`а в виду его большой дороговизны, отказался, перейдя на Open Office (ломка уже прошла))). Но другой хороший софт стоит дорого, а бесплатного на некоторые специфические задачи найти не удаётся.
Однако зарабатываю достаточно много и уже просто неприлично этим делом продолжать заниматься. И совесть всё больше по этому поводу свербит...

Решил опубликовать план по приобретению программ - вдруг кому-то пригодится:

ABBYY FineRider - уже купил. Стоила в р-не полутора-двух тысяч, вроде. Распознавание отсканированных текстов на ура! Вобщем-то по-моему вообще монополист - по крайней мере для русского языка то уж точно. Нужна мне для сканирования некоторых редких старых книг, которые мне попались и теперь их нужно отсканировать и разместить в интернете.
ABBYY Lingvo - нужна, http://translate.ru значительно менее удобен в повседневном использовании, да и обладает менее богатыми библиотеками, которые не всегда выдают нужный результат.
Kaspersky Cristal - до конца года обеспечила контора-производитель, откуда я ушёл месяц назад. Продлять не буду, скорее куплю KIS - Kaspersky Internet Security.
Sparx Systems Enterprise Architect 8.0 Professional. Хоть и не поддерживает JavaScript, для которой я его в основном использую, но прога незаменимая, подсел на неё, ещё когда работал в Лаборатории Касперского и теперь сложные объёмные решения без неё получается сильно дольше планировать и обдумывать, чем с ней - все аналоги либо намного дороже, либо намного хуже, либо и то и другое.
SPKet IDE - плагин к Eclipse, платный для коммерческого использования. Очень удобная штука для JavaScript-программирования - лучшая, что я видел.
Altova XMLSpy. Непревзойдённый XML-редактор, как без рук без него - все аналоги, которые видел, намного хуже.
Saxon. Часто не хватает возможностей XSLT 1.0 для текущих задач, а бесплатных удобных библиотек XSLT 2.0-преобразований найти не удалось. Saxon - практически единственная полноценная библиотека для XSLT 2.0 преобразований.
IntelliJ IDEA Corporate. Лучше среды для Java-разработки придумать, по-моему, просто невозможно.

JBoss 6 - final?

2011-01-12T06:13:00.000-08:00

Ребята из Red Hut, конечно, жгут!.. Выпустили перед самым новым годом (28 декабря) final-версию JBoss`а 6. Подарок типа на новый год людям! А Tomcat 7, который входит в него как сервлет-контейнер, всё ещё beta!!! Нормальный "подарочек", а?.. :))))

Планы на будущее

2009-12-16T02:04:00.000-08:00

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

"Дополняем "include в JavaScript`е"". Переработанная статья Володи Колесникова "Инклюд в яваскрипте" на "Техногрете" - сайте для web-разработчиков от студии Артемия Лебедева.
"Хитрость с finally-блоком" - отличный приём кодинга на JS, который, в частности, позволит немного упростить "Базовую модель" приведённую в статьях цикла "Особенности инкапсуляции на основе замыканий".
"Cookies API" - удобный API для работы с Cookies.
"URL advanced parsing" - переработанный в соответстви с серией статей "JavaScript: Особенности инкапсуляции на основе замыканий" вариант реализации парсинга, предложенный Kottenator`ом в статье "Парсим URL")
"Targeter pattern" - придуманный мной приём для динамического создания и подцепки статических блоков контента на странице. Я не раз использовал его в своих проектах и нахожу весьма ценным.
"SPKet IDE - советы". Переработанный вариант статьи и видео-лекции С.Чикуенка "Eclipse: редактирование JavaScript в Spket IDE"
"JSDoc - советы". Дополнения и критика статьи А.Старшинова - "Документирование JS-кода"
"Rhino и scripting API в Java SE 6 - способы применения в Java-программах (на примере JSDoc Toolkit)"
"Универсализированная Обработка событий" - рабор того, что можно сделать с несовместимостью браузеров в области продвинутых моделей обработки событий.
"Универсализированный метод создания DOM-узлов". Представлю свои библиотеки для создания узлов DOM-дерева. Хочу сосредоточиться на нахождении компромиса между максимальной производительностью и удобством работы с API.
"Работа с замыканиями". Распишу, что представляют собой замыкания и как правильно их использовать.
"Примитивы и объекты в JavaScript". Вопреки распространённому мнению, примитивы в JS есть, но они присутствуют в этом языке неявно и преобразуются на лету при попытке обратиться к ним как к объектам. Это может создать путанницу и привести к задержкам в работе кода (что явно и происходит, по моим наблюдениям, в коде у многих). В статье постараюсь подробно изложить отличия одних от других и показать верный путь для тюнинга JS-скриптов в этом отношении.
"Работа с XPath на JavaScript". Описание стандартного механизма поддержки XPath в браузерах и наилучшей с моей т.з.библиотеки, которая заменяет его в браузерах, не поддерживающих данный стандарт.
"Работа с XSLT на JavaScript". Описание работы с библиотекой AJAXSLT от Google.
"Технологии XUL и HTA/HTC". Описание работы с данными технологиями, позволяющими создавать полноценные приложения при помощи Web-технологий.
"ServerSide JavaScript". Когда-то давным-давно, впечатлившись успехом JavaScript, фирма Netscape создала и серверный вариант этого языка, но он по ряду причин не получил должного распространения, упустив рынок приложений на стороне сервера таким языкам, как Perl и PHP. Сейчас, на основе Rhino и Scripting API Java 6 можно использовать Java-сервера для программирования серверной логики на JS. В статье я постараюсь продемонстрировать, как это можно реализовать.
"Технология компонентов". Дальнейшее развитие идеи паттерна Targeter, к которому добавляется аналогичный GUI-библиотекам Java (Swing) механизм обработки событий.

JavaScript: Drag and Drop - библиотека

2009-06-01T12:11:00.000-07:00

В данной статье я представлю свою небольшую JavaScript-библиотечку для работы с Drag&Drop (Скачать).

Введение

Для начала немного теории. Drag&Drop предполагает, что вы, как разработчик, даёте возможность пользователю перемещать те или иные графические объекты (будем по старинке называть их слоями) по странице, нажав на них левой кнопкой мыши и, не отжимая её, передвигая курсор мыши до пункта назначения.
В более сложном варианте нам необходимо вносить те или иные ограничения на этот процесс, по-этому API библиотеки должно позволять гибко настраивать перенос в соответствии с задачей. Сразу обратим внимание на три фазы перемещения:

Нажатие левой кнопки мыши на элементе
Перетаскивание элемента с помощью перемещения курсора при нажатой левой кнопке мыши
Отжатие левой кнопки мыши после перемещения

На уровне кода данная библиотека представляет собой один объект DnD с двумя методами.

Подключение библиотеки

Архив содержит библиотеку DragAndDrop в 2-х вариантах.

Оптимизированный код - в файлах "./lib/common.js" и "./build/dnd.js".
Комплексный оптимизированный код - в файле "./dnd.js"

Библиотека "common.js" необходима для ряда операций сравнения, по-этому её обязательно нужно подгружать до подгрузки библиотеки "dnd.js".

Эта библиотека довольно простая и может оказаться полезной вам и для других ваших сценариев - если вы будете её использовать ещё для чего-то (как это делаю я), то имеет смысл её загрузить один раз и больше не загружать - тогда удобно отделить её от других файлов библиотек и загружать отдельно - один раз, что бы потом грузить другие библиотеки, которые её используют (исходный код данной библиотеки лежит там же, в директории "./lib"). Для тестирования (файлы в директории "./test/") выбран именно этот способ, для такой сборки в Ant предназначен target по-умолчанию "build".

Если же вы не собираетесь использовать библиотеку "commons.js" где-либо ещё, то имеет смысл для сокращения количества загружаемых файлов, объединить её с библиотекой dnd в один оптимизированный файл. Такой объединённый файл и лежит в корне архива (он собирается с помощью действия "build-complex" в Ant).

Что ещё есть в архиве

"./doc/" - документация
"./test/" - демонстрационные тесты
"build.xml" - сценарий сборки Ant

Первый пример

Если у Вас на странице есть некоторый объект, который Вам хотелось бы сделать передвигаемым по ней, то Вам достаточно зарегистрировать его в объекте DnD:

var /** @type {HTMLElement} */ layer = document.createElement('div');
layer.appendChild(document.createElement('img')).setAttribute('src', 'pic.gif');
document.body.appendChild(layer);
DnD.register(layer);

В результате выполнения этого кода картинка "pic.gif" появится на экране и станет возможным её передвижение по окну браузера.

Второй метод объекта DnD служит обратной задаче - отмены регистрации. Например, если после пердыдущего участка кода вставить следующий:

setTimeout('DnD.unregister(layer)', 6000);

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

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

DnD.register(layer1).register(layer2).unregister(layer3).register(layer4);//...

Перемещать можно только слои, у которых свойство 'position' установлено в значение 'absolute' или 'relative'. По-этому при регистрации слоя происходит проверка на то, какое значение выставлено у него в этом css-свойстве. Если оно не выставлено в одно из этих двух - библиотека сама выставляет для него значение 'absolute'.

Установка ограничений

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

Для этого предусмотрен простой API, регламентирующий Drag&Drop-перемещения для элемента страницы. В основе его лежит событийная модель - для элемента, регистрируемого в объекте DnD, можно определить обработчиков трёх событий. Для каждого из событий в объекте DnD определено поведение по-умолчанию, но если обработчик данного события вернёт булево значение false, то это поведение не будет выполнено. Значение true можно и не возвращать - всё, что угодно, кроме значения false будет командой выполнить действие по-умолчанию (обратите внимание на то, что значение false должно быть иименно примитивным, объект new Boolean(false) будет интерпретирован как true, так же будет интерпретированы и значения null и undefined - только примитив false заблокирует поведение для объекта по-умолчанию).

Таблица №1: Обработчики событий Drag&Drop
Событие	Сигнатура обработчика	Описание параметров	Поведение по-умолчанию
Нажатие пользователем левой кнопки мыши в момент нахождения курсора над слоем - инициализация перемещения элемента.	function mouseDown(/Object/ offset)	В качестве парамметра принимает объект `offset`, содержащий информацию о начале перетаскивания - поля 'x' и 'y' этого объекта содержат разницу между позицией курсора мыши и левым верхним краем элемента, а поле 'startPos' содержит объект с полями 'x' и 'y', содержащими координаты левого верхнего угла элемента.	Перемещение стартует. Форма курсора мыши по всему документу выставляется в значение 'move'.
Изменение координат курсора мыши при нажатой левой кнопке мыши.	mouseMove(/number/ x, /number/ y)	/number/ x - координата по горизонтали, /number/ y - координата по вертикали левого верхнего края курсора мыши.	Передвижение элемента, по вертикали и горизонтали соответствующее перемещению курсора.
Отпускание левой кнопки мыши после перетаскивания элемента.	mouseUp(/number/ x, /number/ y)	/number/ x - координата по горизонтали, /number/ y - координата по вертикали левого верхнего края курсора мыши.	Фиксация слоя в текущей позиции в окне браузера и изменение формы курсора мыши на всём документе на значение 'auto'. В случае отмены данного действия производится возврат слоя к координатам, с которых началось его передвижение.

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

Подробности

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

Все три метода могут возвращать значения типа boolean (обратите внимание - с маленькой буквы, т.е. речь идёт о примитиве, а не об обёртке Boolean). Любое другое значение, а так же отсутствие возвращаемого значения интерпретируется как возвращение значения true.

В общем случае возвращение true означает разрешение на проделывание действий по-умолчанию, false - отказ от этих действий. Действия по-умолчанию для событий приведены в таблице №1.

Пример: Перетаскивание только по горизонтали

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

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

Делается это примерно так:

(function() {
    var /** @type {number} */ offsetX;

    layer.mouseDown = function(offset) {
        offsetX = offset.x;
    }

    layer.mouseMove = function(x) {
        this.style.left = (x - offsetX) + 'px';
        return false;
    }

    layer.mouseUp = function() {
        offsetX = null;
    }
})();

Вставьте этот код перед регистрацией слоя в объекте DnD в первом примере (в начале статьи) - и он придаст слою нужную функциональность. Послоностью пример можно увидеть, посмотре исходные коды тестов (директория "./test/") - там этот пример соответствует примеру №3. Запустите файл "./test/test.html" и проверьте его работу в своём браузере.

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

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

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

Кроме того, было бы полезно в процессе перемещения сразу показывать пользователю, что в данный момент элемент находится не над приемлемой для помещения в неё зоной. Традиционно это делается путём присвоения курсору такого значения, которое выглядит как знак запрета. К сожалению, такое значение для CSS-свойства 'cursor' на сегодняшний момент не стандартизовано, однако, несмотря на это, поддерживается последними версиями всех достаточно популярных браузеров, за исключением, разве что, Opera`ы (будем надеяться, что это временно). Это значение - 'no-drop'.

Допустим, что область карзины представлена объектом SquareArea, которому в конструкторе передаются её координаты и размеры, и у неё есть один метод - isInside(/*number*/ x, /*number*/ y), который возвращает результат типа boolean, говорящий, соответственно, входит или не входит точка с переданными ему координатами в его область. Тогда наш код для этой ситуации может быть примерно таким:

(function() {

    var /** @type {Object} */ offset,
        /** @type{SquareArea} */ toArea = new SquareArea(450, 450, 100, 100);

    layer.mouseDown = function(_offset) {
        offset = _offset;
    }

    layer.mouseMove = function(x, y) {

        this.style.cursor =
        document.body.style.cursor = toArea.isInside(x, y) ? 'move' : 'no-drop';
    }

    layer.mouseUp = function(x, y) {

        offset = null;
        this.style.cursor = 'move';

        return toArea.isInside(x, y);
    }
})();

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

Вставьте этот код перед регистрацией слоя в объекте DnD в первом примере (в начале статьи) - и он придаст слою нужную функциональность. Полоностью пример можно увидеть, посмотре исходные коды тестов (директория "./test/") - там этот пример соответствует примеру №4. Запустите файл "./test/test.html" и проверьте его работу в своём браузере.

JavaScript: Реализация pattern`а Singleton

2009-04-28T04:08:00.000-07:00

По моему мнению гибкость языка JavaScript оставляет далеко позади практически все известные мне языки. Одним из тонких моментов является работа оператора new. Мы привыкли, что он создаёт объект с помощью конструктора, передавая ему аргументы. Но на самом деле результат может быть и иным: если в функции, используемой в качестве конструктора, вернуть какой-либо другой объект, то он-то и станет результатом всего выражения с оператором new. Посмотрим на пример:

function X(){}
function Y(){ return new X; }
var y = new Y; 
alert(y instanceof Y); // false
alert(y instanceof X); // true

Этот приём, например, можно очень удобно использовать для того, что бы заставить IE работать, как это должен делать любой нормальный браузер, с объектом XMLHttpRequest без всяких заморочек с его ActiveX`овскими конструкторами:

// Provide the XMLHttpRequest class for IE 5.x-6.x:
if (typeof XMLHttpRequest == "undefined")
    /** @constructor */
    XMLHttpRequest = function() {
        try { return new ActiveXObject("Msxml2.XMLHTTP.6.0") } catch(e) {}
        try { return new ActiveXObject("Msxml2.XMLHTTP.3.0") } catch(e) {}
        try { return new ActiveXObject("Msxml2.XMLHTTP") } catch(e) {}
        try { return new ActiveXObject("Microsoft.XMLHTTP") } catch(e) {}
        throw new TypeError( "This browser does not support XMLHttpRequest." )
    };

- после этого можно работать с этим конструктором практически так же, как во всех остальных браузерах - FireFox`е, Safari, Opera`е и Chrom`е. Этот приём описан в Wikipedia.

Обычно для реализации Singleton`а применяются специальные конструкции на основе методов и прочего. Но в JavaScript представляется намного более простым использование этой возможности так, что бы внешний интерфейс создания экземпляра вообще не отличался от возврата уже созданного предыдущими вызовами экземпляра.
Так может быть реализован и pattern "Singleton" на JavaScript:

/**
 * @constructor
 * @singleton
 */
function SingletonClass() {

    if (arguments.callee.instance)
        return arguments.callee.instance;
    
    //...
    
    return arguments.callee.instance = this;
}

Update №1 (18.01.2010)
Мне пришла в голову мысль о том, что не очень хорошо делать так, как я предложил в примере выше. Дело в том, что поле instance открыто для редактирования и внесения изменений и этот механизм из-за этого можно сломать. Конечно, вряд ли кто-то станет намеренно так поступать, но лучше всё-таки не оставлять такой возможности.
Так что сейчас я оформляю Singleton`ы несколько подругому:

/**
 * @constructor
 * @singleton
 */
var SingletonConstructor;
(function() {
    var /** @type {SingletonConstructor} */ instance;
    SingletonConstructor = function() {
        if (typeof instance !== 'undefined')
            return instance;
        
        //...
        
        return instance = this;
    };
})();

JavaScript: Выяснение имени класса (конструктора)

2009-04-23T01:10:00.000-07:00

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

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

function x(){}
var x = function(){}

Между этими строками есть небольшое отличие, но в данном случае оно не существенно. Так вот, само название ПЕРЕМЕННАЯ говорит нам о том, что она может менять своё значение, по-этому опираться на то, что эта переменная будет всегда ссылаться на один раз присвоенную ей функцию, нельзя. Следующий пример это демонстрирует:

function x(){};
//...
x = 5;
//...
x(); //Error!

Но что же делать, если про функцию всё-таки нужно узнать её имя? Например, у нас может быть написан следующий код:

function x1(){}
var x2;
if (x1) x2 = x1;
x1 = 5;

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

Здесь следует сказать пару слов о глобальном контексте. В JavaScript определён объект Global, доступный по ссылке this. Это означает, что если мы объявляем переменную не внутри какой-либо функции, а просто в сценарии, то она автоматически становится свойством объекта Global и к ней можно обращаться не только по имени, но и как к свойству этого объекта:

var x = 5;
alert(this.x); // '5'

В частном, но наиболее часто встречающемся случае клиентского JavaScript (client-side JavaScript), т.е. расширения стандарта ECMAScript в браузерах моделью DOM, нам доступна ссылка window, укзывающая на объект Window, который является расширением объекта Global для браузерной среды, и в нём, соответственно, так же можно, обращаться к его свойствам как к переменным, однако в общем случае использование ссылки window нельзя назвать корректным, по крайней мере лично мне хотелоось бы писать решения, которые работали бы, кроме клиентского JavaScript, ещё и, скажем, в Java-программах, использующих Scripting API, поддержка которого есть в JDK6.

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

var /** @type {Global} */ global = this;

Теперь нам будет проще написать нужную функцию, но куда её лучше всего разместить? Мне представляется логичным помещение её в Function.prototype, поскольку тогда она станет доступна у всех функций (т.к. любая функция представляет собой экземпляр объекта Function и ссылается по-этому своей ссылкой __proto__ на объект Function.prototype).

Итак, какой код получаем в результате:

var /** @type {Global} */ global = this;

//...

/**
 * Функция, возвращающая имя функции this, если оно присутствует в глобальном
 * контексте.
 * 
 * @return {string} имя функии, доступное по ссылке this или null, если имя не
 * найдено.
 */
Function.prototype.getName = function() {

    for (var /** @type {string} */ i in global)
        if (global[i] === this)
            return i;

    return null;
}

//...


//Тестируем:

//Объект узнаёт имя своего конструктора:
function x1(){
    this.showMyName = function() {
        alert('My constructor name is ' + this.constructor.getName());
    }
}
y = new x1;
y.showMyName(); // 'My constructor name is x1'

var x2;
if (x1) x2 = x1;
x1 = 5;
y.showMyName(); // 'My constructor name is x2'

// Функция узнаёт своё имя:
function x3(){ alert('My name is ' + arguments.callee.getName()); }
x3(); // 'My name is x3'

// Узнаём у функции её имя:
function x4(){}
alert(x4.getName()); // 'x4'

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

Update: К сожалению, в последней на сегодняшний день версии Internet Explorer`а - 8 (тестировал на версии 8.0.7600.16385) - всем переменным глобального пространства имён и, соответственно, функциям, автоматически присваивается модификатор {Don`t Enum}, из-за чего данный метод в этом браузере не работает... :(

JavaScript: особенности инкапсуляции на основе замыканий. Часть 4: Наследование

2009-04-20T14:47:00.000-07:00

Существует огромное множество различных реализаций наследования в JavaScript - от кустарных приёмов до реализаций в раскрученных библиотеках типа JQuery и Prototype. Но всех их объединяет один недостаток - они не позволяют использовать инкапсуляцию на основе замыканий (и никакую другую тоже). По крайней мере мне не попадалось ни одной реализации наследования в JS, которая позволяла бы скрывать данные.

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

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

Должен в конструкторе первым делом вызывать конструктор класса-предка.
Всегда иметь ссылку на экземпляр созданного в конструкторе класса-предка в переменной super.
Некоторые public-методы могут быть переопределены и добавлены новые. То же самое в отношении public-полей.
Существует возможность открывать потомкам доступ к некоторым функциям и полям (модификатор protected в Java).
Только те исключения (и их потомков), которые мог вызывать переопределённый метод, может вызывать метод переопределяющий. Либо последний исключений может не вызывать вовсе.

По поводу 2 пункта замечу, что слово super в JavaScript является зарезервированным и поэтому его использовать не получится, довольствуясь лишь _super, что вобщем-то даже имеет положительную сторону - будет сразу восприниматься в качестве особой переменной.
Ну а по поводу 4 пункта, честно признаюсь, сколько ни думал о том, как это реализовать с применением замыканий, так ничего путного и не надумал. Возможно, я придумаю, как можно хитро вывернуться, всё-таки реализовав это, но пока давайте про этот пункт забудем и реализуем наследование без него, считая, что такого модификатора у нас нет.

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

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

Мы видим, что прототип ссылается неявной ссылкой (доступной в FireFox по имени __proto__ и недоступной в других браузерах - по-этому я называл её здесь именно так) на объект-прототип класса-предка, а на экземпляр ссылается только ссылка _super.

Первое изменение коснётся механизма создания прототипа. Т.к. разработчики спецификации ECMAScript не оставили нам возможности напрямую контролировать ссылку __proto__, мы вынуждены хитрить, что бы заставить её ссылаться на то, что нам будет нужно.

В Базовой модели конструктор прототипа выглядел так:

A.prototype = new function() {/*здесь код конструктора прототипа*/}
A.prototype.constructor = A;

Таким образом, у нас создавалась безымянная (анонимная) функция и тут же использовалась в качестве конструктора нового объекта-прототипа для класса A. Затем, что бы не нарушать принятые в JavaScript договорённости относительно взаимных ссылок между конструкторами и прототипами, мы выставляли свойству constructor прототипа ссылку на класс.

Теперь же, учитывая, что мы не можем напрямую контролировать ссылку __proto__, единственная возможность для нас прописать в неё то значение, которое нам нужно, состоит в том, что бы функция, создающая объект, который должен ссылаться посредством __proto__ туда, куда нам надо, должна до создания объекта ссылаться туда свойством prototype:

function X() {}
function Y() {this.z = 5;}
var x1 = new X;
X.prototype = new Y;
var x2 = new X;
alert(x1.z); //Выведет 'undefined'
alert(x2.z); //Выведет '5';

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

A.prototype = function() {/*...*/}
A.prototype.prototype = B.prototype; // B - конструктор, от которого мы наследуем A
A.prototype = new A.prototype;
A.prototype.constructor = A;

На выходе получим прототип, ссылающийся ссылкой __proto__ на прототип конструктора-предка.

Теперь осталось разобраться со ссылкой _super. Она будет обладать похожим поведением на ссылку _this - так же будет переменной, имеющий двойника - переменную __super, являющуюся полем объекта. Так же, как и ссылку __this, её не будет смысла очищать в методе privateState.get() и, соответственно, наполнять в privateState.set(). Так же она будет константой для пользователя.
Кроме того, она будет присваиваться вызову конструктора-предка вначале метода pcreatePivateState и в нём же из неё будут извлекаться все свойства и присваиваться ссылке __this - если они, конечно, не будут переопределены в классе-потомке.

Теперь соберём всё вместе и протестируем. Вот, какая получается расширенная модель:

function B() {
    var y = 15;

    this.getY = function(){
        return y;
    }

    this.setY = function(_y) {
        y = _y;
        return this;
    }
}

/**
 * @author Vyacheslav Lapin
 * @version 0.01 09.04.2009 21:10:04
 *
 * @constructor
 * @extends B
 * 
 *
 * @param {number} x + 
 */
function A(x) {

    if (this.constructor !== arguments.callee)
        return new arguments.callee(x);

    this.privateState = this.createPrivateState(x);
}

A.prototype = function() {

    var /** @type {A} */ _this,
        /** @type {B} */ _super,

        /**
         * @static
         * @type {Array<A>}
         */
         __callInstances = [];

    this.createPrivateState = function(__x) {

        //Переменные для хранения private-полей объекта
        var /** @type {number} */ _x = __x,

            /**
             * @constant
             * @type {A}
             */
            __this = this,

            /**
             * @constant
             * @type {B}
             */
            __super = new B(); // Вызываем конструктор класса-предка

        this.createPrivateState = null;

        // Отдельный функциональный блок для того, что бы не заводить в
        // closure ещё одно поле - переменную i
        (function() {
            //Здесь мы перечисляем свойства экземпляра класса-предка
            for (var /** @type {string} */ i in __super)
                // Проверяем, собственное это свойство экземпляра super-класса
                // или унаследованное? Ведь унаследованные свойства нам не нужны -
                // мы и так их унаследуем по цепочке прототипов, если они не будут
                // переопределены в нашем прототипе, а тогда - унаследуем
                // переопределённые, что нас вполне устроит.
                if (__super.hasOwnProperty(i)
                    // Так же проверяем, есть ли такие же в прототипе
                    && !this.constructor.prototype.hasOwnProperty(i)
                    // или в самом объекте?
                    && !this.hasOwnProperty(i)
                )
                    try {
                        this[i] = __super[i];
                    } catch (/** @type {Error} */ e) { }
        })();

        return {
            get: function() {

                if (_this) {
                    __callInstances.push(_this);
                    _this.privateState.set();
                }

                x = _x;
                //...
                _this = __this;
                _super = __super;

                _x =
                //...
                null;
            },

            set: function() {

                _x = x;
                //...

                x =
                //...
                _this =
                _super = null;

                if (__callInstances.length
                    && __callInstances[__callInstances.length - 1] !== __this)

                    __callInstances.pop().privateState.get();
            }
        }
    }

    /**
     * @param {Arguments} args +
     */
    function methodCaller(args) {
        this.privateState.get();
        var result = args.callee.apply(_this, args);
        this.privateState.set();
        return result;
    }

    //--------------------------------------------------------------------------

    var /** @type {number} */ x;
    //...

    /**
     * @return {number}
     */
    this.getX = function() {

        if (_this !== this) return methodCaller.call(this, arguments);

        return x;
    }

    /**
     * @param {number} _x
     * @return {A} this
     */
    this.setX = function(_x) {

        if (_this !== this) return methodCaller.call(this, arguments);

        x = _x;

        return this;
    }

    /**
     * @override
     */
    this.setY = function(_y) {

        if (_this !== this) return methodCaller.call(this, arguments);

        alert('Hello from A!');
        _super.setY(_y);
        
        return this;
    }

}

/** @type {string} */ A._className = "A";
A.prototype.prototype = B.prototype;
A.prototype = new A.prototype;
A.prototype.constructor = A;

// Импортируем в конструктор-потомок так же статические поля
// конструктора-предка- свойства класса
(function() {
    for (var /** @type{string} */ i in B)
        if (!(i in A))
            try {
                A[i] = B[i];
            } catch (/** @type {Error} */ e) { }
})();

//test
var a = new A(10);
alert(a.getY()); //Выводит '15'
alert(a.setY(20).getX()); // Выводит сначала 'Hello from A!', затем 10
alert(a.getY()); //Выводит  '20'

Вот и всё. Можно теперь делать любые сложные деревья наследования в JavaScript в полном соответствии с принципами инкапсуляции.

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

P.S. Напоследок хочу предостеречь вас от попытки на радостях наследовать от системных конструкторов - к сожалению, с ними может не пройти выражение:

__this[i] = __super[i];

Дело в том, что они не являются в полном смысле JavaScript`овыми объектами и для них такой возможности часто не предусмотрено. Например, мне не удалось наследовать от XMLHttpRequest - там это выражение вылетало с ошибкой даже при том, что я обромил его блоком try/catch:

try {__this[i] = __super[i];} catch(/** @type {Error} */ e) {}

Всё равно, даже такой бронебойный код вываливался с ошибкой в браузере. По крайней мере в FF это дело у меня не прошло. Так что ещё раз повторюсь - расширенная модель предназначена для наследования от родных JavaScript-конструкторов объектов. Будьте осторожны!

Другие части:
Часть 1: Основа Базовой модели
Часть 2:Механизм вызова методов
Часть 3: Внутренние вызовы

JavaScript: Контроль типов

2009-04-20T04:41:00.000-07:00

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

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

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

В интегрированной среде разработки Eclipse есть такое средство, как Snippets, прекрасно подходящее для решения задачи контроля типов в JavaScript. Snippet - это кусочек кода в общем виде, настраиваемый под конкретную ситуацию путём редактирования некоторых имён и значений, называемых переменными snippet`ов. Их можно создавать и группировать, что бы потом удобно было находить и использовать. Я у себя создал группу "Params check" и в ней расположил snippet`ы для всех примитивов.

Перед тем, как начать, следует ввести константы-обозначения типов, с которыми будет проще осуществлять эти проверки. Эти константы будут иметь строковые типы и будут служить для сравнения результатов операции typeof, применяемой к переменным:

var undefined,
    Types = {
        // Primitive types
        /** @type {string} */ STRING_TYPE: 'string',
        /** @type {string} */ OBJECT_TYPE: 'object',
        /** @type {string} */ NUMBER_TYPE: 'number',
        /** @type {string} */ BOOLEAN_TYPE: 'boolean',
        /** @type {string} */ FUNCTION_TYPE: 'function',
        /** @type {string} */ UNDEFINED_TYPE: 'undefined'
    };

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

//Param x as boolean check
if (typeof x !== Types.BOOLEAN_TYPE)
    if (x instanceof Boolean)
        x = x.valueOf();
    else {
        if (x instanceof String)
            x = x.valueOf();

        if (typeof x === Types.STRING_TYPE)
            x = x !== '' && x !== 'false';
        else
            x = x ? true : false;
    }

, изначальный же Snippet для этогой проверки должен содержать переменную snippet`а для имяни переменной, что бы внести его один раз и больше не маяться:

//Param ${varName} as boolean check
if (typeof ${varName} !== Types.BOOLEAN_TYPE)
    if (${varName} instanceof Boolean)
        ${varName} = ${varName}.valueOf();
    else {
        if (${varName} instanceof String)
            ${varName} = ${varName}.valueOf();

        if (typeof ${varName} === Types.STRING_TYPE)
            ${varName} = ${varName} !== '' && ${varName} !== 'false';
        else
            ${varName} = ${varName} ? true : false;
    }

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

//Param s1 as string check
if (s1 === null || typeof s1 === Types.UNDEFINED_TYPE)
    throw new TypeError(
        'Required param - s1 - is not specified by function call!'
    );

if (typeof s1 !== Types.STRING_TYPE)
    s1 = s1 instanceof String ?
            s1.valueOf()
            : s1.toString();

if (!/^[1-0a-f]*$/i.test())
    throw SyntaxError('Required param - s1 - has invalid format.');

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

//Param ${varName} as string check
if (${varName} === null || typeof ${varName} === Types.UNDEFINED_TYPE)
    throw new TypeError(
        'Required param - ${varName} - is not specified by function call!'
    );

if (typeof ${varName} !== Types.STRING_TYPE)
    ${varName} = ${varName} instanceof String ?
            ${varName}.valueOf()
            : ${varName}.toString();

if (!/^${regexp}$$/.test())
    throw SyntaxError('Required param - ${varName} - has invalid format.');

Что же касается числового типа - number, то здесь имеется небольшой подводный камешек. Дело в том, что целые и вещественные числа спецификация ECMAScript не различает. Однако, как правило, в сценарии по логике легко понять, какого именно числа мы ждём - целого или дробного, так что я сделал два разных блока проверки - для целых (integer) и вещественных (float) чисел:

//Param x as integer check
if (x === null || typeof x === Types.UNDEFINED_TYPE)
    throw new TypeError(
        'Required param - x - is not specified by function call.'
    );

if (typeof x !== Types.NUMBER_TYPE)
    if (x instanceof Number)
        x = x.valueOf();
    else {
        if (x instanceof String)
            x = x.valueOf();

        if (typeof x === Types.STRING_TYPE)
            x = parseInt(x);
        else
            throw new TypeError(
                'Required param - x - has invalid type!'
            );
    }

if (x < 1 || x > 100)
    throw new RangeError(
        'Required param - x = '
        + x
        + ' - is out of correct range (1 - 100).'
    );


//Param y as float check
if (y === null || typeof y === Types.UNDEFINED_TYPE)
    throw new TypeError(
        'Required param - y - is not specified by function call.'
    );

if (typeof y !== Types.NUMBER_TYPE)
    if (y instanceof Number)
        y = y.valueOf();
    else {
        if (y instanceof String)
            y = y.valueOf();

        if (typeof y === Types.STRING_TYPE)
            y = parseFloat(y);
        else
            throw new TypeError(
                'Required param - y - has invalid type.'
            );
    }

if (y < 0.55 || y > 0.99)
    throw new RangeError(
        'Required param - y = '
        + y
        + ' - is out of correct range (0.55 - 0.99).'
    );

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

//Param ${varName} as integer check
if (${varName} === null || typeof ${varName} === Types.UNDEFINED_TYPE)
    throw new TypeError(
        'Required param - ${varName} - is not specified by function call.'
    );

if (typeof ${varName} !== Types.NUMBER_TYPE)
    if (${varName} instanceof Number)
        ${varName} = ${varName}.valueOf();
    else {
        if (${varName} instanceof String)
            ${varName} = ${varName}.valueOf();

        if (typeof ${varName} === Types.STRING_TYPE)
            ${varName} = parseInt(${varName});
        else
            throw new TypeError(
                'Required param - ${varName} - has invalid type!'
            );
    }

if (${varName} < ${min_value} || ${varName} > ${max_value})
    throw new RangeError(
        'Required param - ${varName} = '
        + ${varName}
        + ' - is out of correct range (${min_value} - ${max_value}).'
    );


//Param ${varName} as float check
if (${varName} === null || typeof ${varName} === Types.UNDEFINED_TYPE)
    throw new TypeError(
        'Required param - ${varName} - is not specified by function call.'
    );

if (typeof ${varName} !== Types.NUMBER_TYPE)
    if (${varName} instanceof Number)
        ${varName} = ${varName}.valueOf();
    else {
        if (${varName} instanceof String)
            ${varName} = ${varName}.valueOf();

        if (typeof ${varName} === Types.STRING_TYPE)
            ${varName} = parseFloat(${varName});
        else
            throw new TypeError(
                'Required param - ${varName} - has invalid type.'
            );
    }

if (${varName} < ${min_value} || ${varName} > ${max_value})
    throw new RangeError(
        'Required param - ${varName} = '
        + ${varName}
        + ' - is out of correct range (${min_value} - ${max_value}).'
    );

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

JavaScript: особенности инкапсуляции на основе замыканий. Часть 3: Внутренние вызовы

2009-04-19T11:20:00.000-07:00

Продолжаю серию публикаций, направленную на усовершенствование применения инкапсуляции на основе замыканий.В первой статье, "Базовая модель", я поставил проблему несовместимости инкапсуляции на основе замыканий с реализацией ООП на основе прототипов, каковая наличествует в JavaScript и предложил т.н. "базовую модель" того, как можно было бы это обойти. Во второй статье цикла, "Механизм вызова методов", я сосредоточил внимание на упрощении вызова методов в рамках базовой модели и исправлении недочёта базовой модели в отношении использования ключевого слова this и в отношении вызовов объектом собственных методов. Данная статья посвящена окончанию разработки базовой модели. Осталась ещё не решённой проблема "внутренних вызовов", т.е. вызовов одним экземпляром объекта методов другого экземпляра этого же объекта.Итак, какая проблема возникает в базовой модели при внутреннем вызове? Давайте посмотрим по-внимательнее на методы get и set:

get: function() {
    x = _x;
    _this = __this;
    _x = null;
},
set: function() {
    _x = x;
    x =
    _this = null;
}

, а так же давайте снова взглянем на methodCaller:

function methodCaller(args) {
    this.privateState.get();
    var result = args.callee.apply(_this, args);
    this.privateState.set();
    return result;
}

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

get: function() {
    if (_this) //Объект уже чем-то наполнен
    //...
}

Ну хорошо, выяснили - наполнен, что делать дальше? Очевидно, нужно куда-то сохранить значения переменных, что бы потом, в методе set, присвоить их обратно. Но куда и как? Перечислять снова все переменные вручную - это уже окончательно перегрузит "базовую модель". Наверное, лучше всего просто вернуть переменные тому объекту, который их разместил, вызвав у его privateState метод set, с тем, что бы потом, в методе set вернуть их назад методом privateState.get. Примерно так:

var __instance = null;
return {
    get: function() {
        if (_this)
            (__instance = _this).privateState.set();
        x = _x;
        _this = __this;
        _x = null;
    },
    set: function() {
        _x = x;
        x =
        _this = null;
        if (__instance) {
            __instance.privateState.get();
            __instance = null;
        }
    }
}

Вроде бы, всё нормально. Но... теоретически, возможна ситуация, когда этого будет не достаточно.Представьте ситуацию, когда a1 и a2 являются объектами, созданными конструктором A и, соответственно, ссылаются на один и тот же прототип. Тогда давайте проанализируем, что же будет происходить:

Какой-то метод a1 вызывает другой или тот же самый метод a2.
Тогда метод a2.privateState.get() вызовет a1.privateState.set(), очищая прототип от переменных a1 и наполняя его своими переменными.
После выполнения вызванного метода a2 вернёт всё обратно, вызвав в методе a2.privateState.set() метод a1.privateState.get().
Метод объекта a1 продолжит выполнение, как ни в чём не бывало. В распоряжении прототипа в этот момент будут именно переменные a1.

Теперь давайте усложним ситуацию - введём дополнительно объект a3:

Какой-то метод a1 вызывает другой или тот же самый метод a2.
Тогда метод a2.privateState.get() вызовет a1.privateState.set(), очищая прототип от переменных a1 и наполняя его значениями своих полей.
Выполняющийся в данный момент метод объекта a2 вызывает какой-то из методов объекта a3.
Вызывается метод a3.privateState.get(), который вызывает метод a2.privateState.set(), который в свою очередь очищает прототип от переменных объекта a2 и (что нам вовсе не нужно) вызывает a1.privateState.get(), который прописывает в прототип значения переменных a1.
После выполнения a2.privateState.set(), метод a3.privateState.get() продолжит выполняться и затрёт в прототипе все переменные объекта a1, присвоив им значения переменных a3. Объект a1 потеряет свои поля.

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

var /** @static
     * @type Array<Object> */
    __callInstances = [];

Тогда нам так же понадобится разделить функциональность метода privateState.set() - что бы выкатывать состояние предыдущего объекта в случае вызова этого метода methodCaller`ом и не выкатывать - в случае вызова privateState.get`ом другого экземпляра того же класса. Определить это проще всего, договорившись добавлять объект в методе privateState.get() в массив __callInstances прежде, чем вызывать у него метод privateState.set() - тогда по нахождению объекта __this в конце массива мы сможем со всей определённостью понять - вызывают метод privateState.set() из privateState.get()`а другого экземпляра того же класса (и тогда выкатывать переменные последнего объекта в массиве __callInstances не нужно) или он вызывается из methodCaller`а прототипа (и тогда, соответственно, нужно):

get: function() {
    if (_this) {
        __callInstances.push(_this);
        _this.privateState.set();
    }
    x = _x;
    _this = __this;
    _x = null;
},
set: function() {
    _x = x;
    x =
    _this = null;
    if (__callInstances.length
        && __callInstances[__callInstances.length - 1] !== __this)
        __callInstances.pop().privateState.get();
}

Так же изменения немного коснутся и механизма вызова methodCaller`а. Напомним, каким он у нас стал после выполнения действий из предыдущей статьи цикла:

if (_this) return methodCaller.call(this, arguments);

Теперь для того, что бы выполнять или не выполнять его, нам недостаточно будет знать о простом наличии в переменной _this какого-то не null`евого значения - ибо в случае вызова одним экземпляром метода другого экземпляра того же класса, у нас переменная _this будет иметь значение, но оно будет не верным, поскольку будет ссылаться на вызывающий, а не на вызываемый объект. Так что теперь нам нужно будет в этом случае осуществлять проверку на идентичность значения этого свойства переменной this, что бы понять, что переменная _this заполнена правильным значением:

if (_this !== this) return methodCaller.call(this, arguments);

Соберём всё вместе и протестируем:

/** @author Vyacheslav Lapin<se-la-vy.blogspot.com>
 * @version 0.01 08.04.2009 17:52:40
 * @constructor
 * @param {number} x */
function A(x) {
    if (this.constructor !== A)
        return new A(x);
    this.privateState = this.createPrivateState(x);
}
A.prototype = new function() {
    var /** @type A */ _this,
        /** @static
         * @type Array<A> */
        __callInstances = [];
    this.createPrivateState = function(__x) {
        //Переменные для хранения private-полей объекта
        var /** @type number */ _x = __x,
            /** @constant
             * @type A */
            __this = this;
        this.createPrivateState = null;
        return {
            get: function() {
                if (_this) {
                    __callInstances.push(_this);
                    _this.privateState.set();
                }
                x = _x;
                //...
                _this = __this;
                _x =
                //...
                null;
            },
            set: function() {
                _x = x;
                //...
                x =
                //...
                _this = null;
                if (__callInstances.length
                    && __callInstances[__callInstances.length - 1] !== __this)
                    __callInstances.pop().privateState.get();
            }
        }
    }
    /** @param {Arguments} args */
    function methodCaller(args) {
        this.privateState.get();
        var result = args.callee.apply(_this, args);
        this.privateState.set();
        return result;
    }

    //--------------------------------------------------------------------------
    var /** @type number */ x;
    //...
    /** @return {number} */
    this.getX = function() {
        if (_this !== this) return methodCaller.call(this, arguments);
        return x;
    }
    /** @param {number} _x
     * @return {A} this */
    this.setX = function(_x) {
        if (_this !== this) return methodCaller.сall(this, arguments);
        x = _x;
        return this;
    }
    /** Метод, вызывающий себя же, но от другого объекта, переданного ему в
     * первом аргументе и передающий второй свой аргумент в качестве первого. В
     * случае, если первый аргумент не передан, выводится результат метода getX.
     * @param {A} [a1=null]
     * @param {A} [a2=null]
     * @param {A} [a3=null]
     * @return {number} */
    this.callMethod = function(a1, a2, a3) {
        if (_this !== this) return methodCaller.call(this, arguments);
        if (a1)
            return this.getX() + a1.callMethod(a2, a3);
        else
            return this.getX();
    }
}
A._className = 'A';
A.prototype.constructor = A;
//test
var /** @type A */ a1 = new A(1),
    /** @type A */ a2 = new A(2),
    /** @type A */ a3 = A(3),
    /** @type A */ a4 = A(4); //Можно вызывать и так - мы это предусмотрели в конструкторе
alert(a1.callMethod(a2, a3, a4));

Результат - "10" во всех браузерах, в которых я тестировал(IE, Opera, FF, Safari последних на данный момент стабильных версий).It works! :)))))На этом фрормирование первой версии "базовой модели" я считаю завершённым. Дальше в статьях данного цикла мы поговорим о том, как можно упростить разработку таких конструкторов с использованием инструментального средства Eclipse, а так же о том, как расширить "базовую модель", что бы применять её для наследования классов в JavaScript с сохранением преимуществ, которые даёт инкапсуляция на основе замыканий.А после этого мы поговорим о том, как расширить язык JavaScript, создав его диалект, направленный на более удобное использование базовой модели.Другие части:Часть 1: Основа Базовой модели Часть 2:Механизм вызова методов Часть 4: Наследование

JavaScript: особенности инкапсуляции на основе замыканий. Часть 2: Механизм вызова методов

2009-04-19T09:28:00.000-07:00

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

"get" - присваивание значений переменных объекта - переменным прототипа,
"set" - присваивание значений переменных прототипа - переменным объекта.

У этой модели имеется ряд неудобств при оформлении кода и ограничений при работе с получающимися объектами, как то:

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

Попыткам разрешить эти неудобства и снять ограничения посвящена данная и последующие статьи данного цикла. Тема данной статьи - разрешение первых двух из приведённых пунктов.Мне хотелось бы разработать максимально удобный паттерн использования инкапсуляции с ООП на основе прототипов, поэтому необходимость при написании каждого метода писать 2 строки кода - одну ("this.privateState.get();") в начале метода, вторую ("this.privateState.set();") - в конце, не может не резать мне глаз.Итак, что мы могли бы сделать, что бы сократить эти две строчки?Было бы здорово, если бы у нас была возможность поставить некоторый фильтр на вызовах всех методов прототипа, производимых через объект. Мы могли бы просто вписать перед ним вызов get, а после вызова самого метода - вызов set и - дело с концом. Но такой возможности у нас нет, поэтому нам придётся этот фильтр всё-таки вызывать из каждого метода, т.е. от одной строки - вызова.Назвать данный метод можно "methodCaller", т.к. он будет ответственным за вызовы методов. Нетрудно будет его написать:

/** @returns {Object} результат выполнения метода в контексте полей
 * данного объекта. */
function methodCaller() {
    this.privateState.get();
    var /** @type Object */ result = //вызов вызвавшей данную функции
    this.privateState.set();
    return result;
}

Как можно было бы передать этому методу имя и параметры вызова той функции, которая его вызвала, что бы он узнал, какой именно метод и с какими параметрами ему нужно будет вызвать? Можно было бы передать функцию - первым аргументом, а параметры - массивом во втором аргументе, но есть вариант по-проще - мы можем передавать ссылку "arguments". Она содержит и параметры вызова нашей функции, являясь их псевдо-массивом и ссылку на неё саму (она содержится в поле "callee").Необходимо помнить, что при вызове функции как метода объекта нам придётся пользоваться одним из методов объекта Function - "call" или "apply", которые предоставляют контроль над ссылкой "this" внутри неё, что бы подставлять методу правильную ссылку "this", иначе она будет вести не туда, куда нужно, что может привести к неадекватной работе метода.Кроме того, следует учесть, что метод может вызывать те или иные исключения. Несмотря на это, для него в любом случае необходимо вызвать метод "set". Для того, что бы этого добиться, поместим вызов этого метода в блок finally, а вызов исконного - в блок try перед ним. Тогда мы сможем элегантно избавиться от создания специальной переменной "result", поскольку блок "finally" выполняется даже после выполнения команды return.Итак, результирующий метод:

/** @returns {Object} результат выполнения метода в контексте полей
 * данного объекта. */
function methodCaller(args) {
    this.privateState.get();
    try {
        return args.callee.apply(this, args);
    } finally {
        this.privateState.set();
    }
}

Теперь рассмотрим возможный механизм вызова данного метода:

this.getX = function() {
    if (/* если вызов происходит извне */)
        return methodCaller.call(this, arguments);
    return x;
}

Осталось только придумать, как же все наши методы могли бы узнать, извне они вызваны или изнутри - методом "methodCaller"? В принципе, у объекта Function есть ссылка на функцию, вызвавшую данную - эта ссылка находится в свойстве caller и доступна только внутри функции. Мы могли бы написать выражение так:

if (arguments.callee.caller !== methodCaller) // если вызов происходит извне

, однако, к сожалению, метод caller не входит в стандарт ECMAScript и поэтому считается устаревшим. Почти все реализации JavaScript его до сих пор поддерживают, но у нас нет никаких гарантий того, что он будет поддерживаться дальше. Так что нужен какой-то другой механизм.Вспомним, что в первой статье данного цикла мы решили об-null-ять ссылки прототипа при окончании выполнения им методов, что бы освобождать память. Таким образом, на момент вызова метода извне, когда метод privateState.get ещё не вызван, у нас все закрытые поля ссылаются на null. Т.е. мы могли бы узнать, произведён вызов метода снаружи или изнутри методом methodCaller, просто проверив любое из полей объекта на равенство null, но вот незадача - мы не можем точно знать, что поле объекта, которое выберем для этого, не окажется равным null по логике работы самого класса и, соответственно, что мы не ошибёмся в нашем выводе о том, кто вызвал метод и не вызовем бесконечный цикл, в котором метод будет вызывать methodCaller, а тот в свою очередь - опять тот же метод.Иными словами, нам нужна такая ссылка в каждом объекте, про которую у нас всегда будет известно, что она - не null. Можно было бы сделать какой-нибудь простой служебный флаг типа boolean, который был бы скрытым полем любого объекта и всегда был бы равен true, что бы по его состоянию каждый метод мог определённо сказать - применён метод privateState.get или не применён, но есть идея по-лучше: помните, я в начале статьи писал о необходимости всегда помнить о том правиле, что приватные методы нам придётся вызывать не как обычно, просто открывая за их именами круглые скобки и перечисляя параметры, а с использованием специальных методов объекта function - call или apply, поскольку нам нужно явно указывать JavaScript-интерпретатору, что в этих методах ссылка this должна вести на объект, иначе она будет вести не туда. Помните? Так вот, теперь у нас появляется возможность обойти это жёсткое правило, приняв определённое соглашение. Т.к. нам всё равно нужна некоторая флаговая переменная для того, что бы мы по ней смогли гарантированно отличить, выполнен уже для объекта метод privateStage.get() или нет, мы можем этой переменной присвоить ссылку на сам этот объект. :)Т.е. введём специальную переменную в прототипе, назовём её _this, и присвоим ей ссылку this. Можно будет из любого закрытого метода использовать её вместо обычной ссылки this и тогда станет возможно вызывать эти методы обычным образом - как функциии, без использования таких дополнительных методов объекта function, как call и apply. ;)Тогда в начале private`ных методов мы можем писать следующую строчку:

if (_this !== this) return arguments.callee.apply(_this, arguments);

и это гарантирует нам правильную работу ссылки this в них.Т.е. теперь механизм вызова методов будет выглядеть так:

function methodCaller(args) {
    this.privateState.get();
    try {
        // Обратите внимание - теперь мы можем использовать ссылку "_this",
        // которая доступна между вызовами методов объекта privateState -
        // "get()" и "set()".
        return args.callee.apply(_this, args);
    } finally {
        this.privateState.set();
    }
}

Теперь рассмотрим возможный механизм вызова данного метода:

this.getX = function() {
    if (!_this) // если вызов происходит извне
        return methodCaller.call(this, arguments);
    return x;
}

И теперь обратим внимание, что мы решили и вторую проблему из списка проблем вначале статьи - "Неправильное поведение при вызове одним методом объекта других методов того же объекта", состоявшее в том, что метод "get" объекта privateState вызывается несколько раз, а потом происходят серии вызовов методов "set". Теперь, если наш метод "getX" вызовет какой-либо другой метод своего объекта, то этот метод пройдёт проверку в начале, т.к. у него уже установлено значение переменной "_this", ведь метод "privateState.set()" у него ещё не вызывался - он вызовется только когда метод "getX" завершит работу.Подведём предварительный итог, приведя весь получившийся код:

/** @constructor
 * @author Vyacheslav Lapin<se-la-vy.blogspot.com> */
function A(x) {
    this.privateState = this.createPrivateState();
    this.setX(x);
}
A.prototype = new function() {
    var /** @type A */ _this,
        /** @type number */ x;
    /** Конструктор объекта состояния private-полей объекта. Метод предназначен
     * для вызова один раз и только из конструктора объекта. Поэтому после
     * вызова он перекрывает объекту доступ к себе, посредством установки у
     * объекта одноимённого свойства, равного null
     * @constructor
     * @return {Object} - privateState-объект для конструктора A */
    this.createPrivateState = function() {
        //Переменные для хранения private-полей объекта
        var /** @type number */ _x,
            /** @constant
             * @type A */
            __this = this;
        // Закрываем возможность вызова этого метода объектом в дальнейшем
        this.createPrivateState = null;
        return {
            get: function() {
                //Присвоение переменным прототипа значений private-полей объекта
                x = _x;
                _this = __this;
                // Об-null-ение переменной объекта на время, пока её значение
                // находится в прототипе, воизбежание возможных проблем со
                // сборкой мусора
                _x = null;
                //, а ссылку "__this" нет смысла об-null-ять - сборке мусора
                // никак не поможет, если мы на время выполнения метода запретим
                // объекту privateState ссылаться на объект, для которого он
                // создан.
            },
            set: function() {
                // Возвращение значения private-полю объекта после использования
                _x = x;
                // Возвращать значение ссылки "__this" из прототипа так же не
                // имеет смысла - по сути она - константа и с ней не должно
                // ничего происходить.
                //Об-null-ение переменных прототипа
                x =
                _this = null;
            }
        }
    }
    /** Cлужебный метод для вызова методов объекта,
     * которые используют его private-переменные. В методах, которые не
     * используют private-поля его вызывать не обязательно.
     * @param {Arguments} args */
    function methodCaller(args) {
        this.privateState.get();
        try {
            return args.callee.apply(_this, args);
        } finally {
            this.privateState.set();
        }
    }
    /** @return {number} x */
    this.getX = function() {
        if (!_this) return methodCaller.call(this, arguments);
        return x;
    }
    /** @param {number} newX Значение X для установки */
    this.setX = function(newX) {
        if (!_this) return methodCaller.call(this, arguments);
        if (typeof newX == 'number')
            x = newX;
        else
            if (typeof newX == 'object'
                && newX instanceof Number)
                x = newX.valueOf();
            else
                throw new Error(
                    'Param is not a number! Param type is ' + typeof newX
                );
    }
    /** Функция для проверки корректности вызовова методов внутри объекта */
    this.getX2 = function() {
        if (!_this) return methodCaller.call(this, arguments);
        return this.getX() * this.getX();
    }
}
if (!A.hasOwnProperty('name'))
    /** @constant
     * @type string
     * @ignore */
    A.name = 'A';
A.prototype.constructor = A;

// Тестируем:
var a1 = new A(5);
alert('a1.getX() = ' + a1.getX()); // Выводит 'a1.getX() = 5'
alert('a1.getX2() = ' + a1.getX2()); // Выводит 'a1.getX2() = 25'

alert(a1.createPrivateState); // Выводит 'null' - метод не доступен

var a2 = new A(40),
    a3 = new A(new Number(562)),
    a4 = new A(0);
alert('a2.getX() = ' + a2.getX()); // Выводит 'a2.getX() = 40'
alert('a2.getX2() = ' + a2.getX2()); // Выводит 'a2.getX2() = 1600'

alert('a3.getX() = ' + a3.getX()); // Выводит 'a3.getX() = 562'
alert('a3.getX2() = ' + a3.getX2()); // Выводит 'a3.getX2() = 315844'

alert('a4.getX() = ' + a4.getX()); // Выводит 'a4.getX() = 0'
alert('a4.getX2() = ' + a4.getX2()); // Выводит 'a4.getX2() = 0'

alert('a1.getX() = ' + a1.getX()); // Выводит 'a1.getX() = 5'
alert('a1.getX2() = ' + a1.getX2()); // Выводит 'a1.getX2() = 25'

Другие части:Часть 1: Основа Базовой модели Часть 3: Внутренние вызовы Часть 4: Наследование

JavaScript: особенности инкапсуляции на основе замыканий. Часть 1: Основа Базовой модели

2009-04-19T08:08:00.000-07:00

Когда-то Дуглас Крокфорд впервые заметил, что на основе замыканий (closures) можно имитировать инкапсуляцию примерно так:

function A() {
    var /* number */ x = 5;
    this.getX = function() { return x;}
    this.setX = function(newX) {
        if (typeof x == 'number')
            x = newX;
        else
            throw new Error('Param is not a number!');
    }
}

var y = new A();
alert(y.getX()); // Вернёт 5
alert(y.x); // Вернёт 'undefined'

Вроде бы, выглядит логично, не правда ли? Вот только есть одна проблема, на которую в своё время обратил моё внимание участник форума Vingrad с ником AKS: каждый объект содержит весь набор методов своего класса, и если объектов будет достаточно много, то этот метод приведёт к очень неэкономному расходованию памяти.

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

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

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

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

Объект-прототип является чужим для того замыкания, в котором находятся поля. Он связан с ним неявной ссылкой (в FF она носит название "__proto__"), но она не поможет ему считать закрытые переменные. Так что же делать?

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

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

Тогда какими должны быть требования к этому вспомогательному замыканию? Оно должно уметь делать две вещи:

Устанавливать в закрытые переменные прототипа значения закрытых переменных объекта;
Записывать в закрытые переменные объекта значения закрытых переменных прототипа (после того, как прототип произвёл с ними некоторые действия).

Т.к. одного действия нам не достаточно, это не может быть функция - это должен быть объект с двумя методами:

метод "get" выполняет взятие значений переменных из объекта, при этом самим переменным объекта неплохо было бы присвоить значение null, что бы не иметь дублирующихся ссылок;
метод "set" устанавливает значения обратно в объект, об-null-яя аналогичные переменные в прототипе.

Сам этот объект назовём "privateState", поскольку он несёт закрытую часть состояния объекта.

Итак, что нам в итоге нужно:

метод для генерации внутреннего замыкания в прототипе объекта, который будет возвращать объект с двумя методами: get и set, которые, соответственно, будут устанавливать в прототип значения закрытых полей из этого объекта и в объект - из прототипа;
механизм вызова для методов прототипа, гарантирующий, что перед выполнением будут установлены значения закрытых полей.

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

Итак, метод генерации privateState-объекта внутри прототипа может выглядеть примерно так:

// Переменная прототипа, в которую будем помещать значение private-поля
// объекта каждый раз, когда будем выполнять какой-либо его метод.
var x;

// Функция, являющаяся конструктором provateState-объекта
this.createPrivateState = function() {

    //"_x" - переменная для хранения private-поля объекта
    var _x;

    return {
        get: function() {
            //Присвоение переменной прототипа значения private-поля объекта
            x = _x;

            // Об-null-ение переменной объекта на время, пока её значение
            // находится в прототипе, во избежание дублирующейся информации
            _x = null;
        },

        set: function() {
            // Возвращение значения private-полю объекта после использования
            _x = x;

            //Об-null-ение переменной прототипа
            x = null;
        }
    }
}

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

this.method1 = function() {
    this.privateState.get();

    //здесь располагается код метода, работающего с private-полями...

    this.privateState.set();
}

Тогда в конструкторе объекта мы могли бы просто вызывать метод createPrivateState() прототипа:

function A() {
    this.privateState = this.createPrivateState();
}

A.prototype = new function() {
    var x;
    this.createPrivateState = function(){...} //Описан выше
    this.method1 = function() {...} //Описан выше
    //Другие методы...
}

A._className = "A"; //Записываем в специальное свойство класса его имя
A.prototype.constructor = A; //Присваиваем прототипу ссылку на конструктор

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

Другие части:
Часть 2: Механизм вызова методов.
Часть 3: Внутренние вызовы.
Часть 4: Наследование.

JavaScript: Дополняем объект Date

2009-04-19T08:00:00.000-07:00

На мой взгляд, объекту Date в JavaScript не хватает небольшого количества констант для более удобной работы с ним. Вот как можно все их создать для него:

// Adding consts for comfortable work with Date constructor.
/** @type {number}*/ Date.MS_PER_YEAR = 365 * (
    /** @type {number} */ Date.MS_PER_DAY = 24 * (
        /** @type {number} */ Date.MS_PER_HOUR = 60 * (
            /** @type {number} */ Date.MS_PER_MINUTE = 60 * (
                /** @type {number} */ Date.MS_PER_SECOND = 1000
            )
        )
    )
);

/** @type {number} */ Date.MS_PER_LEAP_YEAR =
                            Date.MS_PER_YEAR + Date.MS_PER_DAY;

LEAP YEAR - это високосный год.
Т.к. с датой чаще всего бывает удобнее всего работать как с числом, возвращаемым методом getTime() и передавать число в конструкторе, то эти константы часто помогают производить более сложные операции.

Update №1 (18.01.2010):
Учитывая, что дату и время в объекте Date можно менять, периодически возникает задача вернуть объект Date, на который ориентируется внутренняя структура какого-либо объекта и который в нём инкапсулирован (при помощи замыканий) и изменения в котором могут негативно отразиться на логике его работы. Для таких случаев в Java предназначен метод clone. Он возвращает точную копию объекта. Вот какой могла бы быть его реализация:

Date.prototype.clone = function() {
    return new Date(this.getTime());
};

JavaScript: небольшое отличие function от function

2009-04-19T02:16:00.001-07:00

Некоторое время назад я писал на форуме, что не вижу разницы между следующими конструкциями:

function fnName() {
   //...
}

, и

var fnName = function () {...}

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

x(); // Выводит "1", хотя функция ещё вроде бы не определена...
var x = 2;
alert(typeof x); // Выводит "number"
// Следующая строка выполнилась ещё до того, как выполнилась первая строка данного
// примера, так что сейчас она ничего не меняет.
function x(){alert(1);}
alert(typeof x); // Опять выводит "number"
var x = function(){alert(3);}
x(); // Выводит "3". Функция переопределена.

JavaScript: используйте arguments.callee вместо названия функции

2009-01-05T16:09:00.000-08:00

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

var factorial = function(x){
    return x == 1 ? 1 : x + factorial(--x);
}

В данном коде мы, фактически, обращаемся к внешней цепочке областей видимости и читаем из неё переменную "factorial" и, надеясь, что это - функция, вызываем её.

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

var fac = factorial;
factorial = 27;
alert(fac(factorial));

Но функция выдаст ошибку:

factorial is not a function
factorial(26)test.js (line 2)

Просто нужно помнить, что функции в JavaScript - это такой особый тип данных, а не неизменяемая часть программы, как, например, в Java. Функцию можно присваивать любой переменной, свойству объекта или элементу массива, жонглируя ей как угодно. Эта возможность фактически означает, что у функций в JavaScript нет своих постоянных имён! Поэтому для того, что бы не лишать программистов этой возможности, лучше всегда изнутри функции ссылаться на неё с помощью встроенного и поддерживаемого свойства псевдо-массива Arguments, называемого "callee". Это свойство всегда ссылается на функцию, которая выполняется в данный момент, поэтому вы оказываетесь застрахованы от недоразумений, продемонстрированных выше:

function factorial(x) {
    return x == 1 ? 1 : x + arguments.callee(--x);
}
var fac = factorial;
factorial = 27;
alert(fac(factorial)); // Возвращает "378".

Но в JavaScript всё-таки есть способ элегантно обойти данную ситуацию. Если вам не очень нравится прибегать к вызову свойства callee объекта Arguments, то можно воспользоваться конструкцией, называемой "литералом функции" с необязательным параметром, содержащим имя функции:

var factorial = function f(x) {
    return x == 1 ? 1 : x + f(--x);
};
alert(f); // Ошибка: "f is not defined"

В этом коде не создаётся внешней переменной "f", здесь функция, как и в предыдущем примере, присваивается только внешней переменной "factorial", а переменная "f" определяется только внутри области видимости функции и служит для ссылки на данную функцию, так же, как и "arguments.callee", так что можно без опаски использовать переменную "f" для своих нужд - на работу данной функции это никак не повлияет.

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

Программная обработка исключительных ситуаций в JavaScript

2008-05-14T04:39:00.000-07:00

Зачем JS-приграммисту может понадобиться обрабатывать ошибки в сценариях? В принципе, не существует задач, при решении которых без механизма исключений никак нельзя было бы обойтись. Однако часто их использование оказывается заметно удобнее бесконечных if`ов - поскольку в коде мы с их помощью изолируем себя от некоторых ситуаций, в которых программа должна вести себя по-другому (главным образом, это может быть связано с неадекватной работой пользователя, например, при вводе данных) - и сосредотачиваемся на описании алгоритма в случае нужных нам условий, а уже потом отдельно разбираться, как говорится, с косяками. Это как в жизни - мы часто отодвигаем проблемы на потом, просто помним, что они у нас есть, и когда будет время - мы их решим, в противовес if`овому подходу, когда мы всё время должны решать проблемы реакции на неадекватные зигзаги сценария не отходя от кассы. По себе могу сказать, что писать сложный код так намного удобней - и более того, по мере усложнения кода использование исключений становится всё более и более необходимым. А если забыть обработать какое-то исключение, заявленное при написании "чистого" кода - браузер об этом скорее всего напомнит при тестировании.

Для тех, кто не знаком с механизмом исключений в Java

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

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

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

Для тех, кто знаком с механизмом исключений в Java

Здесь я кратко приведу различия между реализацией исключений в Java и JavaScript - пропустите этот раздел если с Java вы не знакомы.

Главное отличие от Java-реализации состоит в отсутствии (в силу не классовой, а прототипной реализации ООП) возможности использовать множественный оператор catch, основанный на наследовании и восходящем преобразовании. Здесь оператор catch может быть только один для каждого try`я. Этот приём можно менее изящно реализовать в обработчике на основе оператора switch.

Блок finally присутствует, но здесь он нужен ещё реже. Сам я, работая с JavaScript, ни разу не сталкивался с ситуацией, где бы он мне понадобился или был удобен - поэтому здесь я о нём тихонько умолчу, только намекнув, что он, в принципе, здесь есть...

Ну и, конечно, нет великолепной возможности (отсутствующей даже в C#) Java, обязывающей указывать возможность вызова исключения функцией при её описании с помощью ключевого слова throws, отсутствие какового сулит обернуться большой путаницей при использовании больших сторонних библиотек...

Объект исключения

Обычно в качестве объекта исключения выступает объект Error, хотя, строго говоря, конструкция throw может передавать абсолютно любой объект (!), который может быть принят оператором catch и соответственно обработан.

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

Какую информацию о состоянии может в себе нести исключение? По большому счёту всего 2 поля - некое название, характеризующие тип исключения, и сообщение, уточняющее особенности конкретного исключения в данном случае - если пользователь возбуждает исключение сам, то он придумывает сообщение сам, если его генерирует система - то уже она решает, какое сообщение писать. Прибавим к этим 2-м свойствам 3-е - prototype, для возможности изменять его характеристики ОО-средствами и 4-е стандартное toString() - и получим объект исключения от ECMAScript, в котором название называется "name" (в случае пользовательских объектов оно содержит строку "Error", а в случае ошибки браузера - название из небольшого списка, представленного в следующей таблице), а строка сообщения - свойство "message". Конструктор исключения от ECMAScript выглядит так:

new Error(message);

У Microsoft вместо имени у ошибки появляется составной номер (свойство "number"), состоящий из кода источника ошибки (facility code) и номера самой ошибки. Что бы выделить номер источника, можно воспользоваться выражением

(e.number >> 16) & 0x1FFF

, а что бы выделить код самой ошибки - выражением

e.number & 0xFFFF

, где e - объект Error), и "description", полностью аналогичное свойству "message" в ECMAScript (начиная с IE 5.5 значение свойства "description" доступно и через свойство "message", т.е. по существу, они - синонимы, ссылающиеся на одно и то же значение). Соответствие номеров описаниям для JScript можно найти в этой таблице.
Конструктор объекта исключения от Microsoft IE выглядит так:

new Error(errorNumber, message);

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

Впрочем, популярный особенно в Linux-среде open-source`ный браузер Mozilla так же нередко расширяет стандарты (хотя существующие - поддерживает, в отличае от IE). В объекте Error для этого браузера добавлено 2 интересных свойства для локализации исключения - "fileName" и "lineNumber", хранящие, соответственно, информацию о файле, где произошла ошибка (актуально, когда в проекте много *.js - файлов и непонятно в котором из них ошибка) и о номере строки в этом файле.

Пример использования

Теперь давайте перейдём к практике. Для отлова исключений используется блок try..catch, выглядит это примерно так:

try {
    оператор1
} catch (исключение) {
    оператор2
}

, где: оператор1 - оператор или их группа, где может быть вызвано исключение, оператор2 - обработчик исключения, исключение - обычно объект Error, характеризующий исключение и передаваемый оператору2.

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

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

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

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

function getMonthName(month) {
    month--; // Переводим month в индекс массива (1=январь, 12=декабрь)
    var months=["январь","февраль","март","апрель","май","июнь","июль",
"август","сентябрь","октябрь","ноябрь","декабрь"];
    if (months[month] != null)
        return months[month];
    else
        throw "Неверный месяц";
}

try {
    monthName = getMonthName(myMonth); // возможно исключение
} catch (e) {
    monthName="неизвестно";
}
document.write(monthName);

Ссылки по теме для более глубокого изучения:
1) Ю.С. Лукач, "Справочник Web-разработчика", раздел "Обработка исключений";
2) Степанищев Евгений: Блоки try... catch... finally... в JScript 5. Статья на сайте CitForum.ru

P.S. Это одна из ранних моих статей, опубликованных на форуме программистов "Vingrad". Ознакомиться с комментариями Vingrad`цев можно тут.

Java: ParamsBean - альтернативный механизм вызова методов

2008-04-21T00:02:00.000-07:00

1. Каждый может принять решение, располагая достаточной информацией
2. Хороший руководитель принимает решение и при её нехватке
3. Идеальный - действует в абсолютном неведении

Законы исходных данных Спенсера
из "Законов Мёрфи"

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

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

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

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

Возвращаясь к примеру со специалистом, можно говорить о том, что если сопоставить специалиста классу, то у него есть:

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

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

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

Прикладные аспекты описания сигнатур методов или чем нам может помочь подход ParamsBean?

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

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

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

Как-то была у меня такая задача - надо было вытащить данные из базы и передать их в функцию, в которой очень-очень много параметров (около 30-ти). Реально нужны из них только 5, остальные - значения по умолчанию, но было известно, что этот метод понадобится ещё для реализации большого числа других функций и так же понадобится модифицировать некоторые из параметров вызова, какие - заранее сказать было сложно. Создавать конструктор с 30ю параметрами было не просто очень неудобно - было нужно иметь возможность задать некоторые параметры, а остальные что бы остались такими, какими должны быть по умолчанию.

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

Я создал JavaBean (точнее именно POJO - обрезанный лишь getter`ами и settter`ами JavaBean), в котором инкапсулировались все параметры по умолчанию, и его через промежуточную функцию стал передавать той самой с огромным числом параметров.

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

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

Obj1 theObj1 = new Obj1();

theObj1
    .setProp1(1)
    .setProp2(2);

- вполне valid`ная. Такая конструкция навешивания изменений свойств была бы идеальна для моей задачи и очень лаконична - если бы я при вызове метода создавал объект и передавал ему те параметры, которые отличаются от параметров по умолчанию, все же остальные оставались бы со значениями по умолчанию.

И вот я подумал - а почему принято setter`ы делать без возвращаемого значения, т.е. "void"? А может быть, стоит заставить их выдавать ссылку на объект своего класса, в конце прописывая выражение "return this;"? Тогда приведённая выше конструкция будет вполне реальной!

Сделал и всё отлично получилось! :-))) Выполнил задачу и остался очень собой доволен.

class A implements Serializable {

    private int forumID = 1;
    public int getForumID(){ return forumID; }
    public A setForumID(int forumID){ this.forumID = forumID; return this; }

    private int memberID = 8;
    public int getMemberID(){ return memberID; }
    public A setMemberID(int memberID){ this.memberID = memberID; return this; }

    private String postBody = "";
    public String getPostBody(){ return postBody; }
    public A setPostBody(String postBody){ this.postBody = postBody; return this; }

    // и т.д.
}

public class B {

    public static void main(String[] args){

        ClassToGo.go( new A()); //Можем вызывать со всеми параметрами по-умолчанию
    
        // Можем задавать все параметры
        ClassToGo.go(
            new A()
                .setForumID(5)
                .setMemberID(2)
                .setPostBody("ляляля")
        );
    
        // Можем выборочно
        ClassToGo.go(
            new A()
                .setPostBody("боди поста")
        );
    }
}

Пока назвал я это ParamsBean - по-моему, очень удобная штука. :)

Преимущества

Теперь я могу каждый раз при вызове менять значения только тех параметров, которые мне нужно изменить по сравнению с параметрами по умолчанию. Кроме того, я всегда знаю их имена и не путаю их, ведь я вызываю специальные методы, содержащие их имена. Так же теперь я жестко не привязан к порядку их следования при вызове метода - порядок отныне произволен. Могу теперь и пользоваться преимуществами модели JavaBeans для параметров метода, т.е. вводить ограничения на данные и преобразовывать их для хранения в другой формат, вообще, реализуя причудливую логику, инкапсулировать в бине часть функций по обработке данных - например, можно задать методу, которому нужна в качестве параметра длина, ParamsBean, в разных setter`ах которого можно задавать длину в метрах, милях, футах или дюймах, а он уж с методом сам как-нибудь разберётся - это уже вешается на составителя библиотеки, а не на клиента.

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

Это возможность распараллелить работу программистов, выполняющих разные роли по Эккелю. Например, они договорились о каком-то методе, которому в качестве параметров передаётся объект "pBean", метод реализует какую-то функциональность. Потом понадобилось изменить метод, передавая ему дополнительные параметры, который в зависимости от них будет менять поведение - для того, что бы старый код работал, просто в этот pBean добавляется новое поле и оно передаётся методу - не надо перегружать метод. Зато программист-пользователь сможет гибче использовать метод и не заморачиваться с теми параметрами, которые ему не известны, при этом не должен будет клянчить каждый раз у разработчика библиотеки специальный перегруженный метод для его ситуации. Т.е. фактически данный подход - это как бы конструктор всех возможных индивидуальных перегрузок метода.

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

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

P.S. Это сокращённый вариант моей статьи на Vingrad`е. Можно ознакомиться с коментариями Vingrad`цев тут.

Отсрочка для разработчиков BEA

2008-03-16T06:36:00.000-07:00

По информации из некоторого внушающего доверие источника, Oracle не собирается как-либо вмешиваться в разработку продуктов купленной им недавно компании BEA Systems по крайней мере до середины лета.

Напомню, что данная покупка, состоявшаяся в начале этого года (и имевшая интересную историю), поставила в первую очередь для контор, ориентирующихся на продукты BEA вопрос о том, будет ли сохранена в неприкосновенности линейка продуктов BEA Aqualogic, т.е. решения SOA и BPM от BEA.

Легко предположить, что курицу, несущую золотые яйца, а именно J2EE Application Server BEA WebLogic, Ларри вряд ли будет трогать, ибо его собственный Oracle Application J2EE server имеет заметно меньший фрагмент рынка и особого смысла его развивать, имея теперь уже в арсенале одного из лидеров, на мой взгляд, нет. Так что в этой ситуации Oracle, с сервером БД которого и так преимущественно использовался BEA WebLogic, скорее всего, предпочтёт ограничиться облегчением своим клиентам перехода на него со своего детища и постепенно свести этот проект к поддержке, постепенно сокращая затраты на неё. С WebLogic`ом же Oracle превратится в гиганта J2EE-рынка, который, за счёт консолидации, будет иметь заметно большие шансы в борьбе за пирог рынка корпоративного ПО против IBM, чем суммарно BEA и Oracle имели раньше.
Дело в том, что один из основных козырей IBM как раз и заключался в том, что они предлагают всё - СУБД (DB2), сервер приложений (WebSphere), инструментарий разработки и моделирования (продукты купленной некоторое время назад Ratonal) и железо, т.е. работая с IBM, вы обеспечивались всем, что вам может понадобиться в этой области, в то время, как sales`ы BEA при всём желании не могли использовать гибкие маркетинговые схемы, например предложить скидку на покупку СУБД Oracle при покупке у них WebLogic`а в то время, как покупка первого действительно чаще всего означала покупку второго. Так что теперь преимущество IBM будет только в железе, софтверную же часть Oracle покроет полностью и получит свободу манёвра, позволяющую почти точно так же "обволакивать" клиентов со всех сторон.

Однако, что касается решений SOA/BPM, то здесь всё выглядит соврем не так однозначно - рынок ещё только формируется и здесь позиции Aqualogic вполне сравнимы с позициями не только традиционного конкурента BEA - IBM, но и большого количества других производителей, в том числе, что критически важно - с позициями собственной линейки SOA/BPM от Oracle. Достаточно вспомнить хотя бы то, что BPM-решение от BEA было куплено и до этого являлось разработкой малоизвестной компании Fuego (однако, по утверждению сотрудников BEA, к 6-й версии они полностью с нуля переписали этот продукт). И со стороны Ларри было бы странно и тут отказываться от своих наработок в пользу решений купленной им BEA.
В итоге из трёх принципиальных схем:

Оставить две линейки жить параллельной жизнью, как это, например, сделала компания Quest Software со своими продуктами для Oracle (продукты TOAD for Oracle и SQLNavigator являются прямыми конкурентами, тем не менее имеют одного владельца и активно развиваются параллельно).
Отказаться от одной линейки в пользу другой.
Попытаться слить линейки и команды разработчиков и превратить в единый продукт.

выбор будет производиться скорее всего из 1-й и 3-ей, и последний пункт не очень приятен для тех, кто ориентировался на решения линейки Aqualogic. Могу сказать, что хотя в ней и хватало глюков и проблем (впрочем, не больше, чем у IBM`а и прочих), но она подавала большие надежды. Насколько я понял, пока чёткого решения на сей счёт ещё не принято.

От себя могу сказать, что в общем-то не хочу класть все яйца в одну карзину и решил пока подстраховаться, овладев линейкой SOA/BPM от IBM.

В общем, пока жить можно - живём и ждём середины лета...

Sun to buy MySQL for $1 billion

2008-01-16T20:26:00.000-08:00

Во дела!

Читаем.

Видимо, Sun действительно решила плотно взяться за рынок небольших приложений (читай - сайтов), раз уж с софтом для крупного бизнеса не заладилось (его практически монополизировали IBM и BEA).

Однако поражает цена. Интересно, какова прибыль акционеров MySQL от этой сделки?

Намерение

2007-11-16T03:34:00.000-08:00

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

Advanced Programming Features

__proto__ для стандартных конструкторов

Задержка выхода второй версии библиотеки Drag&Drop

Коллекции в JavaScript - допиливаем setAddEventListener

Эмулируем List

Эмулируем Set

Эмуляция Map

Пример эмуляции Map

Браузерные войны – 2 или нас ждёт JSON-Hibernate?

Internet Explorer 9 и стандарты W3C

Перспективы

Браузерные войны

Тенденции

Браузерные войны

Антимонопольный комитет

Окончание браузерных войн

Эра Open Source

Последствия поражения

Пляска Microsoft на могиле Netscape

Загадка

Разгадка

Что имеем сейчас

Намечающаяся тенденция

Уровни экспертизы

Вершина иерархии в JavaScript

Обогащение (enrichment) или псевдо-конструктор (pseudo-constructor) как JavaScript-pattern

Самонастраивающаяся функция

"Заплатка" ("Patch") как JavaScript шаблон проектирования

Я скачал ЕЁ!!!

__proto__ во всех браузерах

Навигация в Google Cache

Список используемых программ, которые нужно купить

JBoss 6 - final?

Планы на будущее

JavaScript: Drag and Drop - библиотека

Введение

Подключение библиотеки

Что ещё есть в архиве

Первый пример

Установка ограничений

Подробности

Пример: Перетаскивание только по горизонтали

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

JavaScript: Реализация pattern`а Singleton

JavaScript: Выяснение имени класса (конструктора)

JavaScript: особенности инкапсуляции на основе замыканий. Часть 4: Наследование

JavaScript: Контроль типов

JavaScript: особенности инкапсуляции на основе замыканий. Часть 3: Внутренние вызовы

JavaScript: особенности инкапсуляции на основе замыканий. Часть 2: Механизм вызова методов

JavaScript: особенности инкапсуляции на основе замыканий. Часть 1: Основа Базовой модели

JavaScript: Дополняем объект Date

JavaScript: небольшое отличие function от function

JavaScript: используйте arguments.callee вместо названия функции

Программная обработка исключительных ситуаций в JavaScript

Для тех, кто не знаком с механизмом исключений в Java

Для тех, кто знаком с механизмом исключений в Java

Объект исключения

Пример использования

Java: ParamsBean - альтернативный механизм вызова методов

Прикладные аспекты описания сигнатур методов или чем нам может помочь подход ParamsBean?

Преимущества

Отсрочка для разработчиков BEA

Sun to buy MySQL for $1 billion

Намерение

proto для стандартных конструкторов

proto во всех браузерах