вторник, 22 ноября 2011 г.

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

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

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

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

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

четверг, 10 ноября 2011 г.

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

Иногда 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`а, например, вызываем так

среда, 9 ноября 2011 г.

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

Прошло примерно полтора года после (первой) публикации мной статьи «Браузерные войны» с анализом рынка развития приложений. Тогда я описал ситуацию такой, какой увидел её на момент начала 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!.

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

  1. С одной стороны, мы имеем устойчивую тенденцию перехода к модели сервисов, которая, напомню, состоит в том, что персональный компьютер представляет собой лишь терминал, связывающий пользователя с сервером, и все сервисы пользователь через него получает от сервера.
  2. При этом мощности компьютеров падать явно не собираются. Даже специально разработанные для 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, иначе им самим несдобровать...

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

Примерно полтора года назад мной была написана статья, первоначально озаглавленная "Мечты 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. Под конец можете послушать песенку разработчика о наболевшем:

ППКС! :)))

среда, 2 ноября 2011 г.

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

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

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

Часто приходится слышать размышления о "практическом" и "теоретическом" характере того или иного знания. На мой взгляд, это разделение имеет более фундаментальный характер, чем то, о чём собираюсь написать я. Не следует забывать, что все программисты - это инженеры, а не учёные. Критерии знания учёных-теоретиков отличны от наших, поскольку от инженера, в конечном итоге, всегда требуется тот или иной результат его работы. Так что это разделение мне видится условным, поскольку теоретическое знание - это скорее прерогатива учёных. Конечно, теоретическое знание необходимо и инженеру, но чаще всего оказывается, что не во всей своей полноте, а в сильно-упрощённом и сокращённом виде - часто приходится слышать о том, что та или иная теория, выдвинутая учёными, нуждается в упрощении (обычно - по закону Парето, более известному, как "Принцип 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 подхода к решению данного вопроса.

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

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

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