Интегрированный набор требует гораздо меньше системных ресурсов, чем все его компоненты в независимых модификациях. Интеграция - это не просто общий движок, ядро. Интеграция заметна во многих мелких деталях. Допустим, работая в браузере, вы увидели ссылку mailto:чей-то@почтовый.адрес: нажмите на нее мышкой, и тут же откроется окно создания сообщения для вашего далекого друга. Причем никакие внешние программы запускать не надо, не требуется настраивать «программы по умолчанию» в рабочей среде - все сделано заранее для вашего удобства.
Вы читаете рассылку в почтовом клиенте, увидели ссылку www.желанный.адрес, нажимаете на нее мышкой, и резво открывается окно браузера. То же самое происходит, если вы кликнете на ссылку во время беседы на IRC-канале.
SeaMonkey имеет более богатые настройки, чем Firefox и Thunderbird вместе взятые; для комфортной работы с ним требуется гораздо меньше расширений, что благоприятно сказывается на стабильности.
Стабильность - вторая после интеграции козырная карта SeaMonkey. Над кодом Mozilla Suite люди трудились многие годы, в нем очень мало ошибок.
SeaMonkey настраивается проще и быстрее, чем отдельные компоненты, так как многие настройки влияют сразу на весь набор инструментов. Вам не потребуется путешествовать по нескольким программам, держа в голове, как были настроены другие компоненты.
Будучи наследником Mozilla Suite, SeaMonkey имеет давнюю историю, поэтому хорошо знаком старожилам Интернета.
Вы не можете обновить один компонент, не затронув другой. То же самое происходит, если какими-то настройками вы испортите себе работу, - нарушение будет трудно исправить, не задев собратьев по несчастью.
Отсутствие менеджера расширений делает работу с расширениями игрой в русскую рулетку. Вдруг устанавливаемое расширение окажется неработоспособным? Удалить его будет уже непросто.
SeaMonkey - молодой проект, для работы в нем оптимизировано еще мало расширений, к тому же многие из них имеют остаточную совместимость. Авторы в последнюю очередь заботятся о том, чтобы их детище работало в SeaMonkey.
Интерфейс SeaMonkey кажется неудобным для новичков, которым было бы проще иметь много наглядных кнопок на панели инструментов, нежели запоминать горячие клавиши или расположение пунктов меню для тех или иных действий.
Формально SeaMonkey пока даже не завершен, поэтому у пользователя может создаться ошибочное ощущение изгоя на фоне легиона пользователей Internet Explorer и смелой гвардии поклонников Mozilla Firefox, «возвращающих себе Web», как гласит слоган рекламы «огненного браузера». Ошибочное оно потому, что «Обезьянка» - родная сестра «Лисички». Многие навыки работы с Mozilla Firefox пригодятся и в работе с SeaMonkey.
Альфа-версия SeaMonkey 1.0 вышла месяц назад. Многие могут подумать, что она еще очень сырая, что в ней полно ошибок. Но это совсем не так.
Начнем с того, почему SeaMonkey не претендует на звание финального релиза. Дело в том, что сам движок Gecko 1.8 немного не доделан и имеет статус beta 4. Отчасти по той же причине и Mozilla Firefox носит статус beta. Ее разработчики синхронизируют свою деятельность с авторами движка Gecko, и, скорее всего, выход финальной версии Mozilla Firefox 1.5, запланированный на декабрь, совпадет с завершением работы над Gecko 1.8.
Небольшое отступление. Несмотря на свой статус движок Gecko очень стабилен, в нем мало серьезных ошибок. Дело в том, что разработчики наметили план по улучшению движка и пока весь его не реализуют, так и будут обзывать плод своего труда ругательными для пользовательского уха словами «альфа», «бета»…
Но вернемся к нашей Обезьяне. Вторая причина, по которой проект носит статус альфа. Видимо, разработчики очень стыдятся того, что у проекта пока нет своего логотипа, фирменной графики. Почему? Да потому, что в команде нет ни одного дизайнера!
Но на помощь пришла известная практика OpenSource-проектов. А наша Обезьянка, между прочим, абсолютно бесплатна, и вы можете даже заглянуть ей в рот, увидев там исходные тексты. Так вот, разработчики объявили конкурс на лучшие логотипы для своего продукта. Конкурс недавно закончился, и уже в следующей версии SeaMonkey мы сможем увидеть нечто симпатичное. Что именно?
Фирменную стартовую заставку.
Фирменный индикатор активности браузера (синяя буква "E" в Interner Explorer, буква "N" в Netscape Browser);
Возможно, новую тему оформления.
Взглянем на эту проблему с другой стороны. Заметьте, что вам достаточно установить какую-нибудь дополнительную тему оформления, и все «проблемы» с отсутствием фирменной графики уходят на второй план.
Куда поплывет пароход с Обезьяной?
Для кого же старается команда разработчиков SeaMonkey, которую взяла под крыло могучая организация Mozilla.org?
Во-первых, для стариков. В мире Интернета «старики» - это люди, кому далеко за двадцать и кто начинал свою виртуальную жизнь в прошлом тысячелетии. Ведь интерфейс SeaMonkey практически не изменился со времен Netscape 4.0! До боли в сердце он кажется родным и привычным тем, кто делал первые шаги в Интернете в эпоху господства Netscape Communicator.
Во-вторых, программа ориентирована на тех, кто хочет иметь современные и безопасные инструменты для работы в Сети, но кого совсем не тянет возиться с расширениями для Mozilla Firefox. Лучше, чтобы все было сразу, в одном флаконе.
И, в-третьих, SeaMonkey понравится тем, для кого важнейший критерий - стабильность в работе не в ущерб инновационным решениям.
- Официальная страница проекта:
www.mozilla.org/projects/seamonkey
- Форум поддержки на русском языке: forum.mozilla.ru. Русская версия SeaMonkey 1.0a для Windows и Linux находится по адресу
ftp.mozilla.ru/seamonkey/1.0a
(обе версии имеют размер 11,5 Мбайт).
ТЕХНОЛОГИИ: Что такое Веб 2.0?
Данные - это следующий Intel Inside
Все современные интернет-приложения завязаны на базы данных: поисковик от Google, каталог (и поисковик) от Yahoo!, склад товаров на Amazon, картотека товаров и продавцов на eBay, карты MapQuest, каталоги Napster… Хэл Вэриан в прошлом году даже сказал, что «SQL - это новый HTML». Компаниям эпохи Веба 2.0 важно уметь работать с БД. Так важно, что порой мы называем новые приложения не software, а infoware.
Все это подводит нас к главному вопросу: кто владеет данными?
Очевидно - и тому есть множество примеров, - что в эпоху Интернета тот, кто владеет БД, владеет и рынком, а значит, получает львиную долю прибыли. Монополия на регистрацию доменных имен, предоставленная американским правительством компании Network Solutions (позднее куплена Verisign), была одной из первых по-настоящему денежных сделок в Интернете. И если сохранить рыночное преимущество, контролируя API, все труднее, контроль над важными источниками данных обеспечить куда проще. Особенно если эти источники дорого воссоздать (или они были обогащены с помощью пользователей сервиса).
Взгляните на копирайты на картах от MapQuest, maps.yahoo.com, maps.msn.com или maps.google.com. Везде будет пометка «Maps copyright NavTeq, TeleAtlas» или «Images copyright Digital Globe» (это новый поставщик спутниковых изображений). Обе компании изрядно вложились в свои БД. (Только NavTeq, как говорят, потратила на создание БД с названиями улиц и маршрутами 750 млн. долларов. Digital Globe пришлось расстаться с 500 млн. долларов, чтобы запустить собственный спутник, делающий снимки с лучшим разрешением, чем правительственные сателлиты.) NavTeq дошла до того, что стала лепить свое лого на автомобили, оснащенные системами навигации, - почти как когда-то Intel со своим Intel Inside.
Данные, несомненно, и есть единственный важный компонент подобных приложений, тогда как сам софт по большей части поставляется в открытом виде, а даже если и нет - все равно вполне доступен.
Давайте на примере высококонкурентного рынка веб-картографии посмотрим, как непонимание важности владения ключевыми данными может ухудшить конкурентоспособность. Первой на рынке веб-карт была MapQuest в 1995 году, за ней пришла Yahoo!, потом - Microsoft, а недавно к ним присоединился и Google, - при этом все компании, лицензируют у поставщиков информации, по сути, одни и те же данные.
Возьмем обратный пример: Amazon. Изначально его БД была построена на регистре кодов ISBN от R.R.Bowker. Базы конкурентов, соответственно, не имели существенных отличий. Но в отличие от MapQuest, Amazon без устали дополнял данные, добавляя информацию, предоставленную издателем, - обложки, содержание, оглавление и даже фрагменты из книг. Что важнее, Amazon привлек пользователей для написания аннотаций, и теперь именно Amazon - а вовсе не Bowker - является главным источником библиографической информации для филологов и библиотекарей, не говоря уж о простых смертных. Также в Amazon был разработан уникальный идентификатор ASIN, покрытие которого шире, чем у ISBN.
В общем, Amazon догнал и перегнал своих поставщиков информации.
Представьте, что точно так же поступила бы MapQuest: привлекла бы пользователей к аннотированию карт и маршрутов и даже к созданию новых информационных слоев. Бороться с такой компанией конкурентам, у которых в наличии только оригинальные лицензированные данные, было бы куда труднее.
Именно этим сейчас занимается Google. Google Maps - это эксперимент по созданию конкуренции между поставщиками данных и разработчиками приложений. Упрощенная модель программирования от Google привела к появлению множества дополнительных сервисов, которые построены на совмещении функциональности Google Maps с другими данными, доступными в Интернете. Так, например, housingmaps.com позволяет накладывать на карты от Google риэлторские объявления от Craigslist. На выходе у нас получается новое интерактивное приложение, превосходный пример смешивания технологий.
В настоящий момент подобные гибриды в основном являются инновационными экспериментами, уделом хакеров. Но и предпринимательская активность не за горами. Да уже можно видеть как минимум один класс таких разработчиков - ведь сам Google «увел» роль источника данных от Navteq, превратив себя в популярного посредника. В ближайшие несколько лет мы станем свидетелями самых настоящих битв между поставщиками данных и поставщиками приложений - когда обе стороны осознают, что определенная информация может быть ключевой для построения блоков приложений Веба 2.0.
За определенные классы ключевых данных - местоположение, личную информацию о пользователях, календари общественно-значимых событий, идентификаторы товаров и пространства имен - битва уже началась. Если воссоздать набор информации - удовольствие не из дешевых, то компания, у которой эти данные уже есть, может попытаться воспользоваться своим положением и разыграть карту Intel Inside. В других случаях победит та фирма, чья база данных первой наберет критическую массу с помощью пользователей, - если, конечно, компания сможет обратить эти аггрегированные данные в системный сервис.
К примеру, если мы говорим о сетевой идентификации пользователей, то Paypal, Amazon 1-Click и миллионы пользователей систем связи вполне могут считаться соперниками. (В этом смысле последняя инициатива Google, разрешившего подтверждать аккаунты на Google с телефона, выглядит как попытка расширить свою базу за счет телефонных систем.) С другой стороны, есть такие стартапы, как Sxip, сделавшие ставку на интегрированную личность (см. статью Берда Киви в этом номере. - В.Г.) и пытающиеся создать распределенное и простое решение, на основе которого можно будет построить единую подсистему для всего Веба 2.0. На рынке календарных справочников есть EVDB, пытающийся на базе wiki-подобной архитектуры построить крупнейший совместно пополняемый календарь. И хотя сегодня еще рано делать прогнозы, очевидно, что к появлению приложений нового поколения приведут те стандарты и решения, которые позволят эффективно обратить определенные классы данных в надежные подсистемы «операционной системы Интернета».
Прежде чем идти дальше, скажем пару слов о пользователях, берегущих свое privacy и право на владение информацией как зеницу ока. Во многих ранних веб-приложениях копирайт учитывался лишь номинально. Так, права на все обзоры, опубликованные на Amazon, принадлежат Amazon, но компания никого еще не преследовала за их републикацию. Однако как только компании поймут, что контроль над данными и есть их главное конкурентное преимущество, то станут стеречь свои данные куда ревностней.
Как успех проприетарного софта привел к рождению движения Free Software, так и усиление роли проприетарных БД уже в следующем десятилетии приведет к рождению движения за Свободную Информацию. Ранние проявления этой тенденции можно увидеть уже сейчас, в таких проектах, как Wikipedia, лицензии Creative Commons, или в программистских проектах типа Greasemonkey (дает пользователям возможность определять, как именно будут отображаться данные на их компьютерах).
Некоторые системы спроектированы для усиления взаимодействия. Существует три способа создания большой БД. Первый - платить людям за ее составление (Yahoo!). Второй - набрать для той же задачи добровольцев (open-source-проекты). Третий путь открыл Napster. В клиенте Napster по умолчанию загруженная песня была доступна для скачивания другими пользователями сети. Таким образом, каждый пользователь Napster увеличивал ценность распределенной БД. Потом эта же схема была повторена в других P2P-сервисах.
Пользователи могут повысить ценность приложения, но лишь немногие будут делать это добровольно. Поэтому приложения следует проектировать так, чтобы обогащение проекта пользовательской информацией происходило автоматически. Этот момент должен быть частью архитектуры приложения.
Удачная архитектура, возможно, даже больше повлияла на успех открытого софта, чем упомянутые добровольцы. Архитектура Интернета и веба (как и архитектура открытых проектов) такова, что вынуждает нас автоматически повышать их ценность во время использования. У каждого из таких проектов - небольшое технологическое ядро, четкие механизмы расширения и подход, позволяющий любому человеку добавлять новые компоненты, наращивая новые слои «луковицы».
Другими словами, эти технологии демонстрируют сетевые эффекты, просто потому, что они так спроектированы.
Такую архитектуру взаимодействия можно назвать естественной. Но как показал пример Amazon, последовательные усилия (а равно и экономические стимулы - например, партнерская программа) могут создать подобную архитектуру и в системе, которой при обычных условиях это не свойственно.
Одной из главных характеристик современных интернет-приложений является то, что они распространяются в виде сервиса, а не товара. Это, в свою очередь, ведет к фундаментальным изменениям в бизнес-моделях компаний-разработчиков.
Компания должна уметь управлять процессами. Искусству разработки приложений должно сопутствовать умение организовать ежедневные операции для поддержки работы этих приложений. Разрыв между софтом-артефактом и софтом-сервисом так велик, что уже сейчас нельзя написать хороший продукт и забыть о нем - его нужно поддерживать ежедневно. Google каждый день прочесывает веб, чтобы обновлять свои индексы, отсекая поисковый спам. Google должен каждый день обслуживать сотни миллионов запросов, поставляя пользователю не только качественные результаты поиска, но и контекстную рекламу. И неслучайно информация о системном администрировании, обслуживании сетей, балансировке нагрузки и т. п. охраняется Google, пожалуй, даже лучше, чем сами поисковые алгоритмы. Google научился автоматизировать упомянутые процессы, а это - ключевая часть его ценового преимущества перед конкурентами.
Также не случайно, что скриптовые языки - Perl, Python, PHP, а теперь еще и Ruby - играют в жизни компаний Веба 2.0 столь важную роль. Первый вебмастер Sun Microsystems Хасан Шрёдер (Hassan Schroeder) как-то назвал Perl «скотчем Интернета».
Скриптовые языки (презираемые программистами эры софтверных артефактов) - это естественный выбор для системных и сетевых администраторов, поскольку разработчики создают динамические системы, требующие постоянного изменения.
Пользователей нужно воспринимать как соразработчиков - как, например, принято при разработке открытого софта (даже если само ПО вряд ли будет выпущено под открытой лицензией). Максима открытого софта - «выпускай релизы раньше и чаще» - теперь формулируется еще жестче: «бесконечная бета-версия». Программы обновляются ежемесячно, еженедельно и даже ежедневно.
Не случайно на логотипах таких проектов, как Gmail, Google Maps, Flickr, del.icio.us и т. п., словечко «beta» может висеть годами.
Отслеживание поведения пользователей в реальном времени позволяет видеть, какие новые свойства используются и как они используются - и это еще одна ключевая составляющая успеха технологии. Веб-разработчик одного из раскрученных сетевых сервисов отмечает: «мы добавляем два-три новых свойства в разные части сайта каждый день, и если пользователям они не нравятся - мы отказываемся от этих нововведений. Если нравятся - внедряем на всем сайте».
Кэл Хендерсон (Cal Henderson), главный разработчик Flickr, недавно рассказал, что новый билд Flickrпоявляется каждые полчаса. Это совершенно другая модель разработки! И хотя пока не все веб-приложения разрабатываются с такой экстремальной скоростью, почти у всех цикл разработки радикально отличается от всего, что было в эпоху ПК или клиент-серверов. По этой причине редакторы Zdnet даже пришли к выводу, что Microsoft не удастся победить Google: «бизнес-модель Microsoft построена на предположении, что пользователь обновляет свое компьютерное окружение раз в два или три года. Google же зависит от того, что новенького обнаружит пользователь в своем компьютерном окружении сегодня».
Несмотря на то что Microsoft уже продемонстрировала невероятную способность учиться и в конце концов превосходить своих конкурентов, нет сомнений, что конкуренция заставит Microsoft (и - шире - любую современную софтверную компанию) превратиться в компанию совершенно другого типа. Истинным компаниям Веба 2.0 будет проще, поскольку их не тянут назад старые подходы (а также сопутствующие бизнес-модели и источники прибыли).
Как только идея веб-сервисов стала au courant, в схватку вступили большие компании, выкатившие сложные наборы веб-сервисов, позволяющих разрабатывать надежные среды программирования для распределенных приложений.
Успех веба во многом обязан тому, что большая часть теоретических построений, посвященных гипертексту, была отброшена в пользу простых прагматичных решений, которые и послужили основой идеальной конструкции. RSS стал, возможно, единственным широко распространенным веб-сервисом именно потому, что он прост. А сложные корпоративные наборы все еще ждут своего часа.
Amazon предоставляет два типа веб-сервисов. Первый не отступает от формализма SOAP (Simple Object Access Protocol), тогда как второй просто осуществляет передачу XML через HTTP с помощью упрощенного подхода, известного как REST (Representational State Transfer). Веб-сервисы первого типа используются для B2B-транзакций (например, между Amazon и розничными партнерами), но 95 процентов всех операций проводится с помощью REST.
То же стремление к простоте наблюдается и у других «настоящих» веб-компаний. Возьмем Google Maps. Простой AJAX-интерфейс был быстро «разобран» хакерами, которые затем сумели использовать поставляемые данные для организации новых сервисов.
Картографические веб-сервисы были доступны и раньше: от GIS-вендоров (ESRI, например) и таких компаний, как MapQuest и Microsoft MapPoint. Однако Google Maps завоевал мир, благодаря своей простоте. И если экспериментирование с данными веб-сервисов от «настоящих» вендоров требовало заключения контракта, то Google Maps был спроектирован так, что данные можно было сразу использовать в своих целях - и хакеры очень скоро научились это делать.
Отсюда можно вынести несколько важных уроков:
Поддерживайте упрощенные модели программирования и вы получите свободно-связанных партнеров. Проблема корпоративных веб-сервисов в том, что они предполагают жестко оговоренное партнерство. Во многих случаях это оправданно, но зачастую самые интересные приложения могут быть построены на весьма хрупкой основе.
Думайте о синдикации, а не о координации. Простые веб-сервисы - как RSS или сервисы на базе REST - занимаются синдикацией данных, не пытаясь контролировать, что происходит с информацией на другом конце цепочки. Идея сквозной передачи данных является одной из базовых идей самого Интернета.
Проектируйте с учетом возможных переделок и улучшений. Системы, подобные вебу, RSS и AJAX, сходны тем, что особых помех для их повторного использования не существует. Большая часть полезного софта находится в открытых исходниках, а если и нет, то имеется не так уж много способов защитить свою интеллектуальную собственность. Стандартная браузерная функция «посмотреть исходник» позволяет любому человеку скопировать любую веб-страницу. RSS был спроектирован для того, чтобы пользователь мог читать контент тогда, когда это удобно ему, а не поставщику информации. Самые успешные веб-сервисы - это, как правило, такие службы, которые могут быть изменены неожиданным для их создателей образом (some rights reserved).
В оригинале статья Тима О’Рейли была опубликована за неделю до начала конференции Web 2.0 (web2con.org, проводилась с 5 по 7 октября 2005 года), и, несомненно, автор хотел подогреть интерес к этому событию, что ему прекрасно удалось. Но у Веба 2.0 есть и другая, темная сторона.
Многие наблюдатели отмечают, что сейчас рынок находится в состоянии ожидания. Компаний, говорящих о Вебе 2.0, появляется все больше. Штат фирм, занимающихся разработкой новых веб-решений, растет. Говорить о Вебе 2.0 модно, заниматься им - престижно. И не исключено, что в самое ближайшее время мы увидим второе пришествие доткомов - только взлет новых компаний будет короче, а падение быстрее. Дело еще и в том, что далеко не все инфраструктурные изменения, о которых пишет Тим, могут быть легко конвертированы в деньги. Идея сервисов, построенных на сервисах, которые, в свою очередь, построены на других сервисах, и так далее до бесконечности (mash-up), может, и не плоха, но при всех достоинствах конечного продукта нельзя забывать, что держится он, в общем-то, на честном слове и будет функционировать только до тех пор, пока поставщики сервисов продолжают их предоставлять. Собственных активов у таких компаний, как правило, практически нет.
Тим О’Рейли почти не касается финансовых рисков - его больше увлекают технологические аспекты. Но некоторые венчурные капиталисты, следящие за становлением новой концепции, высказываются более чем осторожно: Рик Сигел пишет о том, что само по себе применение новых технологий вовсе не гарантирует возврата инвестиций; Фред Уилсон признается, что уже вкладывать опасно даже в первые производные (производные от компаний, владеющих интеллектуальными или иными активами), а сейчас предлагается инвестировать во вторые производные (сервис, объединяющий, допустим, Google Maps и delicious, является второй производной, поскольку и Google, и delicious [в меньшей степени] являются в данном случае не владельцами исходных данных, а посредниками).
Упрощенные бизнес-модели - это естественный спутник упрощенного программирования и свободного партнерства. В Вебе 2.0 повторное использование не осуждается. Новые сервисы, такие как housingmaps.com, являются простым совмещением двух существующих служб. У Housingmaps.com нет бизнес-модели (пока), но множество небольших сервисов живет за счет Google AdSense (или, возможно, амазоновских программ, или - и тех и других).
Эти примеры иллюстрируют еще один ключевой принцип Веба 2.0 - то, что мы называем «сборка по-новому». Когда вокруг столько дешевых компонентов, вы можете создавать нечто ценное, просто собирая из них неожиданные или эффективные комбинации. Точно так же, как ПК-революция дала «путевку в жизнь» компаниям, собирающим компьютеры из обычной комплектухи, Веб 2.0 предоставляет возможности компаниям, собирающим свои приложения из чужих компонентов.
Еще одна особенность Веба 2.0, которая заслуживает упоминания, это то, что теперь веб не привязан к платформе ПК. Перед уходом из Microsoft разработчик Дэйв Стац (Dave Stutz) дал своему бывшему работодателю совет: «обеспечить высокую прибыль способно программное обеспечение, работающее поверх устройств».
Конечно, так можно охарактеризовать практически все веб-приложения. В конце концов, простейшее приложение требует для своей работы по крайней мере два компьютера: один - для хостинга сервера, второй - для браузера. И как мы уже обсуждали, развитие веба как платформы расширяет эту идею до синтетических приложений, составленных из сервисов, которые предоставляются множеством компьютеров.
Но - с Вебом 2.0 такое случается частенько - «2.0» означает не что-то совершенно новое, а развитие и углубление существующих концепций. И фраза Стаца поясняет, как нужно проектировать приложения для новой платформы.
В настоящий момент лучшим примером нового подхода является iTunes. Это приложение без проблем соединяет карманное устройство с грандиозной веб-базой, оставляя ПК роль локального кэш-сервера и контрольной станции. Попытки донести веб-контент до мобильных устройств, разумеется, предпринимались и раньше, но связка iPod/iTunes является одним из первых приложений, соединяющих в единую цепочку сразу несколько устройств. Другой хороший пример подобного подхода - TiVo.
Вы читаете рассылку в почтовом клиенте, увидели ссылку www.желанный.адрес, нажимаете на нее мышкой, и резво открывается окно браузера. То же самое происходит, если вы кликнете на ссылку во время беседы на IRC-канале.
SeaMonkey имеет более богатые настройки, чем Firefox и Thunderbird вместе взятые; для комфортной работы с ним требуется гораздо меньше расширений, что благоприятно сказывается на стабильности.
Стабильность - вторая после интеграции козырная карта SeaMonkey. Над кодом Mozilla Suite люди трудились многие годы, в нем очень мало ошибок.
SeaMonkey настраивается проще и быстрее, чем отдельные компоненты, так как многие настройки влияют сразу на весь набор инструментов. Вам не потребуется путешествовать по нескольким программам, держа в голове, как были настроены другие компоненты.
Будучи наследником Mozilla Suite, SeaMonkey имеет давнюю историю, поэтому хорошо знаком старожилам Интернета.
Вы не можете обновить один компонент, не затронув другой. То же самое происходит, если какими-то настройками вы испортите себе работу, - нарушение будет трудно исправить, не задев собратьев по несчастью.
Отсутствие менеджера расширений делает работу с расширениями игрой в русскую рулетку. Вдруг устанавливаемое расширение окажется неработоспособным? Удалить его будет уже непросто.
SeaMonkey - молодой проект, для работы в нем оптимизировано еще мало расширений, к тому же многие из них имеют остаточную совместимость. Авторы в последнюю очередь заботятся о том, чтобы их детище работало в SeaMonkey.
Интерфейс SeaMonkey кажется неудобным для новичков, которым было бы проще иметь много наглядных кнопок на панели инструментов, нежели запоминать горячие клавиши или расположение пунктов меню для тех или иных действий.
Формально SeaMonkey пока даже не завершен, поэтому у пользователя может создаться ошибочное ощущение изгоя на фоне легиона пользователей Internet Explorer и смелой гвардии поклонников Mozilla Firefox, «возвращающих себе Web», как гласит слоган рекламы «огненного браузера». Ошибочное оно потому, что «Обезьянка» - родная сестра «Лисички». Многие навыки работы с Mozilla Firefox пригодятся и в работе с SeaMonkey.
Обезьяна получает билет на интернет-пароход
Альфа-версия SeaMonkey 1.0 вышла месяц назад. Многие могут подумать, что она еще очень сырая, что в ней полно ошибок. Но это совсем не так.
Начнем с того, почему SeaMonkey не претендует на звание финального релиза. Дело в том, что сам движок Gecko 1.8 немного не доделан и имеет статус beta 4. Отчасти по той же причине и Mozilla Firefox носит статус beta. Ее разработчики синхронизируют свою деятельность с авторами движка Gecko, и, скорее всего, выход финальной версии Mozilla Firefox 1.5, запланированный на декабрь, совпадет с завершением работы над Gecko 1.8.
Но вернемся к нашей Обезьяне. Вторая причина, по которой проект носит статус альфа. Видимо, разработчики очень стыдятся того, что у проекта пока нет своего логотипа, фирменной графики. Почему? Да потому, что в команде нет ни одного дизайнера!
Но на помощь пришла известная практика OpenSource-проектов. А наша Обезьянка, между прочим, абсолютно бесплатна, и вы можете даже заглянуть ей в рот, увидев там исходные тексты. Так вот, разработчики объявили конкурс на лучшие логотипы для своего продукта. Конкурс недавно закончился, и уже в следующей версии SeaMonkey мы сможем увидеть нечто симпатичное. Что именно?
Фирменную стартовую заставку.
Фирменный индикатор активности браузера (синяя буква "E" в Interner Explorer, буква "N" в Netscape Browser);
Возможно, новую тему оформления.
Куда поплывет пароход с Обезьяной?
Для кого же старается команда разработчиков SeaMonkey, которую взяла под крыло могучая организация Mozilla.org?
Во-первых, для стариков. В мире Интернета «старики» - это люди, кому далеко за двадцать и кто начинал свою виртуальную жизнь в прошлом тысячелетии. Ведь интерфейс SeaMonkey практически не изменился со времен Netscape 4.0! До боли в сердце он кажется родным и привычным тем, кто делал первые шаги в Интернете в эпоху господства Netscape Communicator.
Во-вторых, программа ориентирована на тех, кто хочет иметь современные и безопасные инструменты для работы в Сети, но кого совсем не тянет возиться с расширениями для Mozilla Firefox. Лучше, чтобы все было сразу, в одном флаконе.
И, в-третьих, SeaMonkey понравится тем, для кого важнейший критерий - стабильность в работе не в ущерб инновационным решениям.
- Официальная страница проекта:
www.mozilla.org/projects/seamonkey
- Форум поддержки на русском языке: forum.mozilla.ru. Русская версия SeaMonkey 1.0a для Windows и Linux находится по адресу
ftp.mozilla.ru/seamonkey/1.0a
(обе версии имеют размер 11,5 Мбайт).
ТЕХНОЛОГИИ: Что такое Веб 2.0?
Данные - это следующий Intel Inside
Все современные интернет-приложения завязаны на базы данных: поисковик от Google, каталог (и поисковик) от Yahoo!, склад товаров на Amazon, картотека товаров и продавцов на eBay, карты MapQuest, каталоги Napster… Хэл Вэриан в прошлом году даже сказал, что «SQL - это новый HTML». Компаниям эпохи Веба 2.0 важно уметь работать с БД. Так важно, что порой мы называем новые приложения не software, а infoware.
Все это подводит нас к главному вопросу: кто владеет данными?
Очевидно - и тому есть множество примеров, - что в эпоху Интернета тот, кто владеет БД, владеет и рынком, а значит, получает львиную долю прибыли. Монополия на регистрацию доменных имен, предоставленная американским правительством компании Network Solutions (позднее куплена Verisign), была одной из первых по-настоящему денежных сделок в Интернете. И если сохранить рыночное преимущество, контролируя API, все труднее, контроль над важными источниками данных обеспечить куда проще. Особенно если эти источники дорого воссоздать (или они были обогащены с помощью пользователей сервиса).
Взгляните на копирайты на картах от MapQuest, maps.yahoo.com, maps.msn.com или maps.google.com. Везде будет пометка «Maps copyright NavTeq, TeleAtlas» или «Images copyright Digital Globe» (это новый поставщик спутниковых изображений). Обе компании изрядно вложились в свои БД. (Только NavTeq, как говорят, потратила на создание БД с названиями улиц и маршрутами 750 млн. долларов. Digital Globe пришлось расстаться с 500 млн. долларов, чтобы запустить собственный спутник, делающий снимки с лучшим разрешением, чем правительственные сателлиты.) NavTeq дошла до того, что стала лепить свое лого на автомобили, оснащенные системами навигации, - почти как когда-то Intel со своим Intel Inside.
Данные, несомненно, и есть единственный важный компонент подобных приложений, тогда как сам софт по большей части поставляется в открытом виде, а даже если и нет - все равно вполне доступен.
Давайте на примере высококонкурентного рынка веб-картографии посмотрим, как непонимание важности владения ключевыми данными может ухудшить конкурентоспособность. Первой на рынке веб-карт была MapQuest в 1995 году, за ней пришла Yahoo!, потом - Microsoft, а недавно к ним присоединился и Google, - при этом все компании, лицензируют у поставщиков информации, по сути, одни и те же данные.
В общем, Amazon догнал и перегнал своих поставщиков информации.
Представьте, что точно так же поступила бы MapQuest: привлекла бы пользователей к аннотированию карт и маршрутов и даже к созданию новых информационных слоев. Бороться с такой компанией конкурентам, у которых в наличии только оригинальные лицензированные данные, было бы куда труднее.
Именно этим сейчас занимается Google. Google Maps - это эксперимент по созданию конкуренции между поставщиками данных и разработчиками приложений. Упрощенная модель программирования от Google привела к появлению множества дополнительных сервисов, которые построены на совмещении функциональности Google Maps с другими данными, доступными в Интернете. Так, например, housingmaps.com позволяет накладывать на карты от Google риэлторские объявления от Craigslist. На выходе у нас получается новое интерактивное приложение, превосходный пример смешивания технологий.
В настоящий момент подобные гибриды в основном являются инновационными экспериментами, уделом хакеров. Но и предпринимательская активность не за горами. Да уже можно видеть как минимум один класс таких разработчиков - ведь сам Google «увел» роль источника данных от Navteq, превратив себя в популярного посредника. В ближайшие несколько лет мы станем свидетелями самых настоящих битв между поставщиками данных и поставщиками приложений - когда обе стороны осознают, что определенная информация может быть ключевой для построения блоков приложений Веба 2.0.
За определенные классы ключевых данных - местоположение, личную информацию о пользователях, календари общественно-значимых событий, идентификаторы товаров и пространства имен - битва уже началась. Если воссоздать набор информации - удовольствие не из дешевых, то компания, у которой эти данные уже есть, может попытаться воспользоваться своим положением и разыграть карту Intel Inside. В других случаях победит та фирма, чья база данных первой наберет критическую массу с помощью пользователей, - если, конечно, компания сможет обратить эти аггрегированные данные в системный сервис.
К примеру, если мы говорим о сетевой идентификации пользователей, то Paypal, Amazon 1-Click и миллионы пользователей систем связи вполне могут считаться соперниками. (В этом смысле последняя инициатива Google, разрешившего подтверждать аккаунты на Google с телефона, выглядит как попытка расширить свою базу за счет телефонных систем.) С другой стороны, есть такие стартапы, как Sxip, сделавшие ставку на интегрированную личность (см. статью Берда Киви в этом номере. - В.Г.) и пытающиеся создать распределенное и простое решение, на основе которого можно будет построить единую подсистему для всего Веба 2.0. На рынке календарных справочников есть EVDB, пытающийся на базе wiki-подобной архитектуры построить крупнейший совместно пополняемый календарь. И хотя сегодня еще рано делать прогнозы, очевидно, что к появлению приложений нового поколения приведут те стандарты и решения, которые позволят эффективно обратить определенные классы данных в надежные подсистемы «операционной системы Интернета».
Прежде чем идти дальше, скажем пару слов о пользователях, берегущих свое privacy и право на владение информацией как зеницу ока. Во многих ранних веб-приложениях копирайт учитывался лишь номинально. Так, права на все обзоры, опубликованные на Amazon, принадлежат Amazon, но компания никого еще не преследовала за их републикацию. Однако как только компании поймут, что контроль над данными и есть их главное конкурентное преимущество, то станут стеречь свои данные куда ревностней.
Как успех проприетарного софта привел к рождению движения Free Software, так и усиление роли проприетарных БД уже в следующем десятилетии приведет к рождению движения за Свободную Информацию. Ранние проявления этой тенденции можно увидеть уже сейчас, в таких проектах, как Wikipedia, лицензии Creative Commons, или в программистских проектах типа Greasemonkey (дает пользователям возможность определять, как именно будут отображаться данные на их компьютерах).
Архитектура взаимодействия
Некоторые системы спроектированы для усиления взаимодействия. Существует три способа создания большой БД. Первый - платить людям за ее составление (Yahoo!). Второй - набрать для той же задачи добровольцев (open-source-проекты). Третий путь открыл Napster. В клиенте Napster по умолчанию загруженная песня была доступна для скачивания другими пользователями сети. Таким образом, каждый пользователь Napster увеличивал ценность распределенной БД. Потом эта же схема была повторена в других P2P-сервисах.
Пользователи могут повысить ценность приложения, но лишь немногие будут делать это добровольно. Поэтому приложения следует проектировать так, чтобы обогащение проекта пользовательской информацией происходило автоматически. Этот момент должен быть частью архитектуры приложения.
Удачная архитектура, возможно, даже больше повлияла на успех открытого софта, чем упомянутые добровольцы. Архитектура Интернета и веба (как и архитектура открытых проектов) такова, что вынуждает нас автоматически повышать их ценность во время использования. У каждого из таких проектов - небольшое технологическое ядро, четкие механизмы расширения и подход, позволяющий любому человеку добавлять новые компоненты, наращивая новые слои «луковицы».
Другими словами, эти технологии демонстрируют сетевые эффекты, просто потому, что они так спроектированы.
Такую архитектуру взаимодействия можно назвать естественной. Но как показал пример Amazon, последовательные усилия (а равно и экономические стимулы - например, партнерская программа) могут создать подобную архитектуру и в системе, которой при обычных условиях это не свойственно.
Конец цикла разработки ПО
Одной из главных характеристик современных интернет-приложений является то, что они распространяются в виде сервиса, а не товара. Это, в свою очередь, ведет к фундаментальным изменениям в бизнес-моделях компаний-разработчиков.
Компания должна уметь управлять процессами. Искусству разработки приложений должно сопутствовать умение организовать ежедневные операции для поддержки работы этих приложений. Разрыв между софтом-артефактом и софтом-сервисом так велик, что уже сейчас нельзя написать хороший продукт и забыть о нем - его нужно поддерживать ежедневно. Google каждый день прочесывает веб, чтобы обновлять свои индексы, отсекая поисковый спам. Google должен каждый день обслуживать сотни миллионов запросов, поставляя пользователю не только качественные результаты поиска, но и контекстную рекламу. И неслучайно информация о системном администрировании, обслуживании сетей, балансировке нагрузки и т. п. охраняется Google, пожалуй, даже лучше, чем сами поисковые алгоритмы. Google научился автоматизировать упомянутые процессы, а это - ключевая часть его ценового преимущества перед конкурентами.
Также не случайно, что скриптовые языки - Perl, Python, PHP, а теперь еще и Ruby - играют в жизни компаний Веба 2.0 столь важную роль. Первый вебмастер Sun Microsystems Хасан Шрёдер (Hassan Schroeder) как-то назвал Perl «скотчем Интернета».
Скриптовые языки (презираемые программистами эры софтверных артефактов) - это естественный выбор для системных и сетевых администраторов, поскольку разработчики создают динамические системы, требующие постоянного изменения.
Пользователей нужно воспринимать как соразработчиков - как, например, принято при разработке открытого софта (даже если само ПО вряд ли будет выпущено под открытой лицензией). Максима открытого софта - «выпускай релизы раньше и чаще» - теперь формулируется еще жестче: «бесконечная бета-версия». Программы обновляются ежемесячно, еженедельно и даже ежедневно.
Не случайно на логотипах таких проектов, как Gmail, Google Maps, Flickr, del.icio.us и т. п., словечко «beta» может висеть годами.
Отслеживание поведения пользователей в реальном времени позволяет видеть, какие новые свойства используются и как они используются - и это еще одна ключевая составляющая успеха технологии. Веб-разработчик одного из раскрученных сетевых сервисов отмечает: «мы добавляем два-три новых свойства в разные части сайта каждый день, и если пользователям они не нравятся - мы отказываемся от этих нововведений. Если нравятся - внедряем на всем сайте».
Кэл Хендерсон (Cal Henderson), главный разработчик Flickr, недавно рассказал, что новый билд Flickrпоявляется каждые полчаса. Это совершенно другая модель разработки! И хотя пока не все веб-приложения разрабатываются с такой экстремальной скоростью, почти у всех цикл разработки радикально отличается от всего, что было в эпоху ПК или клиент-серверов. По этой причине редакторы Zdnet даже пришли к выводу, что Microsoft не удастся победить Google: «бизнес-модель Microsoft построена на предположении, что пользователь обновляет свое компьютерное окружение раз в два или три года. Google же зависит от того, что новенького обнаружит пользователь в своем компьютерном окружении сегодня».
Несмотря на то что Microsoft уже продемонстрировала невероятную способность учиться и в конце концов превосходить своих конкурентов, нет сомнений, что конкуренция заставит Microsoft (и - шире - любую современную софтверную компанию) превратиться в компанию совершенно другого типа. Истинным компаниям Веба 2.0 будет проще, поскольку их не тянут назад старые подходы (а также сопутствующие бизнес-модели и источники прибыли).
Упрощенные модели программирования
Успех веба во многом обязан тому, что большая часть теоретических построений, посвященных гипертексту, была отброшена в пользу простых прагматичных решений, которые и послужили основой идеальной конструкции. RSS стал, возможно, единственным широко распространенным веб-сервисом именно потому, что он прост. А сложные корпоративные наборы все еще ждут своего часа.
Amazon предоставляет два типа веб-сервисов. Первый не отступает от формализма SOAP (Simple Object Access Protocol), тогда как второй просто осуществляет передачу XML через HTTP с помощью упрощенного подхода, известного как REST (Representational State Transfer). Веб-сервисы первого типа используются для B2B-транзакций (например, между Amazon и розничными партнерами), но 95 процентов всех операций проводится с помощью REST.
То же стремление к простоте наблюдается и у других «настоящих» веб-компаний. Возьмем Google Maps. Простой AJAX-интерфейс был быстро «разобран» хакерами, которые затем сумели использовать поставляемые данные для организации новых сервисов.
Картографические веб-сервисы были доступны и раньше: от GIS-вендоров (ESRI, например) и таких компаний, как MapQuest и Microsoft MapPoint. Однако Google Maps завоевал мир, благодаря своей простоте. И если экспериментирование с данными веб-сервисов от «настоящих» вендоров требовало заключения контракта, то Google Maps был спроектирован так, что данные можно было сразу использовать в своих целях - и хакеры очень скоро научились это делать.
Отсюда можно вынести несколько важных уроков:
Поддерживайте упрощенные модели программирования и вы получите свободно-связанных партнеров. Проблема корпоративных веб-сервисов в том, что они предполагают жестко оговоренное партнерство. Во многих случаях это оправданно, но зачастую самые интересные приложения могут быть построены на весьма хрупкой основе.
Думайте о синдикации, а не о координации. Простые веб-сервисы - как RSS или сервисы на базе REST - занимаются синдикацией данных, не пытаясь контролировать, что происходит с информацией на другом конце цепочки. Идея сквозной передачи данных является одной из базовых идей самого Интернета.
Проектируйте с учетом возможных переделок и улучшений. Системы, подобные вебу, RSS и AJAX, сходны тем, что особых помех для их повторного использования не существует. Большая часть полезного софта находится в открытых исходниках, а если и нет, то имеется не так уж много способов защитить свою интеллектуальную собственность. Стандартная браузерная функция «посмотреть исходник» позволяет любому человеку скопировать любую веб-страницу. RSS был спроектирован для того, чтобы пользователь мог читать контент тогда, когда это удобно ему, а не поставщику информации. Самые успешные веб-сервисы - это, как правило, такие службы, которые могут быть изменены неожиданным для их создателей образом (some rights reserved).
В оригинале статья Тима О’Рейли была опубликована за неделю до начала конференции Web 2.0 (web2con.org, проводилась с 5 по 7 октября 2005 года), и, несомненно, автор хотел подогреть интерес к этому событию, что ему прекрасно удалось. Но у Веба 2.0 есть и другая, темная сторона.
Многие наблюдатели отмечают, что сейчас рынок находится в состоянии ожидания. Компаний, говорящих о Вебе 2.0, появляется все больше. Штат фирм, занимающихся разработкой новых веб-решений, растет. Говорить о Вебе 2.0 модно, заниматься им - престижно. И не исключено, что в самое ближайшее время мы увидим второе пришествие доткомов - только взлет новых компаний будет короче, а падение быстрее. Дело еще и в том, что далеко не все инфраструктурные изменения, о которых пишет Тим, могут быть легко конвертированы в деньги. Идея сервисов, построенных на сервисах, которые, в свою очередь, построены на других сервисах, и так далее до бесконечности (mash-up), может, и не плоха, но при всех достоинствах конечного продукта нельзя забывать, что держится он, в общем-то, на честном слове и будет функционировать только до тех пор, пока поставщики сервисов продолжают их предоставлять. Собственных активов у таких компаний, как правило, практически нет.
Тим О’Рейли почти не касается финансовых рисков - его больше увлекают технологические аспекты. Но некоторые венчурные капиталисты, следящие за становлением новой концепции, высказываются более чем осторожно: Рик Сигел пишет о том, что само по себе применение новых технологий вовсе не гарантирует возврата инвестиций; Фред Уилсон признается, что уже вкладывать опасно даже в первые производные (производные от компаний, владеющих интеллектуальными или иными активами), а сейчас предлагается инвестировать во вторые производные (сервис, объединяющий, допустим, Google Maps и delicious, является второй производной, поскольку и Google, и delicious [в меньшей степени] являются в данном случае не владельцами исходных данных, а посредниками).
Собираем по-новому
Упрощенные бизнес-модели - это естественный спутник упрощенного программирования и свободного партнерства. В Вебе 2.0 повторное использование не осуждается. Новые сервисы, такие как housingmaps.com, являются простым совмещением двух существующих служб. У Housingmaps.com нет бизнес-модели (пока), но множество небольших сервисов живет за счет Google AdSense (или, возможно, амазоновских программ, или - и тех и других).
Эти примеры иллюстрируют еще один ключевой принцип Веба 2.0 - то, что мы называем «сборка по-новому». Когда вокруг столько дешевых компонентов, вы можете создавать нечто ценное, просто собирая из них неожиданные или эффективные комбинации. Точно так же, как ПК-революция дала «путевку в жизнь» компаниям, собирающим компьютеры из обычной комплектухи, Веб 2.0 предоставляет возможности компаниям, собирающим свои приложения из чужих компонентов.
Софт работает поверх устройств
Еще одна особенность Веба 2.0, которая заслуживает упоминания, это то, что теперь веб не привязан к платформе ПК. Перед уходом из Microsoft разработчик Дэйв Стац (Dave Stutz) дал своему бывшему работодателю совет: «обеспечить высокую прибыль способно программное обеспечение, работающее поверх устройств».
Конечно, так можно охарактеризовать практически все веб-приложения. В конце концов, простейшее приложение требует для своей работы по крайней мере два компьютера: один - для хостинга сервера, второй - для браузера. И как мы уже обсуждали, развитие веба как платформы расширяет эту идею до синтетических приложений, составленных из сервисов, которые предоставляются множеством компьютеров.
Но - с Вебом 2.0 такое случается частенько - «2.0» означает не что-то совершенно новое, а развитие и углубление существующих концепций. И фраза Стаца поясняет, как нужно проектировать приложения для новой платформы.
В настоящий момент лучшим примером нового подхода является iTunes. Это приложение без проблем соединяет карманное устройство с грандиозной веб-базой, оставляя ПК роль локального кэш-сервера и контрольной станции. Попытки донести веб-контент до мобильных устройств, разумеется, предпринимались и раньше, но связка iPod/iTunes является одним из первых приложений, соединяющих в единую цепочку сразу несколько устройств. Другой хороший пример подобного подхода - TiVo.