Компьютерра - Журнал "Компьютерра" N741-742

      У читателя могло сложиться превратное впечатление о том, что идеологии и технологии, которые W3C и лично Бернерс-Ли понимают под Semantic Web, не имеют ничего общего с Настоящим Семантическим Вебом. Вообще говоря, это не совсем так. Во-первых, восемь лет разработок дали как минимум общую терминологию и "повестку дня". Во-вторых, сами технологии — RDF, OWL и иже с ними — вполне используются где-то напрямую (FOAF, как уже было сказано, — это таки RDF, точнее — OWLонтология, которую можно использовать в RDF, описывающем френдов).
      В-третьих, в "семантических" комитетах W3C тоже стараются не отставать от веяний времени (не идиоты же и там): и приложения к RDF существуют [Например — eRDF, то есть embedded (встроенный) RDF], позволяющие вставлять его элементы как микроформат (то есть дополнительными свойствами к тегам существующей HTML-странички), да и все цели Веба Семантического переформулированы нынче как "семантическое приложение к некоторым частям Веба".
      Кроме того, процесс "наведения мостов" между двумя мирами зачастую дает крайне интересные и общественно полезные результаты, вроде проекта SIMILE [Semantic Interoperability of Metadata and Information in unLike En vi ronments — семантическое взаимодействие метаданных в разнообразных (непохожих) окружениях], в рамках которого создан,к примеру, Piggy Bank — расширение для Firefox, позволяющее создавать (и использовать созданные другими) "превращалки" страниц некоторых сервисов в RDF — с получением всех "плюшек" семантического веба — просмотра, фильтрации и сортировки данных по смыслу, а не "по дизайну". Кстати, именно этот метод — Screen scrapping или Web scrapping, сайтоспецифичные алгоритмы "насильственного вытаскивания важной информации из страниц", — является одним из значимых звеньев нарастания семантичности веба.
      Но вот чем Настоящий Семантический Веб радикально отличается от идей W3C — это способами структурирования данных и границами объектов, к которым прилагается "семантичность". Что до способов структурирования — тщательно разработанным, разветвленным и детальным онтологиям Web 2.0 противопоставил "фолксономии" — классификации на тегах, составляемые пользователями на лету (то есть если какой-то пользователь к своим данным добавил какой-то новый тег — сразу же пополнилась и "общественная" копилка тегов).
      А чтобы разобраться с "границами применимости", возьмем для примера какую-нибудь ужасно прогрессивную блог-платформу, экспортирующую всю возможную информацию о записях пользователя и о нем самом. Заметим, что на уровне текста самой записи у нас попрежнему остается голый HTML, да зачастую еще и плохо отформатированный (вместо заголовков — просто строкиполужирным шрифтом, вместо списков — просто звездочка в начале строки). Возможно, ситуацию когда-нибудь исправят специальные "семантические" редакторы, мощные, удобные и требовательные (в смысле, вообще не позволяющие "просто изменить шрифт" без указания семантики форматируемой области). Но даже и в этом случае мало надежды, что каждый блоггер, журналист или автор Википедии станет заморачиваться "семантическим" указанием: например, "вот эти слова в кавычках — название книги, которую я цитирую" (хотя если это добавит записям "красивости" — вроде вставления обложки книги и ссылки на ее описание…). И в этом смысле идеи Семантического Веба (который, напомню, в первую очередь требует семантичности внутри контента, а не "вокруг" него, в метаданных) — скорее всего утопия

Касание сетки

      Касание сеткиАвтор: Виктор Шепелев
      Опубликовано в журнале "Компьютерра" N25-26 от 08 июля 2008 года Осенью прошлого года Adobe выпустила технологию Adobe AIR, связанную с ее (точнее, купленными у Macromedia) технологиями Flash и Flex. Примерно тогда же в свет вышла Silverlight — прямой конкурент Flash/Flex. Flex, AIR, Silverlight, Google Gears, GWT, Mozilla Prizm, Sun JavaFX — все это технологии, созданные для того, чтобы навсегда изменить привычный нам Интернет, из "Сети документов" превратить его в "Сеть приложений", могучей волной смыть различие между десктопом и Интернетом, веб-сервисом и отдельной программой.
      Эти гибриды обозначаются термином RIA (Rich Internet Applications, "богатые" интернетприложения; а раньше Smart Client, "умный клиент"). Так уже много лет называют гипотетические приложения, более удобные, чем обычные сайты-сервисы, и более Интернето-центричные, чем обычные приложения. Неизвестно, что тому виной — рост ли пропускной способности сетей, приход ли "нового веба", или что иное, но лишь в последние года полтора-два эти гипотетические приложения стали стремительно становиться реальностью. Как и почему — выясним?
       Введение в ria в вопросах и ответах
       Чем плох браузер?
      Да всем хорош. В своей роли: программыпросмотрщика гипертекстовых документов. Равно как язык разметки HTML — отличный язык для разметки гипертекстовых документов[Ну, про его "отличность" есть и альтернативные мнения — как у практиков (разработчиков браузеров и веб-дизайнеров), так и у теоретиков (радетелей Семантической Сети). Но все же.]. Да вот беда: ни то ни другое к созданию приложений не имеет ни малейшего отношения — by design, то есть по определению. И сам HTML как язык разметки, базовыми элементами которого являются абзацы, списки, таблицы, предполагает "поток текста с форматированием", а вовсе не пользовательский интерфейс произвольной формы. И динамическое взаимодействие с HTML-приложениями ограничено "переходом на другую страницу" (ссылка) да "отправлением заполненной анкеты на сервер" (форма). И ограниченность (точнее, отсутствие) связи с пользовательским окружением мешает развернуться — ни иконку информационную в трей не запихнуть, ни вложение в письмо в подходящей программе сходу не открыть. И необходимость для обработки каждого малейшего действия пользователя связываться с сервером мешает в средах с нестабильным подключением (например, мобильных).
       А чем тогда плохи обычные приложения?
      Здесь достаточно сказать одно слово: платформа.
      При всех своих недостатках (см. выше) приложение-вбраузере или его аналоги имеют и массу достоинств: простота доставки пользователю, установки и обновления (в том смысле, что никого не приходится просить "пожалуйста, скачайте новую версию Gmail" — она просто есть), естественность взаимодействия с сервером, лучшее обеспечение безопасности пользователя (неизвестное приложение имеет немного возможностей проникнуть в его систему), работа приложения под всеми распространенными настольными ОС — был бы браузер современный. Да и сами веб-технологии (клиентская часть — HTML/CSS/JavaScript), с технической точки зрения, — штука простая, высокоуровневая и работающая: с сервера по простому протоколу передаются простые текстовые описания пользовательского интерфейса (которые могут быть сгенерированы мириадами способов и технологий), а умный и эффективный клиент-браузер их отображает.
      Может показаться, что все достоинства вебприложений есть обратные стороны их же недостатков (техническое удобство HTML-интерфейсов против семантического неудобства; недостаточная интеграция приложения с рабочим столом против высокой степени безопасности; необходимость за каждым чихом соединяться с сервером против отсутствия необходимости доставки-установки). Однако некоторые технологические новинки последнего времени, которым, собственно, и посвящена эта статья, показали, что кое-какие "плодотворные сдвиги" в этой области вполне возможны.
       Ну, допустим. А что нужно-то? В какую сторону должен происходить "сдвиг"?
      Ответ на этот вопрос органически вытекает из ответа на предыдущие. Нужно средство создания богатых, нетривиальных, динамичных интерфейсов — но позволяющее описывать их на достаточно лаконичном языке (который можно было бы передавать с сервера на клиент как простой текст). Нужна возможность интеграции с пользовательской операционной средой (каждое веб-приложение имеет отдельное окно без "стандартных элементов браузера", может встраиваться в трей, вешать панели на рабочий стол и т. п.) — но контролируемая, с не слишком большими уступами со стороны безопасности. Нужна возможность хранения на клиентском компьютере рабочих данных (актуальных настроек, уже полученных писем и т. п.) и самого интерфейса приложения — чтобы иметь возожность работать в среде с нестабильным интернетподключением и минимизировать трафик — забирать с сервера только обновившуюся информацию[Еще раз подчеркнем — это требование обосновано скорее не потребностями "бедных домашних" пользователей с dial-up’ом, а "богатых мобильных" пользователей с WiFi’ем.].
      К этим главным требованиям добавляются и веяния времени — пользовательский интерфейс должен быть "богатым" не только с точки зрения эффективного представления информации и удобного управления, но и в самом приземленном смысле: переливающиеся кнопочки, плавно выплывающие менюшечки — то есть динамические графические эффекты.
      Личное мнение: вообще говоря, тот факт, что мощнейшие наработки современной графики — возможности железа и библиотек — используются в основном для украшения кнопок, а не для более эффективного представления информации, автор склонен считать признаком упадка нравов и победы потребительской цивилизации.
       И что, есть решения, удовлетворяющие этим требованиям?
      Полноценного и стопроцентного — кажется, еще нет ["Кажется" — потому что в этой горячей области все меняется чуть ли не ежедневно. Например, Adobe AIR уже существует, но возможности его полностью еще не распробованы.].
      Но шаги в нужном направлении — и какие шаги! — делают многие, от гранд-монстров до еще вчера никомуне ведомых героев open source. Если разобраться в этих шагах и аккуратно их разложить, то и в фейерверке технологий, заявленном в первом абзаце, разобраться немудрено.
 

Внешнее: пользовательский интерфейс

 
      Рассказ об интерфейсах "богатых интернет-при ложений" (Rich Internet Applications) нельзя не начать с Gmail: роль этого сервиса в мэйнстримовом понимании "как можно делать веб-приложения" переоценить трудно. При этом, заметим, технологии использовались "старые": HTML/CSS/JavaScript. "Весь секрет" был лишь в довольно большом объеме кода на JavaScript (некогда созданного для простых однострочных инструкций типа "показать это окошко, когда нажмут ту кнопку") и использовании недооцененной возможности JavaScript по отправке запросов на удаленный сервер и получению ответов. Свершение Gmail было идеологическим, а не технологическим: он как бы сказал всем "вот эти (давно существующие) технологии можно использовать и так". Надо заметить, что у новаторского подхода были довольно существенные недостатки: во-первых, проблема переносимости по операционным системам сменилась проблемой переносимости по браузерам (очень немногие из которых оказались готовы к использованию возможностей JavaScript "на пределе", да и готовые исполняли его по-разному); вовторых, программирование сложных элементов интерфейса и аккуратного обновления их с сервера — работа довольно-таки нетривиальная.
      Проблема адаптации к разным браузерам хоть и не решена полностью по сию пору, но стала в некоторой степени проблемой производителей браузеров, а не разработчиков веб-приложений. Здесь тоже большую роль сыграл масштаб шума вокруг гугловских сервисов, поставив вопрос ребром: "А в вашем браузере Google Maps работает?".
      А вот для того, чтобы справиться со сложностью самой разработки, за истекшие годы было создано несколько решений разного толка. Одни из них — удобные библиотеки для эффективного изменения содержимого веб-страницы (например, jQuery, Prototype) — своим существованием обязаны гибкости и изяществу самого языка JavaScript, ранее недооцененного. Другие — Dojo, mooTools, Yahoo! UI Library или приложения к тем же jQuery и Prototype — это большие подборки готовых, профессионально разработанных и отлаженных элементов пользовательского интерфейса и вспомогательных объектов. Третьи, например Google Web Toolkit[Занятно, что для создания Gmail и Google Maps эта библиотека не использовалась. ], вообще предпочитают использовать веб-технологии как "высокоуровневый ассемблер" — приложения при помощи GWT пишутся на Java, а потом пользовательский интерфейс "компилируется" в HTML/JavaScript. Перечисленные средства, как правило, берут на себя не только построение динамичного интерфейса и обновление его с сервера, но и "красивости" (плавное выпадение меню, полупрозрачные окошки и пр.) и некоторую часть несовместимостей между браузерами.
      И все же браузерные несовместимости и несколько насильственное использование не предназначенных для того технологий дают о себе знать. Каждое мелкое отличие в отображении HTML, каждая неоптимальная реализация возможностей JavaScript не слишком критичны для отображения документов, но способны разрушить или сделать малоприменимым интерфейс приложения.
      И тут возникает идея использования схожих, но изначально "под интерфейсы заточенных" технологий: язык описания, подобный HTML, но более удачный; движок отображения встраивается в браузер, но более быстр, во всех браузерах работает одинаково и предоставляет больше специфических возможностей; скриптовый язык, подобный JavaScript (или он сам). Этим путем идут Adobe Flex [Чтобы не запутаться: Flash и Flex — две смежные технологии от одной корпорации Macromedia/Adobe: Flash — средство создания и отображения интерактивной анимации; Flex — технология создания пользовательских интерфейсов, основанная на Flash и использующая его для отображения этих интерфейсов. Сточки зрения клиента, и то и другое — Flash-ролик; но с точки зрения разработчика разница есть] — язык описания MXML, отображается Flash Player’ом; скриптовый язык ActionScript; Microsoft Silverlight — язык описания XAML, отображается Silverlight-плагином (который представляет собой легковесную часть более общей технологии Windows Presentation Foundation); скриптовый язык JavaScript (с версии 2.0 — и другие, в том числе компилируемые); OpenLaszlo [На этой платформе работает, например, pandora.com.] — язык описания LZX, отображается Flash Player’ом или как Java-апплет; скриптовый язык JavaScript; Curl (свои языки и плагины для всего). А в браузерный движок Gecko (Mozilla Firefox), например, без всяких плагинов встроен язык описания интерфейсов XUL — на нем-то и описан интерфейс и браузера, и плагинов. Кстати, и Sun, со своими Java-апплетами полезшая в эту область слишком рано и набившая все шишки, которые только возможно, теперь пытается войти в ту же реку второй раз с технологией JavaFX (и не только с ней — Sun поддерживает несколько фреймворков для создания веб-приложений).
 

Окружающее: интеграция в пользовательскую среду

 
      Чтобы превратить "сайт" в "программу", то есть чтобы "веб-приложение" воспринималось пользователем более как "приложение", нежели "веб", требуется выполнить немало телодвижений. Приложение не должно быть "одной из вкладок браузера", ему нужно свое, отдельное окно. Неплохо бы и иметь возможность запускать приложение со своего диска (если у меня вообще нет доступа в Интернет, чтобы загрузить основной интерфейс Gmail, то как мне посмотреть свою старую переписку, даже если она хранится у меня на компьютере?) — а значит, "упаковывать" приложения и "устанавливать". При этом неплохо бы задуматься и о безопасности: не то "козел"-приложение, пущенный в "огород"-систему без присмотра, дорого обойдется пользователю.
      Решений, в той или иной мере включающих в себя описанные возможности, существует несколько, все они следуют примерно одной и той же модели: пользователь единожды устанавливает у себя "запускалку", то есть платформу, и впоследствии может скачивать или запускать прямо с Веба сами приложения. В "скачиваемом" виде они, как правило, представляют собой архив со специальным расширением (например, webapp) и специальным набором файлов внутри. При запуске такого как-бы-приложения "запускалка" создает отдельное окно: оно, по сути, является окном браузера, но без привычных элементов и с иконкой запущенного приложения; кроме того, "запускалка" может предоставлять приложению дополнительные сервисы (скажем, JavaScript-функции для помещения иконки в трей) и, в идеале, должна контролировать уровень безопасности — скажем, требовать от всех запущенных приложений цифрового сертификата и/или спрашивать у пользователя разрешения на доступ к файловой системе, системным настройкам и рабочему столу.
      Несколько примеров. Adobe AIR — это решение на основе браузерного движка WebKit (используется в Safari), "внутри" себя позволяет запускать air приложения, состоящие из HTML и Flash/Flex файлов, собранных в одно приложение с помощью бесплатного AIR SDK. Если на пользовательском компьютере установлен AIR, то air-приложения устанавливаются "совсем как настоящие" (меню "Пуск", "Установка и удаление программ" и т. п.) и, будучи запущены, выглядят как обычные приложения — и к трею доступ имеют, и обновляться (и даже запускаться) могут с Веба… Правда, модель безопасности в них достаточно простая — либо приложение подписано сертификатом, выданным Adobe, либо "Хотите ли вы запустить это неподписанное приложение?".
      А вот Mozilla Prism (на движке Firefox’а, естественно) позволяет уже существующие веб-сервисы запускать как "совсем настоящие приложения". Для этого нужен специальный файл с расширением webapp — просто zip-архив, внутри которого лежит ini-файл, описывающий, какой сайт да с какой иконкой запускать. Впрочем, этим возможности Prism не ограничиваются — в том же webapp-архиве могут лежать и дополнительные js файлы, которые используют возможности интеграции в пользовательскую среду, предоставляемые Prism (например, раз в секунду проверять, поменялась ли строка, отображающая количество писем в загруженном Gmail приложении, и если да — отображать иконку-конвертик все в том же трее). Правда вот, с безопасностью и контролем у Prism пока совсем никак — но бета, бета ведь.
 

Внутреннее: хранение данных

 
      Из перечисленных ранее "производственных необходимостей" на пути к богатому интернет-приложению осталась необходимость хранения данных на клиенте:полученных писем, пользовательских настроек, уже загружавшихся частей карты, да мало ли чего. Наименее заметный для клиента (и оттого комфортный) способ предлагает библиотека Dojo.storage (часть огромного фреймворка Dojo, упоминавшегося выше как популярное средство построения HTML-интерфейсов).
      Решение Dojo.storage иначе как хаком не назовешь библиотека позволяет использовать уже существующие на клиенте, но имеющие другое предназначение "хранилища": например, возможность браузера хранить информацию в cookies или скрытый Flash-объект (Flash-плагин имеет встроенную возможность сохранять небольшое количество информации на клиенте).
      Как всякий хак, такое решение довольно уязвимо: и объем хранимого ограничен, и полностью рассчитывать на то, что в каждый следующий раз удастся записать/ прочитать сохраненную информацию, нельзя. Более надежное решение — Google Gears, устанавливаемый как плагин к браузеру и позволяющий умеющему работать с ним приложению хранить данные на клиентском компьютере (но только в специальной встроенной БД, доступа к файловой системе приложению не предоставляется). Adobe AIR также содержит встроенную БД и средства работы с ней (к слову, и Gears, и AIR, и многие другие используют один и тот же опенсорсный движок БД SQLite).
 

Куда ты плывешь, крыша моя?

 
      Возможно, судить еще рано, однако похоже, что тенденции на улучшение веб-приложений ведут клиентскую часть Веба куда-то далеко в сторону от изначальной "платформы для чтения документов". Например, мозилловцы, создавшие Prism, говорят о нем как о Site Specific Browser (каждому сайту свой браузер с подходящим именно этому сайту внешним видом и управлением), а горячие норвежские парни из Opera прямо говорят о своем курсе на превращение браузера в "полноценную платформу для приложений, работающую на любом устройстве"[Например, недавно Opera анонсировала поддержку Google Gears по собственному почину, не дожидаясь, пока "приспособление" биб лиотеки к браузеру сделает Google.]. Все это очень здорово, но как бы оставляет за кадром тот факт, что первоначальное назначение Веба — сети гипертекстовых документов — отнюдь не исчерпано. И тем не менее весь браузерный прогресс последних лет направлен вот на то самое — на превращение браузера в "платформу для всего" [Не могу не вспомнить бесконечно бородатую шутку про текстовый редактор Emacs, тоже стремившийся в свое время стать платформой и преуспевший: "Emacs — отличная операционная система, жаль, текстового редактора в ней нету". ], а не на удобство потребления информации. Не то пора, как предлагают некоторые, вводить HyperApplication Transfer Protocol — чтобы спасти Hyper Text от засилья приложений; не то пора создавать веб-приложение-для-удобного чтения [(Не сарказм.) Рекомендую обратить внимание, например, на New York Times Reader, сделанный на основе Microsoft WPF (то есть технологии, частью которой и является Silverlight). ]…
       P.S. Автор благодарит за ценные консультации Андрея Федонюка (Terra Informatica Software) — создателя интерфейсной библиотеки HTMLayout и платформы для RIA-приложений Sciter.

голубятня: Победа над Биби-Иби

      Победа над Биби-ИбиАвтор: Сергей Голубицкий
      Опубликовано в журнале "Компьютерра" N25-26 от 08 июля 2008 года Футбол можно смотреть по-разному. Можно — профессионально: когда смакуешь, поцокивая языком, каждый удачный финт, прорыв по флангу, увенчанный результативным навесом, многоходовку коротким пасом а-ля "Спартачок", голову, подставленную в нужном месте и в нужное время. Футбол можно смотреть и стебально-культурологически — например, так: "То, что мы называем футболом, таит какую-то чрезвычайно архаическую и значимую ритуально-мифологическую жертву, которая, разумеется, имеет сексуальный характер, но главная семантема которой — это утверждение неделимой сферической космической уплотненности, стабильности через разрыв единичного тела, через неудовлетворенность избыточной непристойности желания. То, что мяч проникает в ворота, безусловно важно, но то, что форвард оказывается козлом отпущения, что забивание мяча в ворота, космическое совокупление его головы с головой земли, это, пожалуй, самое важное"[Вадим Руднев, "Метафизика футбола" (журнал "Логос", www.ruthenia.ru/logos/number/1999_08/1999_8_06.htm).].
      Наконец, можно смотреть футбол пообывательски — именно так, как его смотрят сотни миллионов почитателей во всем мире. Смысл обывательского восприятия футбола — в фаллических замерах на уровне дихотомии "свой-чужой": "Мы им сегодня наваляем!" Чем выше уровень этой дихотомии, тем футбол увлекательней и зажигательней. Можно, конечно, смаковать игру "Шинника" родного завода против "Птичника" из пригородного совхоза, но хотелось бы чего-то помасштабнее: например, "Спартак" — "Зенит", то есть наш город против их города.
      Вершина обывательского наслаждения футболом — игры международные, когда дихотомия "свойчужой" достигает кульминации и приносит максимум удовольствия: кто видел, как обнимался испанский принц с испанской принцессой всякий раз, как национальная сборная Испании вколачивала очередной гол в ворота россиянских мастеров голландского футбола, тот оценит масштаб действа и его универсальность, пронизывающую любые социальные страты.
      Задача сегодняшнего культур-джема — втереть бальзам в раненые сердца соотечественников, опечаленных двойным нокаутом, нанесенным иберийскими обидчиками. Не нужно печалиться! Футбол игра хоть и фаллократическая, а значит — универсально мужская, тем не менее годится не для всех.
      В смысле — не всем народам подходит под национальный архетип, который невозможно замутнить никакими голландскими тренерами и бразильскими легионерами.

      Если верить Вадиму Рудневу, катание мяча ногами (= ногомёт, футбол) родилось из сексуальной репрессивности английского народа: "Конец XIX века — викторианство, когда женщине было неприлично вообще двигаться в постели во время полового акта — она должна была лежать на спине тихо и спокойно. Расцвет и одновременно закат английского национального характера — чопорность, замкнутость, порядочность, "обсессивность-компульсивность" [Райх, 1999]. И вот здесь-то и возникает футбол, где играют ногами. Ясна отчетливая сублимативная функция футбола в эпоху с эксплицитно репрессированной сексуальностью. В чем цель (goal — гол) игры в футбол? В том, чтобы при помощи ног (субститутов половых органов) забить (затащить) круглый предмет в некое ограниченное пространство (по сравнению с футбольным полем ворота — это весьма ограниченное пространство), в сетку, в дыру. Стоит ли приводить примеры из "Толкования сновидений"?
      В самом деле — не стоит. Как бы шокирующе ни выглядела подобная трактовка сублимационных импульсов футбола, она, тем не менее, блестяще объясняет, почему одни народы всегда играют в футбол хорошо, а другие плохо. Какие бы тренеры их ни обучали, какие бы иностранные игроки ни усиливали игру, команда, выражающая национальный дух, всегда играет так, как этот дух соотносится с концепцией сексуальной репрессии — в узком плане и культа macho — в широком.
      Рискну сформулировать аксиому: в футбол играют хорошо только те народы, в культуре которых а) существует выраженная традиция перманентного сексуального самоутверждения и б) исторически реализована идея коллективного прозелитизма. В переводе на человеческий язык: хороший футболист — тот, чьи предки по мужской линии всегда ходили павлинами по селу ("Смотри, какой джигит идет!") и постоянно лезли к другим народам (не обязательно соседним) с советами и поучениями (разумеется, не безвозмездными!). При таком раскладе, как вы понимаете, русским людям в футболе мало что светит. Идея сексуального самоутверждения не то что не выражалась в русской культуре перманентно, но и вообще в ней никак и никогда не выражалась. Русская сексуальная традиция девственно чиста. Чтобы понять всю немыслимость сексуального самоутверждения в родных весях, достаточно представить себе, как паренек из тамбовской губернии шлифует бродвей родного села, постоянно держась и поправляя причинное место (коронный жест афроамериканцев — эмблема macho в рафинированном виде!)
      Представили? Ужаснулись? Невероятно? Вот поэтому русские люди всегда будут играть в футбол плохо.
      А португальские, испанские, английские, голландские и немецкие люди будут играть хорошо. Два первых народа (бразильцы — это тоже португальцы, если кто запамятовал) обладают колоссальной сексуальной агрессией, усиленной грандиозным коллективным прозелитизмом в форме колониальных завоеваний. Колониальный запал германских наций еще более масштабен, а их сексуальность хоть и не агрессивна, зато репрессирована до предела религиозно-историческими традициями. Для футбола — самый цимес!

      Поэтому когда сборная России по футболу сливает по полной программе юрким, шустрым черноволосым живчикам-macho, испанским пассионариям, которые постоянно срывают дамские овации элегантными финтами, демонстрируя чудеса индивидуального дриблинга, картинно падая, закатывая глаза в театральном страдании — все для того, чтобы уже через мгновение как ни в чем не бывало с лукавым осклабом ("Как мы их, Хуан, провели!") оказаться на ногах и пробить выуженный из сердобольного судьи штрафной удар, не нужно удивляться: все так и должно быть! Футбол — это их игра!
      Зато хоккей, где десятипудовая глыба Васи может припечатать к борту так, что останется только генитальный трафарет, когда клюшка Пети может неожиданно неприятным образом снести пластиковый шлем вместе с половиной башки, а конек Коляна очень не понарошку отутюжить пах, — зато такая игра уже не для них! Это другая игра, требующая иных форм национальной сублимации, иных исторических традиций и культурных привычек.
      А посему: сливали мы в футбол в прошлом и будем всегда сливать в будущем! Остается смириться и расслабиться. Мы свое доберем по-другому — да хоть бы и газом. Аминь!
      Софтверная часть "Голубятни" у нас сегодня под стать повидлу: расскажу о победе над хорошо знакомым читателям сониевским проприетарным форматом LRF или, в более мелодичной сонористике, популяризированной моей любимой компанией Ectaco, — "Биби-Иби" (BBeB BroadBand eBook).
      Для тех, кто не в теме: "Биби-Иби" — это формат, который применяется в читалках Sony PRS-500 и PRS-505. Гаджет этот, без которого уже не мыслю существования, поскольку читаю только на нем, а об LCD-мониторах вспоминаю с печальной улыбкой, понимает и другие форматы — PDF и TXT, однако ни тот ни другой не могут рассматриваться всерьез. PDF, как и полагается дебильно рожденному саманному дитяти, еле шевелится, а TXT недостаточно, на мое имхо, экспрессивен: мне лично не достает картинок, курсива, жирных выделений и таблиц.

      Остается "Биби-Иби", который, как и все у Sony, сделан таким образом, чтобы икалось всем, включая саму японскую загадочную компанию. Формат LRF очень быстро обрабатывается читалками PRS, передает все богатство форматирования (от изображений до любых шрифтов любого кегля), однако с колоссальным трудом поддается конвертации. До недавнего времени инструментарий любителей электронных чернил ограничивался, собственно, двумя утилитами: Book Designer (вариация — FictionBook Designer) и FB2LRF.
      Оба этих мрачных монстра вылупились из гнезда FB2-тусовки, которая, в свою очередь, была инициирована зловещим гением Дмитрия Грибова (помните программу ClearText, которую я описывал аж семь лет назад в "Голубятне" "Мы пахали"?). Если говорить кратко: формат FB2 гениален по задумке и чудовищен по реализации — не в последнюю очередь из-за того, что его бросили на полпути, не доведя не то что до ума, но и вообще до мало-мальски потребительского вида.
      Тем не менее в библиотеках Рунета FB2 пользуется бешеной популярностью (чего только стоит величественный lib.aldebaran.ru, целиком сидящий на этом формате!), соответственно под него оказался заточен и ВookDesigner, не говоря об утилите прямого действия для конвертации FB2 в LRF.
      О BookDesigner я обломал дюжину копий, воюя с Антонелло, которому эта жуткая программа почемуто нравится. Антонелло говорит: мол, при желании в ВookDesigner можно подготовить книгу не только для чтения на электронном гаджете (для чего эта программа и задумывалась), но и для типографии. Так мне не нужно в типографию! Мне не нужна программа, на освоение которой требуется полугодовое обучение в техникуме библиотекарей и каталогизаторов! Всякий раз, беря BookDesigner в руки, содрогаюсь: его учебная курва в прямом смысле слова буквализирует метафору — вот уж курва так курва!