На мысль натолкнуло исправление очередного бага в Ajax Control Toolkit.
 

Часто мы в проектах, чтобы не изобретать велосипед, используем уже готовые инструменты. Иногда это open source приложения/библиотеки. И что делать, если нам не хватает функциональности этих библиотек или надо срочно исправить какуе-то ошибку? Первая же мысль - это взять исходники, подправить/дописать, после чего скомпилировать и радоваться жизни. Но радоваться будем недолго, до выхода новой версии этой замечательной библиотеке, в которой есть необходимые изменения. Приходится качать исходники, опять вносить туда свои изменение, компилировать и т.д. В процессе этого пишуться письма авторам библиотеке, создаются новые запись в ихнем багтрекере, но необходимых изменений в очередной версии мы так и не получаем.

После нескольких таких итераций голову приходит очередная мысль (нет, не отказаться от этого продукта): "А, может, не будем изменять исходники? Может, просто приспособимся к их API или сделаем класс-наследник и добавим в него недостающую функциональность?". В этот момент начинает казаться, что пользы от open source становится всё меньше и меньше. При таком подходе переход на новую версию используемой библиотеке становится менее болезненным, но мы не застрахованы, что в новой версии ничего не изменится и не поломает нашу функциональность.

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

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

Нет определенного ответа на вопрос "Использовать библиотеку А, В,заплатить за библиотеку С или написать свою?". Все зависит от конкретного случая и выбор, временами, сделать очень трудно. Интересно, какие у вас мысли по этому поводу? Аналогичная, по моему мнению, и ситуация с использованием CMS для сайта: писать свою, взять готовую или на основе готового написать свою?

P.S. Всё это я рассмотрел со стороны рядового разработчика и не учитывал влияния заказчика PM-а и других заинтересованных сторон.


Dynamic Language Runtime (DLR) - позволяет создавать свои динамические языки на платформе .NET. Сейчас самыми популярными из них являются IronPython и IronRuby. Также на просторах CodePlex существует IronLisp и другие динамические языки. Последняя версия DLR имеет номер 0.9 и была выпущена 10 декабря 2008 года.

Кроме того, что DLR позволяет создавать динамические языки, она также позволяет добавлять динамические элементы в уже сеществующие языки: C# 4.0 уже использует DLR - смотрите в сторону IDynamicObject.  Если я правильно понял документ DLR Overview, то DLR 1.0 будет частью Common Language Runtime (CLR), выход которой уже не за горами.

Dynamic Language Runtime состоит из трех основных частей: 

  • Common Hosting - оперирует со скриптами (компиляция, парсинг, загрузка), включает в себя всю необходимую функциональность для работы со скриптами динамических языков.
  • Runtime - как видно из названия отвечает за выполнение скриптов, взаимодействие с COM, CLR.
  • Language Implementation - отвечает за механизмы, необходимые для реализации скриптовых языков.

 



Все это очень хорошо подробно описано в документации (DLR Overview и DLR Spec), которую можно скачать со страницы проекта.

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


Осталось реализовать ещё несколько методов... Сейчас допишу последнюю строчку... Проект пока что не компилируется... Ура! Вот эта заветная строчка в окне Output Visual Studio:

========== Build: 1 succeeded or up-to-date, 0 failed, 0 skipped ==========
 

 Теперь предстоит запустить проект. Но все не так просто. Часто для проектов, которые больше чем знаменитый "Неllo World!" и который пишет команда из нескольких человек, необходимы какие-то условия для запуска:

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

 

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

Но тут к нам приходит на помощь всеми (не)любимая компания Microsoft со своей утилитой MS Build, которая достаточно хорошо интегрирована в Visual Studio. Msbuild.exe запускается каждый раз при сборке проекта или солюшена. 

Посмотрим на свойства проекта на вкладке Build Events.  

 

 
Здесь мы видим две основные его части: Pre-build event command line и Post-build event command line. Для запуска команд до и после билда соответственно. Замечу, что Post-build может выполняться всегда, только при успешном билде или же в случае когда проект при сборке изменяет Output.
При редактировании  Pre-build Post-build событий, нам доступны некоторые макросы, часть из которых можно просто выбрать в окне радактирования события, а остальные детально описаны в MSDN.
 
 



Перейдем к практике и напишем команду, которая будет выполняться после успешной сборки проекта. Допустим у нас в solution есть два проекта: консольное приложение и библиотека с классами.

 


  
Вот только, почему-то, MyClass из проекта MyClassLibrary использует CustomData.xml, предполагая что этот файл будет находится в той же папке, где находится наш solution. Поэтому, если просто добавить ссылку в проекте BuildEvents на проект MyClassLibrary, то ничего у нас работать не будет. Исправляем это добавлением Post Build event commad в проект MyClassLibrary:

 copy $(ProjectDir)\CustomData.xml $(SolutionDir)

Собираем solution и получаем:

------ Build started: Project: BuildEvents, Configuration: Debug Any CPU ------
BuildEvents -> d:\Projects\Samples\BuildEvents\BuildEvents\bin\Debug\BuildEvents.exe
------ Build started: Project: MyClassLibrary, Configuration: Debug Any CPU ------

...

Compile complete -- 0 errors, 0 warnings
MyClassLibrary -> d:\Projects\Samples\BuildEvents\MyClassLibrary\bin\Debug\MyClassLibrary.dll
copy d:\Projects\Samples\BuildEvents\MyClassLibrary\\CustomData.xml d:\Projects\Samples\BuildEvents\
        1 file(s) copied.
========== Build: 2 succeeded or up-to-date, 0 failed, 0 skipped ==========

 Все успешно собралось и файл скопировался - в этом можно убедиться, открыв в проводнике папку с нашим solution. Теперь, если посмотреть содержимое файла MyClassLibrary.csproj, то увидем такие строчки:

<PropertyGroup>
    <PostBuildEvent>copy $(ProjectDir)\CustomData.xml $(SolutionDir)</PostBuildEvent>
  </PropertyGroup>
 

Выше была описана выдуманная мной ситуация. Из практики столкнулся с таким: все config-файлы хранились в одной папке, а при сборке они копировались в Bin-папки проектов.


Пока все делятся впечатлениями от новинок, представленными на MIX09, я решил написать о Microsoft Sync Framework. Исходя из того, что сказано на их сайте, можно синхронизировать всё.

Microsoft Sync Framework – a comprehensive synchronization platform enabling collaboration and offline for applications, services and devices with support for any data type, any data store, any transfer protocol, and network topology.

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

MicrosoftSync Framework предоставляет нам готовый механизм синхронизации данных. Вот только не все так хорошо, как кажется с первого взгляд. Каждый, кто сталкивался с такой необходимостью, знает, что для синхронизации данных нужно каким-то образом определить, были ли эти данные синхронизированы раньше, изменились ли они после этого или нет,а так же нужно определить какие данные нужно синхронизировать, а какие - нет. Для этого MicrosoftSync Framework добавляет к сущности, которая нуждается в синхронизации дополнительное  поле timestamp (имя и тип можно менять в зависимости от реализации сущности). Поэтому, если в проекте уже есть готовая база данных, то необходимо будет добавлять к ней в таблицы, требующие синхронизации, дополнительные поля, что не всегда можно сделать.

На сайте MicrosoftSync Framework уже есть готовые примеры для синхронизации коллекций объектов, баз данный, outlook и устройств, под управлением Windows Mobile. Примеры легкие в понимании и позволяют после незначительных изменений использовать их у себя в проекте.


It Works!

Published 3/18/2009 by e0ne in Blog

После значитального перерыва блог снова возобновил свою работу. Теперь, наконец-то он расположен на нормальном хостинге. До этого он находился на моём домашнем сервере и временами не работал (выключили свет, завис комп, забыл заплатить за инет), но после смены провайдера пришлось расстаться с выделенными IP-адресом, а платить за свой домен на сервисах, предоставляющих dynamic dns не хочется, пришлось задомуться о покупке хостинга. Банально, но решающим фактором оказалась цена. Выбор пал на наш украинский hosting.ua. После двух недель использования жалоб на него нет, хороший, почти круглосуточный (на некоторые вопорсы можно получить ответы по Skype или MSN круглосуточно, но на более технические вопросы через панель управления мне отвечали в течении рабочего дня) саппорт.

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