IT-стандарты *

Сегодня мы поговорим об отечественных стандартах на проектную документацию. Как эти стандарты работают на практике, чем они плохи и чем хороши. При разработке документации для государственных и серьезных частных заказчиков у нас обычно нет выбора — в требования по документированию ТЗ вписано соблюдение стандартов. На практике мне приходилось сталкиваться с различными примерами недопонимания структуры стандартов, того, что должно быть в документах и зачем эти документы нужны. В итоге из-под пера техписателей, аналитиков и специалистов выходят порой такие перлы, что непонятно, в каком состоянии сознания они писались. А ведь на самом деле все достаточно просто. Поиск по Хабру не вернул ссылок на более-менее целостный материал на данную тему, потому предлагаю закрасить этот досадный пробел.

Правда, пока что поддержка внедрена только в те из них, что используют SSL-соединение. Об этом заявили представители корпорации на конференции O’Reilly Velocity. Собственно, этот протокол начал разрабатываться Google еще в 2009 году, но теперь, похоже, этот проект действительно «выходит в люди». Стоит напомнить, что SPDY представляет собой протокол прикладного уровня для передачи веб-контента, который позволяет значительно ускорить загрузку веб-страниц и отдельных элементов. Корпорация Google позиционирует свою разработку, как достойную альтернативу протоколу HTTP.

На открытии конференции Microsoft DevCon'11 был показан русский перевод известного видео про важность поддержки утвержденных веб-стандартов и дебаты вокруг WebSockets.

В блоге Chromium разработчики из Google рассказали о своих успехах по внедрению SSL FalseStart (RFC). Это клиентская технология для браузера, которая не требует никаких изменений на стороне сервера, но при этом на 30% ускоряет подтверждение связи SSL (задержка измеряется как время между первоначальным пакетом TCP SYN и окончанием процедуры по TLS).

Кэмерон Адамс, скрывающийся под псевдонимом The Man in Blue, решил показать миру красоту связи между видеорядом и музыкой, сделав из своей избранной дискографии Daft Punk один большой мэшап.

Интересно то, что плеер и визуализация сделаны на HTML5, CSS3, jQuery и Canvas.

Смотреть мэшап рекомендуется в Chrome, а особенно любопытным можно почитать комментарии автора.

Несколько дней назад консорциум World Wide Web объявил о создании рабочей группы Web Real-Time Communications Working Group, которая должна разработать стандарты пиринговых коммуникаций между браузерами (собственно, сама новость уже обсуждалась на Хабре). Если стандарты примут, то станет возможной прямая передача видео и звука между ПК без использования сервера и отдельных приложений.

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

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

Иногда происходит так, что над одним и тем же изобретением или, скорее, технологией, начинают работать в нескольких местах различные люди. Это то, что происходит с идеей децентрализованного веба. Международный Веб Консорциум (W3C) вчера объявил о создании рабочей группы по веб-коммуникациям в реальном времени (Web Real-Time Communications) для того, чтобы сформулировать API клиентской стороны, позволяющего выполнять подобные коммуникации, без имплементации серверной стороны.

В W3C эту группу возглавляют инженеры из Google и Ericsson, но оказалось, что Opera, по-сути, предлагала ту же самую идею два года назад, только не приобщенную к браузерам в общем, как к инструменту просмотра веб-страниц. Opera, как обычно, оказалась на несколько шагов впереди своего времени.

(Это вторая статья из серии статей, посвященных обзору различных тестов браузеров. Ранее в серии: Погружение в ACID3.)

Если судить по большинству упоминаний HTML5Test (далее h5t), то большинство пользователей данного теста более заинтересованы в конечном результате (сумме баллов), как некотором показателе, на который можно ссылаться и по которому можно сравнивать, нежели во внутренней сути получаемого результата.



В простонародье это зовется пузомерками, а как метко подметили примерно год назад в Lenta.ru (см. ниже) — «у кого HTML5 длинее».

(Это первая статья из серии статей, посвященных обзору различных тестов браузеров.)

Что такое Acid3? Кто его придумал? Как он устроен и как он работает? Что он измеряет на самом деле? Этими и другими вопросами мы зададимся в данной статье и попробуем найти ответы.

Что такое Acid3?

Acid3 — это третий из серии специальных тестов (до этого были Acid1 и Acid2), написанных «в помощь производителям браузеров, чтобы те могли проверить поддержку стандартов в своих продуктах». Конкретно ACID3 нацелен на тестирование спецификаций, связаных с разработкой динамичных «Web 2.0»-приложений.



Acid3 включает 100 специальных тестов, проверяющих 19 различных спецификаций.

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

Один из ключевых протоколов интернета FTP (file transfer protocol) в субботу отметил свой 40-летний юбилей. Студент Массачусетского технологического института Абхай Бушан (Abhay Bushan) опубликовал первые спецификации RFC 114 16 апреля 1971 года, задолго до появления HTTP и даже за три года до TCP (RFC 793)!

С 19 января 2011 года в браузере Chrome появилась поддержка протокола SPDY (SPeeDY), он также включён для SSL-трафика на серверах Google. Таким образом, все сайты, принадлежащие Google, грузятся значительно быстрее в Chrome, чем в любом другом браузере. Четыре месяца пользователи Chrome получают многие странички с сайтов Google вообще не по HTTP.

Кому-то это может напомнить ситуацию с Microsoft, которая «улучшала» стандарты в браузере IE таким образом, чтобы серверы IIS отвечали быстрее, чем Apache. Но здесь ситуация кардинально иная. Речь идёт не о получении какой-то монополии, а об обеспечении быстрого интернета для всех, что выгодно Google априори.

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

Существует тьма статей на тему «как писать документацию», но если вы решили взяться за неё в первый раз, то в новой для вас области не сразу понятно, дело ли пишет автор, или отсебятину выдумывает.

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

Запущен новый конкурс для веб-разработчиков, которые создают приложения нового типа на HTML5 уже сегодня. Конкурс под названием Dev:unplugged предлагает разработчикам участвовать в соревновании в трех категориях для создания наиболее интересных игр, музыкальных приложений и инновационных приложений.

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

Категория инновационных приложений имеет несколько подкатегорий с разными спонсорами:

• лучшее использование геолокации – спонсор Foursquare;
• лучшее применение Pinned Sites – спонсор Microsoft;
• лучшее применение Canvas и SVG -  спонсор FWA;
• инновации в дизайне и UX – спонсор Carsonified.

Разработчиков-победителей ожидают отличные призы:

• супер-приз – $9000 и оплаченная поездка на конференцию Future of Web Apps Las Vegas;
• лучшее игровое приложение – $5000;
• лучшее музыкальное приложение – $5000;
• инновационное приложение – все победители получат планшеты ASUS Eee Slate;
• другие заметные проекты получат Xbox 360.

Условия конкурса, категории и призы опубликованы на официльном сайте по адресу http://www.beautyoftheweb.com/#/unplugged

Сроки конкурса следующие:
— 3/1 – Contest Opens (submit early, don’t miss a chance to get voted-up!)
— 4/5 – Submission gallery opens to the public and voting begins!
— 5/9 – Submission deadline
— 5/12 – Top-40 Finalists are announced
— 5/23 – Winners are announced!

P.S… Хотелось бы так же напомнить о том что продолжается конкурс «Прикрепленных сайтов». И у вас есть еще немного времени чтобы принять участие в этом конкурсе.

Как вы, наверное, уже знаете, в Internet Explorer 9 RC был добавлен механизм Tracking Protection, который позволяет запрещать слежение за активностью пользователя в интернете сторонними ресурсами через различные способы добавления контента на сайты.



Эта технология была представлена к рассмотрению в организацию W3C для стандартизации, как открытая технология защиты приватности пользователя. И вот, сегодня в блоге разработчиков IE и блоге interoperability@microsoft появились анонсы того, что W3C приняла технологию к стандартизации.

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

Вы можете ознакомится с запросом на стандартизацию Tracking Protection на этой странице. Сам черновик стандарта расположен по этому адресу. Работа по нему только началась и будет продолжаться.

Вы PM. Как узнать – готова ли вёрстка к реальному использованию?
Вы заказчик. Как убедиться, что работа выполнена качественно?
Как оценить качество вёрстки?

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

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

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

Итак что же это за список?

Краткая версия теперь доступна на html5checklist.com (github), где можно вносить pull-request'ы.

История обновлений:

• 2015/08/11: Актуализировал рекомендации по оптимизации скорости загрузки. Добавил требование поддержки Retina. Дополнил «19. Мелочи» требованием что изображения должны масштабироваться в зависимости от размера окна.
• 2015/08/10: актуализирован список исключений для CSSLint
• 2015/07/29: актуализирован пункт №13 «плохо»/«хорошо»
• 2015/04/08: добавлено требование использования препроцессоров и рекомендация использования систем сборки
• 2013/04/25: добавлены анализаторами качества кода: CSSLint и JSHint, указан сайт подбора css font stack (спасибо @fliptheweb), мелкие уточнения (работу интерактивных элементов страницы, что не пропадает фон на высоких разрешениях, не должно быть пустых презентационных блоков, при проверках контента — пробовать удалять заголовки, менять местами блоки)
• 2013/04/24: добавил пункт об минимизации каскада (БЭМ-техники, MCSS, SMACSS), необходимости вписывания в экран моб. устройства, заменил ссылку на проверочный текст отображения стандартного html на код с normalize.css, поправил пример где в рекомендации встречался длинный каскад, упомянул про Opera на Presto и новый уровень семантики — в именах классов BEM.
• 2012/04/12: отсортировал пункты проверки в порядке важности, выделил главные, дополнил статью подробностями
• 2011/12/07: дополнил согласно доклада на WSD Минск'2011.
• 2011/07/19: добавлено про повышение надёжности вёрстки благодаря html5-тэгам, про необходимость favicon/apple-touch-icon, отсутствие багов при ресайзе textarea
• 2011/06/15: добавил пояснения какие ошибки валидации допустимы, рассказал про отсутствие официальной кнопки «HTML5 Valid» и про официальное лого HTML5 на сайте.

Думаю, многие из вас уже знают, что WHATWG перешёл к безверсионной модели развития.
В комментах началась паника по поводу «что теперь будет?». Паника — необоснованная, а решение — очень логичное и учитывающее современные реалии.
Я постараюсь объяснить, что всё это сулит. Доступно и кратко.

В 2009 году WHATWG объявила, что разработка спецификации HTML5 находится на завершающей стадии. Тогда планировалось закончить спецификацию в этом году и опубликовать снимок «HTML5» в 2012 году. Однако, вскоре после этого мы поняли, что спрос на новые возможности HTML высок, и поэтому мы должны продолжать поддерживать HTML и добавлять новые возможности до того, как сможем назвать «HTML5» завершённым. В результате мы перешли на новую модель развития — без версионности. Вместо этого у нас будет просто живой документ, определяющий технологию так, как она развивается.

 

Сегодня W3C обнародовал логотип HTML5. Логотип доступен в соответствии с лицензией «Creative Commons Attribution 3.0» поэтому он может быть адаптирован дизайнерами под свой проект.

Кроме главного логотипа так же есть логотипы сопутствующих технологий:


Подробнее Вы сможете ознакомиться на странице логотипов.

Там же можно сгенерировать для своего проекта кнопочку, которая как бы намекает на качество сайта (ниже полный набор):


Конечно же сама страница сверстана на HTML5, если кто-то из верстальщиков не курил эту тему — пора начинать, будущее рядом.