Знакомство с Dynamic LINQ

- Dynamic LINQ, знакомьтесь, это мои читатели.
- Читатели, знакомьтесь, это Dynamic LINQ.    
                           Знакомство читателей с Dynamic LINQ

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

Язык программирования C# в отношении «строгости» типизации является скорее мультипарадигменым: его можно отнести к статическим языкам, однако он в значительной степени поддерживает и динамическую составляющую. Еще начиная с первой версии языка, вы могли достучаться к методу, свойству или полю по его имени с помощью механизма рефлексии, а с появлением ключевого слова dynamic (а точнее с появлением функциональности, скрытой за этим ключевым словом), этот процесс вообще здорово упростился.

Конфигурябельность

Повествование в художественном или разговорном стиле на компьютерную тематику дело не новое. Наверное, одним из первых и самых известных представителей этого жанра является Том ДеМарко со своей замечательной книгой "Deadline. Роман об управлении проектами". Вот и я решил опробовать этот стиль на себе и посмотреть, что из этого выйдет.

*****************

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

На очередном стендапе я стою себе в сторонке, никого не трогаю, народ в это время обсуждает куски какого-то проекта, и тут Славка (лид наш) вспоминает о моем существовании, поворачивается ко мне и говорит:
- Серега, ты же сейчас ни чем особым не занят?
- Да вроде бы нет, - осторожно отвечаю я. - Мне Мэт еще на той неделе обещал подогнать какое-нибудь разумное задание, но так и не подогнал, вот я сижу и дурью маюсь помаленьку.
- Отлично, - говорит Славка, - У меня как раз к тебе заданьице есть. Возьмешься?
- Ну, а чего ж не взяться-то, раз оно есть-то. Давай, конечно.
- Вот смотри, ты же в курсе, что мы переписываем этот Loader с плюсов на шарп? Так вот, заказчик аж кипятком исходится, так хочет, чтобы он был конфигурабельный. Ну, типа, мы в конфиге чего-то прописали, и оно уже как-то по-другому работает.
- Ну, ладно, - говорю. - Идея-то разумная, а что сильно часто им приходилось правки вносить? - спрашиваю.
- Да, х его з, - отвечает Славка, - Народ говорит, что запросов на изменения, дескать, вообще не было, ибо они в этот г#$@о-код даже лезть боялись. Так что я не в курсе, насколько это на самом деле пригодится, но точно знаю, что без конфигурябельности они никуда не хотят.
- Оки, дай мне денек, я поразбираюсь в коде старой системы и в том, что вы уже успели наваять для новой версии, да покумекаю, стоит ли прикручивать сюда эту конфигурабельность аль нет.

Книга Криса Смита «Программирование на языке F#»

Любая методология разработки, инструмент, технология или язык программирования привлекает к себе внимание по разным причинам. Это может быть нечто инновационное и тогда по прошествию десятка или двух лет (!), до него таки дотянутся руки всего остального компьютерного сообщества. Так было практически со всеми идеями, которым пришлось пройти длительный путь от конференций гиков до признания широкой общественностью. Другим способом ворваться в «мейнстрим» является поддержка уже известного вендора, например такого, как компания … Майкрософт. Большинство людей инерционны и не будут вкладывать свои силы в «нонейм» инструменты, пока не удостоверятся, что их капиталовложение будет востребовано. Если же инструментом занимается подобный вендор, то риск изучить что-то, что не пригодится в будущем, очень не велик.

На самом деле такое мнение весьма близоруко, поскольку при изучении нового инструмента, языка или технологии вы развиваетесь, узнаете что-то новое и включая способности применять эти подходы в другом контексте. Это особенно справедливо, когда речь касается новых парадигм программирования, таких как функциональное программирование, которое само по себе не привязано к конкретному языку или технологии.

Microsoft Moles

Moles – это легковесный тул от MS Research, который умеет автоматически генерировать заглушки для интерфейсов и виртуальных методов, а также для sealed классов, невиртуальных и статических методов (!), путем генерации кода, которому позднее можно будет подсунуть нужный делегат, вызываемый вместо определенного метода. Первый тип заглушек называется стабы (stubs), а второй – молы (moles). Именно эту штуку я использовал для тестирования асинхронных операций, о которых я рассказывал ранее, но давайте обо всем по порядку.

Stubs

Давайте рассмотрим такой пример. Предположим, что мы понимаем ценность модульных тестов, а также таких принципов, как Dependency Inversion, и других безумно полезных принципов и паттернов (может быть всех остальных принципов S.O.L.I.D., а возможно даже и F.I.R.S.T.). И дело даже не в том, что мы фанаты тестов или дядюшки Боба, а просто потому, что мы знаем, что высокая связность – это плохо. Поэтому мы стараемся в разумных пределах уменьшить зависимости путем выделения интерфейсов с последующим «инжектом» их в конструкторы классов или в методы, которым эти интерфейсы необходимы для выполнения своих задач.

Знакомство с асинхронными операциями в C# 5

• Часть 1. Асинхронные операции и AsyncEnumerator
• Часть 2. “Реактивные расширения” и асинхронные операции
• Часть 3. Знакомство с асинхронными операциями в C# 5

В прошлый раз мы говорили о том, как можно упростить работу с асинхронными операциями с помощью класса AsyncEnumerator Джеффри Рихтера, а также с помощью библиотеки Reactive Extensions. Однако, как поведал нам недавно Хейлсберг с компанией, счастье таки наступит с выходом новой версии языка C# и нам не понадобится использовать сторонние и не очень велосипеды, при работе с асинхронными операциями.

Идея, которая лежит в основе асинхронных операций в C# 5, очень похожа на ту, которую использовал Джеффри Рихтер в своем классе AsyncEnumerator, только на этот раз помимо нас с вами и старины Рихтера о ней еще узнал и компилятор (что здорово сказывается на вкусовых качествах сего синтаксического сахарка).  Для начала, давайте вернемся к синхронной версии нашего гениального примера, который мы использовали ранее:

static void SyncVersion()
{
    Stopwatch sw = Stopwatch.StartNew();
    string url1 = "http://rsdn.ru";
    string url2 = "http://gotdotnet.ru";
    string url3 = "http://blogs.msdn.com";
    var webRequest1 = WebRequest.Create(url1);
    var webResponse1 = webRequest1.GetResponse();
    Console.WriteLine("{0} : {1}, elapsed {2}ms", url1,
        webResponse1.ContentLength, sw.ElapsedMilliseconds);
 
    var webRequest2 = WebRequest.Create(url2);
    var webResponse2 = webRequest2.GetResponse();
    Console.WriteLine("{0} : {1}, elapsed {2}ms", url2,
        webResponse2.ContentLength, sw.ElapsedMilliseconds);
 
    var webRequest3 = WebRequest.Create(url3);
    var webResponse3 = webRequest3.GetResponse();
    Console.WriteLine("{0} : {1}, elapsed {2}ms", url3,
        webResponse3.ContentLength, sw.ElapsedMilliseconds);
}

“Реактивные расширения” и асинхронные операции

Часть 1. Асинхронные операции и AsyncEnumerator

Часть 2. “Реактивные расширения” и асинхронные операции

Часть 3. Знакомство с асинхронными операциями в C# 5

Прежде чем переходить непосредственно к работе с асинхронными операциями с помощью библиотеки Reactive Extensions (или Rx), важно понять причины возникновения этой библиотеки, и какие основные принципы положили разработчики в ее основу.

Одним из наиболее типичных отношений между двумя классами является отношение использования (“uses a” relationship), когда один класс используют функциональность других классов для решения своих задач. Мы с подобным отношением сталкиваемся ежедневно, даже не задумываясь о нем: наши классы используют строки, целые числа, классы работы с консолью, сетью, файлами и другими ресурсами. Говорят, что объект класса A взаимодействует (interact) с объектом класса B и получает (вытягивает, pulls) у него необходимые данные; такая модель взаимодействия называется pull-моделью (или интерактивной моделью) (рисунок 1а). С другой стороны, часто возникает ситуация, когда объект класса A не знает, когда будут доступны необходимые ему данные в классе B, и в таком случае гораздо удобнее, чтобы объект класса B «сказал» об этом самостоятельно и «вытолкнул» (push) некоторые данные, когда они станут доступны. В этом случае говорят, что объект класса А реагируют (react) на возникшие событие и соответствующая модель называется push-моделью или реактивной моделью (рисунок 1б) [Meijer RX1].

 
Рисунок 1а. Класс A взаимодействует с классом B

 
Рисунок 1б. Класс A реагирует на события от класса B

Pragmatic Podcast с Робертом Мартином

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

Вот и мне совсем недавно попался “прагматичный” подкаст с Робертом Мартином, "товарищем" достаточно известным, автором принципов S.O.L.I.D. (точнее этой аббревиатуры), нескольких книг, ну и вообще человеком с более чем сорокалетним стажем в нашей с вами области. Поскольку немалая толика этой известности приходится именно на аббревиатуру S.O.L.I.D. не удивительно, что в каждом интервью с участием "дядюшки" Боба ему задается этот вопрос. Но в данном случае мой интерес вызвало не то, что Роберт все таки помнит об этих принципах, а то, что этим принципам уже без малого 20 лет. По словам Роберта этот термин появился где-то в 1993 году в результате общения в USENET. Получается, что самому понятию понадобилось без малого десятилетие на то, чтобы обрести известность.