31 декабря 2009 года

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

ВСЕМ СОТРУДНИКАМ ОТДЕЛА

1. Какие умения и знания будут востребованы в 2010 году

2. Десять наиболее заметных логотипов 2009 года (мне показались интересными далеко не все)

 

3. Лучшие программные продукты 2009 года по версии Lifehacker’а

ВСЕМ РАЗРАБОТЧИКАМ

1. Что такое дамп, как его создать и что из него можно выжать

2. Думаю, что парень беспокоится за судьбу своего детища – MEF’а

3. Сертификаты в WiX’е (разработчики инсталляторов, рекомендую)

4. Использование редактора политик для ограничения доступа к дискам

5. Как стать фрилансером, не бросая основную работу

 

6. Не стану переводить…

 

7. Кто-нибудь помнит Химена (He-Man’а)?

8. ( Не только ) Запрещающие знаки 

9. Что-то мне эта программа напоминает… (песик к этому “напоминанию”не имеет ни малейшего отношения)

 

10. Двадцать трюков с PhotoShop’ом, о которых нужно знать

11. Вопрос, который возник у меня сегодня во время написания дайджеста – а почему сейчас наперебой рекламируются сайты, которые предлагают что-то сделать в онлайне? Например, бесплатно обследовать ваш компьютер на предмет наличия вирусов? Или бесплатно проверить конфигурацию вашего компьютера и выдать рекомендации по его настройке? Или предлагают бесплатное и супернадежное хранилище для ваших файлов? Кстати, сегодня же я прочел и предложение о надежнейшем хранилище ваших конфиденциальных данных… Это некая тенденция? А вот и пример — http://www.ma-config.com/en/home/

12. Сегодня – день рождения Анри Матисса (1869 — 1954). Я помню, как в Эрмитаже (а я в Эрмитаж ходил не на экскурсии, а отдыхать, гулять, особенно мне нравился третий этаж, на котором были выставлены полотна импрессионистов) я стоял перед его “Музыкой” и “Танцем”…

А вот его “Танец” —

13. А еще сегодня – день рождения актера Анатолия Кузнецова. Я думаю, все его знают как товарища Сухова.

Реклама

Подарок

Одна известная фирма поздравила меня с Новым годом. Несколько снимков этого подарка я решил выложить в блог.


Формат и содержание файла описания рабочих элементов в TFS’е (часть 2)

В предыдущей части мы рассмотрели общую структуру файла описания рабочих элементов и увидели, что в нем приводятся ссылки на файлы описаний типов рабочих элементов, ссылки на файлы, содержащие запросы, а также приведены задачи, которые превентивно выставляются разработчикам во время создания проекта. Думаю, что теперь любой разработчик при желании сможет самостоятельно определить и список рабочих элементов, и поставить задачи для проекта. Однако, пока еще непонятно, что же представляют собой непосредственно файлы описания типов рабочих элементов. В этой статье мы и постараемся разобраться, что к чему, каким образом взаимодействуют между собой элементы файлов. Главное, мы постараемся увидеть в Visual Studio значения элементов, описанных в файлах описания рабочих элементов.

Сразу оговорюсь, что я разобрал для сравнения всего лишь несколько файлов. Их содержимое, разумеется, показательно, но я не могу гарантировать, что описал все возможные варианты. Хотя, с другой стороны, в отсутствие какой-либо информации о схеме xml-файлов… Те схемы данных, которые я описываю, получены при помощи xsd. Кроме того, я не буду упоминать о тех полях, которые присваиваются автоматически, например, идентификаторах поля.

Итак, если взять файл, описывающий рабочий элемент, то мы увидим, что его содержимым является единственный элемент типа WITD (вероятно, Work Item Type Definition). Ниже приведены примеры этого элемента, взятые из разных файлов:

<witd:WITD application="Work item type editor" version="1.0"

xmlns:witd="http://schemas.microsoft.com/VisualStudio/2008/workitemtracking/typedef">

<WITD application="Work item type editor" version="1.0">

Думаю, понятно, что в данных случаях важен просто сам факт наличия элемента WITD. Внутри элемента WITD также находится единственный элемент типа WORKITEMTYPE. Единственным атрибутом этого файла является name:

<WORKITEMTYPE name="Task">

<WORKITEMTYPE name="SDL Task">

<WORKITEMTYPE name="Bug">

Именно эти названия и отображаются, когда мы пытаемся добавить в проект новый рабочий элемент, то есть поставить разработчику задачу (task) или указать на ошибку (bug). Изменение этого имени приведет к изменению содержимого выпадающего меню.

У элемента WORKITEMTYPE могут быть четыре дочерних элемента – DESCRIPTION, FIELDS, WORKFLOW и FORM. Рассмотрим их подробнее.

Назначение элемента DESCRIPTION очевидно из его названия – этот элемент хранит в себе словесное описание рабочего элемента. Приведу примеры:

<DESCRIPTION>Tracks work that needs to be done.</DESCRIPTION>

<DESCRIPTION>Includes information to track an SDL task through the development lifecycle</DESCRIPTION>

<DESCRIPTION>Describes a divergence between required and actual behavior, and tracks the work done to correct the defect and verify the correction.</DESCRIPTION>

<DESCRIPTION>Includes information to track the work to resolve the Bug and to verify its resolution.</DESCRIPTION>

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

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

Теперь попробуем разобраться с элементов WORKFLOW. Исходя из его схемы, он может состоять из двух элементов – STATES и TRANSITIONS. В элементе STATES хранится информация о возможных состояниях объекта, при этом каждое состояние представлено элементом STATE. А в элементе TRANSITIONS хранится информация о том, в результате каких событий рабочий элемент может перейти из одного состояния в другое. Очевидно, что каждый переход описан одним элементом типа TRANSITION.

Элемент STATE имеет только один атрибут – строковое поле value. В нем можно определить состояние, в котором находится рабочий элемент, например, "Active”, “Pending”, “Closed” и т. д. Приведу примеры определения этого атрибута:

<STATE value="Active">

<STATE value="Resolved">

<STATE value="Closed" />

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

Кроме того, элемент типа STATE хранит в себе список полей, которые будут изменены при переходе в другое состояние. Никакие другие поля при нахождении элемента в данном состоянии изменяться не могут. Например, рабочий элемент Bug, соответствующий обнаруженной в приложении ошибке, может находиться в состоянии “Active”. Из этого состояния он может перейти в состояние “Resolved” (причина ошибки выяснена, но еще не устранена, так как устранение требует времени) и “Closed” (все, ошибка устранена). В соответствии с этим у состояние “Active” могут быть изменены поля “ResolvedDate” (дата определения причины ошибки), “ResolvedBy” (кем была выявлена причина ошибки), “ResolvedReason” (описание причины ошибки), “ClosedDate” (дата устранения ошибки) и “ClosedBy” (кем была устранена ошибка). Элемент STATE также хранит в себе значения, которые будут присвоены данным полям при переходе в это состояние. Ниже я привожу пример определения состояния “Active” элемента Bug, входящего в состав шаблона SDL:

<STATE value="Active">

  <FIELDS>

    <FIELD refname="Microsoft.VSTS.Common.ResolvedDate">

      <EMPTY/>

    </FIELD>

    <FIELD refname="Microsoft.VSTS.Common.ResolvedBy">

      <EMPTY/>

    </FIELD>

    <FIELD refname="Microsoft.VSTS.Common.ResolvedReason">

      <EMPTY/>

    </FIELD>

    <FIELD refname="Microsoft.VSTS.Common.ClosedDate">

      <EMPTY/>

    </FIELD>

    <FIELD refname="Microsoft.VSTS.Common.ClosedBy">

      <EMPTY/>

    </FIELD>

  </FIELDS>

</STATE>

Таким образом, пре переходе в состояние “Active” значения перечисленных в нем полей попросту сбрасываются. Другой пример – состояние “Closed”. Оно является “конечным”, из него нет переходов и, соответственно, оно не изменяет значения полей. Это отражается и в его определении:

<STATE value="Closed">

</STATE>

Однако, в этой логике есть несколько  пробелов. С одной стороны, мы не знаем, из какого состояние в какое может переходить элемент. Например, если у элемента есть состояние “Waiting” (ожидание), то можно ли из этого состояния переходить сразу же в состояние, скажем, “Closed” или же сначала необходимо перейти в состояние “Resolved”, а только потом в “Closed”? Кроме того, невозможно определить, из какого состояния, кто и по какой причине перевел элемент в данное состояние. Для отслеживания этих данных используются элементы типа TRANSITION.

У элемента типа TRANSITION есть два атрибута – строковые поля “from” и “to”. Их значениями должны являться, соответственно, названия состояний, из которого в которое перешел элемент (значения атрибутов value полей типа STATE).

Помимо этого, каждый элемент типа TRANSITION включает в себя элементы REASONS и FIELDS. REASONS в свою очередь, включает в себя элементы типа REASON (их может быть много) и DEFAULTREASON (он должен быть единственным). Другими словами, элемент типа REASONS представляет собой список возможных причин перехода из одного состояния в другое, при этом одна из причин предлагается по умолчанию. FIELDS определяет список полей, изменяющих значение при переходе из состояния в состояние, а также присваиваемые этим полям значения. Например, факт создания нового элемента типа Bug может быть описан следующим образом:

<TRANSITION from="" to="Active">

  <REASONS>

    <DEFAULTREASON value="New"/>

    <REASON value="Build Failure"/>

  </REASONS>

  <FIELDS>

    <FIELD refname="Microsoft.VSTS.Common.ActivatedBy">

      <COPY from="currentuser"/>

      <VALIDUSER/>

      <REQUIRED/>

    </FIELD>

    <FIELD refname="Microsoft.VSTS.Common.ActivatedDate">

      <SERVERDEFAULT from="clock"/>

    </FIELD>

    <FIELD refname="System.AssignedTo">

      <DEFAULT from="currentuser"/>

    </FIELD>

  </FIELDS>

</TRANSITION>

Понятно, что в данном случае возникновение ошибки может быть связано либо с невозможностью сборки проекта, либо просто с фактом обнаружения ошибки разработчиком или тестером. Время возникновения ошибки и обнаруживший ее пользователь фиксируются автоматически, ошибка адресуется пользователю, обнаружившему ее. Еще пример – при переходе из состояние “Active” в состояние “Resolved” могут быть выбраны причины из следующего списка:

<REASONS>

  <DEFAULTREASON value="Fixed"/>

  <REASON value="Deferred"/>

  <REASON value="Duplicate"/>

  <REASON value="As Designed"/>

  <REASON value="Unable to Reproduce"/>

  <REASON value="Obsolete"/>

  <REASON value="SDL Exception"/>

</REASONS>

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


30 декабря 2009 года


29 декабря 2009 года (вечерний выпуск)


29 декабря 2009 года

ЮРИЮ

1. Понимание кода, сгенерированного "CodedUI Test’ом" (часть 1)

2. Понимание кода, сгенерированного "CodedUI Test’ом" (часть 2)

3. Каким образом "CodedUI Test" находит контролы

ВСЕМ РАЗРАБОТЧИКАМ

1. Почему лучше иметь одну большую dll-ку, чем множество маленьких (можно, конечно, поспорить…)

2. Как создать собственный сниппет

3. Свидание с программным кодом

4.  О многопоточном программировании

5. Многоуровневый анализ производительности

6. Обновился Training Kit для Azure

ВСЕМ СОТРУДНИКАМ ОТДЕЛА

1. Десятилетие в графической форме

2. Не нужно постоянно переставлять Windows…

3. Вот это мастерство! Вот это слаженность!

4. Что нужно есть

5. Прошлое и настоящее… (Москву мы тоже потеряли…)

6. Недавно я публиковал заметку о Михаиле Богдановиче Барклай де Толли. В этот день в 1761 году он родился.

7. День рождения Карла Росси, человека, который построил половину Петербурга

8. По Ясскому мирному договору к России (не к Украине) присоединен Крым

НА РАБОТЕ НЕ СМОТРЕТЬ!

1. Напейся с отцом!


28 декабря 2009 года (вечерний выпуск)