IDN (Internationalized domain name) – это имена доменов, которые могут быть представлены в виде имени, содержащем не только латинские буквы, но и буквы других национальных алфавитов, вроде русского, арабского, китайского и т.п. (на данный момент поддерживается не так много). Представлены – это ключевое слово, так как на самом деле хранятся и передаются они в виде Punycode строк. Например, у нашей любимой почты России есть сайт http://почтароссии.рф, а Punycode представление этого сайта http://xn--80aqavbdjjaf8c.xn--p1ai/. Это важно понимать, если вы будете в запросах своего приложения (используя WebRequest, например) писать хост как IDN представление, то это имя хоста не будет распознано (если у вас не какой-нибудь специальный DNS сервер), нужно заранее переводить его в Punycode строку.

Изучал тут как-то примеры книги Professional Twitter Development: With Examples in .NET 3.5, хотел разобраться как работает эта самая OAuth авторизация для твиттера. Раньше у меня на сайте было немного действий с твиттером, подгружались мой твитты, хранились, отображались, но потом твиттер что-то поменял в авторизации, вроде разрешил только OAuth, а в тот момент я что-то не шибко разобрался с этим OAuth, да и времени не было, хотя вроде еще тогда LinqToTwitter ее поддерживал (а я использовал именно эту библиотеку). В общем-то, просто в тот момент подумал, что тема OAuth авторизации интересна, и нужно бы посмотреть как она реализована в деталях попозже. Вот и набрел я тут недавно на книгу Professional Twitter Development: With Examples in .NET 3.5, точнее только на ее примеры, решил поковыряться. Код там был не из простых, и я просто тупо стал рефакторить его, чтобы разобрать что и как работает. Вот, например, одно из превращений, которое я уже правда публиковал в твиттере давно (и может быть вы уже видели):

Думаю, что даже уже начинающий разработчик должен быть знаком с понятием Inversion of Control (сокращают как IoC). Любой проект сейчас начинается с выбора фреймворка, при помощи которого будет реализован принцип внедрения зависимостей. Если взять русскую википедию, то там определение для IoC выглядит следующим образом:

Инверсия управления (Inversion of Control, IoC) — важный принцип объектно-ориентированного программирования, используемый для уменьшения связанности в компьютерных программах и входящий в пятерку важнейших принципов SOLID.

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

Для .NET платформы, как и для любых других платформ, есть огромное разнообразие библиотек, которые можно использовать в проектах: Unity, StructureMap, Ninject, Castle Windsor. Это только часть, которую я вспомнил на данный момент, но есть и еще немалое количество, помню даже кто-то из знакомых писал свой. Для бизнес проектов, ну и для проектов, бинарники которых вижу только я, мне хватает этих библиотек, да более того мне хватает только Unity. Но вот, если хочется написать какую-нибудь утилиту или приложение для общественности, либо библиотеку, то написав приложение в 100 килобайт тянут за ним еще по 300 килобайт библиотеки для записи логов и 300 библиотеки, реализующей для тебя IoC немного дико. И дико иметь привязку на какую-то специфичную реализацию IoC, особенно, если вы распространяете библиотеку, ведь ваши пользователи могут держать в привычке использовать совершенно другую реализации IoC. А в случае приложения дело даже не в размере, а в том, что у вас вместо всего одного exe файла будет поставляться еще гора каких-то непонятных библиотек (все зависит конечно еще от того, как будете распространять свое приложение). Есть, конечно, еще и простое решение, можно объединить все ваши бинарники приложения при помощи утилиты ILMerge.exe в один exe файл. Ну а все-таки, если дело в размере? Хочется, чтобы приложение было действительно очень небольшим в размерах.

Передо мной встала задача, нужно было бы собрать все события объекта и подписаться на них (подписать определенный метод), только в том случае, если на это событие не подписан кто-то еще. Я могу даже больше сказать, делал я это для классов-оберток, которые генерирует Visual Studio на Add Reference Service…. Используем мы их по стандартному, как и все, наверное. Используем в коде не сами классы-обертки, которые генерирует Visual Studio, а используем свои реализации, которые нам предоставляют возможность тестировать наши модели, подставляя Mock и Stub объекты вместо самих реализаций. Давайте лучше покажу на примере.

Заголовок для этой заметки достаточно сложно было придумать. Проверка наличия подписчиков – это все-таки малая сердцевина того, что я тут описываю, но я думаю это просто самая интересная часть. В целом, я тут описываю вариант обработки результатов от методов сервисов в Silverlight приложении.

Недавно внедрил в проект Entity Framework 4. Надоело писать все на хранимых процедурах. Конечно, что-то можно и нужно делать на хранимых процедурах, но что-то быстрее и проще можно сделать с помощью ORM. Может встать вопрос, почему не nHibernate? Очень просто. nHibernate велик и всемогущ, но у него нет дизайнера. У нас очень простая бизнес логика, потому все прелести такого ORM нам не нужны. Честно, хватило бы и LINQ to SQL, но остановились на Entity Framework потому что: “а мало ли?”. Начал использовать я дизайнер, и первое с чем столкнулся – дизайнер, генерируя по базе, по связи многие-ко-многим (через таблицу связи) так и связывает сущности в дизайнере связью многие-ко-многим, а мне бы хотелось все-таки оставить промежуточный объект (вроде одно из отличий EF от LINQ to SQL, что есть поддержка связи многие-ко-многим, а мне не нравится). Полазил в интернете и единственное решение, которое нашел, было – добавить в промежуточную таблицу еще какое-нибудь поле, тогда все будет хорошо. Такое решение мне не подходило, и, конечно же, не хотелось мне лезть в XML файлы маппинга и править там все руками.

Первый раз достаточно близко я познакомился с тестированием лет 5-6 назад, как раз начало моей карьеры. Тогда, я помню, мне рассказывали про покрытие кода тестами. Причем никаких Unit тестов меня не просили писать, просто говорили: “вот видишь if с тремя условиями, который ты написал, ты должен проверить все эти три условия”. Подразумевалось, что я, после того как напишу код, должен его проанализировать, и полностью протестировать обычным проходом по интерфейсу приложения. Как вам? Со временем знания в тестировании у меня немного выросли, я немного научился писать тесты. Я до сих пор не видел и не участвовал ни в одном живом проекте, написанным при помощи Test Driven Development (TDD) подхода. Основа моих знаний была в подглядывании того, как делают это коллеги в предыдущей моей конторе, чтении статей (например, у Алесандра Бындю была отличная статья “TDD для начинающих. Ответы на популярные вопросы”), просмотра пару сринкастов. Я решил покончить с безграмотностью и проникнуться темой, для этого я сел за прочтение книги The art of Unit Testing with Examples in .NET. Притом, что в текущей конторе? можно сказать, что тесты пишу только я для своего кода. Нужно быть образцом.

Прошло уже более месяца с того момента, как я начал использовать Code Contracts в проекте нашей компании, и как я написал статью о них Небольшой пример использования Code Contract. Хочу порекомендовать документацию с сайта Microsoft Research, если еще не читали.

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

Признаюсь честно, что с темой Code Contract в .Net 4 я знаком давно, но вот реально ее использовать мне что-то не очень-то хотелось. Привык я к простым и обычным проверкам, вроде

if (argument == null) 

    throw new ArgumentNullException(“argument”)

А вот большого плюса от контрактов я не увидел. И вот недавно переставлял себе Windows из-за счастливого приобретения Intel® X25-M, и так получилось что случайно выбрал в фиче R# или Visual Studio 2010 при щелчке на классе левой кнопкой мышки при удержании Ctrl переход на метаданные, а не как обычно Object Explorer. И вот как-то перейдя на один из классов System.xxx попался мне исходный код (метаданные) одного из базовых классов .Net, там я заметил, что контракты распространенно используются в базовых классах фреймворка. Кстати, кто-нибудь знает как сделать так, чтобы при щелчке на классе с зажатым Ctrl все-таки переходить в Object Explorer?

Пару дней назад мне попался на форумах GotDotNet вопрос [C# + WPF] Отлов нажатий клавиш, хуки, горячие клавиши в проекте WPF, зашел туда, посмотрел, и в голове всплыло, что год назад я реализовывал похожее на WinForms, регистрировал глобальные клавиши в системе для приложения. Делал я это для проекта Vista Keys Extender. Так как я на 100% помнил, что у меня там все работало, я сразу предложил автору вопроса посмотреть на тот мой проект, чтобы найти нужное решение. Однако, мой проект не подошел для решения данного вопроса, так как в WPF работа с сообщениями реализовано по-другому. Все же я решился помочь автору в этом вопросе и разобраться с данной проблемой. Отталкиваться я начал опять же с моего проекта, шаг за шагом разбираясь, что нужно изменить и как.

Пару недель назад я писал про небольшую утилиту Config Transformation Tool, которую я создал на базе задачи трансформирования web.config файла. В тот момент у меня сразу же возникла идея, что было бы неплохо еще иметь возможность указывать места в файле-трансформере, вместо которых можно было бы подставлять значения при помощи этой утилиты. И вот, сегодня я готов объявить, что мне удалось решить эту задачу. Сначала хотелось бы поблагодарить AlexBar, за то, что он порекомендовал посмотреть глубже при помощи .Net Reflector в недры библиотеки Microsoft.WebApplication.Build.Tasks.Dll, и отыскать там класс Microsoft.Web.Publishing.Tasks.XmlTransformation, который умеет выполнять XML-Document-Transform для строк. Мне это очень сильно упростило реализацию. Чтобы утилита смогла поддерживать параметры мне предстояло решить две задачи: (а) уметь пробегаться по файлу и подставлять значения вместо параметров, (б) уметь парсить командную строку на предмет передачи параметров со значениями.