Помоги проекту - поделись книгой:
Вокруг проекта по переходу на ODF возникла нездоровая атмосфера. Главного идеолога миграции Питера Куинна (Peter Quinn), ответственного за IT в администрации Массачусетса, обвиняли в недостаточно проработанной оценке стоимости проекта, в предоставлении неоправданных преференций бизнес-моделям, ориентированным на открытый код, игнорировании нужд различных групп пользователей, которым требовалось использовать MS Office (в частности, из соображений accessibility) и прочих смертных грехах. В начале 2006-го, за год до планируемого перехода, Питер Куинн был вынужден подать в отставку. Тем не менее новый главный CIO Массачусетса Луис Гутиэррес (Louis Gutierrez) заявил, что штат остается верен курсу на открытые стандарты - но не планирует мигрировать с MS Office, а будет использовать уже появившиеся к тому времени плагины для работы с ODF[Впоследствии в штате Массачусетс был разрешен и формат MS OOXML, когда он стал стандартом Ecma, - о чем будет рассказано ниже].
"На сей раз пронесло", - вероятно, подумали в Microsoft.
Один из распространенных пунктов технической критики OOXML: согласно календарным формулам, приведенным в спецификациях формата электронных таблиц, 1900 год получается високосным, что неверно. По словам представителей Microsoft, впервые этот "баг" появился в Lotus 1-2-3 - в те давние времена процессорное время было дорого и упрощение формул за счет таких незначительных погрешностей только приветствовалось. Однако, ради соблюдения обратной совместимости, до сего момента этот "баг" умышленно повторялся в большинстве реализаций электронных таблиц. Исправить его в спецификации OOXML - раз плюнуть, но когда "технари" от Microsoft заикнулись об этом на заседании технического комитета Ecma, им быстро "заткнули рот" представители крупного бизнеса, опасавшиеся проблем с уже накопленным массивом данных. Тем не менее, ссылаясь на критику, поступившую из ISO, Ecma предлагает все-таки внести необходимые изменения - и, быть может, исправить досадное недоразумение.
Впрочем, Массачусетс не был "первым звоночком" для редмондского гиганта. Еще в мае 2004-го комитет по техническому взаимодействию между администрациями Евросоюза (Telematics between Administrations Committee, TAC) выпустил несколько важных рекомендаций, связанных с форматами документов. Изучив положение дел в отрасли (в тот момент были опубликованы как промежуточные спецификации готовящегося стандарта ODF, так и XML-формата WordML от Microsoft - части будущего OOXML), Еврокомиссия предложила Microsoft "взять на себя обязательства по публикации и предоставлению недискриминирующего доступа к будущим версиям спецификаций формата WordML", а также "внести свои XML-форматы в какую-либо международную стандартизирующую организацию по своему выбору".
Microsoft сделала выбор спустя полтора года: в ноябре 2005-го было принято решение стандартизировать XML-формат, используемый в разрабатываемом Office 2007, силами организации Ecma International. Спустя еще год Ecma утвердила окончательный текст стандарта, получившего название ECMA-376 "Office Open XML", и приняла решение о его передаче в ISO для окончательного утверждения по ускоренной процедуре (Fast Track). Казалось, что Microsoft находится в двух шагах от обретения "собственного" (то есть уже практически реализованного в Office 2007) стандарта ISO.
Нетрудно было догадаться, что подобный шаг софтверного гиганта мало кем будет встречен на ура. Но вряд ли кто-то мог знать, что вокруг OOXML развернется битва не на жизнь, а на смерть.
Критика посыпалась со всех сторон. Первый и естественный вопрос вообще не касался технического устройства формата: зачем нужен второй стандарт ISO на формат офисных документов, если один уже есть (ODF был стандартизован в ISO практически в тот же момент, когда люди из Ecma подали свою заявку)? Критики указывали на то, что это противоречит целям ISO, а необходимость поддерживать два стандарта существенно увеличивает нагрузку на индустрию. Почему Microsoft не поддерживает уже принятый ODF? Почему бы не объединить OOXML и ODF?
В Microsoft приводили развернутые аргументы в пользу того, что OOXML и ODF имеют принципиально разные цели и задачи (например, расходятся в вопросе об обратной совместимости), поэтому нельзя говорить, что они задают взаимозаменяемые стандарты (а значит, никаких противоречий с целями ISO нет), и объединить их, сохраняя различные подходы к архитекутре - невозможно. "К тому же было бы нечестно делать ODF единственным международным стандартом лишь по той причине, что его сторонники успели первыми со стандартизацией в ISO", - говорит менеджер по стратегии платформ Microsoft Владислав Шершульский.
Другая форма критики касалась технических недочетов в спецификациях. При обсуждении и анализе 6 тысяч страниц описания стандарта в ходе процедуры Fast Track было высказано больше 3 тысяч замечаний (правда, оценить, сколько из них уникальны, а сколько повторяются, пока невозможно). Претензии были самые разные: нестандартный формат представления времени (не позволяющий работать с датами до 1900 года); использование (в целях пресловутой обратной совместимости) тегов типа SpaceLikeWord95, описанных в терминах поведения приложений предыдущих поколений; возможность использования пользовательской семантической разметки документов с помощью custom-тегов (открывающее, по мнению критиков, простор для создания проприетарных расширений формата) и многое, многое другое. В Microsoft и Ecma на критику реагировали и отвечали, критики отвечали на ответы… Обмен любезностями продолжался. Активные действия тоже.
Европейская организация FFII (Foundation for a Free Information Infrastructure, Фонд свободной информационной инфраструктуры) открыла сайт NoOOXML.org, на котором приводились самые "громкие" аргументы против OOXML и собирались подписи под петицией соответствующего содержания. Некоторые "подписанты" впоследствии стали получать письма от организатора NoOOXML Бенджамина Хенриона (Benjamin Henrion), призывающие организовать массовые обращения в местные стандартизирующие организации (представляющие страну в ISO) с требованием голосовать "против, с комментариями" (No with comments). Список "комментариев" прилагался.
В ходе первого голосования, завершившегося в сентябре 2007, в стандартизации OOXML было отказано: голосов "за" явно не хватило, а "против" было слишком много. Однако этот результат не означал "нет" - он означал "не сейчас". Согласно процедуре, Ecma давалось время для того, чтобы учесть комментарии и подготовить свои предложения по их разрешению. В конце февраля в Женеве на пять дней соберется конференция (Ballot Resolution Meeting, BRM), на которой будут приняты решения о внесении изменений в проект стандарта. После чего состоится повторное голосование о стандартизации OOXML. Оно-то и будет окончательным. А пока - битва продолжается.
Мы хотим единого открытого стандарта XML-формата офисных документов, свободного от возможности нестандартизованных вставок, любых видов патентных ограничений и со свободной реализацией. На основе этих принципов можно сотрудничать и с инженерами Microsoft.
Алексей Новодворский, заместитель генерального директора ALT Linux
Картина сражения выглядит очень по-разному - в зависимости от того, откуда смотреть. С точки зрения противников Microsoft, все очень просто: нехорошие люди из стана софтверного монополиста хотят пропихнуть сырой, невероятно сложный и (якобы) эффективно проприетарный формат как международный открытый стандарт и продолжать пользоваться своим доминирующим положением на рынке, пока конкуренты будут пытаться реализовать 6 тысяч страниц спецификаций (что, по мнению критиков, вообще невозможно сделать вне платформы Windows). Как только и если это случится, компания вряд ли станет строго соблюдать свои же спецификации, а скорее всего - разработает проприетарные расширения, которые будут снова нарушать интероперабельность с продуктами конкурентов. В это время все честные люди планеты встали единым фронтом, чтобы не допустить такого развития событий и отстоять честь уже принятого стандарта ODF.
С точки зрения Microsoft и ее сторонников, все совсем наоборот. Хорошие люди из организации Ecma International собрались (помимо Microsoft в заседаниях технического комитета участвовало множество компаний - Apple, Novell и даже The Gnome Foundation) и сделали прекрасный формат офисных документов, обеспечивающий замечательную обратную совместимость со старыми версиями MS Office (а также офисных пакетов других разработчиков), широкие возможности для корректной расширяемости (те самые пользовательские XML-теги) и поддерживающий другие функции, имеющиеся в Office 2007, которые разработчики ODF не горят желанием реализовать. Всем будет лучше, если этот формат, который лидер рынка безусловно будет поддерживать и в дальнейшем, станет стандартом ISO. Однако нехорошие люди из компании IBM в своих корыстных интересах развернули массивную кампанию и даже мобилизовали наиболее активных и неконструктивных участников FOSS-движения, чтобы не допустить стандартизации OOXML и тем самым продолжать наслаждаться эксклюзивным положением ODF как единственного "правильного" стандарта (который IBM поддерживает, например, в недавно выпущенном пакете Lotus Symphony) - и вытеснить Microsoft самым неконкурентным способом.
Есть и третья точка зрения на проблему, сформулированная в конце XVI века Вильямом Шекспиром: "Пади чума на оба ваши дома". Именно ее я слышал, разговаривая со специалистами из лагеря свободного софта, реально занимающимися офисным ПО: между двумя форматами есть технический паритет (где-то выигрывает один, где-то другой), а ожесточенное противостояние в деле стандартизации OOXML ("возня стандартов" - по выражению Анатолия Якушина, известного в России участника OpenOffice.org) - это не то, чем нужно заниматься индустрии. Несмотря на в целом негативное отношение к наличию двух стандартов ISO, нужно отвлечься от тонкостей процесса стандартизации и противостояния и задуматься над вопросом, поставленным в начале статьи: "А зачем?". Каковы реальные, видимые сегодня - а не теоретические - преимущества стандартизованных XML-форматов в случае офисных документов? Где те самые инновационные приложения и сервисы, которые будут использовать возможности что ODF, что OOXML? Их пока нет - и это одинаково касается и Microsoft, и ее конкурентов.
Появятся ли эти приложения? Несомненно. Для какого формата этот процесс пойдет активнее? Анатолий Якушин считает ODF более перспективной платформой по довольно банальным причинам: сравнительная простота спецификаций (722 страницы ODF 1.0 против 6 тысяч страниц текущего драфта OOXML), использование уже принятых стандартов там, где это возможно (например, SVG для представления векторной графики, MathML для представления формул), а самое главное - наличие свободных и открытых имплементаций формата - в частности, создаваемого в рамках проекта OpenOffice.org набора инструментов ODF Toolkit. Подобные инструменты для OOXML еще только предстоит написать (и эта работа ведется - не без поддержки Microsoft, - но может занять много времени).
Вполне вероятно, что именно эти соображения, а не мартовское голосование в ISO, и уж точно не акции NoOOXML, определят судьбу противоборствующих форматов и поддерживающих их компаний, а заодно - пути развития рынка офисных приложений на ближайшее и даже отдаленное будущее.
История, изложенная выше, не окончена, и в том, что уже произошло, многие моменты допускают неоднозначную трактовку, сильно зависящую от "кочки зрения". Особенно хорошо это можно проследить, анализируя блоги участников дискуссии о стандартах - по каждую из сторон баррикад есть свои любимые факты, любимые документы, любимые отчеты и любимая логика изложения. Однако есть некоторые факты, которые стали очевидными, и некоторые вопросы, которые остро встали в ходе этого противостояния.
Во-первых, индустрия выбирается из vendor lock-in, связанного с офисными форматами. Совсем недавно Microsoft объявила, что опубликует спецификации своих старых бинарных форматов (ранее их можно было получить, только вступив в переписку с компанией) - это уже бесполезное оружие в современном мире.
Переход к стандартизации означает, что "гонка за фичами" в форматах офисных документов завершена. Независимо от результатов голосования в ISO, OOXML уже является международным стандартом (Ecma), на который могут влиять (в той или иной степени) различные игроки - и чтобы внести в него изменения, сначала требуется достигнуть консенсуса и лишь потом выпускать поддерживающий эти изменения продукт.
Во-вторых, начинает осознаваться значение открытых стандартов в ИТ - особенно в государственном управлении. Вряд ли переход будет быстрым и скачкообразным (скажем, в широко обсуждаемом отчете Gartner, подготовленном по заказу Еврокомиссии и посвященном интероперабельности в общеевропейском e-Government, большое внимание уделяется вопросам обратной совместимости, на которую так любит упирать Microsoft), но он идет на наших глазах - и он необратим.
Из важности стандартов следует важность процедуры их разработки и утверждения. Достаточно ли они эффективны, честны и открыты для современного динамичного мира? Что нужно сделать, дабы исключить "возню", возникшую вокруг ODF и OOXML, или по крайней мере упростить разрешение подобных конфликтов? К чему приведет использование XML-форматов офисных документов, когда страсти улягутся? Станут ли они платформой для новой революции или по крайней мере появлению принципиально новых, более удобных средств работы, снимут ли они с нас еще какую-то часть рутинных занятий, оставив время для более интересных дел? Хочется верить, что да. Надо только перестать кричать и драться - и чуточку поработать…
КАФЕДРА ВАННАХА: "На той войне незнаменитой…"
Современные американские боевые роботы (о, где ты, Первый закон Азимова?..) начали убивать в прошлом году, в Афганистане и Ираке. А когда роботы дебютировали на поле боя? Где и как это было? Вопрос не праздный, и не только для любителей пожелтевших страниц! Дело в том, что автоматизация армии лишь обостряет проблему контроля общества над вооруженными силами, делая его (контроль) критическим для определения будущих судеб наций.
Но контроль требует знания, которым должны располагать не столько военные чиновники, сколько общество в целом. Комитеты солдатских матерей, особенно оживляющиеся после случаев, которые заставляют вспомнить Военный афоризм №33 усопшего поручика и кавалера Фаддея Козьмича Пруткова, и мужественная забота офицеров и их жен о собственной социальной защите, никакого отношения к гражданскому контролю над обороной нации не имеют. Гражданский контроль над обороной это: жизненные интересы нации; вероятные угрозы и противники; компромисс между ресурсами, потребными для обороны, и ресурсами, коими страна располагает; принятие решения о строительстве Вооруженных сил и оборонной инфраструктуры.
И все это требует знаний - дабы правильно интерпретировать поступающую информацию. Проиллюстрируем это на одном событии Советско-Финляндской войны 1939–40 гг., имеющем самое прямое отношение к тематике "КТ".
Итак, "на той войне незнаменитой" произошло вполне эпохальное событие - в бою впервые были применены автоматизированные машины. И не единичный экземпляр, вылизанный заводскими специалистами и управляемый инженерами КБ-разработчика, а полноценные подразделения.
С начала боевых действий в составе 20-й тяжелой танковой бригады была 7-я специальная рота, состоящая из семи телеуправляемых танков ТТ-26 с аппаратурой ТОЗ-IV. А уже в ходе боевых действий, 10 декабря 1939 года, в распоряжение 20-й бригады прибыл 217-й танковый батальон в составе тридцати трех телетанков и танка управления.
Дебют состоялся 17 декабря. Поддерживая наступление 123-й стрелковой дивизии, три танка ТТ-26 пошли на дистанционном управлении. Один был потерян.
Затем телетанки ходили перед обычными Т-28 при атаке финских позиций; горели, принимая на себя первый огонь.
В феврале 1940-го телетанки использовались для вскрытия системы минных полей, подрываясь на финских минах; безуспешно пытались подорвать финские доты. Выведен в резерв 217-й батальон был 18 февраля.
Автор многочисленных книг по военной истории Александр Широкорад, рассказавший об этой давней истории, крайне негативно оценивает эксперимент с телеуправляемыми танками.
"Так потерпела фиаско одна из бредовых идей маршала Тухачевского - создание телеуправляемой армии: управляемых по радио танков, самолетов, подводных лодок, торпедных катеров и даже пулеметов в дотах. Группа авантюристов во главе с В. И. Бекаури занималась ими почти двадцать лет, израсходовав десятки миллионов рублей, но ни один из перечисленных типов вооружения не нанес врагу ни малейшего ущерба ни в Финской, ни в Великой Отечественной войнах" [Широкорад А.Б., Три войны "Великой Финляндии". М., 2007, с.167].
А вот с такой оценкой выдающегося инженерного труда согласиться никак нельзя. Дело в том, что новый образец оружия не может быть удачным сразу. Он требует длительной инженерной отработки. Рвались первые пушки. А ранние ружья были куда менее скорострельны, чем луки.
Но и после того, как техника доведена до ума, есть проблемы. Надо учиться ее использовать. Сначала на полигонах, потом в бою. Отрабатывая специальную тактику. Преодолевая косность. Можно вспомнить, как генерал Драгомиров выступал против магазинных винтовок…
Некоторые образцы оружия остаются сугубо специальными, другие - способны менять тактику рода войск, а то и влиять на оперативное искусство и стратегию. Если компетентность офицерского корпуса позволяет их освоить.
Управляемые по радио саперные танкетки появились в вермахте лишь во второй половине 1943 года. Это были специальные машины Sd.Kfz. 301 фирмы Borgward. Потери, которые они несли, тоже были тяжелыми. Но небезызвестный Гейнц Гудериан оценивал новую технику положительно: "Для разведки минных полей использовались танкетки, управляемые по радио. Они предназначались… для того, чтобы облегчить батальонам танков "Тигр" преодоление оборонительных позиций противника", - хотя и грустил оттого, что "Ограниченное производство управляемых танков и большие потери в них не позволили постоянно придавать их всем танковым батальонам" [Гудериан Г., Танки - вперед! М., 1958, с.165]. Обратим внимание - никаких стенаний о трате куда более ограниченных ресурсов Рейха на научно-исследовательские и опытно-конструкторские работы, отставшие от СССР на четыре года!
Но главное, траты на системы телеуправления В. И. Бекаури были вложениями в технологию - самую передовую и работающую в самых жестких условиях наземных боевых машин. И без этих вложений был бы невозможен послевоенный взлет ракетной техники, локаторов, старт 12 апреля… А пулеметы-роботы заступают ныне в караул в Корее.
И общество, если хочет жить и развиваться, обязано рассмотреть за военными тратами самые дальние перспективы. Но для этого нужны - знания!
АНАЛИЗЫ: Третья Азия
Главной темой IBM’овской конференции Lotusphere 2008 (Орландо, Флорида, 21–24 января) было сотрудничество: как его сформатировать и запрограммировать?
Lotusphere - не только ежегодная (уже пятнадцатая) мегаконференция, но еще и Universe, Вселенная, в том смысле, который это слово имеет в бизнесах, вовлекающих массы. В данном случае - внушительные массы айтишников. В двух громадных отелях флоридского Дисней-мира, "Лебеде" и "Дельфине", собрались тысячи программистов, инженеров, аналитиков, менеджеров всевозможных специальностей и калибров. Все эти люди живут в экосистеме[Экосистемой в ИТ-бизнесе и индустрии часто называют систему поставщиков и потребителей разработок, вырастающую вокруг того или иного крупного продукта или платформы] софта корпорации Lotus Software, зародившейся на успехе спредшитов Lotus 1-2-3, которые приводили в восторг наших далеких предков еще в начале 1980-х.
Ныне корпорация Lotus - часть IBM, она создает продукты (в сущности, целые платформы) для обеспечения информационной инфраструктуры компаний - системы коммуникаций в реальном времени (Lotus Sametime), офисные приложения (Lotus Symphony), корпоративную почту (Lotus Domino) и многие другие. Однако я ехал в Дисней-мир не затем, чтобы представить читателю картину всей лотосовой экосистемы (желающие могут начать с www.ibm.com/developerworks/lotus/newto). Главной целью была линия фронта в извечной битве организации против беспорядка и за дружную продуктивную работу - галерея исследовательских проектов в области социального софта, выполняемых в лаборатории CUE из IBM Research (CUE - это Collaborative user experience, что хочется перевести как "Опыты совместного труда"). В небольшой аудитории "Азия-3" айбиэмовские исследователи дежурили у своих компьютеров и давали подробные пояснения по паре десятков проектов, демонстрируя все, что возможно, в действии.
Флагманский проект этой серии называется Beehive ("Улей") [По-моему, не без иронии - хотя как знать? Например, и у Oracle уже есть близкий по содержанию проект с таким же названием]. Пленарный доклад завлаба CUE Айрин Грайф (Irene Greif), одной из самых успешных женщин в сегодняшнем мире ИТ, обладательницы очень престижного звания IBM Fellow, был почти наполовину посвящен "Улью".
Что такое "Улей"? Коротко - это корпоративный аналог Facebook’а. Очень может быть, что такие ульи скоро появятся во всех крупных корпорациях - усилий это потребует сравнительно небольших, а отдача может оказаться серьезной, мы же видим, что социальные сети делают с людьми. Но пока о результатах говорить рано, и статус проекта остается исследовательским. Можно говорить лишь о техническом наполнении "Улья", выделяя некоторые ключевые моменты.
Первое: сеть отделена от внешнего мира, и это рассматривается авторами как важный стимулирующий фактор для приобщения к "Улью", - сотрудники знают, что выложенные ими семейные фотографии, частные обсуждения и прочий социальный контент не попадут в поле зрения случайных людей, а останутся достоянием родного коллектива. С другой стороны, общение на уровне "социальной информации" поможет, как считается, доверию и взаимопониманию в работе.
Второе: свободная форма профилей участников. О чем идет речь, авторы поясняют по контрасту с более ранней системой социальной коммуникации Lotus Connections. Там обязаловка - здесь свобода. Там при регистрации - заполнение подробных анкет, здесь, в "Улье", - свободный самобрэндинг, пиши о себе что хочешь. Что хочешь - но лучше все-таки не только об интересе к велоспорту и фотографированию кротов. Лучше все-таки и о профессии, и о работе, хотя бы по касательной, концептуально, абстрактно. Впрочем, это "лучше" не навязывается и вслух не произносится - но подразумевается в описании сети: социально-деловая.
И если ты начинаешь писать о работе, но делаешь это не для отчета перед начальниками и не для тупого "повышения эффективности" ("Улей" явно не заточен на работоголизм в духе "Друзья! Давайте обсуждать наш новый проект не только трижды в день в офисе, а еще и по ночам здесь?"), а просто потому, что ты не любишь термина "офисный планктон" и у тебя есть серьезные профессиональные интересы, - и вдруг в корпоративной ленте друзей появляются и другие люди, которых в науке, инженерии, менеджменте вдохновляет то же, что и тебя, - вот тут-то и может заработать таинственная сила неформальных сетевых связей.
Идея стара, как постиндустриальный мир. О "коллективе единомышленников" мы много слышали еще на комсомольских собраниях 1980-х. А вот инструментарий действительно новый, существенно новый. Так почему бы не проверить его на людях?
Межнациональные Деловые Машины, подражая традициям врачей-героев, испытывают собственное произведение на себе. "Улей" открылся прошлой осенью, а сейчас там уже 6500 сотрудников IBM, которые выложили 8000 фоток, завели 3500 списков (в духе "топ-5 чего-нибудь") и провели 350 мероприятий (events). Мероприятия - еще одна объединяющая, по замыслу, фича. Пример мероприятия - Hackday, когда гики совместно разбирают по винтикам какие-нибудь новые приложения или API, обмениваясь впечатлениями в открытом доступе. После мероприятий в профилях часто появляются новые теги, за счет этого сеть связей апдейтится. Система может и автоматически конвертировать кое-какую информацию из профилей в облака тегов, и это тоже провоцирует развитие связей по профинтересам.
"Улей" больше похож на идеологическую, а не технологическую инновацию - в том же смысле, в каком еще десяток лет назад идеологической инновацией был корпоративный веб-сайт. В те времена колумнист "КТ" Анатолий Левенчук писал, как трудно объяснить людям бизнеса, почему их фирмам необходим веб-сайт с обширной информацией, причем не только о продуктах на продажу (для всех), но и о ходе производственных процессов (не для всех). Тогда многие искренне считали это бездумной погоней за модой - сегодня фирма, не имеющая такого веб-сайта, производит впечатление несуществующей.
В докладе на открытии конференции генеральный менеджер (General Manager) Lotus Software Майкл Родин (Michael Rhodin) наметил генеральную линию прогресса в организации работы: от "документо-центричности" в прошлом к "человеко-центричности" сейчас и к "коммуно-центричности" (community-centric collaboration) в ближайшем будущем. Другой его тезис - виртуальный мир в корпорации должен быть похож на тот, к которому человек (в первую очередь - молодой!) привык за ее пределами. Похоже, что "Улей" неизбежен и неотвратим.
Bluegrass - виртуальный мир на движке для многопользовательских трехмерных игр Torque, интегрированный при помощи средств Lotus с платформой разработки Rational Jazz, с вышеупомянутым "Ульем", с другими средами и источниками данных. Сотрудники представлены в этом виртуальном мире своими аватарами и могут заниматься совместной разработкой, находясь географически где угодно.
Тенденция к использованию виртуальных миров при коллективной разработке софта появилась довольно давно (на уровне идей - как минимум лет десять назад), и сейчас настало время промышленной реализации этих идей (в своем докладе Грайф упоминала MUPPETS [muppets.rit.edu], MPK 20 [research.sun.com], а также деятельность сообщества программистов на Ruby в Second Life). Bluegrass уже понемногу используется внутри компании для работы над небольшими проектами. Функциональность и визуальный облик этого мира разработали по своему вкусу миллениалы (millenials) - юные люди, входящие в самостоятельную жизнь на рубеже тысячелетий. Один из миллениалов, Ли-Те Чень (Li-Te Cheng), демонстрировал мне сцены из жизни на синей траве:
- Вот ландшафт, домики, другие объекты. Над одним из объектов поднимаются пузырьки с кодами, это его самоописание. Мы подходим к нему и видим - объект представляет данные медиа-потока. А вот аватар генерирует пузырьки - они показывают, над чем он работает. Ага, он работает над проблемой номер 209. Одна из задач визуализации - показать, как объекты берут данные из внешних источников. Мы видим, что вот этот человек программирует нечто вне виртуального мира. Член команды может приносить информацию из разных источников, с любых сайтов.
На картинке, что мне любезно прислали авторы проекта, читатель видит, как легоподобные аватары расхаживают по экрану со списком проблем и work items, подталкивая друг к другу ящики с багами. Ли-Те Чень в "Азии-3" показывал более живописные сцены, он провел меня и в виртуальный дом для мозговых штурмов:
Поделиться книгой: