Логово разработчика

В этом уютном логове я буду оставлять записи так или иначе связанные с разработкой программного обеспечения

    Вчера на TopCoder закончился 61-й марафон, первый, в котором я принял участие.
    Меня там заинтересовала проблема: даны вершины графа и ребра между ними, требуется написать алгоритм размещения вершин на плоскости таким образом, чтобы количество пересечений ребер было минимально.
    Прочитав описание задачи я подумал: "Хоу! Интересно, заодно освежу теорию графов!".
( Читать далее... )

    Не так давно мне понадобилось дерево вызовов операций с такой информацией, как имя сервиса, имя операции, имя пользователя, ip-адрес компьютера, время выполнения. Причем требовалось, чтобы она обновлялась в реальном времени.
    Сначала я смотрел в сторону стандартной трассировки. Если такую настроить на каждом сервисе, то потом можно собрать все файлы и с помощью утилиты SvcTraceViewer смотреть граф вызовов.
    Но в моем случае этот вариант не подходил, так как он не позволяет обновлять информацию в реальном времени, а также не предоставляет информацию информацию об имени пользователя, который вызывал операцию. Если к этому добавить большое количество сервисов (более 25-ти) - собирать эти файлы было бы не особо приятным занятием.
    Таким образом я решил написать свою собственную реализацию трассировки. ( Читать далее... )
    Исходники библиотеки, предоставляющей инфраструктуру для создания своей собственной трассировки, а также пример ее использования можно посмотреть в проекте WcfTrace.

    Сегодня разбирался с отменой рабочих потоков в Windows Workflow Foundation (WWF). Казалось бы: в чем тут может быть проблема?
    И действительно, если в проекте используется WWF 4.0 то проблемы нет - там есть метод CancelWorkflow, но что делать если версия более старая? В этом случае я столкнулся с тем, что каких-либо штатных механизмов отменить рабочий поток - нет, и как обычно пришлось придумывать что-то свое.
    Для отмены рабочего потока я решил использовать механизм отправки команд рабочему потоку, описанный мной ранее. Не буду описывать все мои размышления и поиски, лучше сразу опишу решение:

1. Рабочему потоку отправляется команда: "Отменить выполнение", которая также может содержать какую-либо другую информацию, наподобие имени пользователя или причины отмены.
2. Поток, получив эту команду - вызывает метод Cancel(ActivityExecutionContext), которая отменяет выполнение текущго Activity.

    Вроде бы все просто? Но в этом методе есть свои проблемы:

1. Если в рабочем потоке несколько действий на первом уровне, то будет начато следующее Activity.
2. Если действий нет, то поток завершится также, как если бы действие не отменяли.

    Для решения первой проблемы требуется, чтобы на первом уровне рабочего потока было только одно SequenceActivity, а остальные должны содержаться в нем. Ну а для того, чтобы отличить успешно завершенный поток от отмененного - я добавил обработчик события завершения последовательности действий потока, в котором записывается в Tracking некая информация о результатах завершения.

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

P.S. И что кстати за шумиха такая с этими функциональными языками?

    Есть у меня один сервис, предоставляющий данные и использующий в качестве ORM NHibernate. Его дергают запросами наподобие "Дай <Объект> УКоторого Свойство "Состояние" равно 5". Вообще он поддерживает довольно много операций сравнения, на основе которых создаются те или иные критерии для NHibernate, среди которых есть операция 'In', означающая: "Значение свойства содержится в коллекции".
    С этой операцией и возникла проблема когда начали ходить очень большие объемы данных. Она используется в запросах вида "Дай <Объект> УКоторого (Свойство1 в списке A) И (Свойство2 в списке Б)", где списки А и Б могут содержать большое количество элементов. Эти элементы передаются в Sql Server как параметры для хранимой процедуры sp_executesql, а на их количество существует ограничение - 2100. Следовательно если элементов в списках в сумме больше 2100 (на практике вернее 2000), то возникает исключение.

( Читать далее... )

    Решил тут описанный ранее кейс оформить ввиде предложения по улучшению TFS и отправить в Майкрософт.
Захожу на их сайт, например сюда, нахожу внизу страницы ссылку "Свяжитесь с нами", по которой иду дальше. Попадаю на страницу обратной связи, там вижу: "Если вы хотите подсказать нам, как улучшить наши продукты, то просто пришлите нам свое предложение.". Перехожу по ссылке "Предложение по продукту", и попадаю на страницу: "Как мы можем вам помочь?". Да не нужна мне помощь, я идею хочу предложить, вот только нет там ссылки на форму для фидбека, даже электронной почты нет.

    Столкнулся сегодня с интересной проблемой, связанной с Team Foundation Server (TFS): есть к примеру аналитик, ведущий разработчик клиентской части, ведущий разработчик серверной части и несколько обычных разработчиков. После общений с заказчиком, либо анализа предметной области аналитик понимает, что нужна определенная фича. Что он делает? Он заводит задачу, в которой описывает фичу, указывает ее приоритет, а исполнителем назначает к примеру ведущего разработчика клиентской части. Тот смотрит и понимает, что задачу надо декомпозировать, а также доработать серверную часть. Что ему делать в этом случае?
    Казалось бы - создать несколько подзадач, для части из них назначить испольнителями своих разработчиков, а для другой - ведущего разработчика серверной части, который тоже возможно декомпозирует их. После выполнения всех подзадач - декомпозированная задача считается завершенной. Все вроде замечательно, вот только нельзя такого в TFS сделать, а было бы красиво.

    На сайте CodePlex создал демонстрационный проект RetryActivity Sample. Там можно посмотреть на код RetryableActivity, о котором я писал ранее; увидеть пример его использования (RetryableCodeActivity); а также посмотреть как оно работает на тестовом примере.
    Кроме того в этом проекте есть пример использования ControlSequentialWorkflowActivity, не так давно описанным мной, ну и вообще кому-то может оказаться полезным глянуть на небольшую инфораструктуру, обеспечивающую работу всего этого.

    По прошествии какого-то времени после начала использования Windows Workflow Foundation столкнулся с проблемой: если в процессе выполнения рабочего потока возникало какое-то исключение (статус в базе не найден, с сервисом какм-нибудь временно связи нет), то он переходил в состояние Faulted, его состояние удалялось из базы данных и приходилось начинать все заново. Тогда-то я и подумал, что неплохо было бы вместо такого поведения - дать возможность повторно выполнить действие.

( Читать далее... )