« Поставить закладку » « Сделать стартовой »

« Форумы » « Блоги » « Статьи » « Новости » « Файлы » « Realcoding IRC » « Site map » « Поиск »


Главная Главная
Анонсы Анонсы
Форумы Форумы
Каталог Каталог
Поиск Поиск
Опросы Опросы
Книжный магазин Книжный магазин
Реклама на сайте
Публикации Публикации
Партнеры Партнеры
Карта Карта сайта
Рассылки Рассылки
RSS экспорт
Настройки Настройки
О нас пишут О нас пишут
Контакты Контакты
Гостевая книга Гостевая книга







    Популярное
Шаблоны в PHP для чайников

Выбор похожих значений

Сохранение и загрузка данных в объекты на примере коллекций.

События клавиатуры

Факторы, влияющие на html вёрстку (Часть 2: Работа PM и Рабочий процесс)

Зарезервированные слова C# (Csharp)

Роли .NET в Windows

Функция AccessResource

Создание перекрестной таблицыс помощью мастера

Глава 8. ЗАПРАШИВАНИЕ НЕСКОЛЬКИХ ТАБЛИЦ ТАК ЖЕ, КАК ОДНОЙ


ПнВтСрЧтПтСбВс
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      
    Архив файлов

    Сообщества

    Документация

    Кто на сайте
Вы не зарегистрированы.
Имя:

Пароль:

Запомнить

Регистрация позволит Вам пользоваться дополнительными сервисами.
Сейчас на сайте:
Гостей: 11
Пользователей: 0

Статьи:: Интернет технологии :: Вебмастеру :: Будущее веб-стандартов


отправить ссылку другу версия для печати  Обсудить на форуме

Будущее веб-стандартов



Примечание: ниже находится перевод статьи The future of web standards, в которой автор рассматривает текущее состояние организаций, связанных с разработкой веб-стандартов, и возможное будущее как организаций, так и самих веб-стандартов вообще. Мои комментарии далее даны курсивом.



Индустрию веб-дизайна и веб-разработок, основанных на применении стандартов, в последнее время достаточно сильно будоражит. Статья Andy Clarke "CSS Unworking Group", по видимому, открыла дорогу обсуждению текущего неудовлетворительного состояния подхода (или отсутствия оного) по стандартизации новых возможностей для веб-разработчиков и дизайнеров. Статья Alex'а Russell "The W3C Cannot Save Us" и моего друга и бывшего коллеги Jeff'a Croft "Do we need a return to the browser wars?" продолжила эту дискуссию, как и Stuart Langridge c "Reigniting the browser wars", которая появилась уже после того, как я закончил первый черновой вариант этой своей заметки.

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

Первая, не слишком лицеприятная, заключается в том, что текущий прогресс разработки новых стандартов, в лучшем случае, заморожен. HTML был создан из первоначальной задумки до версии 4.01 менее чем за десятилетие. Но текущая версия 4.01 не изменялась еще с конца прошлого тысячелетия (XHTML не сильно лучше: версия 1.0 была, практически, идентична HTML 4.01, за исключением XML-синтаксиса, а XHTML 1.1 не сильно изменил ситуацию, так как все новшества фокусировались на реорганизации и разделении стандартов на модули). Совершенно аналогично, CSS застыл на спецификации версии 2 с 1998, а CSS 2.1 по-прежнему всего лишь "Candidate Recommendation".

Второй проблемой является то, что все основные нововведения в интернете появляются из проприетарных технологий: Flash выскакивает везде, где только можно, Microsoft и Adobe раздельно работают над следующим поколением RIA (rich internet application), а наиболее модное слово — "AJAX" — изначально произошло из исключительно Microsoft'овской технологии (XMLHttpRequest), которая тем или иным образом была включена в другие браузеры.

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

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

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

Ложная дилемма моделей стандартизации

Одним из наиболее существенных моментов при решении этих проблем является то, что бОльшая часть дискуссии проходит при изначальном предположении ложной дилеммы (false dilemma), которая подразумевает, что существуют только два пути для осуществления процесса стандартизации:

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

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

В поисках баланса

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

В первую очередь, я думаю в сторону разработок программного обеспечения с открытым кодом (open-source), которые сталкивались с похожими проблемами уже много раз: существует огромное количество абсолютно разного программного обеспечения с открытым кодом, которое используется как «среднестатистическим американцем», так и международными корпорациями, и только немногие из таких проектов успешно развиваются. Одним из таких примеров успеха может послужить ядро Linux; сообщество, участвующее в его разработке, не является ни закрытым, ни полностью открытым, но чем-то между этими двумя крайностями. Разработка Linux не является ни диктаторским режимом, ни демократией: Linus Torvalds и его доверенные «лейтенанты» полностью удерживают контроль над всем проектом, но при этом любой вклад от активного сообщества принимается к рассмотрению. И хотя не все мнения признаются одинаковыми, процесс принятия решения, каким мыслям придать больше веса, а каким — меньше, по-видимому, является весьма практичным и справедливым.

В результате, участие больших корпораций не превращает Linux в закрытое сообщество разработчиков, и более мелких участники могут свободно обсуждать и развивать проект без превращения оного в «кричащую толпу» (howling mob). Это, определенно, успех, и такую модель поведения ни в коем случае не стоит упускать из рассмотрения при реформировании процесса веб-стандартизации.

Естественно, существует еще множество замечательных примеров успешных сообществ: Perl, Python и Ruby, например, все разрабатываются с открытым исходным кодом, но полностью контролируются единственным "BDFL" (бессрочным великодушным диктатором, Benevolent Dictator For Life) и(ли) его несколькими «лейтенантами». Успех такой организации во множестве различных отраслей показывает, что процесс в целом протекает исключительно благоприятно: общий шаблон поведения, при котором все вносимые изменения обсуждаются в присутствии нескольких высокопрофессиональным специалистов, обладающих большим кредитом доверия. Они и правят балом, и обладают достаточным весом для принятия финальных решений: какие изменения должны быть внесены, а какие стоит отклонить или подвергнуть дальнейшему обсуждению. Эти же специалисты должны предотвращать все возможные минусы от применения любой из двух полярных моделей, описанных выше.

Сперва W3C, затем WHAT

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

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

  • Хотя группа в целом является открытой, и вступить в нее может любой желающий, ею достаточно жестко управляет собственный "BDFL" — Ian Hickson — который, возможно, знает о веб-браузерах и их истории больше любого из живущих. Участие Ian ' а в WHATWG очень сильно смахивает на классическое поведение BDFL в успешных проектах с открытым кодом: он знает эту область лучше любого из участников, охотно руководит рассмотрением и принятием даже малейшего вклада в общий процесс от любого из участников. Также он, если кто в курсе событий в рассылке WHATWG с сентября 2004, обладает большим опытом в разрешении конфликтов, удовлетворении всех интересов и поиске хороших компромиссных решений.
  • Хотя WHATWG и является достаточно молодой группой, она уже добилась некоторых значительных результатов: Apple, Mozilla и Opera по-прежнему активно работают над реализацией различных рекомендаций от WHATWG. Группа также обладает готовностью поддерживать необходимые нововведения, которые требуется перенести из одной области в другую (в качестве примера можно привести API (Application Programming Interface) для автономного (offline) хранения данных, которое явилось на свет и получило свое развитие благодаря Google Gears).

Скорее всего, кто-то обязательно вспомнит недавнее волнение по поводу медиа-кодеков в качестве примера, когда WHATWG слишком сильно защищала корпоративные интересы, но я не разделяю эту точку зрения (хотя, если быть честным, я также не уверен, что задача HTML-спецификация состоит в том, чтобы указывать, какими медиа-форматами стоит пользоваться, а какими — нет). В отличие от многих людей, которые с пеной у рта начинают доказывать свою позицию по этому поводу, я просто слежу за дискуссией, и пока ничего в ней не вызвало во мне противоречий. Спецификация больше не так настоятельно рекомендует Ogg Theora, но по-прежнему оставляет возможность для реализации поддержки открытых и свободно распространяемых медиа-форматов. В конечном счете может оказаться, что «неизвестное неизвестного» (unknown unknown) (воспользуюсь цитатой из Tao от Donald Rumsfeld) будет хуже для больших компаний, чем известное неизвестного в реализации Theora. И текущий язык черновой рекомендации более похож на голос дантиста, который утверждает, что больной зуб когда-нибудь да выпадет.

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

Монстр Microsoft'а

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

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

Если вы еще не ознакомились со статьей Joel Spolsky "Fire and Motion", сделайте это сейчас, потому что все мои слова не будут столь информативными в противном случае. Давайте, прочитайте ее прямо сейчас (прим.: в статье автор забавно рассуждает о том, как Microsoft применяет принцип «Стреляй и Беги», "Fire and Motion", в действии), она очень интересная, но самое главное, что хотелось бы выделить на фоне остальных фактов, это доминирующее положение Microsoft ' а по причине, которую сам Joel очень красноречиво высказал при помощи сравнения ее с боевой тактикой пехоты:

Конкурентам ничего не остается, как выделять все свое время на перенос [возможностей с одной платформы на другую] и поддержку [своих программ], выделенные на это ресурсы уже нельзя потратить на разработку новых возможностей. Давайте окинем общим взглядом рынок программного обеспечения. Компании, которые добились успеха, ориентируются только на большие корпорации и не закладываются в своих жизненных циклах разработок на исправления ошибок, которые характерны только для Windows XP. Те же, кто постоянно отстает, пытаются гаданием на кофейной гуще предсказать направление инноваций в Microsoft. Люди беспокоятся по поводу .NET и решают переписать всю архитектуру под .NET, потому что им кажется, что так нужно сделать. Microsoft постоянно атакует [новыми идеями и разработками], а им ничего не остается, как принимать огонь на себя, а не двигаться вперед, ибо так делаются дела, дружок.

Однако, давайте теперь остановимся и посмотрим на Internet Explorer 7 (о-да, я имею в виду "Windows Explorer 7"). IE7 является прекрасным примером того, как Microsoft, несмотря на всю мощь своей рекламной кампании, вынуждена уступить требованиям индустрии. Mozilla, Apple и Opera атакуют ее со всех сторон: табы в браузере, повышенная безопасность, и все те улучшения, без которых люди просто не могут жить — и Microsoft вынуждена изменить своей собственной стратегии. Как следствие, многие производители программного обеспечения, стараясь успеть за Microsoft, выпускают некачественные продукты, при этом Microsoft, как это ни странно, приходится идти на поводу у интернет-сообщества и выпускать некачественный браузер.

То же самое сейчас происходит с Microsoft одновременно по нескольким направлениям:

  • Появление Apple буквально повсюду и успех ее продуктов свидетельствуют о том, что Microsoft уже не является лидером на рынке операционных систем. В результате этого Vista провисла: все, что могло быть в ней интересного, уже давно появилось на свет, и выход Vista является всего лишь попыткой догнать OS X и представить хотя бы какой-то конкурентный аналог.
  • Явное доминирование в интернете технологии Flash и появление первых приложений на AIR (Adobe Integrated Runtime) и JavaFX опять заставляют Microsoft «догонять» индустрию, только уже на другом фронте: в виде расширения для браузера Silverlight для нужд настольных API.

Microsoft проигрывает; она безуспешно пытается следовать тому, что уже сделано, тогда как отрасль предлагает все новые возможности и технологические решения. Естественно, панихиду по Microsoft играть пока рано, совсем рано: IE по-прежнему является лидером среди браузеров, и Windows по-прежнему лидирует среди операционных систем. Но в индустрии уже заметны волны изменений: Microsoft, непробиваемый джаггернаут, все же несет потери, и ей приходится следовать всем нововведениям, чтобы не упустить доминирующего положения. В данном случае можно процитировать Lewis Carroll, что она бежит так быстро, насколько может, но все равно остается на месте.

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

Куда катится мир?

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

  • Любой процесс по обновлению [стандартов] должен прийти к равновесию где-то между двумя полюсами: закрытым сообществом и «кричащей толпой», и начинать нужно с осознания того факта, что существуют не только эти два полюса.
  • По-видимому, лучшим местом для успешных примером является сообщество разработчиков программного обеспечения с открытым кодом.
  • WHATWG подает определенные надежды, но пока рано говорить, на что оно способно, и является ли оно панацеей в данной ситуации.
  • Участие Microsoft не стоит далее рассматривать как существенное.

Но и после всего сказанного, я не знаю правильного пути решения проблемы. В данный момент я пристально слежу за WHATWG (как и последние несколько лет, ибо это единственная организация, которая действительно что-то делает), но, может быть, будет иметь место и более благоприятный вариант. Я считаю, что наиболее важным шагом для всех, кто недоволен ситуацией со статусом кво, должно стать принятие решения о дальнейших действиях. Andy Clarke уже предложил пару идей, но при этом забавно высмеял мысль о принятии общего решения путем консенсуса, пока все предложения выдвигаются самим сообществом (и, по-видимому, сильно увлекся ложной дилеммой, описанной выше). Это все замечательно, особенно осознание того факта, что, возможно, присутствует другая возможность по развитию событий, но в каком именно направлении они будут развиваться, предсказать практически невозможно. Итак, я позволю себе закончить цитатой по этому поводу от одного из моих любимейших философов, G.K. Chesterton (из первой части его удивительной книги Еретики):

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

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

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

Источник перевода

Автор: http://sunnybear.habrahabr.ru/ 



Рубрика: Вебмастеру



О том как разработчики пьют кофе.

Юмор

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


Подробнее... | Рубрика: Юмор | Добавлено: 24.06.2008

Работаем с LINQ to XML.

LINQ

Что же, попробуем раскрыть принципы работы этой новой технологии от Microsoft.


Подробнее... | Рубрика: LINQ | Добавлено: 24.06.2008

XmlSerializer - Assembly Leak без спроса.

Сборки и развертывание

В некоторых частях .NET Framework, таких как XmlSerializer, используется внутреннее динамическое создание кода.XmlSerializer создает временные файлы C#, компилирует результирующие файлы во временную сборку и затем загружает эту сборку в процесс. Такое создание кода тоже стоит сравнительно дорого, поэтому XmlSerializer размещает временные сборки в кэш, по одной на каждый тип. Это значит, что в следующий раз при создании кода XmlSerializer для класса Х не будет создаваться новая сборка, а будет использована сборка из кэша. Однако, не все так просто.


Подробнее... | Рубрика: Сборки и развертывание | Добавлено: 24.06.2008

Остальные статьи:

Реализация MVC в WPF. Александр Шер
ADO.NET Sync Services. Марат Бакиров
Рефакторинг JavaScript с применением Microsoft ASP.NET AJAX. Александр Шер
Архитектура приложений: интерфейс пользователя. Дмитрий Мартынов
Введение в Windows Workflow Foundation. Марат Бакиров
Создание расширяемых и удобных библиотек на платформе .NET. Особенности реализац...
Почему Ruby и Python не могут занять место стареющей Java
Использование пространств имен для организации JavaScript-кода
Создание сложных приложений в ExtJS
Google добавил интерфейс для AJAX-библиотек
Стивен Синофски о Windows 7
Несколько вещей об Ajax, которые должен знать веб-мастер
Model-View-Controller для JavaScript
Remix 2008: интернет меняет Microsoft
Планировщик задач на JavaScript
Построение систем автоматического протоколирования Си/Си++ кода

Цитата дня (все,добавить):

    Рубрикатор

Программирование

C/С++
Обучение
Windows API
XAML
Моделирование
Паттерны
Visual Basic 7 .NET
WxWidgets
Функции WinApi
Функции С++
Разработка под Mac OS
Eiffel
Visual Studio 2008
UI дизайн
Алгоритмы
Конкурсные статьи
Turbo Pascal
Visual Studio
CASE-средства
Visual Studio 2005
Без VCL
Delphi
Тех. документация
Тестирование
Software Testing
ООП
TCP/IP
Google Android
Windows Installer
.NET Framework
Драйвера
C# C Sharp
Справка
Проектирование
Информ. системы
Visual Basic
Assembler
Оптимизация кода
Gtk+
Компоненты
Реинжиниринг
Управление проектами
Extreeme programming
Lotus Notes
Алгебраическое проектирование

Интернет технологии

PHP
Perl
ASP
WAP
Cookies
SSI
CGI
Web Servers
VB Script
DNS
CSS
XML
Html
Java Script
Java2ME
Firewall
Flash
.htaccess
Apache
VRML
Протоколы
Поисковые системы
Технология JAVA
Учебник по PHP
Учебник по JavaScript
Учебник по XML
Java Q&A
AJAX
DHTML
XHTML
Dreamweaver
Web 2.0
Python
Вебмастеру
Cisco
Ruby on Rails
Silverlight

Базы данных

Access
InterBase
MySQL
Oracle
ADO .NET
Основы SQL
Учебник по Access 2002
MS
Microsoft FoxPro
Доступ к данным
XML в MS SQL Server 2000
ODBC и MyODBC
Обучение
Caché
DB2
PostgresSQL
Sybase
Теория
Хранилища данных
Безопасность
Реляционные данные
MySQL и mSQL

Остальное:

Разное
Обзоры книг
Безопасность
Графика и дизайн
Юмор
Linux
Фракталы
Microsoft Axapta
Многоядерность
Сети
Microsoft Office
Работа
MS-DOS
Криптография
Графика и игроделание
Новости SDK
Системы защиты
Учебник по AutoCad
CVS
Windows XP
Windows Server 2003
Windows Vista
Windows 7
Мероприятия