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

Достаточно любопытный факт: менеджеры Google реально очень скучные. И им правда нравится выглядеть именно так (по крайней мере пока их PR-коллеги находятся рядом). Они не разговаривают о конкурентах. Они не делают прогнозов о развитии индустрии. И они не говорят конкретно кто над чем работает внутри Google. Просто-напросто они фокусируются на совершенствовании своих продуктов, особенно в направлении удобства использования пользователями, разве этого не достаточно?

Возможно Jack Menzel, старший продукт-менеджер, лучше всего это выразил, когда пошутил о «неблагодарности» работы над веб-поиском в Google: «Вы демонстрируете [новую функцию поиска] людям, а они говорят: 'Да, вроде она работает, ну и что?'» (Как быстро все мы забываем, каково это было искать информацию в Интернете всего несколько лет назад.) Что ж, без дальнейших предисловий, перейдем к основным моментам, связанным с различными аспектами работы Google.

По мотивам статьи на xconomy.com, автор Gregory T. Huang.

Поиск в реальном времени

Google активно работает над максимально оперативным обновлением результатов поиска по сети Интернет, в том числе и по социальным медиа вроде Twitter или Facebook, практически так же быстро, как такая информация и публикуется.

Menzel, бывший сотрудник Microsoft, который изучал компьютерное ремесло в University of Washington, возглавляет продуктовую группу на данном фронте. Он говорит, что компания Google работала над ускорением процесса индексации и ранжирования на протяжении уже многих лет: когда-то данные обновлялись раз в месяц, потом обновление стало ежедневным, чтобы поспевать за блогами и новостными сайтами. В течении прошлого года Twitter стал популярен и, как следствие, появилась достаточно критичная потребность в обновлении информации за считанные секунды или в крайнем случае минуты. «Мы двигались по направлению к тому, чтобы становиться все быстрее и быстрее, на протяжении уже достаточно длительного периода времени», говорит Menzel. «Данная траектория развития была выбрана уже давно. Каждый шаг в данном направлении приводит к все новым и новым проблемам и трудностям. Мы верим, что именно получение доступа к свежей информации является одним из ключевых факторов, являющихся залогом успеха Google.» (В число остальных факторов, относящихся к самому поиску, входят такие показатели как релевантность, быстрота получения результата и полнота контента.)

Menzel считает, что самой сложной задачей является не просто быстродействие, а релевантность результатов потребностям пользователей (возможно, кто-то привык называть этот показатель словом «пертинентность»). «Это очень, очень непросто собирать свежий короткоживущий контент и ранжировать его рядом с, скажем, статьями из New York Times или просто постами из блогов.» Стоит заметить, что когда контент появился буквально только что, обычно на него еще практически никто не успел сослаться, а значит Google не может полноценно использовать PageRank, их классическую технологию.

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

Говоря о будущем, Menzel повторил то, что казалось бы на сегодняшний день говорят все о поиске: еще рано. «На самом деле мы лишь начали работать над данной задачей и у нас все еще очень долгий путь впереди». Он надеется, что в течении 5 лет Google сделает поиск намного более персонализированным, чем он есть сегодня. Например, Google будет знать что ты увлекаешься футболом, но привык называть его не «soccer», а «football», то есть помимо прочего поисковая система должна понимать кем является каждый ее конкретный пользователь, как и с кем он связан, кем он является в реальной жизни, где находится, и, тем самым, помогать ему организовывать всю информацию вокруг него.

«Поиск — все еще очень далекая от решения проблема,» — говорит Menzel.  "Существует еще масса вещей, которые очень не просто найти в Интернете."

Локальный поиск

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

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

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

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

Maslan считает, что основной отличительной чертой Google в области локального поиска является «открытость для всех источников», что достаточно сложно с технической точки зрения. Это включает в себя пребывание в состоянии «активной глобальности», а не просто в индексировании информации о ключевых станциях метро. «Масштаб, с которым Google работает с картографическими и гео-кодированными данными, в совокупности с пониманием принципов работы Интернета является ключем для успешной работы в данной области».

Возможно в скором будущем мы увидим вещи вроде карт и списков компаний или мест от Google в еще большем количестве мест и языков по всему миру, с еще более точной информацией, чутко реагирующей на локальные события вроде открытия, закрытия или перемещения предприятий и организаций. «Мы четко понимаем, какие именно вещи у нас получаются лучше всего» — говорит Maslan. «У нас есть небольшие команды из людей, фанатично настроенных на реализацию их наиболее правильным образом».

Облачные вычисления

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

Ken Norton, старший продукт-менеджер Google (а также выпускник Boston University и бывший предприниматель), поведал о Google Apps и стратегии компании в области облачных вычислений. Команда Norton'а работает конкретно над Google Calendar, но Google Apps также включают в себя и другие продукты, такие как Gmail, Google Talk, Google Docs и Google Sites. “Сеть выигрывает на том, как приложения будут потребляться” — он сказал.

Ключевым преимуществом Google на данном фронте является масштаб и инфраструктура. «У нас есть настолько много серверов и датацентров по всему миру, что мы можем содержать их достаточно дешево и эффективно» — говорит Norton. Это преимущество оказывает влияние и на индивидуальные устройства, так как оно «открывает новые возможности» для потребителей, возможность использовать веб-приложения с любого типа устройств, будь то смартфон, нетбук или обычный полноразмерный ноутбук.

Работа Google в области облачных вычислений сфокусирована на двух уровнях: на первом располагаются готовые программные продукты вроде Google Apps, направленные на прямое потребление конечными пользователями (как индивидуальными, так и корпоративными); второй же уровень занимает App Engine, «облачная» платформа, предназначенная для использования разработчиками программного обеспечения для эффективного построения их собственных веб-продуктов.

Относительно прогнозов на следующий год на фронте облачных вычислений, Norton сказал, что «мы постоянно совершенствуемся». В 2009 году было запущенно более 100 основных новых функциональных возможностей в Google Apps — таких вещей, как видео чат в GTalk или Gmail offline. Он считает, что Google «продолжит делать акцент на коммуникационных предложениях». Помимо развития Gmail и Calendar, это включает в себя доведение до ума Google Docs и придание более завершенного вида набору их возможностей. Norton говорит, что Google также ищет возможности по расширению своих предложений в области коллаборации, в том числе в виде продуктов для крупного бизнеса, совместимыми с различными системами обеспечения безопасности для аутентификации.

Подведем черту: все выглядит как-будто Google совершает переход от фокусирования на бесплатных потребительских продуктах, работающих в «облаках», к более активной работе над платными облачными сервисами для бизнес-пользователей.

Освобождение данных

Последнее время в компании все больше внимания уделяется предоставлению пользователям легко экспортировать их данные из продуктов Google, таких как Blogger, Google Maps, Google Docs, Chrome и App Engine (пользовательские данные разработчиков). На первый взгляд это может показаться очередным капризом PR-менеджеров, но на самом деле за этим фактом стоит более глубокая и интересная инновационная стратегия.

Brian Fitzpatrick, ветеран opensource разработок, возглавляет двухлетний проект от офисов Google в Чикаго. Основная идея заключается в оказании помощи пользователям, если они хотят получить свои файлы и другие данные из облака Google, чтобы у них была возможность перейти на какую-то другую систему, если они захотят. «Большинство людей не думает о возможности экспорта данных до тех пор пока не станет слишком поздно» — говорит Fitzpatrick. «Мы надеемся, что если вы прекратите использование одного нашего продукта сегодня, то у вас будет возможность попробовать другой продукт завтра.»

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

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

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

Начать наверное стоит с обозначения основной сути: поисковая система изображений, ориентированная на глобальный рынок. Да-да, мы уже видели поиск картинок в исполнении Google/Yahoo!/MSN/Яндекс/Рамблер (нужное подчеркнуть) — скажете вы, так в чем же разница?

Сейчас объясню. Никогда не возникало мысли, что частенько поиск картинок в обычных поисковых системах по большей части выдает всякий бред, очень слабо коррелирующий с тем, что Вы на самом деле искали? Основная их проблема заключается в том, что способов провести ассоциацию между текстом и изображением не так-то много. Чаще всего в их распоряжении лишь HTML-документы, ссылающиеся на изображение. То есть на основании атрибута alt у тэга <img /> и изредка anchor-текста обычных ссылок, поисковая система должна составить представление о том, что же на самом деле изображено в графическом файле. Варианты ручного построения таких соответствий тоже существуют, но либо нужно платить огромнейшему количеству человек за рутинную работу (что-то на грани фантастики — количество изображений в Сети измеряется числом с слишком большим количеством нулей) или подталкивать людей заниматься этим бесплатно, оформив это, например, в виде online-игры. Обычно в таких играх двум участникам одновременно предоставляется один и тот же набор изображений, а их задачей является последовательно вводить свои ассоциации связанные с текущим изображением. Если они оба ввели одно и то же слово — оно ассоциируется с изображением, а пользователям начисляются виртуальные очки. В общем поиск изображений по ключевым словам — задача, связанная с массой проблем и неточностей.

It's a pic является как раз поисковой системой, призванной избавить людей, ищущих изображения от всех этих проблем с неточностью и некорректностью результатов. Чтобы не придумывать каких-то временных решений проблемы было решено искоренить основательно: основная идея заключается в использовании в качестве критерия поиска не набор ключевых слов, а просто изображение. Сказать, что два изображения похожи, компьютеру намного проще, чем сказать что на картинке нарисован, например, жираф — именно на это и делает ставку этот проект.

Выглядит это примерно следующим образом: допустим Вы хотите найти побольше изображений заката и выбрать наиболее приглянувшееся, для этого достаточно загрузить в систему с локального компьютера изображение заката (хотя если оно уже присутствует в Сети — можно и просто указать URL) и собственно говоря нажать кнопку «Найти» — вот и все! Вот ваши результаты:

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

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

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

Сегодня же произошло другое событие, связанное с этим крупным каталогом: я стал редактором очень небольшого его раздела — World/Russian/Компьютеры/Программирование/Блоги. Раздел и правда оказался очень маленький — сегодняшним же утром за часок-другой разгреб все заявки, которые там лежали нерасмотренными. В целом впечатления от данного процесса очень положительные — нашел несколько интересных сайтов в заявках, которые потом еще достаточно долго читал просто так, уже после принятия решения о добавлении в каталог. Хотелось бы конечно раздел побольше, но я думаю всему свое время. Если у кого-нибудь из Вас есть блоги, подходящие под тематику выделенного мне раздела — добавляйте их, с удовольствием рассмотрю.

В целом все свойства объектов hCard можно поделить на семь групп:

идентификационные

– различные варианты имен объекта.

адресные

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

телекоммуникационные

– любые формы контактной информации: номера телефонов, факс, адреса электронной почты и так далее.

географические

– месторасположение объекта.

организационные

– информация о должности и компании или организации, в которой работает объект.

уточняющие

– любая дополнительная информация об объекте.

безопасность

– ограничение доступа к информации в hCard.

Значением каждого свойства является видимый пользователю текст, получающийся в результате обработки документа браузером (или другим парсером данных). Но стоит несколько остановиться на свойстве photo, так как для него действуют несколько другие правила размещения значения:

• при использовании свойства photo в тэге <a>, значением является адрес из атрибута href;
• в тэге <img>, значением является само изображение, то есть значение атрибута src
• в <object>, значением является атрибут data, то есть его источник данных.

Раз уж зашла речь об размещении значений свойств, то сразу хочется сказать об небольшом исключении в виде тэга <abbr>, где оно задается в атрибуте title, а внутри самого тэга — некое более удобное для чтения людьми его представление.

Если тэг, обозначенный любым свойством, содержит какую-либо информацию помимо самого значения свойства, то для отделения релевантного контента от лишней информации можно разместить внутри тэга свойства дочерние объекты, обозначив их атрибутом class="value". Это даст понять парсеру микроформата, что собрав воедино (методом конкатенации) все значения помеченных таким образом объектов он сможет получить значение исходного свойства. Описание получилось несколько запутанным, так что лучше продемонстрировать этот принцип на примере, в котором значению свойства fn будет присвоено значение «Иван Блинков»:

Иван подпрыгнул три раза на месте,
  обернулся и увидел написанную на стене
  свою фамилию: Блинков.

Как не трудно заметить, значение свойства разбавлено массой ненужной информации, но с помощью тэгов с атрибутом class="value" мне удалось выделить лишь важную информацию, не поменяв при этом внешний вид документа. Парсер микроформатов, читая этот документ, соединит обе части и получит в итоге как раз «Иван Блинков», что и будет соответствовать желаемому имени объекта.

Вы заметили в предыдущем примере пробел после моего имени? Он был поставлен для того, чтобы при конкатенации составные части значения не слились в одно слово «ИванБлинков», не самый удобный подход к решению проблемы, но у него есть альтернатива в виде тэга <abbr;> (не забываем про упомянутое чуть выше исключение):

Иван
  подпрыгнул три раза на месте,
  обернулся и увидел написанную на стене
  свою фамилию: Блинков.

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

Свойство fn уже успели слегка обсудить, так что перейдем сразу к n. Как уже было сказано, используется он для детализации составных частей полного имени объекта, для чего оно имеет ряд подсвойств, используемых в дочерних элементах:

given-name

– имя.

additional-name

– отчество.

family-name

– фамилия.

honorific-preffix

– какой-либо префикс к имени, отображающий социальный статус человек.

honorific-suffix

– суффикс с тем же смыслом.

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

    Иван
    Иванович
    Блинков

Адресные свойства

Адрес может быть указан в двух формах:

• adr — структурированной (с указанием составных частей);
• label — не структурированной.

Для структурированного адреса используются подсвойства по аналогии с n:

label же используется просто для написания адреса по тому же принципу, как если бы Вы писали его, например, на конверте традиционного письма. Возможно использование подсвойства type как и в adr.

С телекоммуникационными свойствами все проще:

• телефон — tel;
• адрес электронной почты — email;
• почтовый клиент — mailer (не понятно — и зачем он тут сдался?).

Телефонный номер может иметь тип (type):

• home — домашний
• msg — имеется автоответчик
• work — рабочий
• pref — предпочтительный
• voice — голосовой
• fax — факс
• cell — мобильный aka сотовый
• video — для видеоконференций
• pager — пэйджер
• bbs — bulletin board system
• modem — возможно использование модема
• isdn — integrated services digital network
• pcs — personal communication service

Географические свойства также не отличаются особой сложностью:

• tz — временная зона
• long — широта
• lat — долгота

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

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

• title — должность
• role — роль
• logo — ссылка на логотип компании
• agent — указание представителя индивида, например секретаря, например в виде ссылки на его hCard
• org — название компании

Дополнительные свойства:

• category — категория, то есть чем по сути является данный hCard, например — визитка
• note — какие-либо замечания к остальным свойствам
• rev — время последнего редактирования hCard, то есть время на которое данная информация является актуальной
• sort-string — отмечает какая часть hCard (обычно часть имени), которая будет использована при сортировке списка из нескольких hCard
• sound — адрес, указывающий на звуковой файл с правильным произношением имени индивида
• url — адрес персонального или корпоративного сайта
• uid — уникальный идентификационный номер в каком-либо специфицированном IANA формате (подсвойство type указывает в каком именно)

Для обеспечения ограничения доступа к данным из hCard используется два свойства — class и key. class определяет уровень доступа по примерно тому же принципу, что и в ООП: public или confidentional. А свойство key предоставляет публичный ключ, для расшифровки данных с закрытым доступом.

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

В заключение хочу сказать, что в качестве источников информации для данной статьи были использованы официальная вики и презентация от Robert Costello, а подписаться на RSS можно вот ТУТ.

Против

• nofollow не в состоянии полностью предотвратить спам в ресурсах указанных выше типов;
• название «nofollow» лишь сбивает с толку, crawler'ы все равно следуют по таким ссылкам;
• nofollow порой вредит естественным ссылкам на сайты, которые вполне заслуженно могли бы и получить свою входящую ссылку при расчете того же, например, PageRank;
• для использования простыми пользователями, этот микроформат абсолютно бесполезен;
• благодаря nofollow поисковые системы порой не в состоянии отличить ссылки на сайты добросовестных читателей ресурса от ссылок спаммеров;
• он препятствует возможности людей, оставляющих комментарии, привлечь внимание к какой-либо странице;
• если взглянуть со стороны поисковых систем, nofollow препятствует Сети выглядеть как сеть, в прямом смысле этого слова;
• единственные кто получают какую-либо пользу от этого микроформата — поисковые системы.

За

• но тем не менее, если ссылка размещается посетителем только ради влияния на позицию своего ресурса в поисковых системах, наличие nofollow заставит его как минимум задуматься: а стоит ли?
• помимо поисковых систем, данный микроформат может служить инструментом вебмастера для организации более эффективной перелинковки страниц в рамках одного сайта;
• в недалеком будущем, возможно, движки сайтов смогут ставить атрибут nofollow не на всех подряд ссылках, оставленных посетителями, а только на подозрительных с их точки зрения (которая могла бы определяться, допустим, средствами эвристического анализа);
• так как oформлен он в виде микроформата, он не противоречит стандартам XHTML и HTML.

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

Реализуется этот микроформат с помощью атрибута rel тэга <a>, возможные варианты значения (имеется возможность их комбинировать):

Как не трудно заметить, практически все возможные варианты отношений могут быть описаны одним из значений или их комбинацией. Наш пример из начала этого поста с использованием XFN выглядел бы: <a href="www.site.ru" rel="friend met">Сайт моего друга</a>

Помимо этого есть еще один маленький нюанс, необходимый для того, чтобы browser'ы и поисковые системы знали, что данная страница оффциально поддерживает этот микроформат, для этого необходимо указать следующий атрибут тэгу <head>:

<head profile="http://gmpg.org/xfn/11">

Этот пост был написан по мотивам оффициального сайта XFN, если Вас заинтересовал этот микроформат, возможно имеет смысл посетить и его: там можно найти FAQ, утилиты для автоматической генерации кода, а также всю остальную информацию по данному микроформату (на английском естественно).

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

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

Что представляют собой микроформаты?

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

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

Что же может дать осмысленность разметки?

В перспективе вся эта затея направлена на повышение качества сервисов, предоставляемых в Сети. На данный момент большая часть сервисов, основанных на анализе данных расположенных в Сети, способна лишь на частичное использование разметки документа для уточнения смысла той или иной информации. Показать это лучше всего на примере: тэги <em> и <strong> говорят о том, что содержащаяся внутри них информация имеет некий смысловой акцент, но в то же время многие другие тэги не несут за собой никакой дополнительной смысловой информации, помимо содержащегося внутри них текста. Одним из таких тэгов является <a>, который говорит о наличии ссылки на некоторую интернет-страницу, как-то связанную с текстом между открывающим и закрывающим тэгами, а также расположенную по URL, указанному в атрибуте href, можно конечно к этому прибавить атрибут title, но так или иначе на этом информация о ресурсе, на который ссылается автор документа, заканчивается. Один из микроформатов, позволяющих расширить возможности простых ссылок, называется XFN и предоставляет авторам документов возможность описать свое отношение к другим авторам, на работы которых они ссылаются, выглядит это примерно следующим образом:

<a href="http://www.my-friend.ru" rel="friend">Сайт моего друга</a>

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

Классификация

Наверняка к Вам в голову приходила мысль: а почему необходимо пользоваться именно вот этими микроформатами? Если в XHTML допускаются любые значения тэгов rel и class, почему я не могу придумать свои микроформаты и пользоваться ими? Ответ прост: микроформаты призваны повысить качество Сети вцелом, а не какого-то конкретного сайта отдельно. Только часть микроформатов получила широкое распространение, и именно ими приходится пользоваться всем остальным сайтам под влиянием сетевого эффекта (т.е. того факта, что ценность технологии прямо пропорциональна обширности ее применения, в нашем случае в рамках Сети), просто чтобы быть совместимыми с остальной частью Интернета.

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

• элементарные — применимые только к одному конкретному типу тэгов. В эту группу попадают упомянутый выше XFN, а также множество других, например rel-tag, rel-nofollow, и так далее;
• композитные (или составные) — имеют более сложную структуру, и для своей реализации требуют модификации нескольких тэгов одного элемента. Микроформаты из этой категории предназначены для описания более сложной структуры, например hCard, используемый для описания людей или организаций (можно посмотреть на пример его использования на моей странице "О себе").

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

Применение на практике

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

• Многие поисковые системы активно используют при составлении своего индекса микроформат rel-nofollow, об этом мне уже доводилось упоминать в одной из предыдущих записей;
• Plug-in для Firefox под названием Operator — позволяет просматривать используемые на текущей странице микроформаты, а также предлагает небольшой ассортимент действий, с ними связанных. Например, hCard предлагается экспортировать в адресную книгу, а для rel-tag — осуществить поиск по скромному списку интернет-сервисов. Лично я уже достаточно его себе установил и всегда держу включенным, не для того, чтобы реально им пользоваться, а просто чтобы быть в курсе, что тот или иной ресурс вдруг начал поддерживать эту замечательную технологию;
• Появляется все больше и больше CMS, поддерживающих различные микроформаты "из коробки" или с помощью plug-in'ов, что ведет к все более активному расширению списка сайтов, следующих этим стандартам представления данных. WordPress, на которой работает этот блог, тоже относится к категории CMS, поддерживающих микроформаты, в чем вы можете убедиться, установив упомянутый в предыдущем пункте Operator. Сам по себе этот факт какой-либо полезности не несет, но является лишним стимулом для разработчиков программного обеспечения и интернет-ресурсов, поддерживающих микроформаты.

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

Подводим итоги

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

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

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

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

Обсуждаемая нами технология дает возможность веб-мастеру предоставить crawler'ам, образно говоря, путеводитель по его сайту. Методов для этого имеется несколько:

• Любой crawler прежде чем перейти на новый домен проверяет существование файла по адресу http://www.некий-домен.ru/robots.txt. В таком файле веб-мастер может разместить директивы для потенциальных компьютеризированных посетителей в соответствии с соответствующим стандартом. Если поисковый робот обнаруживает этот файл, то прочитав его он корректирует свой маршрут обхода всего интернет-ресурса в соответствии с указанными директивами.
• Внутри заголовка любой HTML-страницы или любого другого документа, передаваемого по http протоколу (с помощью заголовков самого протокола), можно разместить специальный meta-tag для роботов, который также должен соответствовать стандарту, опубликованному в 1996 году.
• Основной частью путеводителя чаще всего является карта сайта в формате XML. С ее помощью программа может быстро определить весь ассортимент страниц, которые ей было бы неплохо проиндексировать.
• Самым последним был воплощен в жизнь метод, основанный на микроформатах. Реализуется он с помощью параметра rel="nofollow", указанного внутри тэга <a>, который обозначает ссылку, не предназначенную для перехода по ней пауком.

Карты сайтов и директивы robots.txt предназначены для определения маршрута путешествия crawler'а, в то время как микроформаты и meta-тэги — для влияния на сам процесс индексации.

У каждого из описанных выше методов есть своя узкая специализация:

• robots.txt предоставляет базовый набор директив для роботов, которым они следуют даже в случае конфликтов с другими использованными методами.
• Карта сайта влияет на последовательность и набор страниц, посещенных пауком, с помощью указания приоритетов страниц или времени последней модификации.
• Мета-тэги распространяют свое действие на весь документ и влияет на индексирование страниц (если они одновременно присутствуют как в заголовке (X) HTML документа, так и в заголовках X-Robots-Tags HTTP-протокола, то приоритет считается выше у заголовков протокола).
• Микроформаты позволяют в случае необходимости переопределять параметры любого конкретного тэга документа, не смотря на указания в мета-тэгах.

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

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

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

О процессе создания такого канала я и хочу Вам рассказать.

Конечно же многие CMS поддерживают автоматическую генерацию RSS-каналов, и WordPress, на которой работает этот блог, к ним относится. RSS-канал этого блога, хоть и не является новостным по сути, но также прекрасно генерируется из постов блога. Но для того, чтобы работать с технологией обычно бывает не лишним понимать как она работает, по-этому в этой записи я поведаю Вам о ручном составлении RSS-канала, а в одной из последующих — об автоматической генерации.

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

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

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

По сравнению с XML, RSS-документ должен обладать четко определенной структурой:

1. За стандартным XML-заголовком открывается корневой элемент, содержащий указание версии RSS:
   (не забываем его закрывать в конце документа)
2. В корневой элементе должен должен содержаться ровно один элемент <channel>, символизирующий наш канал
3. Внутри <channel> обязательно должны содержаться три элемента:
   • <title> — заголовок канала
   • <link> — ссылка на сам сайт
   • <description> — описание канала
4. Помимо них он должен содержать один или несколько элементов <item>, которые будут обозначать одну конкретную новость, запись, пост, статью, заметку, не важно какое из этих слов больше подходит к каждому конкретному случаю — суть от этого не меняется.
5. Элементы между парой тэгов <item>, как ни странно, тоже должны в себя включать в себя волшебно-обязательные элементы, разница лишь в значении, которое им придается:
   • <title> — заголовок новости-записи-поста-статьи-заметки
   • <link> — ссылка на нее же, обычно на страницу внутри сайта
   • <description> — собственно говоря сам текст

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

Дочерние элементы <channel>

Дочерние элементы <item>

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

В этой записи я планирую перечислить и объяснить все 9 правил, с использованием примеров.

В качестве примера будет использован следующий XML документ, описывающий книгу:

  R. A. Salvatore
  
    Well met!
  

Не правда ли легко понять, что речь идет именно о книге?

Теперь самое подходящее время перейти непосредственно к правилам оформления документов.

1. Документ должен начинаться с определения типа документа, содержащее указание версии XML (в нашем случае — 1.0) и кодировку символов (соответственно — UTF-8)
2. Должен содержать ровно один корневой элемент — в нашем пимере это <book> </book>
3. Каждому открывающему тэгу должен соответствовать один закрывающий. Как не трудно заметить это правило соблюдается в примере, если Вы привыкли в HTML оставлять тэги открытыми примерно следующим образом:

   Какой-то текст

   то изучение XML может стать неплохим поводом отучиться от этой вредной привычки.
4. XML тэги чувствительны к регистру символов. Тэги <Book>и <book> считаются разными, запись <Book> </book> будет считаться ошибочной.
5. Тэги должны быть расположены строго друг внутри друга. Продемонстрирую на отдельном примере:

6. Значения всех атрибутов всегда должны быть заключены в кавычки. Например: <title subtitle="The Dark Elf Trilogy">Sojourn</title> — верно, а <title subtitle=The Dark Elf Trilogy>Sojourn</title> — нет.
7. Последовательно расположенные пробелы не объединяются в один. Имейте это ввиду, если вы привыкли к HTML.
8. Конец строки обозначается просто переводом на новою строку, без возврата каретки. Во многих приложениях для обозначения конца строки используется возврат каретки совместно с переводом на новую строку (/r/n), в XML же принято для этих целей использовать просто перевод на новую строку (/n).
9. Комментарии обозначаются так же как и в HTML: <!––комментарий––>

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