Составление и навигация в диаграммах

В видео ниже я делюсь своими соображениями по поводу составления диаграмм и навигации в них для удобного изучения схем.

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

Hard’n’Heavy!

Работа с MS Exchange — II

Составление строки поиска

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

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

  • Создаем необходимые фильтры
  • Объединяем их в коллекции по логическому использованию «И» или «ИЛИ»
  • Создаем специальные коллекции для использования

 

Я думаю, что основная идея, как это работает, ясна. Так же советую поэкспериментировать с разными критериями поиска.

Подробнее

Работа с MS Exchange — I

сложность 100-200

Когда ко мне пришла задача по вытаскиванию вложений из писем с нашего Exchange сервера, я весь внутренне содрогнулся, скривился и постарался откреститься от этой задачи, так как в памяти еще до сих пор свеж опыт работы с VSTO. Я думал, что это будет такой же кромешный ад и страдания в попытке разобраться в логике компонентов, что и для excel и word.

Первые предположения сделали за меня, подумав, что надо будет соединятся с Outlook и через него выдирать сообщения и вложения к ним. К тому письму приложили до кучи пример, мол вот уже все готово, только оформите нам службу красивую. В примере конечно же использовались обертки над COM, с заголовками с структурами работы с С++. С этим языком я работал только в университете и как-то мне не улыбалось снова к нему обращаться, так как не умею на должном уровне. Помимо самой реализации, с которой возникли бы большие проблемы при желании как-то расширить пример, а такие желания возникают обязательно, была проблема безопасности Outlook, который спрашивал разрешения пользователя каждый раз, когда бы служба лезла к ящику. Кроме того реализация не учитывала новые клиенты и Office 2013 шел лесом. В общем, косяков слишком много, чтобы делать что-то серьезное таким способом.

Мир не мог быть так жесток и пришло спасение в виде EWS Managed API от самой MS. Полностью управляемый код для общения с сервером Exchange, что на мой взгляд гораздо лучше для работы с почтой, чем использовать API Outlook.

Кратно о возможностях библиотеки:

  • Возможность создавать, читать, манипулировать всеми пользовательскими элементами сервера (письма, контакты, календарные события, правила).
  • Не требуется пакет офис на целевой машине
  • Автоматический поиск сервера. Т.е. вы вводите только имя пользователя, пароль и имя ящика, все другие необходимые данные для связи библиотека постарается найти сама, в точности как Outlook.
  • NTLM и явная авторизация.

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

Что будет показано в статье?

Я планирую показать далее следующие техники:

  • Поиск писем и папок
  • Создание и отправка писем. С вложениями.
  • Удаление писем.
  • Ответ и форвардинг писем.
  • Получение писем, уведомления, извлечение вложений.

Подробнее

С днем рождения, блог =)

Ура, ура, блогу исполнилось 3 года!

За это время много разного узнал и про многое написал, надеюсь, что и дальше буду регулярно писать в блог и радовать вас интересными статьями )

 

Удачи!

Создание проектов с NuGet и ReSharper

В этом видео я рассказываю как работать с пакетами NuGet, как их комплексно устанавливать. Как пользоваться ReSharper для добавления usings и почему я никогда не указываю используемые неймспейсы. Так же расскажу о некоторых подводных камнях.

 

Hard’n’Heavy!

 

 

Конвейер (Pipeline) — IV

Ближе к жизни

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

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

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

Подробнее

Конвейер (Pipeline) — III

Конвейер для больших массивов

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

До этого я специально взял количество данных в наборе равное четырем. Так как это еще разумное количество потоков для многопроцессорных машин. Для экспериментов приближенным к реальности можно взять количество элементов равным 60.

По сути код останется тем же, только надо увеличить количество элементов.

Линейную реализацию с перебором всех значений не будем рассматривать уже как совсем не интересную.

При работе с Task, замеры времени показывают среднее значение обработки в 51 секунду. Это означает, что все 60 потоков не создаются одновременно, а выстаиваются в какую-то очередь и все это безобразие занимает 51 секунду (разброс от 50 до 53 секунд), если использовать такой код:

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

Подробнее

Конвейер (Pipeline) — II

Конвейер для небольших массивов

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

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

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

Ничего сложного, но зато можно отследить порядок выполнения фаз. При прохождении через сервис, мы должны получить значение с постфиксом «smf».

Подробнее

Конвейер (Pipeline) — I

Сложность 200-400

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

Преамбула

Задача в общем смысле стояла примерно так:

  • С некоторой периодичностью приходят файлы данных в xml;
  • Файлы надо распарсить;
  • Проверить данные, контрольные суммы, верность указания справочников;
  • Отправить пользователю на проверку суммарные данные;
  • Сохранить данные в базу.

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

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

Подробнее