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 файл. Ну а все-таки, если дело в размере? Хочется, чтобы приложение было действительно очень небольшим в размерах.

Был у нас team leader (дальше просто лид). Тогда нас всех еще набирали на работу в компанию, где я сейчас работаю. Тогда намечалось создание нового продукта. Тогда нас брали, чтобы мы реализовали этот продукт. Перед тем как нас брали лид сделал правильную вещь, он остановился на модульной архитектуре, выбрал Prism, создал несколько модулей на клиенте, а на сервере под них сервисы. Раздал каждому разработчику по модулю (они практически были все независимы) и ждал результата. Очень все было верно, разработчики знали друг друга плохо, мы писали потихоньку код и знакомились.

Прошло уже более месяца с того момента, как я начал использовать 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?

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

Пару недель назад мне в руки попала бумажная копия книги Pablo Cibraro, Kurt Claeys, Fabio Cozzolino, Johann Grabner - Professional WCF 4: Windows Communication Foundation with .NET 4. По объему данная книга получилась не очень большая – около 400 страниц, честно говоря, уже забыл, когда видел такие “тоненькие” книжки по технологиям. Книга по объему не большая, но охвачено там достаточно интересных тем.

Первая глава – это паттерны и принципы создания SOA-приложений. Это, конечно же, лучшая глава в данной книге, видно, что у авторов есть опыт создания приложений типа Service-oriented architecture. Авторы описали всевозможные архитектурные принципы, по которым можно создать SOA-приложения. Причем они не опирались только на WCF, а постарались описать все принципе вообще, которые можно реализовать при помощи WCF, и для которых WCF не совсем предназначен. В общем, эта глава must read для всех, независимо от того, какие технологии вы используете. И по счастливому случаю wrox предоставил данную главу для ознакомления с книгой в свободном доступе на своем сайте Design Principles and Patterns. Всего 30 страничек, не поленитесь прочитать.

Вопрос, какую директорию создаст этот код?

string sole = DateTime.Today.ToString("yyyy/MM/dd");

string path = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, sole);

if (!Directory.Exists(path))

    Directory.CreateDirectory(path);

Для логгирования приложений, написанных под .NET большинство разработчиков используют log4net (а другие разработчики используют log4 под другие платформы). Но так, к сожалению, бывает не везде. Так, например, в нашем проекте до сегодняшнего дня мы использовали свою самописную библиотеку для логгирования. Была она, видимо, написана давно нашим team leader, но так как нас сейчас покидает текущий team leader, мы решили так же распрощаться с некоторым legacy кодом, который был дорог нашему лидеру, но который не особо то мы хотим поддерживать. Сразу уточню, что код написан отлично, и наш team leader – отличный кодер, но log4net имеет больше преимуществ, а текущий логгер нам приходится частенько дописывать функционалом, который уже давно есть в log4net.