Преобразуем XML в JSON с помощью XStream

Иногда возникает задача преобразовать существующий XML-документ в эквивалентное ему JSON-представление. Например, такая задача может возникнуть, если вы разрабатываете AJAX-интерфейс к существующей системе, которая генерирует XML. Дело в том, что из JavaScript гораздо проще оперировать объектами, представленными в формате JSON, нежели XML, просто потому что первый формат - нативный.

Так вот, быстро преобразовать XML в JSON можно с помощью замечательной библиотеки XStream, подробное введение в которую опубликовано в статье xstream - сериализуем Java-класс в XML. В состав данной библиотеки входит драйвер JettisonMappedXmlDriver, отвечающий за быстрое преобразование XML -> JSON. Порядок преобразования следующий:

Когда система тормозит...

Так получилось, что последние несколько дней Суровый челябинский программист занимался ускорением Naumen DMS в рамках решения проблемы конкретного заказчика. После успешного завершения процесса у меня появилось несколько мыслей, которыми я и хочу с вами поделиться. Сразу скажу, что все мысли относятся к решению проблем с производительностью только бизнес-приложений, потому что при разработке игр или встраеваемых систем возникают совершенно иные ситуации.

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

ECF: Взаимодействуем с Twitter с помощью REST API и XStream

Продолжаем беседу об Eclipse Communication Framework. Сегодня мы рассмотрим, как использовать появившийся в версии 3.1 REST API на примере взаимодействия с наиболее популярным сервисом микроблогов - с Twitter.

Поддержка REST была добавлена в ECF этой осенью горячим немецким парнем по имени Holger Staudacher в рамках Google Summer of Code (который я, кстати, считаю гораздо более полезным, нежели Imagine Cup от небезызвестной корпорации). Реализация данной функциональности представленна контейнером ecf.rest.client и базируется на Remote services API.

ECF: Пишем Jabber-бота с использованием Habra API

Сегодня Суровый челябинский программист хочет поделиться исключительно Just for fun'ом, а именно - рассказом о том, как легко и непринужденно написать Jabber-бота с использованием Bot Framework. Наш бот будет принимать команды вида ~karma %username% и воозвращать соответствующую информацию о хабражителе с указанным именем. Для получения данной информации используется Habra API.

Сначала поговорим о содержательной части задачи. Habra API предоставляет возможность получать с помощью GET-запросов по определенному урлу (заданному в формате http://habrahabr.ru/api/profile/%username%) XML-документ с информацией о пользователе или об ошибке, если, например, такой пользователь не зарегистрирован в системе. Понятно, что хотелось бы большего, в частности - получать информацию о месторасположении пользователя или его интересах, а также иметь возможность вытягивать посты целиком или даже публиковать информацию через API. Надеюсь, что хотя бы часть из этого хаброавторы сделают, пока же мы имеем то, что имеем.

Теперь, что касается Bot framework. Данный фреймворк представлен бандлом org.eclipse.ecf.presence.bot и позволяет писать ботов, работающих с поддерживаемыми ECF Messenger-ами (например, Jabber, Skype, Yahoo) и т.н. ChatRoom-ботов, т.е. роботов для IRC-каналов и/или Jabber-конференций. Включает в себя четыре точки расширения, позволяющие регистрировать роботов и обработчики команд. Рассмотрим их подробнее:

Небольшое введение в механизм точек расширения Eclipse

Здравствуйте, уважаемые читатели. Суровый челябинский программист вернулся из земли Египетской, акклиматизировался и готов порадовать вас новой статьей (хотя, конечно, переход от +28 к - 20 это жестоко).

Сегодня мы поговорим об основном на сегодняшний день механизме расширения функциональности разрабатываемого Eclipse-плагина - о точках расширения, которые появились еще тогда, когда Eclipse не базировался на технологии OSGi и не мог использовать сервисы, события и прочие полезные вещи, предоставляемые этой платформой.

Суть заключается в следующем: в корне плагина находится файл plugin.xml, в котором содержатся объявления точек расширения (тег extension-point) - элементов описывающих те места системы, которые можно расширять. В платформе Eclipse RCP определены точки расширения для регистрации своих адаптеров, видов, перспектив, пунктов меню, кнопочек на панели быстрого запуска и т.д. и т.п.

Точка расширения характеризуется уникальным идентификатором (атрибут id, который обычно задают, придерживаясь доменной модели, как и java-пакеты; именем (атрибут name), служащим больше для удобства программиста, и схемой (атрибут scheme) - путем к exsd-файлу, который содержит XScheme, описывающую формат расширения.

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