пятница, 24 сентября 2010 г.

Воистину пятничный баг

Я сейчас занимаюсь разработкой модуля видеонаблюдения за спящими пациентами (ибо в сфере медицины сна) под .NET при помощи libvlc (ядра небезызвестного плеера VLC). И все бы ничего, но иногда VLC конфликтовал с Windows, в результате чего возникал BSOD (Blue Screen Of Death). В скором времени я набрел на топик на форуме VLC с описанием этой проблемы. Если отбросить технические детали (по ссылке их предоставлено сполна), то проблема решалась установкой для заданного ключа реестра значения IMMLoad из 1 в 0. Сказано-сделано: установление ключа интегрированого в инсталлятор - бага пофикшена.

Однако некоторое время спустя тестеры очень расстроили меня сообщением о том, что они снова воспроизвели BSOD (тестеры у нас классные, меня сам факт расстроил). Трудно описать мое удивление, когда в реестре я обнаружил значение LoadIMM (похож на IMMLoad, правда?), выставленное в 1. Меняем на 0 - и все опять хорошо. Я очень люблю симметрию, но такой подставы не оценил :)

Оказывается, на разных версиях Windows используется либо IMMLoad, либо LoadIMM (с очень высокой вероятностью, делают они одно и то же). Мы с коллегами немного по-пятничному пофантазировали на тему того, что значений может оказаться больше (хотя я очень надеюсь, что это не так):



Приятных вам выходных!

четверг, 23 сентября 2010 г.

Открыты исходники проекта BeAware

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

Однако недавно ко мне обратился человек с предложением присоединиться к разработке BeAware. Я был не против, но, к сожалению, человек оказался из Java-стека (что характерно для семантики в целом), и не захотел разрабатывать проект под .NET. Однако это подтолкнуло меня к идее открыть исходники и попытаться найти людей, которые продолжат развитие проекта (по нему может защититься еще не один магистр), и которым я впоследствии смогу полностью его передать.

Итак, прошу любить и жаловать: http://code.google.com/p/beaware/

Изменение структуры онтологии в BeAware

В одном из предыдущих постов я оставлял список открытых вопросов по онтологии. Процитирую его:

Список открытых вопросов по структуре онтологии:
1. Сейчас событие "музыкальный концерт" является наследником "развлекательного события". Однако, на мой взгляд, концерты классической музыки претендуют на звание культурного события. В рамках текущего подхода, когда корневыми событиями (корневыми в визуальном плане: все события являются наследниками базового класса Event) являются события, относящиеся к какой-либо сфере жизни, было бы логично выделить класс "концерт классической музыки" и сделать его подклассом "культурного события". Однако мне кажется, что такой подход будет путать пользователей (и концерты классической музыки будут по ошибке создаваться как экземпляры "музыкального концерта"), поэтому решение этой проблемы пока под вопросом.
2. У события "Театр" есть свойство "вид театрального искусства" (не придумал более лаконичного лейбла). Стоит ли оставить это так, или лучше выделить оперу, баллет и т. д. в подклассы класса "Театр"? С одной стороны, это загромоздит онтологию, с другой, - текущая реализация не позволит нам в будущем добавить дополнительные свойства, например, для балета (технически-то сможем, но юзабилити такого решения представляется мне сомнительным).
3. Есть ли какая-то стандартизированная классификация наук? Текущая иерархия для свойства "вид науки" взята из английской википедии, но, во-первых, она довольно куцая, а во-вторых, слабо коррелирует с классификацией, принятой на постсоветском пространстве.
4. Не приложу ума, куда разместить событие "выставка" (exhibition). Выставки бывают разные: картин, собак, IT (софт, железо, игры) и т. д.
5. У меня есть большой соблазн создать корневую категорию IT. Пока я с ним успешно борюсь... но встает более серьезный вопрос: по каким критериям выделять корневые события?

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

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

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

С типом события вышло сложнее. Раньше на первом уровне располагались сферы жизни, а на нижележащих - конкретные типы событий. Пришлось выделить два свойства: тип и категория события (те самые сферы жизни). Теперь, например, проблему с концертом классической музыки можно решить, создав событие с типом концерт и двумя категориями: развлекательной и культурной.


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

воскресенье, 25 июля 2010 г.

Делай, как мы!

Внимание, в этом посте содержится наглая, ничем не прикрытая пропаганда здорового образа жизни!

Недавно кто-то из коллег обратил внимание на то, что в штате нашего томского офиса компании MCC численностью 9 человек нет ни одного курящего. Интересное совпадение(?) на фоне общей статистики.

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

В общем, делай, как мы - и умрешь здоровым :)

суббота, 17 июля 2010 г.

Корни теории относительности (Relativity and its Roots)

Забавная штука переезд. На фоне общей рутинности этого процесса, нет-нет да найдется что-нибудь "спрятавшееся", затерявшееся и т. д. Порой случаются очень интересные находки :) В ходе моего недавнего переезда одной из таких находок стала книга "Корни теории относительности" (англ. "Relativity and its roots"). Я с трудом вспоминаю, откуда у меня эта книга... Почему-то кажется, что мне подарил ее преподаватель физики на младших курсах, но не припоминаю, при каких обстоятельствах. Отчетливо помню, что несколько лет назад я хотел прочитать ее, но положил на полку и... и вот.

Было несколько причин для того, чтобы перенести "Корни теории относительности" в верхнюю часть моего ToRead-списка.

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

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


Примечание

Квантовая гравитация — направление исследований в теоретической физике, целью которого является квантовое описание гравитационного взаимодействия, а в будущем — объединение гравитации с остальными тремя фундаментальными взаимодействиями, то есть построение «теории всего».

Два основных направления, пытающихся построить квантовую гравитацию, — это теория струн и петлевая квантовая гравитация.

А в-третьих, просто приятно иногда отвлечься от айтишной литературы и почитать что-нибудь художественное или научно-популярное.

В книге, написанной одним из немногочисленных учеников Эйнштейна - Б. Гофманом, автор не только повествует о специальной и общей теориях относительности Эйнштейна, но и рассматривает череду предпосылок к ним от древшнейших времен до конца 19-го века. По пути к описанию работ Эйнштейна автор пишет об Аристархе, Копернике, Галилее, Ньютоне, Фарадее, Максвелле и многих других. Повествование очень интересное и порой даже захватывающее. А занимательные факты и разнообразные цитаты под авторством великих умов не дадут читателю заскучать даже в самых сложных частях книги.

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

У меня в руках оказался перевод издательства "Знание" 1987-го года (на Amazon'е есть два издания оригинала этой книги: 83-го и 98-го годов). Мало того, что перевод превосходный, так он еще и дополнен полезными комментариями переводчиков и редакторов. Никакого сравнения с нынешними переводами, на большинство из которых без слез не взглянешь. Интересно, почему в Советское время переводная литература была на качественно другом уровне? Поддержка государства? Понимание важности миссии книгоиздательского дела сознательными советскими гражданами? Что-нибудь еще?

Если качество перевода меня приятно удивило, то тираж, который я заметил совершенно случайно, просто шокировал: 100 000 (!) экземпляров узкоспециализированной (пусть и научно-популярной) книги по физике. Совестский Союз действительной был очень читающим государством... ну или по крайней мере очень покупающим книги :)

P. S. Учитывая тираж, думаю, тем, кто захочет ознакомиться с этой книгой, будет несложно найти ее в ближайшей серьезной библиотеке.

среда, 14 июля 2010 г.

Test-Driven Development vs. Test-First Development

Натолкнулся на днях на статью с провокационным названием "Why Test-Driven Development Really Isn’t Test First". Основная идея заключается в том, что необходимо сначала писать интеграционные тесты (например, при помощи Fit), а затем уже писать Unit-тесты и код в режиме TDD:
... we should not drive our acceptance tests from our unit tests, but rather do it the other way around since we need to be creating our acceptance tests first.

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

Update
Оказывается, Acceptance TDD - широко известная практика. Выходит, мой интерес к этой статье обусловлен лишь слабой осведомленностью в вопросах Extreme Programming.

В этой статье разработчики не соглашаются с критикой ATDD Кентом Беком и рассказывают свою success-story.

По результатам поверхностного изучения ATDD добавил в ToRead-список две книги под авторством Кента Бека: Extreme Programming Explained: Embrace Change и Test Driven Development: By Example

вторник, 13 июля 2010 г.

C# 3.0 Design Patterns

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

Перечитывать классическую книгу по этой тематике - "Design Patterns: Elements of Reusable Object-Oriented Software" (aka Gang of Four = GoF) - настроя не было: хотелось найти книгу посвежее (а за 15 лет по мотивам GoF было издано немало книг). Прошерстив Amazon, я остановился на книге "C# 3.0 Design Patterns". Как .NET-разработчика меня не в последнюю очередь привлекло название: интересно было посмотреть, какие изюминки автор видит в портировании паттернов на C# 3.0. Противоречивые отзывы на Амазоне настораживали, но любопытство взяло свое.

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

Негатив

Factory method и Abstract factory

В главе про FactoryMethod описывается и реализуется Parameterized Factory Method. Традиционный дизайн этого паттерна (когда тип создаваемого объекта переопределяется в виртуальном методе наследника) остается за кадром. Видимо, поэтому в главе про Abstract Factory автор не упоминает, что приведенный дизайн Abstract Factory - вариация на тему Abstract Method. Кроме того, при описании Abstract Factory опускается альтернативный дизайн этого паттерна, построенный на паттерне Prototype (этот дизайн интересен своей гибкостью).

Bridge

Сравним выдержки из описания паттерна Bridge из GoF:
An adapter often becomes necessary when you discover that two incompatible classes should work together, generally to avoid replicating code. The coupling is unforeseen. In contrast, the user of a bridge understands up-front that an abstraction must have several implementations, and both may evolve independently. The Adapter pattern makes things work after they're designed; Bridge makes them work before they are.

и "C# 3.0 Design Patterns":
The Bridge pattern decouples an abstraction from its implementation, enabling them to vary independently. The Bridge pattern is useful when a new version of software is brought out that will replace an existing version, but the older version must still run for its existing client base.

GoF рекомендует закладывать использование Bridge заранее, а "C# 3.0 Design Patterns" заявляет, что паттерн отлично подходит для legacy-кода. Из оперы "точно так же, но наоборот". Мое понимание паттерна Bridge совпадает с трактовкой GoF, и пример из главы про Bridge, остался для меня загадкой.

Mediator

В GoF паттерн Mediator описывается на знакомом каждому разработчику примере взаимодействия визуальных объектов на форме. При этом показывается, как Mediator позволяет уменьшить связность и сосредоточить логику, которая иначе была бы "размазана" по множеству объектов или обработчиков событий, в одном месте. В "C# 3.0 Design Patterns", в свою очередь, приводится невыразительный пример взаимодействия объектов через Mediator, причем акцент сделан на общении объектов, а не на логике внутри Mediator.

Все так плохо?

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

Однако "C# 3.0 Design Patterns" имеет смысл прочитать/пролистать .NET разработчикам, которые уже изучили фундаментальный труд по этой тематике.

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

Во-вторых, реализация некоторых паттернов имеет занимательную специфику по отношению либо к C#, либо к .NET в целом. Например, мне показалась интересной реализация паттерна Visitor на базе рефлексии. Конечно, то еще извращение, но при работе с legacy-кодом может пригодиться.

Вместо заключения

В блоге у Jason McDonald есть отличная шпаргалка по GoF паттернам. Незаменимая штука, если вам нужно быстро вспомнить, кто есть кто.

воскресенье, 11 июля 2010 г.

Читаем блог "от корки до корки"

Бывает, найдешь отличный блог и хочется прочитать его "от корки до корки". Например, недавно натолкнулся на блог Эрика Липперта, одного из разработчиков C#, который за семь лет написал около 400 постов. Нужно ооочень много времени, чтобы прочитать все посты, комментарии, и во всем этом разобраться. Если сильно увлекаться этим процессом, страдают другие задачи (внезапно). Я нашел для себя следующий компромисс: завожу под блог отдельное окно в браузере (чтобы не забывать и не путаться) и даю себе обещание читать фиксированное количество записей в день (в случае с Липпертом это 4). Пока работает. А как поступаете вы?

суббота, 10 июля 2010 г.

Славься, SOLID! Славься, TDD!

Никакой информативности, просто порыв души :)

воскресенье, 27 июня 2010 г.

Мифический человеко-месяц


То тут, то там постоянно слышал о книге "Мифический человеко-месяц" (англ. "The Mythical Man-Month"), но все никак не находил времени ознакомиться с ней. А тут снял квартиру, предыдущие жильцы которой не пользовались интернетом. В первый день я поленился оформлять договор с провайдером, а вечером в поисках офлайновой альтернативы Google Reader начал читать "Мифический человеко-месяц". Книга показалась мне интересной, и я решил не подключать Интернет, пока ее не дочитаю :)

Не буду подробно описывать автора, саму книгу и ее историческую значимость: Google в этом вопросе бесценный помощник (вот, например, хорошее описание). Лишь поделюсь своим впечатлением и особенно понравившимися цитатами.

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

На фоне того, как динамично развивается IT, я ожидал, что в 75-м все было совсем плохо. Однако в книге сплошь да рядом встречаются описания идей/проблем, которые актуальны и по сей день (пусть и лучше проработаны). Было интересно спроецировать описываемые Бруксом ситуации на проекты, в которых я принимал участие. Пожалуй, пару передовых приемчиков 75-го года стоило бы перенять :)

Достойная, познавательная книга, которая актуальна (в общем, а не в частностях) до сих пор. Отложите книгу по новомодному фреймворку, и окунитесь в историю индустрии создания программного обеспечения.

Ниже приведу несколько особенно понравившихся мне цитат.

1. "In many ways, managing a large computer programming proj-
ect is like managing any other large undertaking — in more ways
than most programmers believe. But in many other ways
it is different — in more ways than most professional managers
expect."

2. "The bearing of a child takes nine months, no matter
how many women are assigned."

3. "The second is the most dangerous system a person ever
designs; the general tendency is to over-design it."

4. "Einstein repeatedly argued that there must be simplified explanations of nature, because God is not capricious or arbitrary. No such faith comforts the software engineer."

P. S. А я пока, пожалуй, не буду подключать эти ваши интернеты: уж больно To-Read список разросся.

четверг, 24 июня 2010 г.

Prostopleer ввел премиум-аккаунты

Prostopleer ввел премиум аккаунты. Я примерно полгода назад променял LastFm на ProstoPleer по причине малого количества русской музыки и отсутствия возможности скачивания треков. Ребята делают действительно отличный сервис, и я был рад купить премиум аккаунт (хотя функционал базового аккаунта меня вполне устраивает): всегда приятно посодействовать развитию интересного проекта.

Однако в плане лицензионности контента прослеживается аналогия с ТурбоФильмом: пользователи оплачивают доступ к контенту, до авторов/правообладателей которого не доходит ни копейки. Неправильно это :(

вторник, 22 июня 2010 г.

Новый блог

Недавно начал вести блог на английском: http://alexidsa-en.blogspot.com. Впредь записи будут публиковаться либо в одном из двух блогов, либо дублироваться (по особым случаям).

вторник, 25 мая 2010 г.

RDF vs. неRDF на примере геоданных в контексте BeAware

Одной из исходный целей создания BeAware было попробовать с пользой применить технологии из стека Semantic Web (на фоне разочарования от трехлетнего внедрения семантики туда, где она, по большому счету, не нужна). Предлагаю рассмотреть вопрос актуальности применения RDF-массивов Linked Data по сравнению с другими формами представления данных.

На текущий момент в формате Linked Data опубликовано огромное число массивов данных. Интересно, что для большинства из них исходной является реляционная форма представления, и два крупнейших массива геоданных: GeoNames и LinkedGeoData, не являются исключениями. Так, GeoNames ежедневно публикуется в виде CSV-дампов, которые отлично ложатся на реляционную модель, а LinkedGeoData является RDF-представлением данных OpenStreetMap, которые доступны в разных неRDF форматах. Встает вопрос: какую пользу мы можем извлечь за счет перевода данных в RDF? Я не буду останавливаться на теоретических аспектах этого вопроса (предполагается, что читатель с ними знаком), а опишу конкретные юзкейсы, которые стали/станут нам доступны за счет использования RDF.

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

На начальном этапе казалось, что нужды использовать GeoNames нет, ведь LinkedGeoData содержит информацию не только об объектах, но и о городах, странах и т. д. Однако ввиду ориентации OSM на контент, а не на контекст, города (об областях, штатах и т. д. и говорить не приходится) размечены очень плохо: нет ни того богатства локализованных имен, ни четкой иерархии, что есть в GeoNames.

Итак, решение принято: используем GeoNames для первого "измерения" места проведения события - города. Однако вопрос, что использовать: реляционное или RDF представление, все еще был актуальным. В ходе одного из обсуждений в гуглгруппе GeoNames Prateek Jain дал мне ссылку на научную работу, соавтором которой он является. Эта статья открыла мне глаза на довольно очевидную вещь: как можно играюче обрабатывать транзитивные иерархии GeoNames-сущностей (например, город->район->область->страна) за счет движка логического вывода. Действительно, вряд ли какое-то средство справится с этим лучше, чем заточенный под подобного рода задачи движок логического вывода (бай-бай, рекурсивные SQL-запросы).

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

Выбор между LinkedGeoData и "чистым" OpenStreetMap тоже был не из сложных.

Во-первых, ввиду того, что LinkedGeoData ориентирован не на показ карт, а на обработку запросов, LinkedGeoData поставляется не только в полной версии, но и в урезанной - LinkedGeoData Elements. Урезанная версия не содержит малоинтересные объекты (хайвеи, висячие элементы и др.) и содержит в 25 раз меньше триплетов. Для нашего скромного бюджета - то, что доктор прописал (хороший хостинг 3 миллиардов триплетов полной версии LinkedGeoData обошелся бы недешево). Этот пункт не имеет отношения ни к семантике, ни к RDF и, возможно, подобные урезанные массивы публикуются и для "чистого" OpenStreetMap (хотя мне не попадались). Но это лишь подчеркивает, что у массивов из Linked Data могут быть и чисто технические, выходящие за рамки семантики преимущества.

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

Мы рассмотрели преимущества использования RDF-массивов GeoNames и LinkedGeoData по отдельности. Однако название Linked Data как бы намекает на то, что дополнительные плюсы должны проявляться при интеграции массивов. К сожалению, на текущий момент маппинга между LinkedGeoData и GeoNames нет. Однако когда он все же будет разработан (такой пункт значится в todo-листе разработчиков LinkedGeoData), для нас откроется несколько полезных юзкейсов. Ниже приведу один пример.

Каждая сущность как в GeoNames, так и в LinkedGeoData снабжается координатами (широтой и долготой). Для городов (да и для других объектов с большой площадью) координаты, насколько я могу судить, не имеют какой-либо семантики (например, можно было бы предположить, что это координаты здания городской администрации): это просто координаты внутри города. Так вот в GeoNames и LinkedGeoData эти координаты частенько отличаются. Отличие в координатах, как правило, не очень большое, но достаточное для того, чтобы наступить на следующие грабли. В OpenStreetMap рядом с этими координатами прописывается название города. Когда в форме добавления нового места вы выбираете город, на карте устанавливается точка из GeoNames (ведь поиск городов осуществляется при помощи GeoNames), при этом название города на карте не видно (по крайней мере при используемом по умолчанию масштабе). Имея же маппинг GeoNames+LinkedGeoData, мы сможем подгружать для GeoNames-городов координаты из LinkedGeoData.

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

Текущее положение дел в проекте BeAware

В этом посте я расскажу о текущем положении дел в проекте BeAware, опишу актуальные проблемы и очерчу ближайшие перспективы. Пост имеет дискуссионный характер, поэтому любые комментарии приветствуются (наши гуглогруппы: английская - beawareat, русская - beawareat_ru).

Начнем с сердца проекта - онтологии.

На мой взгляд, онтология BeAware должна удовлетворять следующим критерям:
1. Быть дружелюбной к пользователю. Этот пункт не случайно на первом месте. Мы создаем не академическое приложение, а поэтому нельзя допустить, чтобы пользоваться сайтом могли лишь обладатели степени PHD Оксфордского Университета.
2. Одним из конкурентных преимуществ семантических технологий является возможность логического вывода, поэтому считаю, что онтология должна максимально эффективно (эффективно для пользователя, опять же) его использовать. Сейчас работа движка логического вывода проявляется, например, при поиске всех развлекательных событий (сколько бы нижележащих уровней иерархии ни было) или научных конференций по всем гуманитарным наукам. Лучше, чем ничего... но эта сторона онтологии еще явно требует доработки.
3. Онтология должна быть обобщением основных типов событий, происходящих в мире.

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

Список открытых вопросов по структуре онтологии:
1. Сейчас событие "музыкальный концерт" является наследником "развлекательного события". Однако, на мой взгляд, концерты классической музыки претендуют на звание культурного события. В рамках текущего подхода, когда корневыми событиями (корневыми в визуальном плане: все события являются наследниками базового класса Event) являются события, относящиеся к какой-либо сфере жизни, было бы логично выделить класс "концерт классической музыки" и сделать его подклассом "культурного события". Однако мне кажется, что такой подход будет путать пользователей (и концерты классической музыки будут по ошибке создаваться как экземпляры "музыкального концерта"), поэтому решение этой проблемы пока под вопросом.
2. У события "Театр" есть свойство "вид театрального искусства" (не придумал более лаконичного лейбла). Стоит ли оставить это так, или лучше выделить оперу, баллет и т. д. в подклассы класса "Театр"? С одной стороны, это загромоздит онтологию, с другой, - текущая реализация не позволит нам в будущем добавить дополнительные свойства, например, для балета (технически-то сможем, но юзабилити такого решения представляется мне сомнительным).
3. Есть ли какая-то стандартизированная классификация наук? Текущая иерархия для свойства "вид науки" взята из английской википедии, но, во-первых, она довольно куцая, а во-вторых, слабо коррелирует с классификацией, принятой на постсоветском пространстве.
4. Не приложу ума, куда разместить событие "выставка" (exhibition). Выставки бывают разные: картин, собак, IT (софт, железо, игры) и т. д.
5. У меня есть большой соблазн создать корневую категорию IT. Пока я с ним успешно борюсь... но встает более серьезный вопрос: по каким критериям выделять корневые события?

Перейдем ко второму пункту сегодняшнего поста - к обзору геоданных и их применения в BeAware.

Итак, каждое событие привязывается к определенному месту, где:
Место = Город (GeoNames) + [Объект (LinkedGeoData)], где объект - опциональный параметр.

Сначала предлагаю обсудить, как можно использовать привязку каждого события к GeoNames. Итак, имеем следующие исходные данные:
1. У каждого события есть URI из RDF-массива GeoNames
2. GeoNames построен на транзитивной иерархии (например, вот (http://ws.geonames.org/hierarchy?geonameId=1489425) иерархия для Томска: Томск->Томская область->Российская федерация->Европа->Земля). Причем количество и названия элементов иерархии меняются от страны к стране.
3. Движок логического вывода Virtuoso может играючи обрабатывать транзитивность, определяя принадлежность события, к тому или иному уровню иерархии.

Раз все так хорошо, почему у нас реализована лишь фильтрация по городам и странам? Дело в том, что мы пока не нашли красивого user-friendly решения. Я вижу два варианта реализации гибкой фильтрации (под гибкой я имею в виду фильтрацию, которая использует иерархию GeoNames в полной мере):
1. На базе существующего решения. Просто убираем ограничение поиска лишь по странам и городам - пользователь сможет найти и районы, и области, и республики и т. д. Но это будет полный бардак. Сейчас при поиске сущности вручную прописывается, является ли она городом или страной. Однако при гибком подходе мы можем прописать лишь GeoNames feature code (http://www.geonames.org/statistics/total.html), но это очень недружелюбно к пользователю.
2. Пользователь может вводить только города, но рядом с соответствующим фильтру городом отображается вышележащая иерархия (элементы которой можно выбрать наравне с городом). В этом случае засчет визуальности иерархии отчасти решается проблема первого подхода, но при этом рождается новая: пользователю нужно знать город в том регионе, который он хочет выбрать.

Ни один из вариантов мне не нравится но, вероятно, один из них придется реализовать. Что думаете на сей счет?

Иерархия GeoNames на текущий момент не включает в себя объединения стран. При этом идея фильтрации тех же научных конференции по всему Европейскому Союзу выглядит довольно интересной. Реализовать это можно: во-первых, в этом направлении идет работа внутри GeoNames, а во-вторых, есть замечательная геополитическая онтология, которую можно интегрировать с GeoNames. Вот, кстати, недавняя дискуссия на сей счет в гуглгруппе GeoNames. Но будет ли это востребовано? Есть ли еще объединения стран (кстати, необязательно именно стран) со столь же высокой степенью интеграции, как в Евросоюзе? Не хочется лишний раз нагружать и без того не самый простой интерфейс BeAware.

Продолжая вопрос геофильтрации, обратимся ко второму "измерению" месторасположения события, к конкретному объекту из LinkedGeoData. Почему бы не дать пользователям возможность фильтровать события по кокретному месту в городе? Навскидку, довольно полезный юзкейс: можно отслеживать все представления в любимом театре или все вечеринки в любимом ночном клубе. Серьезных сложностей с реализацией этой возможности возникнуть не должно, однако в релиз она попадет вместе со всеми изменениями, касающимися геоданных: придется крепко поломать голову над тем, как объединить все виды геофильтрации, и при этом не отпугнуть пользователей излишней сложностью.

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

Довольно логичным решением было бы использовать интерфейс, базирующийся на поиске по имени/адресу объекта. Однако в этом случае пользователь может по ошибке выбрать объект, не находящийся в выбранном им городе. Кстати, этой проблемы не лишен и текущий интерфейс. Пользователь может выбрать город, затем увести карту куда угодно и выбрать объект в другой части света. Проверить принадлежность координат к городу довольно сложно, учитывая, что города постоянно растут. По крайней мере мне не известен ни один сервис, предоставляющий такую информацию. Может, у военных попросить... :) В качестве обходного пути я вижу следующее решение. Для каждого города у нас есть координаты его условного центра (просто некоторая точка внутри города). Также у нас есть некоторый объект (у которого тоже есть координаты). Мы можем рассчитать расстояние между этими точками и разделить его на население города (здесь предполагается, что размер города находится в прямой зависимости от его населения). Если это нормированное значение превышает некоторый порог, мы либо выдаем предупреждающее сообщение пользователю, либо отдаем событие на премодерацию. Что скажете?

На этом данный пост завершается и плавно переходит в следующий, который появится совсем скоро.

воскресенье, 23 мая 2010 г.

Запущена альфа-версия проекта BeAware

Все началось несколько месяцев назад, когда в поисках информации о конференции я посетил не один каталог событий, однако ни один из них меня не порадовал: отсутствие удобного поиска (что при большом наполнениии превращает сайт в мусорку), недостаток интеграции с геоданными и другие огрехи подтолкнули меня к идеи реализации собственной площадки событий. При этом, пожалуй, самым серьезным мотиватором стал потенциал применения в этом проекте технологий из стека Semantic Web (а такой проект я подыскивал уже давно). Объединившись с Ефимовым Александром, мы приступили к работе над проектом BeAware.

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

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

После того, как выбран тип события, необходимо задать место его проведения. Можно либо выбрать уже ранее отмеченное место (здесь ничего интересного), либо добавить новое:
Место - это, прежде всего, город (используется GeoNames)। Однако, выбрав город, можно задать и конкретный объект в нем (используется массив LinkedGeoData, который, в свою очередь, базируется на OpenStreetMap). Между выбором города есть промежуточный этап выбора типа объекта, который помогает отфильтровать объекты (кстати, здесь ненавязчиво используется логический вывод, например, при выборе всех типов зданий).
После того как место выбрано, перед нам открываются остальные свойства события (их список варьируется в зависимости от типа события):
Заполняем их - и событие создано.

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

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

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

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

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

Во-вторых, будет улучшена геофильтрация. Это просто нелепо иметь в руках GeoNames+LinkedGeoData+Движок_логического_вывода и выжать из всего этого лишь фильтрацию по городам и странам. Постараемся существенно улучшить этот компонент.

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

В-четвертых, добавим RDFa-разметку.

В-пятых, интегрируем MusicBrainz для музыкальных концертов.

В-шестых, предлагайте свои идеи - мы не оставим их без внимания :)

До запуска беты наши основные приоритеты - функционал и юзабилити, после - популяризация.

P. S. Спасибо ребятам из компании "Соционика" за помощь с дизайном и версткой.
PP. S. Отдельное "спасибо" хабрачеловеку LeeMiller. Взявшись за разработку дизайна и верстки BeAware, он начал за здравие, но после получения предоплаты его как будто подменили. В течение полутора месяцев он кормил нас "завтрками" и враньем на любой вкус, а в результате сорвал нам все сроки (особенно если учесть, что его мы искали после того, как нас кинул предыдущий дизайнер: видимо, была черная полоса). Я, быть может, и забил бы на эту ситуацию, но LeeMiller проигнорировал мои сообщения о том, что было бы неплохо вернуть предоплату - а значит это уже не халатное отношение к работе, а мошенничество. Уважаемый LeeMiller, в ваших интересах прислушаться к моим сообщениям раньше, чем мы не доберемся с постами о BeAware на Хабр.

суббота, 27 февраля 2010 г.

Впечатление о Карлсруэ

Я уже две недели как уехал в командировку в Карлсруэ, замечательный город на юге Германии. Сегодня решил написать о вещах, которые показались мне особенно примечательными на контрасте с Томском.

В Карлсруэ великолепная транспортная система, базирующаяся на трамваях. Причем трамваи ходят не только в пределах города, но и до пригородов, тем самым выполняя роль электричек. Это круто даже для Германии (особая гордость жителей Карлсруэ). Трамваи современные, быстрые, бесшумные, но поездки обходятся недешево. Одна поездка стоит два с небольшим евро (100 рублей), а это дороговато даже для местных жителей. Правда, есть абонементы, которые делают трамваи более доступными. Так уж сложилось, что я неравнодушен к поездам... а в эти трамваи я просто влюбился :)

Немцы очень трепетно относятся к воскресенью - право на отдых в последний день недели даже закреплено конституцией. Нравится это далеко не всем (вот недавно очередной замес был), но факт остается фактом: в воскресенье почти никто не работает. К тому, что будет закрыто абсолютное большинство магазинов, я был готов. А вот то, что неожиданно упавший воскресным утром интернет (недешевый, надо сказать, интернет) от Vodafone подняли только в понедельник, меня неприятно удивило (темная сторона отдыха в воскресенье). Трудно представить такое в США: засудили бы. Я на сутки остался без доступа к SVN-серверу стартапа, над которым сейчас работаю в свободное время - пожалел, что поднял SVN, а не GIT/Mercurial.

Здесь повсеместно применяются экономичные включатели света, выключающиеся самостоятельно по истечение некоторого промежутка времени. При этом включаются они, как правило, либо вручную, либо от датчика движения. Последний вариант используется у нас в холле. Дверь моей комнаты находится как раз посередине между двумя датчиками, и когда я выхожу из комнаты, ни один из них не срабатывает. И чтобы увидеть замочную скважину в темное время суток, приходится поболтать ногой в ту или иную сторону :)

Меня не перестает радовать отсутствие в Карлсруэ представителей бестолковых профессий вроде вахтеров и охранников. За время работы в государственной организации вахтеры, по обыкновению "одаренные" соответствующим синдромом, выпили не один литр моей кровушки, поэтому к ним у меня особое отношение. Вот, например, сегодня (в субботу) я пошел на работу. Большое здание, в котором расположены офисы нескольких крупных компаний; выходной; ни единой души, а для того чтобы попасть на рабочее место мне нужен лишь один ключ. Никаких вахтеров, никаких сигнализаций - лишь мораль да честное слово. Вот так в России не будет никогда (ну если только не введут смертную казнь за малейшее правонарушение...).

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

Недостатки? Дайте подумать... Ну вот, например, купюры, начиная от 50 евро, широкие и не влазят полностью в мой кошелек :) А если серьезно, то я еще в первый день спросил у нашего PM, который бывал в Томске, есть ли, на его взгляд, у Карлсруэ какие-либо недостатки по сравнению с Томском. Он крепко задумался, а потом сказал, что здесь очень высокие налоги (даже на фоне других немецких городов). Но так ли уж это плохо? Ведь, во-первых, налоги здесь если и пилятся, то в гораздо меньших масштабах (по крайней мере невооруженным взглядом видно, на что тратятся деньги налогоплательщиков), а во-вторых, здесь и зарплаты раза эдак в три-четыре выше, чем в заМКАДье.

P. S. Хорошо там, где нас нет. И пока нас нет :) Не долго мне осталось наслаждаться жизнью в Карлсруэ - через 2 недели обратно. В Карлсруэ сейчас +10, а в Томске -30 - даже не верится.

среда, 27 января 2010 г.

Чтобы понять рекурсию, нужно сначала понять рекурсию

Писал сегодня сообщение в буржуйский мейл-лист и решил проверить, правильно ли написал слово рекурсия (recursion). Ввожу в Гугл - смотрю и не могу понять:
Подозвал коллегу - тот посмеялся и говорит: "Это не баг - это фича". Тут до меня наконец-то дошло: Гугл так шутит. Оказывается, это известный трюк, который даже на Хабре проскакивал.

P. S. Мне кажется, на русском я бы не повелся. А в английском нет такой уверенности... Да, ищу оправдание :) Обычно в таких ситуациях все сваливают на "конец рабочего дня" и "бессонные ночи"... но я приберегу эти джокеры до следующего раза.

воскресенье, 3 января 2010 г.

Semantic Web, Web of Data, Linked Data и агенты в двух абзацах

Оригинал:
According to (Berners-Lee, 2000, pp.191) "The first step is putting data on the Web in a form that machines can naturally understand, or converting it to that form. This creates what I call a Semantic Web - a web of data that can be processed directly or indirectly by machines". Therefore, while the Semantic Web, or Web of Data, is the goal or the end result of this process, Linked Data provides the means to reach that goal.

By publishing Linked Data, numerous individuals and groups have contributed to the building of a Web of Data, which can lower the barrier to reuse, integration and application of data from multiple, distributed and heterogeneous sources. Over time, with Linked Data as a foundation, some of the more sophisticated proposals associated with the Semantic Web vision, such as intelligent agents, may become a reality.
Вольный перевод:
Согласно (Бернерс-Ли, 2000, стр. 191), "Первый шаг - размещение в сети информации в форме, которую могли бы легко понимать компьютеры, или перевод существующей информации в такую форму." Поэтому, если Semantic Web, или Web of Data, - конечная цель, то Linked Data является средством достижения этой цели.

Размещая Linked Data, люди и сообщества делают вклад в создание Web of Data, который снизит сложность интеграции и использования данных из распределенных разнородных источников. Базируясь на Linked Data, со временем некоторые более сложные концепции Semantic Web (например, интеллектуальные агенты) могут стать реальностью.
Взято отсюда.