Нужно будет вернуться. Интересный город в плане выйти-погулять.

К тому же я так и не узнал доподлинно, как же звучит люксембургский язык :)

Несколько фотографий здесь: http://picasaweb.google.be/alexey.raga/Luxembourg

В прошлые выходные съездили в Keukenhof, это городок в Нидерландах, в 45 километрах от Амстердама.

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

Фоторезультаты этого гуляния можно пронаблюдать здесь: http://picasaweb.google.be/alexey.raga/Keukenhof

Собственно, больше ничего писать не буду, фото говорят сами за себя.

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

Руководитель проекта - это не "начальник программистов". 
На самом деле существуют три независимые "ветки одного дерева" - ПиЭмы, Разработчики и Тестеры. Независимые. Точно так же, как тестеры не подчиняются программерам и программеры не подчиняются тестерам, точно так же ПиЭмы не находятся в подчинении программеров\тестеров и программеры\тестеры не находятся в подчинении ПиЭмов. Вместо подчинения они все друг с другом сотрудничают.

И часто ПиЭмы сводят на нет всю идею собственной позиции, воспринимая себя как человеков, созданных для того, чтобы давать таски и спрашивать "как продвигается".

На самом деле ситуация становится гораздо продуктивнее, когда все три "ветви власти" работают в штатном режиме, каждый в своей зоне ответственности:

1. ПиЭмы - это зона бизнес-требований, бизнес-процессов, взаимодействия с клиентом. Эти требования и видение должны быть изложены так хорошо, чтобы все остальные участники проекта имели представление о том, чего нужно добиться в ходе работы над продуктом, а так же были поставлены в известность о рисках проекта. Исходя из этих данных строится весь процесс разработки продукта.
2. Разработчики - это зона архитектуры приложения, концепции, разработки прототипов, разработки и поддержки продукта.
3. Тестировщики - именно их (а не ПиЭмов) зона ответственности состоит в том, чтобы сказать "продукт готов".
   Неправильно воспринимать тестировщика как человека, работа которого заключается в том, чтобы проверить "кнопка кликнул - бага нету". Тестировщик, в числе прочего, ответственен за проверку того, насколько тестируемый продукт или фича соответствует духу тех требований, которые (через ПиЭма) были получены от кастомера. Тестировщик - это некий "эмулятор" кастомера, он может (и должен) возражать не только против возникающих исключений, но и против нелогичного содержания форм, против неинтуитивного интерфейса, неполного покрытия нужд клиента. Даже если формально все требования выполнены и все фичи реализованы, тестировщик в праве сказать, что в реальной работе программа должна вести себя иначе.

То, насколько именно тестировщиком (и всей командой) понята концепция этой самой "реальной работы" - вот одна из задач ПиЭма.

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

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

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

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

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

делать неправильно ;) К сожалению, это очень часто встречается...

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

Некоторое время я "ковырялся" в бесплатном софте типа VirtualDub, MediaCoder и т.д, но понял, что это не для меня.

Ни один из встреченных мною бесплатных продуктов не умел делать работу полностью - от захвата видеоизображения и до получения результата. Так, например, VDub умеет делать захват, кое-какой процессинг, но в нем совершенно невозможно делать даже самый простенький (многого мне не нужно) монтаж... Кроме того, мне не удалось заставить его, например, кодировать результат с помощью кодеков из Windows Media SDK 11.

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

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

Все это жутко нудно и неудобно, поэтому я снова стал смотреть в сторону платного софта (в самом начале эпопеи я перепробовал практически все триалы, какие нашел).

Выбирал из трех вариантов бюджетных продуктов:

1. Pinnacle Studio
2. Ulead VideoStudio Plus
3. Sony Vegas Studio

Первым "отпал" Пинакл по причине своей капризности, нестабильности и требовательности. Ну и интерфейс там странный, но это уже придирки :)

В борьбе Юлида и Сони Вегаса победил Юлид. Он продемонстрировал бОльшее количество "фич", кроме того, к нему есть патч, созданный специально для "понимания" моей камеры.
К тому же очень понравилась технология SmartProxy, при которой для работы в редакторе (предпросмотра и т.д.) в фоновом режиме создается "уменьшенная" копия видеопотока (разрешение можно задать самому). Благодаря этому редактор работает быстрее, так как для предпросмотра в окошечке и на таймлайне ему не приходится обрабатывать для меня весь HDV-поток.

После оплаты (благодаря PayPal это заняло пару минут) я получил не только сам VideoStusio Plus но и еще всякие пакеты с бонусами и дополнительными возможностями (типа Cool3D). То есть, вместо 2-х инсталляционных файлов мне предоставили аж 9 оных, приятно :)

Пойду сносить триалы, устанавливать все это дело и, наконец, обрабатывать видео с того же Мон-Сан-Мишеля и Парижа :)

Я уже писал о том, что такое DSL и Software Factories, как выражается второе через первое и т.д.

Теперь вы можете увидеть это своими глазами на примере Services Software Factory V3.
Причем, именно увидеть: здесь разработчики выложили видео (рекомендую скачать, всего 11 мегабайт, но виднее) о том, как будет работать следующая версия их фабрики.

Отличия в частности в том, что в данном случае мы будем иметь "классический" DSL вместо обычного для фабрик набора указаний "сделай то-то".

Лично мне этот вариант кажется более логичным, гибким и удобным.

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

Как я уже писал, в прошлые выходные съездили во Францию, в Нормандию, в совершенно замечательное место - Mont Saint Michel.

Что это такое лучше всего видно на фотографии:

Это монастырь, построенный на острове, на скале высотой около 80 метров. Примечательно то, что монастырь этот был построен потому, что этого настоятельно требовал архангел Михаил. Именно настоятельно, так как ему пришлось при этом трижды сниться епископу Альберту и убеждать его в необходимости сей постройки. Сам же епископ вовсе не горел желанием что-либо строить в такой "дыре" и полагал, что его сны есть не более, чем ночные видения. И тогда Архангелу Михаилу пришлось действовать более радикально: приснившись епископу в очередной раз он нажал пальцем на лоб спящему, да не просто нажал, а сделал там нехилую вмятину размером с монету. Череп епископа с этой самой вмятиной, кстати, хранится в музее и его можно увидеть.
Естественно, после этого бедному Альберту пришлось идти и строить.. А то кто знает, на что он там в следующий раз нажмет...
Словом, строили много лет и построили. Сегодня высота башни, с которой смотрит архангел Михаил, около 150 метров.

Представьте, как это было: практическии полная изоляция, два раза в сутки прилив-отлив, вода прибывает и убывает со скоростью около 20 км/ч, во время отлива море уходит километров на 15-20 от стен монастыря. Самая большая в Европе высота прилива - 9 метров - именно здесь.

Значительно позже строится дорога, соединяющая Mont Saint Michel с "большой землей", а до того поломники (а это одно из мест поломничества) добираются (те, которым везет) до цели во время отливов прямо по пескам.
Примерно вот так:

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

Интересен и тот факт, что Mont Saint Michel никогда не был захвачен силой, ибо на лодках подойти к нему невозможно по причине отливов, а держать осаду невозможно по причине приливов.

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

Еще пара фотографий:

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

P.S. Напоследок показавшийся забавным факт, рассказанный гидом: в окресностях Mont Saint Michel жители держат много барашков специальной породы - с серыми туловищем, черными ногами и черной головой. Так вот, поскольку эти самые барашки пасутся в такой вот местности, куда постоянно приходит море, мясо их имеет солоноватый вкус, оно мягкое и лишено характерного привкуса баранины.
Это мясо является одним из "фирменных" блюд этой местности, которое, при возможности, обязательно нужно попробовать.
К сожалению, у меня такой возможности тоже не было :(

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

Итак, релиз. Из основных улучшений и новшеств:

- Новые Application Blocks: Validation Application Block и Policy Injection Application Block (немного расскажу ниже)
- Поддержка .NET 3.0 (WPF, WCF)
- Data Access Application Block "научился" поддерживать транзакции и работать с SQL Server Compact Edition
- Некоторые изменения в Exception Handling Application Block и в Logging Application Block.

Коротко о новых блоках.

Valication Application Block позволит разработчику в декларативной форме (с помощью атрибутов или непосредственно в конфигурационном файле) задавать правила валидации свойств объектов. Работает это и в WinForms, и в ASP.NET и в WCF
Блок содержит набор уже готовых правил, таких, как валидация с использованием регулярных выражений, валидация даты (можно, например, задать правило при вводе даты рождения для проверки совершеннолетия пользователя), валидация по значению перечислений, длинны строки, null и т.д. Кроме этого можно создавать свои собственные правила.
Более того, правила можно комбинировать (OR и AND), а так же задавать различные наборы правил для различных контекстов. Так, например, правила валидации для интерфейса пользователя могут быть отличны от правил валидации при сохранении в БД.
Повторюсь, что наборы правил можно задавать с помощью атрибутов, а можно прямо в конфигурационном файле, то есть, без изменения существующего кода.

Policy Injection Application Block - позволяет разработчику контроллировать операции, осуществляемые над объектом. Например, можно задать правило, чтобы при вызове метода Hello класса World происходила запись в лог. Или, перед вызовом проверить какие-то условия (разрешен ли доступ, находимся ли в режиме онлайн и т.д), а после завершения вызова совершить какие-то действия (записать аудит, сбросить кеш и т.д.).
С помощью таких pre- и post- полиси мы можем управлять некоторыми аспектами поведения системы без модификации кода кучи методов (например, без вставки кода записи в лог в начало каждого метода).
В "наборе" блока имеется ряд полезных "хандлеров" (обработчиков):
Exception Handling Handler, Caching Handler, Performance Counter Handler, Validation Handler, Logging Handler, Authorization Handler. Используя эти обработчики можно в декларативной форме задавать правила, которые будут обрабатываться блоком.

В общем об инфраструктуре EL3 можно сказать еще и то, что "конфигуратор" теперь интегрирован в Visual Studio 2005. Не скажу, что это такое уж большое и важное изменение, но все же приятно :)

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

А пока буду думать о Нормандии :)