`

Schneider Electric - Узнайте все про энергоэффективность ЦОД


СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Сразу два события в мире open source

Крупнейший репозиторий и набор сервисов для разработчиков программного обеспечения с открытыми исходными текстами, SourceForge, провёл очередное голосование среди участников сообщества для выявления лучших проектов.

Примечательно даже не то, что в лидеры попали программы для платформы Windows. И даже не то, - какие именно программы, это-то  как раз вовсе и не примечательно, потому что и архиватор 7-Zip, и "запускалка" Launchy (в каком-то смысле аналог QuickSilver из мира MacOS X и нового меню Start из Windows Vista), в дополнительных рекомендациях и представлениях не нуждаются (я сам к Launchy давно привык, и от этой привычки не избавило даже появление Vistart - точного аналога великолепного Start-меню Vista). Примечательно же то, что и 7-Zip, и Launchy - проекты не кросс-платформенные, а "чисто Windows", при этом активно живущие и даже развивающиеся (хотя, казалось бы, куда уже развиваться 7-Zip...).

И просто как по заказу, практически синхронно, Microsoft открыла... open source раздел корпоративного сайта. Ответов на часто задаваемые вопросы (ну мы же помним, что RTFM, RTFM и ещё раз - RTFM!) и самих вопросов здесь немного, но они заслуживают внимания.

"Open source - вовсе ни прихоть индустрии, ни серебряная пуля. Методы разработки, обычно объединяемые термином "open source",  дают и потребителям, и разработчикам некоторые дополнительные ко многим доступным в разных технологических экосистемах, возможности...

750 тысяч партнёров (Microsoft) во всём мире... зарабатывают суммарно $8 на каждый заработанный Microsoft $1...

...более 79 тысяч open source приложений создано разработчиками для платформы Windows (репозитории SourceForge и CodePlex)..."

 

Что же происходит? 

Очевидно, что огромная пользовательская база ОС семейства Windows представляет не только интерес для амбициозных разработчиков, но и даёт возможность прямо зарабатывать авторитет, а, косвенно,  - и деньги, - на популярности своих бесплатных open source программ. Также очевидно, что битва за десктоп существует разве что в отдельных горячих головах - на деле же это не битва, а затянувшаяся возня с сезонными обострениями (я не выдумываю - почитайте "исповедь" автора популярных "настольных" пачей ядра Linux Кона Коливаса "Почему я ушёл", и это только одна сторона медали). Соотвественно, - свято место пусто не бывает, и для разработчиков open source ПО "настольного" характера платформа Windows неизбежно будет становиться всё более интересной. Платформы *nix, в свою очередь, будут неизменно популярны среди разработчиков системного ПО и сервисных (серверных) программ - это видно уже сейчас, по голосованию на SourceForge.

Кстати, я лично с удовольствием проголосовал бы за (кроме Launchy) виртуальный десктоп для Windows - VirtuaWin, программу стабильно развивающуюся (особенно приятно, что разработчики быстро реагируют на сообщения об ошибках и с каждой новой версией программа работает всё лучше и лучше) и очень неплохо делающую то, что она должна делать. И ещё - за менеджер системного буфера обмена, Ditto - это также образцовая open source программа, без которой трудно обойтись.

Замечательная штучка, просто замечательная!

У операционных систем Oberon и Plan 9 есть одна очень важная общая черта - их пользовательский интерфейс строится на модели "любой фрагмент текста может трактоваться как множество команд". Для реализации этой модели было использовано сквозное проектирование (всей системы - в случае Oberon, текстового пользовательского окружения Acme - в случае Plan9).

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

Теперь, благодаря стараниям Леона Бамбрика (Leon Bambrick) и идеям Дона Сайма (Don Syme), все пользователи Visual Studio получили доступ к этой "фишке" двух замечательных систем из совсем другого мира.

Итак, -

  • если вы используете VS 2005, - распакуйте в каталог "C:\Documents and Settings\{Your Username}\My Documents\Visual Studio 2005\Addins" содержимое этого файла (если указанного каталога на вашей машине нет, - создайте его самостоятельно);
  • если вы используете VS 2003, - инсталлируйте это приложение.

Собственно, - всё. Теперь вы можете выделять любой фрагмент кода и одной клавишей передавать его на исполнение!

Я беззастенчиво утянул с сайта Бамбрика эту анимированную картинку только потому, что идея утилиты Exec-Inline мне понравилась сразу, это любовь с первого взгляда, а ближайшая инсталляция Visual Studio - дома, так что не вытерпел:

Замечательная штучка, просто замечательная!

 

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

На всякий случай - все ссылки на связанные с утилитой ресурсы (в обратном хронологическом порядке):

анонс версии для VS 2005;

анонс версии для VS 2003;

анимированный скриншот и краткое описание принципа работы.

Замечательная штучка, просто замечательная!

Запасайтесь "минусами" для оценки этой записи

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

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

Несколько неожиданное начало, не правда ли? То ли ещё будет...

Предположим, что вам показали следующий фрагмент кода:

00  if (условие_1)
01        goto got_lock;
02  if (условие_2) { /* тело блока */ }
03  got_lock: функция_1();

и спросили, - можно ли избавиться в этом фрагменте кода от goto?

Что бы вы ответили, точнее, - не что, а как бы вы стали отвечать на такой вопрос?

Мне кажется естественным, что ответ на него во многом зависит от кода, находящегося за пределами фрагмента - вполне возможно, что goto здесь совершенно логичен и даже полезен. В конце концов, классики времён структурного программирования боролись не с самим оператором goto, а с бесконтрольным и тотальным его использованием.

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

Так в чьей голове мог зародиться такой ответ на совершенно невинный вопрос:

"Вам промыли мозги люди из CS (Computer Science), которые думают, что Никлас Вирт действительно знает, о чём говорит. А он не знает. У него нет никаких (beep) знаний".

Знаете в чьей?

Линуса Торвальдса.

Я же предупреждал, - заготавливайте минусы для этой заметки.

Вот ветка обсуждения "Using goto in Kernel Code", в которой, собственно, эта фраза и прозвучала (второй ответ Торвальдса). Прочитайте-прочитайте, а выводы делайте сами.

Я своих выводов не скажу, я Плутарха лучше перечитаю в очередной раз.

Надо же хоть чем-нибудь быть недовольным

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

Хороший пример, - "новое" пользовательское рабочее окружение (десктоп, если хотите) Pyro.

Начнём с того, что новизны в нём, уж извините, но - кот наплакал.

Потому что вот эти диалоги в ОС Windows на моей памяти были и в старом добром "винтукее" (а то и раньше, просто с более ранними Windows я дела не имел, поэтому гадать не буду):

Надо же хоть чем-нибудь быть недовольным

Пару раз для развлечения я сам такое делал - создавал десктоп из настроенной персонализированной страницы одного из развитых web-сервисов. И тут же от этой "продвинутости" отказывался ввиду бессмысленности и неудобства.

Правда, разработчики Pyro пошли дальше обычного Active Desktop, добполнив и без того не очень востребованную идею (не видел ни разу, чтобы кто-то реально использовал возможности диалогов с приведенного выше снимка экрана) совершенно гениальными решениями. Например, - отрисовкой окон приложений... фактически средствами лежащего в основе Pyro браузера (это Firefox). Если быть точным, то Pyro десктоп создаёт DOM-описание настольного окружения с окнами работающих приложений и "отдаёт" его браузеру для отображения.

Какой-то смысл в таком "изящном" решении мог бы быть, если бы браузер мог функционировать без расположенной "под ним", на системном уровне, X Window, - в таком случае хоть извращённо-теоретически  можно было бы использовать идею для "тонких клиентов" (извращённо опять же потому, что для тонких клиентов есть более адекватные решения). Но и такой возможности нет.

В общем, в блоге разработчика Pyro совершенно прекрасен первый же комментарий (некоего Peter) к анонсу изделия:

Oh boy! A window manager which leaks more memory than metacity! :D

Ох, парень! Наконец-то оконный менеджер, жрущий больше памяти, чем metacity! :D

По моему мнению эта курьёзная поделка не заслуживает более серьёзного обсуждения, но злые блоггеры и мелочами кормятся, и вот ещё одно мнение, которое я во многом разделяю - "Оставьте web в браузере!". Кстати, - да, оставьте!. И пользователей в покое - тоже. А то только лопнул мыльный пузырь "всеобщих тонких компьютеров", как началась новая волна - web2.0-приложений.

Очень новое - это очень хорошо забытое очень старое

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

Итак, - Burrogh. Конечно, - знаменитый Барроус, один из первых серьёзных западных производителей вычислительных систем, оборудование которых поставлялось в СССР официально, а не чёрным импортом, через третьи страны, сквозь кордоны CoCom (было такое образование во времена [пред?]последней холодной войны).

Модель 5000. Машина, специально созданная для поддержки на аппаратном уровне ПО, созданного я языках высокого уровня - Algol и Cobol тогда уже были, и по сей день кажутся далеко не такими плохими языками.

Особенности архитектуры центрального процессора: вместо регистрового банка - аппаратно реализованный стек, с доступными для каждой команды вершиной и лежащей под ней ячейкой, причём как ячейками длиной в слово, так и двойными, - для команд расширенной точности. Посдсистема памяти также преподносит сюрприз - каждое машинное слово B5000 сопровождалось группой из трёх битов - меткой слова (word tag), определяющей класс, к которому относится это слово. Например, - для кодов команд был свой класс, при этом на аппаратном уровне как коды программы были защищены от модификаций, так и было запрещено передавать управление на блоки данных.Три бита позволяли описать восемь классов слов, - и кроме "кода", к этим классам относились данные одиночной и двойной точности, а также специальные "управляющие коды", например, вынесенные в отдельный класс команды манипуляции аппаратным стеком. Метки слов, используемые как модификаторы команд, позволили реализовать самоконфигурирующиеся машинные команды, то есть, - единая команда ADD определяла классы своих операндов (например, один из них - число с одинарной точностью, второй - с двойной) и затем уже выполнялась. Забавно, что использование меток слов приводило всего к 6%  перерасхода оперативной памяти (исключительно дорогой в те времена), - сегодня 6% от 1GB,  составляющие прримерно 64 MB, стоят сущие гроши (центы?).

Но главной архитектурной особенностью машины было то решение архитекторов Барроус, из-за которого машина получила кодовое название "The Descriptor". Дексриптор - специальная команда, обеспечивающая аппаратно поддержанный (!) механизм доступа к областям памяти с автоматической проверкой невыхода за границы доступа и битовой меткой, индицирующей факт загрузки области памяти в ОЗУ. Иными словами, - фактически с аппаратной поддержкой оверлеев и... виртуальной памяти.

Изюминок у B5000 было немало. Чего стоит, например, машинная команда завершённой транзакции "чтение-запись слова данных", облегчающая реализацию семафоров в многозадачных приложениях, Барроус даже продумал интерфейс к этой команде (и сопутствующим) из языков высокого уровня - тип данных "событие" (event) и генерируемые по требованию программиста программные прерывания. А машинная команда... итератора связных списков LLLU (Linked List LookUp), также поддержанная аппаратно?

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

Конечно, - виноваты в этом масоны, потому что они виноваты вообще во всём.

Шучу.

Одна из главных причин - в стековых машинах очень трудно реализовать развитые механизмы оптимизации потока вычислений, доступные разработчикам регистровых архитектур (исполнение out of order и проч.). Соответственно, - как только достигается предел тактовой частоты, возникают нюансы с производительностью.

Правда, физические стековые машины так и не достигли предела тактовой частоты.

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

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

Опять о языках, точнее, - об одном языке

Ещё точнее, - о несуществующем языке.
 
Я люблю C. Потому что это действительно хороший язык (хоть и ужасный, конечно). И очень много кто ещё любит C – иначе бы сегодня не было столько разных производителей С-компиляторов для столь разных платформ (от 8-битовых контроллеров до 256-битовых спецвычислителей). C пережил многие языки, которые некогда считались панацеей от всех болячек. C пережил легенду под названием Ada – уже и программное обеспечение пассажирских самолётов (можете представить себе степень надёжности, требуемую в этой области) мирового класса пишут на C, вот свидетельство:
C пережил Lisp, Prolog и Smalltalk – сейчас эти языки существуют, но ничего значимого на них давно уже не пишется (в сравнении с пишущимся на C).
Итак, C прожил долго, счастливо, и будет жить ещё долго. Потому что он нужен, платформенно-независимый высокоуровневый ассемблер, он очень нужен. Но если смотреть на С именно как на ассемблер обобщённой вычислительной машины традиционной архитектуры, есть некоторые претензии.
Мне лично бы хотелось, чтобы в высокоуровневом ассемблере были как минимум две конструкции, отсутствующие в C: суффикс, ключевое слово at и суффикс, ключевое слово when.
at позволяет указать физический адрес размещения объекта в памяти, например:
volatile unsigned int PORT_A at 0x0002 ;
что значит – слово (размер – unsigned int для целевой платформы), расположенное по адресу 0x0002,  является отображённым на память регистром порта ввода-вывода A. Подобных регистров в самых разных архитектурах необъятное количество.
Ключевое слово when, по сути, являющееся модификацией at и относящееся исключительно к функциям. Оно позволяет задавать обработчики прерываний без обращения к ассемблерному коду:
void Signal_From_Gyro( void ) when INT_11 ;

То есть, - это указание компилятору и редактору связей, что функция Signal_From_Gyro() является обработчиком прерывания INT_11 (на деле это должна быть предопределённая константа), соответственно, - для этой функции должен быть сгенерирован специфический код и указатель на функцию должен быть помещён в ячейку памяти, где «сидит» адрес обработчика прерывания INT_11.

В принципе, можно обойтись и без when, только c at, но в таком случае программист будет вынужден городить ещё больше низкоуровневого машинно-зависимого кода в тех случаях, когда с этой задачей прекрасно может справиться генератор кода компилятора.

Ещё хотелось бы, чтобы серьёзно «прошерстили» последний стандарт языка, выловили все оставленные на откуп разработчикам конкретных реализаций компиляторов неоднозначности (ведь многие из них тянутся со времен Кернигана и Ричи), и постарались от них избавиться. Причем так, чтобы грамотный прежде написанный код всегда работал. Во многих случаях это возможно.

Например, жёсткое правило, что при операциях присваивания (lvalue = rvalue) сначала генерируется (и исполняется) код вычисления rvalue, затем – код вычисления lvalue, и только после этого выполняется собственно присваивание, устраняет много мелких семантических пакостей (и никак не влияет ни на эффективность генерируемого кода, ни на исполнимость написанного ранее – потому что из-за неоднозначности в нынешнем стандарте языка такой код «с нюансами» заслуженно считается неправильным).

Вообще, неплохо было бы создать гибрид семантики современного алголоподобного языка (Modula-2 или Oberon-1), самой приятной части C-синтаксиса и, непременно, - адресной арифметики, - получилось бы очень «вкусно».
По-моему, Никлас Вирт мог бы создать язык действительно взрывной популярности, если бы пошёл по этому пути. Кстати, -  совершенно необязательно делать такой язык объектно-ориентированным, хоть бы и в минимальной степени (как Oberon-2). Причина одна – для объектно-ориентированных языков крайне трудно создавать верификаторы.
Ну а насчёт функциональных языков… Системы управления реального времени, где сейчас царит C – область volatile-переменных и обработчиков прерываний. Чистым функциональным языкам эти понятия – как серпом по… А сложные абстрактные построения, которые призваны устранить это отчуждение изящной чистой математики от безобразной реальности, сами по себе настолько безобразно уродливы (как те же монады), что уж лучше возиться с императивным ассемблером. Было бы иначе – разработчики ПО Airbus предпочли бы функциональный стиль - уж они-то своё дело знают, будьте уверены.

Ruby. 001.

Этим стулом мастер Гамбс начинает новую партию мебели. Да. Итак, начинаем потихоньку о Ruby.

""Вскоре после того, как я впервые столкнулся с компьютерами в начале 80-х годов, я стал интересоваться языками программирования. С тех пор я стал "языковым гиком" (я бы переводил это слово как "шизанутый фанат", АЗ).

В 1993 году... я не был удовлетворён возможностями существующих (скриптовых) языков, таких как Perl или Python. Я не мог отыскать идеального языка, поэтому решил создать свой.

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

Поэтому, при проектировании Ruby, оринетированного на использование человеком языка программирования (human-oriented language), я следовал принципу Минимума Сюрпризов. Я считаю, что всё, что не является для меня сюрпризом (то есть, - неожиданностью, и не всегда приятной, АЗ) - это неплохо. В результате пользования этим принципом, мне удалось придать языковым конструкциям ощущение естественноcти от программирования на Ruby, даже ощущение радости от этого занятия. Многие программисты всего мира подтверждают справедливость этого моего утверждения.""

Юкихиро "Матц" Матсумото

автор Ruby

001. Установка

Пока обойдёмся без лишних вопросов, ограничимся готовыми ответами. Инсталлируем Ruby из бинарного файла (если для Windows) или собираем (из портов) - если для *nix. Так как в *nix все эти мелкие детали должны быть тривиальными для пользователя (иначе зачем он вообще пользует *nix), я их даже не буду касаться.

После установки в Windows бинарного дистрибутива вроде получается всё что нужно и как нужно (не зря он называется "инсталлятор одним кликом"). Но. Изучать язык лучше в интерактивном режиме - это очевидно. И Ruby располагает всем необходимым для полноценной интерактивной работы - таким себе собственным шеллом. Если вы установили Ruby, например, в каталог C:/ruby, то полное путевое имя файла этого шелла будет следующим: c:\ruby\bin\irb.bat. Пока не будем заглядывать в его содержимое (там всего несколько строк).

Я бы посоветовал запускать irb в ConEmu (несколько слов об этой программке было сказано в ранней записи блога). Причём делать это так: тырцнуть в иконку в левом верхнем углу ConEmu, выбрать Settings.

Ruby. 001.

Появится окно настроек консоли.

Ruby. 001.

В нём нам действительно важно прописать командную строку  того, что будет запущено при запуске ConEmu. В поле Command Line надо поместить следующее: C:\ruby\bin\irb.bat -r irb/completion
Можно (я бы сказал и нужно) выбрать шрифт Consolas, размер 14x0 - но это на любителя.
После этого жмём кнопку "сохранить установки" (save settings), и можно считать рабочее место минимально подготовленным к изучению Ruby.

Что мы сделали?
При запуске ConEmu программа передаёт cmd.exe указанную нами командную строку, соотвественно, - запускается интерпретатор Ruby в режиме интерактивного шелла. При втором (после конфигурирования) и последующих запусках CmdExe мы получим в своё распоряжение Ruby-шелл. Но в командной строке есть ещё какие-то параметры. Они указывают шеллу, что мы инициируем механизм автодополнения.

Теперь сразу опробуем и шелл вообще, и механизм автодополнения.
Введём арифметическое выражение 1+2 и нажмём Enter. Интерпретатор ответил результатом сложения - очень хорошо, никаких сюрпризов.

Ruby. 001.

А теперь попробуем понять, что такое эта самая цифра "три" в Ruby. Введём два символа 3. и дважды нажмём Tab - интерпретатор расскажет нам всё о том, что цифра 3 позволяет делать с собой. Иными словами - мы получаем перечень методов, которыми обладает объект "цифра" в Ruby.

Ruby. 001.

Механизм автодополнения работает и с именами методов, например, если ввести 3.to_ и дважды нажать Tab, получится более короткий список имён методов, имена которых начинаются с подстроки "to_".

Ruby. 001.

Теперь попробуем вполне очевидную по названию команду (принцип Минимума Сюрпризов!) to_s, в имени которой угадывается "в строку" (to string) - набираем 3.to_s, жмём Enter, убеждаемся, что результат похож на строку, содержащую один символ "3".

Ruby. 001.

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

Второй вывод менее очевиден. Мы только что имели дело с цифрой три. С литералом. Или, если хотите, - просто со значением. Не присвоенным никакой переменной с типом "число", не помещённой ни в какой типизованный "контейнер". И, между тем, у объекта "цифра три"  есть свои методы. Целая куча. Это главная особенность Ruby как объектно-ориентированного скриптового языка - тип (как множество операций, допустимых для данного объекта) является частью самого объекта, а не переменных.

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

До встреч в эфире,
АЗ

Забытая, совсем забытая тема

Об этом уже и говорить как-то неудобно, после финансовых перипетий компании Xybernaut. О wearable-компьютерах. То есть, - компьютерах настолько персонализованных, что их носитель не расстаётся с ними в идеале никогда.

Итак, с одной стороны, имеем:

  • единственный серьёзный производитель wearable-компьютеров, компания Xybernaut, чудом и не без скандала избежала банкротства;
  • ресурс по wearable-компьютерам Массачусетского технологического не обновлялся с 2005 года.

С другой стороны, -

  • розничная стоимость компонента, некогда считавшегося ключевым элемента wearable-компьютера, микродисплея, упала ниже отметки $100;
  • микроконтроллеры с ядром ARM, с маленьким энергопотреблением, с приличной тактовой частотой, и в копеечном ценовом диапазоне, сегодня не выпускает только ленивый;
  • стоимость энергонезависимой памяти (flash) также резко упала, а такая память носимому персональному компьютеру просто необходима.

В результате же никаких wearable-компьютеров не существует. За исключением разве что настоящих курьёзов и устройств более чем сомнительной полезности (особенно при учёте цены).

В чём же дело?

По-моему, - дело вовсе не в компонентной базе. Дело в приложениях, - даже не столько в них, сколько в идеях приложений. И в системном ПО, которое должно радикально отличаться от "традиционного" из-за особенностей этих самых идей.

Вот, например, хорошая идея "глоггинга" - непрерывной видео-фиксации всего, попадающего в поле зрения носителя wearable-компьютера. Кстати, глоггеры уже есть, и даже делятся своими "глогами". Пока это даже ещё не идея, а так, - зародыш. Но если добавить к ней позиционную информацию, высокоуровненвые сервисы типа Google Maps, мониторинг физического состояния носителя, мониторинг бесконтактного информационного поля (например, ZigBee-сигналов от других носителей или вообще ZigBee-меток, встроенных в объекты, - представьте себе картину в музее, в которую посетители могут сбрасывать свои впечателения, цитаты, и знакомиться с оставленным другими посетителями "наследием"), и ещё Бог знает что - ведь получится очень интересная штука. А программы интерактивного распознавания слитного текста, когда машинка в случае нечёткого распознавания слова переспрашивает носителя? А средства распознавания жестов, которые можно использовать вместо клавиатур и указательных устройств? А уличные беспроводные "доски объявлений", в которых можно оставить сообщение всем, желающим прочитать их содержимое - я не знаю, зачем всё это может быть нужно, но пока такого нет, никто так и не узнает, зачем.

Вот чего, по-моему, не нужно wearable-компьютеру, так это:

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

Ни одна современная ОС, к слову, не создавалась именно для таких задач - некоторые системы можно насильно для них приспособить (хорошо ли, плохо ли - не вопрос, потому что ответ дан практикой), но это не дело.

И ещё одна возможность заявить о себе

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

Соревнование в этом году называется Mobile Rules! и состоит из двух "забегов". В первом будут соревноваться разработчики (программисты), создающие для платформы Nokia приложения, относящиеся к четырём классам:

  1. многопользовательские игры и игры с подключением к централизованным сервисам (connected games);
  2. мультимедийные приложения;
  3. корпоративные задачи;
  4. infotainment (информационно-развлекательные приложения).

Во втором забеге участвуют бизнесмены, стартапы и академические институты. И соревнуются здесь не продуктами, а бизнес-планами.

Призы скромны - миллионов никто не обещает, из материального в их перечне - разве что мобильные устройства производства Nokiа.

Зато победители получают возможность использовать ресурсы Nokia в продвижении своих программ и идей, а вот это уже дорогого стоит.

Просто и не без вкуса

Конечный автомат - абстракция очень полезная и удобная. Особенно в программировании.

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

Поэтому программка VAS (Visual Autoamata Simulator) показалась мне очень привлекательной. Она кросс-платформенная (Java), бесплатная, с открытыми исходными текстами, но это всё - мелочи.

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

Главное, - что VAS позволяет заставить нарисованные автоматы работать. Если вы задали алфавит и конечный автомат, - можете предъявлять ему строки и проверять реакцию автомата на них. А можете, по желанию, проводить пошаговую отладку (инициируется Ctrl-D, новый шаг - Ctrl-F), отлично отображаемую подсветкой элементов диаграмм.

Кроме того, VAS позволяет автоматически преобразовывать недетерминированные конечные автоматы в детерминированные.

А еще VAS умеет имитировать машину Тьюринга (эта возможность, конечно, больше нужна студентам).

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

В общем, - весьма небесполезная вещь, особенно для документирования и отладки на уровне логики работы всяких нетривиальных (и, напротив, - тривиальных) фрагментов кода. Например, - распознавания классов битовых строк или строк символов.

Просто и не без вкуса

 
 
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT