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

XML - универсальное зло

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

    1. DSL (domain-specific language). Это настолько ужасное место для применение XML, что даже есть книги по тому как это эффективно делать. Моё мнение совпадает со старой статьёй Фаулера: Language Workbenches: The Killer-App for Domain Specific Languages?. Статья уже достаточно старая. Народ, есть же куча генераторов парсеров, которые выдают исходный код на куче всевозможных языков. В качестве рекламы, уже почти полгода как зарелизался продукт от JetBrains: Meta Programming System. Это действительно классная штука. Сам пока баловался только на уровни простых примеров. Но сами JetBrains выпустили отличный баг трекер на нём (сами его используем, язык поисковых запросов у них очень удобный). Я считаю не стоит ленится и сделать свой язык, при этом забыв про XML, и вы посмотрите, у вас получится отличный продукт. Хороший и жизненный пример это aspectj и spring aop. Во втором случае, как всегда в спринге, приходится писать здоровенный xml, а в первом просто немного простых директив непосредственно в коде, при этом отличная интеграция с эклипсом. Показывает например методы, на которые распространяется аспект. По моему даже обсуждать глупо, в этом случае однозначно свой велик.
    2. Разновидность первого, это различные конфигурационные файлы. Скажем так, это более простой случай DSL. Для Java мне кажется достаточно хорошим решением в замен являются аннотации. Очень-очень часто, смена конфигурации несёт переделку кода, так что все равно пересобирать проект. Если динамический язык как Python, то вообще нет вопросов. При использовании средств языка, при создании конфигураций, можно получить много бонусов при использовании IDE, более точный поиск и автоматический рефакторинг. Но, если действительно, нужен текстовый конфиг, который будет часто изменятся, то я считаю лучшее решение это YAML. Чем то напоминает JSON, только более расширенный. Убил бы человека, который придумал, что XML удобный для чтения формат, читать его конечно можно, но это не черта не удобно, столько уже этого насмотрелся во всяких java framework's. Вообщем, если действительно пишете очередной фреймворк, и вам нужны файлы конфигурации, пожалуйста присмотритесь к простым property файлам, может быть вам будет достаточно. Нет? Тогда может YAML, это действительно очень расширяемый и удобный формат, причём всяких парсеров, так же как для XML, для многих языков более чем достаточно.
    3. Обмен данными. Да, вот тут уделать XML не так легко. Рассмотрим два случая:
      1. Формат данных навряд ли будет изменятся. Спросите где это возможно? Например ETL приложение. Одним из ключевых элементов такого приложения является Промежуточное хранилище. В большинстве случаев, внутри такой системы элементы представляют собой словарь атрибутов. Поэтому в качестве промежуточного формата данных можно выбрать бинарный формат [name|value|....]. Причём например если известен максимальный размер имени и значения, при выборке, можно выбирать только нужные поля, пропуская в массиве байтов остальные. 
      2. Будет изменятся. Тут есть проблемы, можно конечно рассмотреть сериализацию объектов, но тогда может возникнуть проблема с десериализацией в разных языках. Можно присмотреться к уже реализованным бинарным протоколам, например Google Protocol Buffers. Конечно, если вам надо распарсить одну XML в час, то вам наверно всеравно, но если пару десятков тысяч в секунду, то приходится задумываться над эффективностью действий. Да и хранение + последующая выборка избыточны и не добавляют производительности приложению. Да, открытось бинарных протоколов оставляет желать лучшего, тогда возвращаемся к упомянутым выше YAML и JSON. Хотя бы для начала посмотрите, как можно решить вашу задачу с их помощью, перед тем как кричать XML.
В целом посыл поста был один. Не стоит использовать XML как универсальное средство решение любой проблемы, потому как есть более эффективные способы решить вашу проблему и стоит вначале оценить их и сравнить с волшебным XML'ем.

Google Chrome и Плагины

Google Chrome классный браузер, полюбил его за скорость и интерфейс. Раньше писал про плагины, которые у него появились. Это круто, что они работают в отдельных процессах, если один падает (что иногда случается так как сижу на dev канале хрома), то просто появляется сообщение и кнопочка перегрузить его. Но есть одна проблема, как только стартует первый процесс браузера, он стартует все плагины, у меня их 6, т.е. стартует ещё 6 процессов. А так как в процессе работы я часто закрываю и открываю его (привык начиная с первой версии хрома), то время первого старта браузера сильно замедлилось, что меня печалит. Поэтому теперь держу gmail открытым как приложение, остальные экземпляры стартуют быстрее. Но вообще да, как-то не очень получается с этими плагинами.
А ещё одно наблюдение, что-то страницы стали грузится не в отдельных процессах иногда, как-то страно это.

четверг, 11 февраля 2010 г.

Java: Read escaped quote as escaped quote from xml

Всё началось с того, что на проекте мы используем написанный нами фреймворк для автоматического тестирования. Многое в нём завязано на xml. В частности очень важная задача сравнение двух xml, "сравнитель" оброс большим количеством всевозможных плюшек. Вот понадобилось ещё одну реализовать. Подробно о ней написала моя коллега: StackoverFlow:Read escaped quote as escaped quote from xml. Ничего дельного ей не ответили до её ухода в отпуск. Задача мне показалась интересной, поэтому решил побаловаться с ней. Вкратце, проблема состоит в том, что когда DOM парсер строит дерево, к значениям элементов применяет unescaping. Нам бы хотелось, чтобы он так не делал, потому что нам надо сравнить два DOM дерева построенных по двум xml файлам, и убедиться именно в их идентичности, что эскейпинг проведен правильно.
На предыдущем проекте пришлось много сражаться с особенностями open source библиотек, которые мы использовали. Причём на форумах тоже было очень молчаливо, а задания делать надо было. Тогда я и заразился любовью в копании в исходниках open source библиотеки, чтобы решить свою проблему, очевидный и очень эффективный метод :)