вторник, 8 февраля 2011 г.

Программируем электронную книгу Qumo Libro

Недавно приобрел себе читалку Qumo Libro (писал об этом в Buzz'е), и был совершенно уверен, что программировать её нельзя, поскольку слово "прошивка" четко обозначало (раньше, как минимум) что-то, что заливается в ППЗУ и намертво.

И только после покупки набрел на форум сайта The-eBook.org, где обнаружилось, что писать программы для этой книжки можно, да к тому же не на какой-нибудь обрезанной Java, а на самом обычном C.

Ну, дернуло и меня этим заняться, особенно всвязи с тем, что в Libro НЕТ ШАХМАТ!! :( Но на то, чтобы подступиться к программированию, потратил кучу времени. Крупицы требуемых полезных сведений были разбросаны чуть ли не по всему форуму, и стоило большого труда всё это собрать воедино.

Между прочим, Qumo Libro программно совместима с Qumo Colibri, Digma e*, Gmini, Sibrary, и другими подобными электронными книгами, поэтому данное руководство и для вышеозначенных книг тоже должно подойти.

В общем, всвязи со всем этим, решил написать небольшую статью для тех, кто вдруг тоже купит себе читалку, совместимую с Qumo Libro, и захочет для этого девайса что-нибудь написать!

четверг, 3 февраля 2011 г.

Отображаем число подписчиков на кнопке Google buzz

В поставляемых Google'ом кнопках подписки нет возможности отобразить текущее число подписчиков.

Решив этот минус исправить, сделал себе такую вот кнопку для желающих подписаться на мой Buzz (туда транслируется данный блог, а также пощу некоторые менее формальные сообщения):


Здесь скриншот, собственно кнопка - в правой колонке на блоге (это на всякий случай, для читателей по RSS и через Buzz). Если кто-то хочет себе такую же, в этом посте объясняю, как это сделать.

среда, 2 февраля 2011 г.

Пишем Wix Extension (CompilerExtension)

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

Проблема

Дело в том, что у нашего продукта множество вариаций. Версии Базовый и Стандарт, различные локализации, вариации для Saas и т.д... Все это выливается в необходимость создания большого числа однотипных установщиков.

Раньше мы использовали для этого Microsoft Setup Project, однако количество багов и слабые возможности этого решения вынудили все это переделать на WiX, чем я и занялся.

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

Поиск решения

Решение вроде бы напрашивалось само собой: в библиотеке WixUIExtension имеются элементы XmlFile и XmlConfig. Однако, для генерации больших файлов они не подходят. Попробовав их использовать, я выяснил, что 10 строк обычного xml с их помощью преобразуется аж в 100(!!).

Ну и конечно, XmlFile и XmlConfig не позволяют подключить интеллисенс, ведь для нашего файла конфигурации специально была создана тщательно документированная xsd-схема, благодаря чему создание и изменение файлов конфигурации было довольно удобным.

Поэтому, для активной генерации xml элементы XmlFile и XmlConfig явно не подходят. В процессе поиска альтернативного решения, я обратил внимание на Wix Extensions, и задумал написать собственный такой модуль расширения, который бы позволил максимально быстро и эффективно развертывать наш конкретный xml, и желательно, позволял бы использовать нашу же xsd-схему при его создании/изменении.

Например, это могло бы выглядеть примерно так:

<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">

    <!-- ... -->

    <DeployConfigFragment File="[TARGETDIR]\DeployConfig.xml" xmlns="http://www.deskwork.ru/2010/DeployConfig">
        <SolutionsList>
                <Solution Name="Softline.Portal.Helper" Id="21e394a2-7dab-4565-aaad-2540d360daf2" Require="true" Order="0" />
                <Solution Name="Softline.Portal.Libraries.MediaLibrary" Id="3b3ae4b1-26e7-4680-bd5c-db7e10de86e9" Require="true" Order="1">
                    <Features>
                        <Feature Name="Softline.Portal.Libraries.MediaLibrary.Softline_MediaLibrary" Id="fcc74650-a765-48af-91f6-247d50e7a907">
                            <ActivateRequire>true</ActivateRequire>
                        </Feature>
                    </Features>
                </Solution>
        </SolutionList>
    </DeployConfigFragment>

    <!-- ... -->

</Wix>

И все, что внутри <DeployConfigFragment>, хотелось бы чтобы в неизменном виде развертывалось в xml-файл DeployConfig.xml.

ДА! Я согласен, что это неправильно идеологически. Лучше разделять xml разного смысла, заключая inner xml в CDATA... Однако, в этом случае мы лишаемся интеллисенса, а этого бы очень не хотелось.

В общем, в итоге именно на таком варианте я и остановился, и приступил к исследованию возможности создания WiX Extensions.

Однако, в интернете оказалось не так уж и много документации по вопросу создания WiX Extension'ов, и поэтому мне пришлось лезть в исходники WiX и WiX Contrib Project.

В общем, этом посте я детально рассмотрел процесс создания CompilerExtension расширения для WiX.