Вложенные web.config-и

Искал-искал, как сделать аналог include в app/web .config - и наконец нашел. Начиная с .Net 2.0 у конфигурационных тегов есть малоизвестный атрибут configSource.

Вот что о нем написано на MSDN: http://msdn2.microsoft.com/en-us/library/ms228167(VS.80).aspx

Script#

НЕ МОГУ ПОВЕРИТЬ

существует компилятор C# -> JavaScript

http://www.nikhilk.net/ScriptSharpIntro.aspx

Это может быть убийцей Google Web Toolkit :-)

Скачал, засел разбираться...

UPD: http://code.google.com/p/extsharp/ - C# programming for ExtJS

Утилиты для отладки веб-приложений

Как и всякий веб-разработчик, я нередко нуждаюсь в утилите, которая покажет мне трафик между веб-сервером и браузером. Особенно это важно, если разрабатываешь AJAX-приложение, а оно работает неправильно. Ну и бывает, нужно посмотреть, как работают приложения других разработчиков :-)

Раньше, я использовал Proximitron. Это приложение Windows, которое изначально предназначно для фильтрации всякого рода рекламы, pop-up-ов и проч. Ну и заодно, показывает HTTP трафик.

Но Proximitron давно не обновлялся, да и настраивать каждый раз параметры proxy в браузере мне было очень лениво, и я стал искать замену...

Devolutions.HTTPSpy

Почти сразу я нашел очень прекрасный и совершенно бесплатный (есть и pro-версия за $50) Devolutions.HTTPSpy.Net, который показывал мне HTTP трафик между локальной машиной и удаленным сервером.

Правда, у HTTPSpy есть один большой минус - он не умеет показывать локальный трафик. То есть, если я отлаживаю свое приложение локально - толку от него нет. И я стал искать дальше...

IEAnalyzer

Поиск выдал довольно коммерческих продуктов, которые встраиваются в браузер и умеют показывать локальный трафик. Одним из низ был довольно удобный HTTPAnalyzer, который сделали те же ребята, что и IEInspector. Скачал, поставил месячный evaluataion, все в нем понравилось, только 130 долларов платить было жалко.

Nikhil Kothari's Web Development Helper

И вот - о чудо! В книге Dino Esposito про ASP.NET AJAX я наткнулся на упоминание утилиты, которую написал один из разработчиков Atlas - Web Development Helper. Бесплатный и все умеет. Работает как плагин для Internet Explorer. Умеет, кроме трафика, показывать еще всякие другие полезности:

* Показывает ASP.NET ViewState

* Atlas JavaScript Class Browser

* DOM Browser

Очень рекомендую

Ссылка на статью, посвященную WDH: http://www.nikhilk.net/WebDevHelperDebuggingTools.aspx

Скачать: http://projects.nikhilk.net/Projects/WebDevHelper.aspx

IE Development Toolbar

Ну и напоследок, IE Development Toolbar от Microsoft. Тоже незаменимая штука. Посмотреть описание и скачать.

UPD 22 aug:

* Fiddler (free): http://www.fiddler2.com/fiddler2/

* HttpWatch ($200+): http://www.httpwatch.com/

UPD 19 jan 09

* еще можно пользоваться сниффером (http sniffer) - WireShark  (бывший Ethereal)

Command Line Arguments Parser

UPDATE Feb.09
Выложил парсер командной строки, которым мы пользуемся, в Google Code:
http://code.google.com/p/commandlineargs/

Собственно, сам пост

Разбираясь с исходниками NUnit, наткнулся на любопытный способ разбора параметров командной строки.

Вообще-то, не могу понять, почему в .Net Framework не предусмотрели классов для парсинга командной строки. Банальный же массив string[] args, который передается в Main(), для серъезного дела вообще никак не подходит. Вот и пишет каждый разработчик себе такой класс самостоятельно, потому что дело вроде плевое и импортить что-то чужое не хочется. Я вот тоже писал, и не раз.
Что нужно хорошему парсеру аргументов командной строки? Несколько вещей, на мой взгляд:
- поддержка опции /help. То есть утилита должна напомнить пользователю, как ее правильно вызывать
- поддержка именованных параметров, вне зависимости от очередности их расположения в строке вызова. То есть util.exe /console /admin должен интерпретироваться так же, как и util.exe /admin /console
- грамотная валидация. То есть утилита должна объяснить пользователю, что он ввел не так

Так вот, в NUnit используется класс Codeblast.CommandLineOptions. В нем используется интересный подход, суть которого в следующем:

Разработчик command line утилиты создает наследник класса CommandLineOptions, в котором описывает требуемые параметры командной строки просто как properties. Такие properties он помечает специальным атрибутом Option("..."), указывая описание свойства, которое потом автоматически сгенерируется и покажется пользователю.

Авторы (Gert Lombard и James Newkirk) в коментариях к коду дают вот такое описание возможных параметров:

// I define 3 types of "options":
// 1. Boolean options (yes/no values), e.g: /r to recurse
// 2. Value options, e.g: /loglevel=3
// 2. Parameters: standalone strings like file names
//
// An example to explain:
// csc /nologo /t:exe myfile.cs
//
// + parameter
//
// + value option
//
// + boolean option

Вот так этот класс применяется в NUnit console runner. Посмотрите на диаграмму классов:



Пользоваться таким парсером очень просто:

ConsoleOptions options = new ConsoleOptions(args);

if(!options.nologo)
WriteCopyright();

if(options.help)
{
options.Help();
return 0;
}

Решение, на мой взгляд, простое и зрелое - проверяется безопасность типов (при парсинге args[] проверяется PropertyInfo требуемых свойств) и использующему параметры коду уже не нужно беспокоиться об парсинге строковых значений, как это бывает в не столь красивых парсерах. Плюс к тому - описывать набор принимаемых параметров через атрибуты очень удобно.

Во всем этом великолепии, на мой взгляд, не хватает всего пары вещей

• Декларативного описания правил валидации. Ну например, через атрибут RequiredOption().
• Множественных layout-ов, когда в зависимости от значения какого-нибудь параметра изменяются требования к наличию-отсутствию других параметров. Можно сделать, например, через дерево классов-наследников CommandLineOptions.
• Неименованных параметров, чтобы можно было бы сделать так: util.exe /update Module1/src

UDDI

Кажется, в новом нашем проекте впервые придется использовать службы UDDI.

Вкратце - UDDI (Universal Description, Discovery, and Integration) применяют, чтобы сделать loosely coupled связывание различных систем при помощи веб-сервисов, ремотинга и тому подобной хренотени. Точнее - не само связывание, а управление связыванием, регистрация endpoint-ов и линков между ними в едином месте.

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

Сайт OASIS UDDI: http://www.uddi.org/

Антипаттерны "God Object" и "Big Hairy Object"

God Object
Wikipedia: http://en.wikipedia.org/wiki/God_object

“God Object” – это объект, который знает слишком много или делает слишком много.

Программисты создают Объект-Бога, когда не могут (не хотят) нормально провести объектно-ориентированную композицию. Объекта-Бога невозможно покрыть юнит-тестами, потому что у него огромное количество состояний и «завязок» на внешние сущности. Нельзя проверить какой-то один аспект его функциональности, потому что они намертво связаны с остальными.

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

Решение – покрывать юнит-тестами по чуть-чуть и делать рефакторинг. Желательно использовать для этого автоматизированные средства, такие как JetBrains ReSharper.

Big Hairy Object

Wikipedia: http://en.wikipedia.org/wiki/Big_Hairy_Object

Почти то же самое, но с огромным числом свойств и методов, напиханных «абы как», безструктурно.

См также:
Другие антипаттерны: http://en.wikipedia.org/wiki/Anti-pattern

101 Ways To Know Your Software Project Is Doomed

1. Management has renamed its Waterfall process to Agile Waterfall
2. You start hiring consultants so they can take the blame
3. The Continuous Integration server has returned the error message “Fuck it, I give up”

Еще читать: http://www.codesqueeze.com/101-ways-to-know-your-software-project-is-doomed/

Visual Studio 2005 for Database Professionals

Попробовал сегодня VS 2005 for Database Professionals. В целом - ощущения позитивные. Ты создаешь проект типа Database, в котором в 2-х режимах (при помощи sql скриптов или специального schema viewer) создаешь свою базу. Для каждой сущности - свой sql скрипт.




После этого пишешь скрипты для записи начальных данных в базу, настройки и т.п. А дальше - либо собираешь "инсталляционный" .sql, либо напрямую деплоишь в БД.




Как и должно быть, система позволяет отслеживать различия между исходной БД и базой назначения, создавать инкрементальные скрипты и т.п. стафф.




Вообщем - чуть-чуть кривенько (окошки моргают, притормаживает) но вполне бодренько.


Умеет работать с SQLServer 2000 и 2005. С Ораклом не умеет :-)

Как подключиться к MS SQL Server Embedded Edition

Век живи, век учись...

Оказывается, во всем утилитах для MS SQLServer 2005 при подключении к серверу БД можно вместо Server Name вводить имя named pipe. Например, это помогает подключиться к SQL Server Embedded Edition, в котором по умолчанию для standalone установки хранят свои базы SharePoint Services.

Для этого всего лишь надо в поле server name ввести "\\.\pipe\mssql$microsoft##ssee\sql\query"

В противном случае - пришлось бы ставить SQL Server Management Studio Express

Найдено тут: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=949426&SiteID=1

"квотирование атрибутов в XML" или "век живи, век учись"

Вот уж действительно - век живи, век учись. Оказывается, согласно Стандарту XML квотировать атрибуты можно как одинарными, так и двойными кавычками. Это значит, что xml вида



Вполне себе валидный. Вот что говорит стандарт:

Literals
[9]
EntityValue ::= ' " ' ([^%&"] PEReference Reference)* ' " ' " ' " ([^%&'] PEReference Reference)* " ' "
[10]
AttValue ::= ' " ' ([^<&"] Reference)* ' " ' " ' " ([^<&'] Reference)* " ' "

Такие дела. Я, когда xml с одинарными кавычками увидел, был на 100 процентов уверен, что он не валидный.

PS: А MS IE например, его открывает нормально, но показывает уже с двойными кавычками.

Как пользоваться LINQ или MS DAL

Ссылка на историю в 3-х частях о том, какой будет ORM DAL в .Net vNext

1. http://weblogs.asp.net/scottgu/archive/2007/05/19/using-linq-to-sql-part-1.aspx
2. http://weblogs.asp.net/scottgu/archive/2007/05/29/linq-to-sql-part-2-defining-our-data-model-classes.aspx
3. http://weblogs.asp.net/scottgu/archive/2007/06/29/linq-to-sql-part-3-querying-our-database.aspx