PostSharp Thread\Dispatcher Toolkit

Сложность 100

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

Итак, сегодня в программе тулкит, который позволяет с помощью атрибутов указать выполнение метода в отдельном потоке, а так же указать какие методы вызывать в потоке UI. Собственно вот и весь функционал.

О том как решаются эти проблемы в «традиционном» стиле, я рассказывал в статье про эволюцию сервисных методов, там же описана библиотека MakeMeAsync, которой я с удовольствием и активно пользуюсь на данный момент. Не буду повторятся какие альтернативы существуют. Сейчас уже официально выпущен .Net Framework 4.5 c поддержкой конструкции async\await, так что я надеюсь что использование монструозных конструкций для выполнения кода асинхронно будет сходить на нет.

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

Подробнее

App Crash Handler

Может быть, вы замечали у себя в системе процесс GoogleCrashHandler.exe, который постоянно работает, появляясь в системе с установкой браузера Chrome. Долгое время где-то в подкорке постоянно крутилась мысль о том, как же он может работать. Интуитивно мне было понятно, что это относится к браузеру, что этот процесс отслеживает падения браузера и отсылает отчеты с параметрами падения, чтобы инженеры в Гугл могли оценить причины прекращения работы и принять какие-то решения по улучшению работы. Я не поддерживаю конспирологические теории на счет того, что с помощью этого процесса собирается приватная информация о пользователе.

Скриншот не с моей машины.

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

Исходя из названия и общей идеи мне стало интересно сделать свой «велосипед», так как коммерческие решения на рынке существуют, а вот о бесплатных я как-то не слышал. Да, есть программы у Microsoft (бесплатно) или у RedGate (платно), по которым тебе будут высылаться все отчеты об ошибках, которые возникли во время работы, но для этого нужно, чтобы пользователь нажал на кнопку «отправить данные». Зарегистрировать свою программу у вендора для участия в таком сборе. В корпоративном секторе, когда разработка внутренняя и градус паранойи повышен, такие варианты слабо прокатывают – все должно быть внутри и за пределы компании не выходить из соображений безопасности.

Идея

Почему это может быть важно для вас?

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

  • анализировать частоту возникновения ошибок
  • тип ошибок
  • можно сразу реагировать на ошибки, так как не требуется письма или звонка пользователя
  • писать автоматизированные отчеты о критических ошибках на основе данных в БД

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

Подробнее

TFS Aggregator

Или как автоматизировать некоторые действия в TFS 2010.

Сразу скажу, что для TFS 2012 автор обещает быстро выпустить обновленную версию, однако, на мой взгляд, с учетом того, что API не поменялось или мало поменялось, то данный небольшой проект вполне может завестись и на новом TFS 2012 RC.

Идея

Последние статьи повествуют о настройке шаблонов процессов для TFS, но данные шаблоны оторваны друг о друга, по сути, хотя и связываются в работе связями типа: Child, Parent, Related To и так далее. Было бы логично использовать эту связь, для добавления интерактивности во всю схему, чтобы элементы действительно были связанны, чтобы они действительно реагировали на состояния друг друга в зависимости от типа связи и состояния. Чтобы можно было делать некоторые аккумулирующие подсчеты в метриках, ведь все эти данные доступны и их можно использовать в автоматическом режиме, сокращая время рутинных действий.

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

Например, представим себе ситуацию, когда пользовательская история имеет полный набор артефактов и готова к работе, созданы конкретные задания для реализации этой истории. В данной ситуации история находится в состоянии Ready For Development, а все задачи в состоянии Proposed. Разработчик берет задачу в работу, меняет ее состояние на Active. Далее он должен поменять состояние истории на WIP (Work In Progress). Однако этот шаг ведь можно автоматизировать! А автоматизация в свою очередь ведет к большему порядку и красоте. Т.е. как только разработчик взял задачу в работу, состояние всей истории поменялось автоматически!

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

Так же полезным функционалом было бы, когда все задачи решены, то статус истории автоматически переходит в состояние Resolved.

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

Подробнее

Make me async

Сложность 200

Почти месяц назад я написал статью «Эволюция сервисных методов». В ней я пришел к реализации библиотеки MakeMeAsync, которая позволяет декорировать вызовы методов, делая их асинхронными. При этом код остаётся максимально читабельным и чистым, на мой взгляд.

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

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

Итак, я думаю, что для начала стоит обновить информацию о том, как используется библиотека MakeMeAsync.

Подробнее

Эволюция сервисных методов

Сложность по шкале Microsoft 200-300

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

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

Простейшие

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

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

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

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

Подробнее

Сообщения с таймером

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

Задумка

Я думаю, что если подумать, то все вспомнят о статусной строке в приложении, где часто пишется состояние программы, уведомления о завершении каких-либо фоновых задач, другая интересная информация о работе программы. Еще можно вспомнить о программах, которые показывают информационное сообщение пользователю в каком-либо специальном месте на интерфейсе, а через какое-то время (секунд 5) надпись исчезает. Учитывая последние тенденции к тому, чтобы избавлять пользователя от popup-окон, в которых написано что-то в духе: Данная операция не может быть совершена, так как она в процессе выполнения, — и на всплывшем окне только одна кнопка OK. Раздражает такое поведение неимоверно, так как приводит к лишним действиям! В общем, сегодня я покажу, как можно реализовать набор классов для реализации такого поведения и использовать его в дальнейшем без существенных модификаций.

Неискушенный читатель наверно может воскликнуть: «Что за бредятина, какие еще  наборы классов для того, чтобы сделать два set’a строки? Надо показать сообщение, так присвоил переменной сообщения нужный текст, когда не надо – присвоил пустую строку. Any problem?»

Если кратко, то проблем много! Сейчас попробую перечислить их, как они придут в голову:

  • Много инфраструктурного кода получится, ведь надо будет вводить таймеры, ответы и наверняка что-то еще. И это каждый раз при попытке сменить текст.
  • Надо запоминать предыдущий текст в сообщении, если он был.
  • Легко запутаться что, где и зачем реализовано. Скорее всего, будет много копи-пасты, а следовательно больше мест для ошибок.
  • Некрасиво!

Лично для меня хватило только первого пункта из-за моей профессиональной лени.

Подробнее

Тестирование событий с помощью Moq

Вообще название статьи опять очень длинное на самом деле, что-то в духе: Тестирование сложных сценарий с событиями на примере Moq, связыванием StructureMap, построением объектов с помощью NBuilder, и проверки условий с помощью FluentAssertions. Но согласитесь, что это как-то чересчур и надо что-то выбрать одно, а то перечислять все технологии в заголовке плохо. Особенно когда рассматриваешь пример не простого приложения типа Hello World.

При тестировании real-life приложения возникает очень много вопросов по реализации и использовании технологий, которые обычно не рассматриваются в обзорных статьях, которые копипастятся друг у друга блогерами и агрегаторами статей. Надеюсь, данная статья прольет свет на некоторые аспекты использования упомянутых технологий.

Подробнее

BLToolkit. Intro — II

Хранимые процедуры

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

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

Подробнее

BLToolkit. Intro — I

Уже достаточно давно меня интересует тема CQRS, но пока что все останавливалось на изучении документов, примеров и самому написать что-то используя подход CQRS не доводилось. В последние дни работа в этом направлении активизировалась с новой силой, и пошлел процесс по исследованию инструментов более всего пригодных для реализации этой концепции. Наверно так повлияла конференция Patterns’n’Practices, когда было объявлено что к концу года команда выпустит гайдлайны по реализации CQRS на практике.

Одной из ключевых вещей является непосредственное получение информации из базы данных без промежуточных программных слоев. Такое получение данных должно быть быстрое и простое. Простое и быстрое. По многочисленным источникам и по результатам сайта ORM Battle был выбран для экспериментов BLToolkit.

Насчет скорости работы есть диаграмма сравнения с другими фреймворками на 30 июля 2011 года:

Не могу не вспомнить фразу с презентации на NDC2011 по поводу Kill your ORM, где ведущий высказался в таком духе: «Linq2Sql вышел слишком простым и быстрым, поэтому придумали EF. Больше абстракций!».

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

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

Подробнее

Eloquera and WPF

Во время экспериментов с объектной базой Eloquera, я столкнулся с одним очень неприятным эффектом, который меня напрягал в течение месяца наверно или даже больше. За это время я успел замучать самих создателей базы, отписался на официальном форуме DevExpress, даже вовлек в эту котовасию Дона Смита после конференции Patterns’n’Practices и его коллег. В итоге, после многочисленных писем со стэк-трейсами и примерами кода, проблема была решена. Но обо всем по порядку.

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

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

Здесь за переменной content скрывается StackPanel, так что приводить код основной формы не стоит.

Далее начинаются волшебные вещи, которые можно было охарактеризовать фразой из старинного анекдота: «Если я тебя по голове ударю, у тебя шнурки развяжутся?», так вот шнурки развязывались. При создании экземпляра класса базы данных Eloquera, выкидывалось сообщение о невозможности найти визуальный компонент в библиотеке CustomControl. Такое поведение характерно только для работы базы в конфигурации Desktop.

The component ‘CustomControls.ExternalDllControl’ does not have a resource identified by the URI ‘/CustomControls;component/externaldllcontrol.xaml’.

Дальнейшая работа была невозможна. Ошибка происходила в независимости от того, в каком потоке создавалось соединение с базой данных.

Проблему можно было обойти перенеся все компоненты в исполяемую сборку, но это было частичное решение и работало только если не использовались визуальные компоненты третьих сторон, с которыми могли произойти те же самые сложности.

О причинах такого поведения

После долгих расспросов и копаний обнаружилось, что проблема была в механизме обнаружения хранимых процедур, которые появились в версии 4.1, но задел к которым был наверно уже с версии 3.4.1. Данный механизм автоматически сканирует библиотеки в директории по умолчанию и загружает их в пространство памяти сервера. Таким образом, сервер пытался отъесть все библиотеки, и если остальному коду было все равно, на то какой у них codebase, то с WPF такой фокус не прокатил.

Решение

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

Изменить путь до хранимых процедур можно декларативно в коде, причем сделать это желательно как можно раньше, до загрузки визуальных компонентов. Я поместил код в App.

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

 

Hard’n’Heavy!