В общем, китайцы удивляют по полной с самого начала. Вместо того, чтобы “вписать” метеоданные в дескриптор HID-устройства (это не ругательство, а класс USB-устройств, очень полезных по жизни), они развернули “поверх” HID целый протокол обмена данными, способный “вписать” 32 байта “реальных” данных в 56 байт – это 7 восьмибайтовых пакетов, максимально допустимых для HID-устройства. Как мне кажется, это – вариация на тему какого-то древнего протокола обмена по RS-232, отсюда вылезли и обязательные даже в восьмибайтовом пакете контрольные суммы, и переменная длина “значащих” байт в пакете – например, в одном пакете имеется 7 “значащих” байт и 1 байт длины, в другом – значащий байт только один.

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

Кроме того, в процессе поиска информации об этой метеостанции в Интернете, нашлись очень интересные материалы о качестве девайса. Например, в датчике скорости ветра (ветряк и оптопара из мышки) китайцы сэкономили на конденсаторе, поэтому при штиле, когда датчик не крутится с бешеной скоростью, оптопара колеблется в “промежуточных” положениях, а индикатор показывает, что на улице бушует страшный ураган. Говорить о “высококачественном” радиоприемном модуле – сверхрегенераторе на двух транзисторах без кварца – я даже не буду.

Кстати, никак не доходят руки до окончания обещанной для EasyElectronics статьи про USB. Ни у кого нет идей, какой можно сделать интересный демонстрационный девайс, который стоило бы “научить” двусторонему обмену данными с компьютером? Очередной ЖК-индикатор с выводом текущей песни в Винампе делать не хочется, да и Винампом я не пользуюсь.

Речь идет про окружающие нас микроконтролеры. По многим подсчетам, у “современного цивилизованного человека” в квартире и машине имеется около 50 микроконтролеров. Каждый такой микроконтролер – это небольшой компьютер, снабженный собственным программным обеспечением, которое, к сожалению, подвержено ошибкам. Чтобы не быть голословным, приведу небольшой пример.

Думаю, многие видели на дорогах чудо отечественного автопрома под названием УАЗ Патриот (а кто не видел, может мельком ознакомиться с ТТХ по ссылке). В общем, по массогабаритным характеристикам это типичный представитель класса БЧД (большой черный джип), а по потрясающей маневренности и отличной управляемости – ближайший родственник ЗиЛ-130. А вот – шокирующая правда (из газеты Авторевю):

Дмитровский полигон, тест Авторевю, внедорожник УАЗ Патриот ходом штурмует заснеженный подъем. Половина уже пройдена, осталось еще немного, еще чуть-чуть… И вдруг — хр-р-р! — у УАЗа выбивает передачу в «раздатке», и машина остается без тяги. Ногу на тормоз, чтобы не скатиться вниз! Педаль встает колом, а Патриот лавиной катится вниз, неумолимо набирая ход. Поберегись! Почуяв неладное, фотограф отскакивает в сторону, а УАЗ, откатившись на десять метров от подножия склона, наконец-то «включает» тормоза и останавливается.

Оттуда же, из другой статьи:

Как показали дополнительные заводские тесты, которые ульяновцы провели после публикации АР, время отключения тормозной системы после длительной пробуксовки может достигать 10 секунд. Очень опасно! В чем причина? Заводчане отмалчиваются, но нам стало известно, что доводку программы управления АБС для Патриота компания Bosch поручила… студенту-практиканту. В принципе это обычная практика для крупных компаний, которым фирмы «третьего мира» заказывают какие-нибудь малобюджетные работы. Но странно, что ни тесты самой фирмы Bosch, ни заводские испытания УАЗа этой прорехи в программном обеспечении не выявили.

Решайте сами, а мне не хотелось бы оказаться на тормозном пути двухтонного внедорожника с “зависшей” АБС. К чести УАЗовских конструкторов, хочется добавить, что проблемы с раздаточной коробкой и АБС на более новых машинах уже решены, и вообще по количеству внедренных с начала производства доработок “Патриот” мог бы дать фору многим другим отечественным автомобилям (которые ездят с хорошо известными “косяками” уже десятки лет). К сожалению, далеко не все владельцы УАЗов 2007 года выпуска знают о дефекте АБС – многие “забивают” на дилерское техобслуживание сразу после покупки.

Наверное, от глюков прошивки УАЗа можно спастись, не выходя на улицу (а жратву покупать в “Утконосе”, хе-хе). Но кто гарантирует, что такой же студент-практикант не заложил подобную “мину замедленного действия” в микроволновку или гидромассажную ванну с десятком программ? Кто может поручиться, что стиральная машина не зальет соседей внизу, а музыкальный центр не врубит марш “Гори, еврей!”, когда рядом будут проходить озлобленные антифашисты? А как вы будете себя чувствовать, когда курьер из “Утконоса” на ваших глазах провалится в шахту лифта? И что вы будете делать, когда кондиционер с термостатом, сговорившись, решат вас немножко заморозить?

Многие, наверное, никогда не задумывались над этим, но современные методы разработки и тестирования программного обеспечения не гарантируют того, что это программное обеспечение будет работать безошибочно. Более того, сейчас “безошибочность” софта уже не является таким конкурентным преимуществом, как дешевизна и актуальность – соответственно, усилия разработчиков направлены на быстрый и недорогой выпуск ПО – как минимум, в самом широком сегменте рынка – приложениях для персональных компьютеров. В конце концов, всегда можно выпустить “патч”.

Эти методики проникают и в более “ответственные” приложения. Как заметил infowatch, в следующий раз прошивку для АБС будет делать аутсорсинговая фирма, “у которой в штате тот же один практикант плюс три юриста”. А затем – и индусы подключатся. Возможно, критикуемый в тамошних комментах “несовременный” метод, когда программу пишет собирающийся на пенсию дядечка, менее подвержен ошибкам, чем перекладывание ответственности, называемое модным словом “аутсорсинг”.

Но на мой взгляд, это не столь страшно, сколько постоянно растущая сложность встроенных систем. Если на УАЗе еще можно вытащить предохранитель и послать Bosch с ее практикантами в известном направлении (у нас нет дорог – одни направления), то в любой современной импортной машине компьютер еще и проверит уровень алкоголя в выдыхаемом воздухе, напомнит о необходимости пристегнуться, скажет “до сервиса осталось 100 километров”, а если водитель заснет за рулем, несмотря на алкотестер – еще и подложит подушечку. Надо ли говорить, что без этого компьютера вы просто не запустите двигатель?

Помните закон Брукса про количество связей в коллективе? То же самое верно и для числа связей между модулями программы. Предположим, программист пишет программу из 7 как-то взаимосвязанных частей (большее количество трудно держать в голове) – например, работающую с 7 какими-нибудь датчиками. Тогда между ними имеется 7*6/2=21 различная “связь” (например, “если опросить датчик А, то следующее показание датчика Б будет на 1 завышено”) – а это количество уже удержать в голове нельзя и можно допустить ошибку, просто забыв учесть какое-либо из них. Современные языки программирования и “соглашения о кодировании” позволяют свести количество связей между модулями к минимуму (предположим, к 6 вместо 21) – но о каких “паттернах проектирования” речь может идти в случае микроконтролера с парой килобайт ОЗУ? Если же уйти от “мелких” PIC и AVR к младшим ARM – то тут мы столкнемся со сложностью самой аппаратной платформы, не уступающей неплохому компьютеру 70-х годов. К тому же, если захочется использовать на этом ARM какую-нибудь адаптированную ОС – нет никаких гарантий, что в ней самой нет ошибок.

Не знаю, как будет называться OS/360 применительно к встроенному ПО (а скорее всего, каждый эмбеддер создаст “свою”, с которой и натрахается вволю), а обращу внимание еще на один прискорбный факт – сейчас практически нет эффективных способов проверки программного обеспечения на безошибочность. Как говорил Дейкстра, тестирование может лишь выявить ошибки, но не доказать их отсутствие. С другой стороны, столь любимое Дейкстрой формальное доказательство правильности программ совершенно непригодно для использования.

В мире hardware этот этап прошли в середине 90-х, после обнаружения ошибки FPU в первых Pentium. Тогда из обширного багажа знаний уехавших на Запад советских ученых были извлечены математические методы проверки работы электронных схем, не требовавшие перебора всех вариантов входных данных – и благодаря им удалось внедрить такое тестирование для всех новых разработок. Думаю, что и для программ существуют аналогичные методики – в конце концов, любая программа для компьютера представляет собой лишь конечный автомат, разве что с невероятным количеством состояний.

Интересно, каким будет программный сбой, который заставит внедрить “контроль качества” в разработке программ? Думаю, что даже если Берлускони улетит в Везувий на презентованном ему в свое время Путиным “Патриоте”, никто и не почешется. А вот упавший в Большой Каньон Обама – это уже поинтереснее. Подарит ли Медведев Обаме замечательный российский джЫп (с негротюнингом, разумеется)?


#define BEGIN {
#define END }


и после этого писать, как на богомерзком Паскале. А вот сегодня нашел логичное продолжение этого подхода:


// Находим среднее арифметическое
срака посередине стало шняга кагбэ ХУЙ да;
туды_сюды в_общем какая_то козёл стал норма; козёл почти фигня; козёл и_ещё_больше ну
начал
посередине присобачить шнягу кагбэ козёл да;
Подрыхнуть в_общем чуть_чуть ну;
кончил
посередине стало посередине хуякс фигня;
Слышь_это "\n\nСреднее арифметическое элементов массива: " эээ посередине эээ бля;


Надо применить такой подходец на практике, надо.

http://www.vedomosti.ru/newspaper/article/2010/07/22/241292

Автор утверждает, что:

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

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

аналитическая геометрия … даже в курсе мехмата выглядит как трогательный рудимент

Вот насчет этого трогательного рудимента я и хочу высказаться. Что такое “ангем” на мехмате (на первом курсе, кстати говоря)? Это декартовы координаты на плоскости и в пространстве, скалярное и векторное произведения, уравнения прямой и плоскости, аффинные преобразования, немного – о проективных координатах и проективных преобразованиях, наконец, классификация кривых и поверхностей второго порядка.

А вот теперь, вооружившись этими знаниями, сравним программу по ангему с вот этой шпаргалочкой:

http://pshenichny.livejournal.com/26954.html

Или вот с этой (секция “матемачиха и линейное щастье”):

http://blog.gamedeff.com/?p=64

О чем речь? О том, что кажущийся рудиментом ангем оказывается необходим, к примеру, программисту (и не только “игровому” – в любой области, где речь идет о каких-то координатах и какой-то графике). Хотя что может знать об этом человек, занимающийся экономикой и “чистой” математикой (точнее, дифференциальными уравнениями)?

Мне лично интересно: если начать обучение на мехмате сразу с линейных и гильбертовых пространств произвольной размерности (и не упоминать даже про R^n), кто после этого всего сможет сказать, откуда “растут ноги” у скалярного произведения (которое в произвольном гильбертовом пространстве считается “данным свыше” и никак не связано с длиной отрезка в обычном понимании)? Конечно, это красиво с математической точки зрения, но все-таки необходимы и простейшие примеры, возникающие из того же ангема, тем более, что они имеют практическое применение (с которым выпускник мехмата вполне может столкнуться).

PS Кстати, пользуясь случаем, хочу пнуть Javascript (точнее, ECMAscript) за отсутствие там возможности определить нормальные классы с нормальным operator+. Приходится либо писать такие извращения:

a = new SFVec3f(a1, a2, a3);
b = new SFVec3f(b1, b2, b3);

c = a.divide(2).add(b.divide(4)).multiply(3);

Кстати, как называется такая запись? Есть “инфиксная”: с = 3*(a/2 + b/4), есть “польская” или “постфиксная”, знакомая многим по программируемым калькуляторам: 3 a 2 / b 4 / + *, есть префиксная: * 3 + / a 2 / b 4, такое чудо я боюсь сравнивать с чем-то осмысленным.

…либо под каждый временный объект заводить переменную и писать так:

t1 = a.divide(2);
t2 = b.divide(4);
t3 = t1.add(t2);
c = t3.multiply(3);

Оба способа мне не нравятся, но ничего приличного сделать не получается :(

А вот в разработке ПО, видимо, можно сформулировать аналогичную вещь: “Возможности железа определяют методику разработки ПО”. Я об этом писал на примере Arduino, а вот еще пример, не менее поучительный. Недавно видел у belnetmon ссылку на статью о разработке ПО для мобильной операционки Android. Что же нам в ней советуют?

Ресурсы нужно экономить.
Нужно мгновенно выдавать реакцию на действия и поддерживать обратную связь с пользователем.
Производительность приложения главная цель. Нужно постоянно в процессе разработки оптимизировать производительность, не оставляя эту работу на потом.
Нужно измерять время выполнения, протоколировать и анализировать ход выполнения приложения, узкие участки кода, возникновения событий, выделение памяти, время жизни объектов. Что не измеряется, то нельзя оптимизировать.
Избегайте создания лишних объектов.
По возможности делайте методы статичными.
Используйте прямой доступ к полям вместо методов посредников.
Используйте static final для констант.
Не используйте enum там, где достаточно обычной переменной целого типа.

Все это вытекает из возможностей “железа”. Современные мобильники и КПК сравнимы по производительности с “персоналками” где-то десятилетней давности (причем очень “грубо” – например, над 24 доступными для процесса мегабайтами ОЗУ в 2000-м году посмеялись бы). Вспомним, что происходило в программировании в те далекие времена.

Бывшие паскалисты (спасибо дядьке Фаронову!) успешно освоили “программирование мышкой” в Delphi. Сишники разделились на два лагеря – первые вслед за паскалистами поклялись в вечной любви к фирме Borland и пользовались CBuilder, вторые забыли TurboC, как страшный сон, и переметнулись в стан любителей Microsoft Visual Studio 6.0. С++ использовался в варианте “C on steroids” – слова “инкапсуляция”, “наследование” и “полиморфизм” до многих доходили слабо, зато “заклинания” типа TForm1.OnClick() весьма понравились. Надо ли говорить, что полноценного стандарта C++ не было реализовано нигде, библиотека STL зачастую отличалась непредсказуемым поведением (например, в книжке Б. Кернигана и Р. Пайка “Практика программирования”, вышедшей в 1998 году, приводится пример, когда один из Windows-компиляторов С++ был снабжен ужасно медленной версией входящего в STL дека), да и поведение компиляторов иногда оставляло желать лучшего (кто помнит, почему не стоит писать “for(int i=0; i < N; i++)" в VC++ 6.0?). Языки программирования, отличные от C и Pascal, в нашем Отечестве не котировались (по причине неведомо кем культивируемой веры в крутость русских программистов), а в Буржундии к тому времени уже по достоинству оценили хоть и более медленные, зато более "безопасные" Java и Visual Basic. Кстати, там же, в Буржундии, как раз к 2000-му году вылезли из своих нор мамонты и динозавры - знатоки FORTRAN, поправили где надо год и отправились на заслуженный отдых, пока им в аду прогулы считают.

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

С другой стороны, "Практика программирования" Кернигана и Пайка тоже написана не на пустом месте и не потеряла актуальность в начале 2000-х (а то и сейчас, во всяком случае, многие похапешники после нее будут плакать кровавыми слезами). Несмотря на все замечательные возможности языков, очень большое внимание уделялось и производительности - часто даже в ущерб языковым возможностям (например, самописный hashmap часто оказывался существенно быстрее STL-ного, в результате чего мог считаться предпочтительнее).

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

PS А вот более развернуто мое мнение про Arduino:

http://community.livejournal.com/ru_radio_electr/759218.html?thread=12768946

На данный момент “мейнстримом” в плане динамического контента в вебе является Adobe Flash, правда, с начала 2000-х сильно сдавший позиции в пользу более универсального Ajax. Во всяком случае, извращения тех лет, вроде “сайтов целиком на Flash”, встречаются реже и реже – “изобразительные” и “технические” возможности Flash теперь реализуют с использованием HTML, CSS и Javascript.

Единственная область, где позиции Flash до сих пор сильны – это динамическая графика. Если, к примеру, текстовую “мочиловку” такого типа:

И плодть его содрыгнулыся от боли, и страшные черные птицы обклювали иго со всех сторон…
А злой волшебник Хухур достал иликрическую пилу и стал, весело хохоча, отпиливать ему ногу и отпилил ее три раза! Воистину!..
И он, хохоча, откусил ему глаз…
Злая колдунья острым ножом разрезывала плоть жертвы…
Его жилы, хохоча, хрустнули под ударом стальной дубины, и кровь толстым потоком затопила Долину Смерти…
Воистину прольется кровь, ибо да будет так!!!

…думаю, этого достаточно – все же видели игрушки типа “Бойцовского клуба”, где “мочилово” представляет собой длинный лог того, кто откусил кому яйца, в общем, если такую мочиловку попытаться снабдить графикой, то придется использовать Flash – нормальное рисование в Javascript+HTML совершенно недоступно (а когда все дойдут до поддержки HTML5 и элемента Canvas – я не скажу, да и никто не скажет).

В принципе, ничего против Flash я не имею – это довольно удобное средство отображения динамически меняющихся двумерных картинок. Но вот когда речь заходит о трехмерности…

Конечно, трехмерная графика с “оперативным” рендерингом на ПК применяется уже лет 20, вспомним тот же Wolfenstein 3D или Doom. Математическая основа 3D-графики прекрасно известна, и реализация “софтверного” рендерера не должна вызывать больших проблем при использовании любого языка высокого уровня (хоть того же ECMAScript). Недостаточная производительность скриптовых языков уже лет пять как не является проблемой, в чем нас пытаются убедить “веб-программисты”. Но это теория. А что мы имеем на практике? Для Flash существует десяток софтверных 3D-”движков”. Как говорит про них Википедия,

Скорость работы перечисленных движков зависит от используемой версии Flash Player, но в целом пока не достаточно высока.

Естественно, верить википедии на слово не стоит, а лучше убедиться лично, что я и проделал. Думаю, golergka прекрасно известна многопользовательская игра “Танки онлайн“, в 2009 году ставшая “прорывом года” в использовании Flash.

Немного поиграл в эту “техническую заслугу” отечественных флешеров. Как игра – вполне приятно, ничего против не имею. Но насчет поразительной 3D-графики – не соглашусь. Графика довольно примитивна и каким-то прорывом является лишь для браузерных игр. А достигается это просто невероятной ценой – на моей не особо “дохлой” машине загрузка процессора достигала, держитесь за стул, 60-70%. Неудивительно – уже лет 10-15 для обсчета сложных 3D-сцен применяют либо очень низкоуровневые языки (вплоть до “оптимизации” на уровне ассемблерных кодов), либо специализированные графические процессоры. Flash не имеет доступа ни к тому, ни к другому.

В общем, по уровню графики все это напомнило мне виденную еще в начале 2000-х “игрушку” с паровозиком, сделанную фирмой Parallel Graphics для демонстрации возможностей своего VRML-браузера.

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

Для работы потребуется VRML-плагин, причем желательно – Cortona 3D Viewer. Скачать его можно на сайте производителя.

PS Не надо понимать эту запись, как “Flash говно, VRML форева”. Просто мне хочется показать, что в разработке 3D-контента для веба существует не только современный мейнстрим (в виде Flash и софтверного рендера) и не только перспективные разработки (Silverlight, JavaFX), но и “хорошо забытое старое”. Кстати, поддержка асинхронных запросов к серверу в VRML тоже была прописана в стандарте 1997 года (в виде функции CreateVRMLfromURL()), просто применений ей тогда не нашлось.

UPD Почему-то Parallel Graphics не любит браузеры, отличные от IE, хотя их плагин в них прекрасно работает. Видимо, срабатывают ограничения из начала 2000-х.

Отсюда: http://www.bobhobbs.com/files/kr_lovecraft.html.

Вот, например, извращенная задачка в веб-программировании. Есть два сайта – один на ASP.NET под IIS, другой на PHP под Apache. Первый крутится по адресу, к примеру, http://webserver:80/, другой – http://webserver:8080/. Задача – на первом сайте есть ссылка, открывающая окошко со страничкой второго сайта, оттуда надо передать JavaScript-ом какие-то данные в родительское окно. Думаю, все видели вот такие “палитры”, так что представить в состоянии.

Разница в том, что “палитра” расположена немного по другому адресу и может подпадать под блокировку “кроссдоменной” передачи данных. Причем самое интересное – это то, что каждый из трех популярных браузеров понимает “кроссдоменность” по-разному.

Internet Explorer всех версий вообще не делает различий между domain.com:80 и domain.com:8080. Соответственно, все работает правильно.

Firefox считает такие “домены” разными и по умолчанию блокирует передачу. Правда, спасает вот такое заклинание, произнесенное перед открытием “палитры” в родительском окне и в дочернем – до передачи данных:

document.domain = document.domain;

Смысл заклинания совершенно необъясним, поэтому “это нельзя понять, это надо запомнить”.

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

Вопрос фанатам “альтернативных браузеров”: и чего же вы добились, обвиняя Microsoft и Internet Explorer во всех смертных грехах, начиная от монополизма? Похоже, только того, что в каждом из браузеров надо применять свои “костыли и подпорки”, а любая программа на JavaScript начинается с разбора трех случаев.

PS К сожалению, ни прикрутить ASP.NET к Apache, ни PHP к IIS нереально – апачевский модуль для ASP.NET совершенно не хочет работать, а PHP-шная часть сайта существенно использует апачевские возможности по работе с .htaccess.

А может, этим деятелям хочется привязать народ к своей софтине – ведь XML в определенном смысле самодокументирующийся, в отличие от. Главное – не раскрывать (всех) секретов своего глючного формата, хе-хе. Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious.

PS Все надежды жадных до денег разрабов (да-да, документация “без гарантий совместимости с последующими версиями” за бабло) перечеркивает WinHEX. А кроме того, умение с умным видом смотреть на файл в шестнадцатеричном виде вызывает неподдельное уважение у всяческих PHP-программистов, особенно если сопровождать сей процесс высказываниями: “ага, это у нас 16-битное целое” :)

Почему-то совершенно незамеченной в то время осталась возможность VRML-плагинов взаимодействовать со страничкой, в которой они находятся. Web 1.0 тихо исчез, уступив место для динамических сайтов с JavaScript, DHTML и AJAX (все эти три слова означают примерно одно и то же, разница в гламурности). VRML вообще не отличался особыми красотами, анимация там была в зачаточном состоянии (ЕМНИП, делалась она средствами реализованного там же JavaScript, но писать всякие “эффекты” приходилось практически вручную), а о возможности изменения 3D-сцены по полученным откуда-то “снаружи” командам никто не задумывался.

Теперь – о своем опыте прикручивания модного AJAX к немодному VRML. Конечно, можно было бы выбрать в качестве 3D-среды более современный X3D – дальнейшее развитие VRML, но для него попросту нет приличных плагинов для браузера. Для VRML я использовал Cortona 3D.

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

Естественно, задача очень легко решается, если отказаться от использования всяких VRML-ных хитростей, а сделать все с использованием обычного HTML и AJAX. С другой стороны, можно управлять VRML-сценой через JavaScript в браузере. Почему-то эта возможность VRML используется настолько редко, что о ее существовании в рунете не упоминают, а в буржуйских интернетах удалось найти лишь перепевы курсовой работы по программированию в университе Нэпира, что находится в доброй старой Англии. Надо ли говорить о том, что про объединие AJAX и VRML не написано вообще ничего? Решается же вышеописанная задача буквально парой десятков строк кода.

Конечно, можно решить ту же задачу тысячей разных способов. Например, можно отображать трехмерные объекты с использованием Flash. Можно использовать не VRML и не V3D, а какой-нибудь гугловский O3D или даже COLLADA. Пожалуй, всерьез использовать это могут только разработчики браузерных говноигр. Кстати, графика в современных VRML-плагинах вполне “на уровне” и не уступает многим более серьезным играм. Ну что, как насчет Lineage прямо в браузере?

PS Кстати, Cortona3D не работает с примером Turtle Graphics. Там требуется совсем небольшая доработка, но раскрывать этот маленький секрет я пока не буду.