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

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

Как сказано на самом сайте, Fixie – Conventional Testing for .NET. Т.е. тестирование по соглашению. Под соглашениями здесь понимается то, к чему мы в целом привыкли – все операции выполняются на основе «устного» договора, джентельменского соглашения об именовании. Ближайший пример – scaffolding. Это когда мы договорились, например, что тестовые классы содержат слово Test, или что тестовые классы должны быть публичными и ничего не возвращать.  Тогда такие классы будут распознаны как тестовые. И больше никаких атрибутов и всего такого прочего. Просто классы и методы.

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

или «Прекратите характеризовать хранилища данных как CP или AP»

Джеф Ходжес в своем прекрасном посте «Заметки о распределенных системах для новичков» рекомендует использовать САР теорему для критики найденных решений. Многие, похоже, восприняли этот совет слишком близко к сердцу, описывая свои системы как «СР» (согласованность данных, но без постоянной доступности при сетевой распределенности), «АР» (доступность без согласованного состояния при сетевой распределенности), или иногда «СА» (означает «Я всё ещё не читал статью Коды (Coda Hale) почти 5-летней давности»).

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

(Да, я понимаю всю иронию написания целой статьи по теме того, о чём призываю не писать других вообще. Но, как минимум, у меня будет ссылка, которую я смогу давать интересующимся, когда меня будут спрашивать, почему я не одобряю обсуждение САР теоремы. Также, я хочу извиниться, если статья вам покажется слишком напыщенной, но эта напыщенность опирается на множество ссылок.)

САР использует слишком узкое определение

Если вы хотите ссылаться на САР как на теорему (а не на расплывчатый концепт в маркетинговых материалах к вашей базе данных), вы должны быть точны. Математика требует точности. Доказательство сохраняется только если вы вкладывается в слова, то же самое значение, что было использовано при доказательстве. И оно опирается на очень точные определения:

Корпоративные системы быстро эволюционируют из монолитных хранилищ в распределенные приложения, основанные на сервисах с гибкими схемами использования.  Чтобы идти в ногу со временем, IT организации должны приспосабливать свои старые приложения к изменяющимся бизнес-требованиям почти что в режиме реального времени, и фактически без возможности второго шанса. Сервис-Ориентированная Архитектура (SOA) эволюционировала для поддержки гибкости операций и федеративности бизнес-процессов, подсистем. Авторы статьи Николас Серано (Nicolas Serrano), Хуасин Эрнандес (Josune Hernantes) и Горка Галлардо (Gorka Gallardo) дают обзор текущего состояния технологии SOA и как развиваться в существующем окружении.
                                                                                        Предисловие от Кристофа Эберта (Christof Ebert)

Современный бизнес должен быть способен гибко и быстро приспосабливаться к требованиям рынка, но даже незначительные изменения в процессах могут повлечь переработку множества информационных систем, которые изначально были разработаны как монолитные хранилища. Для сохранения конкурентоспособности, затраты на поддержку должны постоянно снижаться, а системы ­постоянно эволюционировать. SOA делает возможным переход от монолитных систем к сервис-ориентированным. Это содействует гибкости, слабой связанности, выделению абстракций из реальной инфраструктуры. Возможности по обнаружению сервисов и повторному использованию гораздо выше с SOA. Дополнительные возможности и принципы можно узнать из Манифеста SOA. ^[1][2]

Новизна SOA заключается в том, как моделируется инфраструктура архитектурного решения, основанная на сервисах, вместо фокусирования на всём приложении. Сервисы являются маленькими, обособленными элементами ПО, которые решают одну задачу и могут быть повторно использованы во многих приложениях. SOA основывается на принципе слабой связанности, что означает что каждый сервис – это изолированная сущность с ограниченными зависимостями от других общих ресурсов, таких как базы данных, легаси приложения или разные API. Такое архитектурное решение позволяет создать уровень абстракции между потребителями и создателями. Это влечёт за собой свободу в реализации и обновлениях без ущерба для потребителей сервиса. Да, SOA имеет немало плюсов для бизнеса, но это не лучшее решение для всех случаев. Среди плюсов подхода можно обозначить следующие пункты:

Разработка веб API это нечто большее чем просто URL, HTTP статус-коды, заголовки и содержимое запроса. Процесс проектирования – то, как будет выглядеть и восприниматься ваш API – очень важен и является хорошей инвестицией в успех вашего дела. Эта статья кратко описывает методологию для проектирования API с опорой на преимущества веба и протокола HTTP, в частности. Но не стоит думать, что это применимо только для HTTP. Если по какой-то причине вам необходимо реализовать работу ваших сервисов используя WebSockets, XMPP, MQTT и так далее – применяя большую часть всех рекомендаций вы получите практически тот же API, который будет хорошо работать. К тому же полученный API позволит легче разработать и поддерживать работу поверх нескольких протоколов.

Хороший дизайн затрагивает URL, статус-коды, заголовки и содержимое запроса

Обычно руководства по проектированию Web API фокусируются на общих концепциях: как проектировать URL, как правильно использовать HTTP статус-коды, методы, что передавать в заголовках и как спроектировать дизайн содержимого, которое представлено сериализованными данными или графом объектов. Это всё очень важные детали реализации, но не настолько в смысле общего проектирования API. Проектирование API – это то, как сама суть сервиса будет описана и представлена, то что вносит значительный вклад в успех и удобность использования Web API.

Хороший процесс проектирования или методология предоставляют набор согласованных и воспроизводимых шагов для создания компонентов сервисов, которые будут доступны в виде Web API. Это значит, что такая прозрачная методология может быть использована разработчиками, дизайнерами и архитекторами для координации своих действий по реализации ПО. Использованная методология так же может уточнятся со временем по мере того, как улучшается и автоматизируется процесс без ущерба для деталей методологии. На самом деле, детали реализации могут меняться (например, платформа, ОС, фреймворки и стиль UI) независимо от процесса проектировки, когда эти две активности полностью разделены и задокументированы.

Гугл открыла исходный код своего проекта Jsonnet, языка для конфигурации, который заменяет стандартный JSON и добавляет новые возможности без нарушения обратной совместимости. Среди таких возможностей: комментарии, ссылки, арифметические и условные операторы, массивы и работа с объектами, импорт, функции, локальные переменные. Программы на Jsonnet транслируются в совместимый с JSON формат данных.

Комментарии. Jsonnet принимает комментарии в стиле С ( /* … */ ) и С++ ( // )

Ссылки. Ключевое слово self может быть использовано для ссылки на текущий объект. Оператор $ позволяет использовать корневой объект.

Арифметические и условные операторы. Оператор + может складывать числа, строки, массивы и объекты. Операторы == и != возвращают true или false. Оператор if работает как тернарный оператор ?: в С. Далее несколько примеров с операторами языка и результат. Примеры взяты со страницы проекта.

// bar_menu.3.jsonnet
{
    foo: 3,     
    bar: 2 * self.foo,  // Multiplication.
    baz: "The value " + self.bar + " is "
         + (if self.bar > 5 then "large" else "small") + ".",
    array: [1, 2, 3] + [4],
    obj: {a: 1, b: 2} + {b: 3, c: 4},
    equality: 1 == "1",
}

Всем привет!



Вниманию хабрасообщества хочу представить интересную презентацию Стефана Тилькова, со основателя и главного консультанта в innoQ. Стефан рассказывает об идее разделения больших систем на небольшие приложения, которые отвечают за разные аспекты системы. Сама идея не нова, но автор упирает на то, что основной причиной такого разделения должна быть изоляция. Благодаря границам приложений полученных таким образом, сложнее получить связанные модули, которые на самом деле должны быть независимыми. Тут еще можно вспомнить подход «domains boundary», для разделения доменных сущностей по областям применения, вместо того, чтобы создавать единую модель данных на всю большую организацию/процесс.

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

Достижение начального успеха для Сервис-ориентированной Архитектуры (Service Oriented Architecture, SOA) определяется:

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

Множество команд разработчиков создают и используют сервисы, но до сих пор идет мучительный подбор архитектуры, при которой сервисы будут широко использованы, с потенциалом для повторного использования внутренними командами разработки. Вместо создания согласованной сервисной архитектуры и демонстрации множественного использования одних и тех же сервисов, разработчики вновь и вновь не нарочно создают «Просто Набор Веб Сервисов» (Just a Bunch of Web Services (JBOWS)) или «Просто Набор REST Сервисов» (Just a Bunch of REST Services (JBORS)).

Простое приложение чаще всего работает с неким сервисом и спагетти-сетью конечных точек, поставщиков данных этого сервиса, которые переплетены связями один-к-одному. Многие команды в этом случае сходятся во мнении что фокус на SOA и REST не то чтобы помогал в решении вопросов гибкости решений. Скорее просто происходит подмена набора IT инструментов, форматов сообщений и протоколов.

Управление SOA, API, и приложением может стать мостом между этими концепциями и улучшить архитектурную согласованность всего решения.

Сервисы, API и архитектура

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

На недавно прошедшей онлайн конференции dotNetConf организованной Microsoft, рассказывалось множество интересных вещей. И коль скоро было большое количество обсуждений по поводу WPF, что он живее всех живых, то хочется сделать краткий обзор доклада программных менеджеров WPF, что нового нас ждет в релизе, что уже можно посмотреть и к чему все идет. Действительно все так плохо и будет ли аналог нового движка для WPF, как например Razor для ASP.NET.

12 ноября 2014 года блог WPF ожил (сейчас активен тоже) и был представлен генеральный план развития фреймворка.


Здесь и далее, скриншоты с видео, так что качество не очень, но разглядеть все можно.

В начале выступления, ведущие Уни Равиндранатан (Unni Ravindranathan) и Харикришна Менон (Harikrishna Menon) обмолвились, что есть вещи, которые еще находятся в разработке, и они не имеют права о них рассказывать, NDA и все такое. Но то что они могут показать, внушает оптимизм и видно, что работа идет. Забегая вперед, скажу, что прежде всего разработчики подумали о быстродействии, например, как сократить визуальное дерево для конкретной целевой платформы.

Всем привет!

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



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

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

Всем привет!

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

Ни для кого не секрет, что основной целью наших конференций является дать возможность людям познакомиться на почве профессиональных интересов. Доклады являются пищей для размышления и вводной частью к последующим дискуссиям различной степени детальности. На наш взгляд, такое общение способствует осознанию собственных убеждений в более глубокой мере, так как вы сталкиваетесь с другими, порой диаметрально противоположными мнениями. Так что же приготовлено для конференции Desktop UI & Business Application?



Сначала представим темы, которые относятся к бэкенду, к серверной части, которая будет интересна всем разработчикам, занятым в сфере энтерпрайз разработки. Т.е. это и WPF, и WinForm, и ASP.NET.

История представления реальных данных и процессов в мире программ имеет богатую и долгую историю. Можно сказать, что все началось с транзакционных скриптов, и процедурного программирования. Когда доменную модель пытались полностью представить в виде набора процедур и данных, которые хранятся в базе данных. По сути, все крутилось вокруг таблиц. Шагом вперед, вместе с ООП разработкой стала модель табличных данных, которые уже были представлены набором данных в памяти программы. Теперь таблицы стали отправной точкой в представлении доменной логики. Процедуры уже не объявлялись в глобальном пространстве имен, а были «пристегнуты» к определенной таблице, в зависимости от своих функций. Дальнейшее удешевление и распространение компьютеров привело к тому, что все более широкое применение находило компьютерное моделирование. В то же время сложные реальные доменные модели надо было отображать как можно более проще для поддержки и расширения. Так Мартин Фаулер предложил, а Эрик Эванс развил идею Domain Driven Design, которой большинство сейчас придерживается, в той или иной степени.

Привет, коллеги!

Совсем недавно мы анонсировали конференцию, посвященную Desktop UI & Business Application. В поддержку, чтобы посмотреть на настроения публики, была опубликована статья «WPF живее всех живых», которая оказалась дискуссионной и заставила нас в несколько другом свете взглянуть, на то, что и как мы хотим донести до широкой публики.

Как показали комментарии, не WPF единым живет десктоп разработка. Есть порты Qt для .NET, есть WinRT, если в эпсилон окрестности от дефолт-сити есть спецы по этим технологиям, которые хотят высказаться – у нас есть трибуна! Для этого все и задумано, чтобы показать различные варианты для ваших проектов.



Буквально вчера закончилась онлайн конференция dotNetConf 2015, которую, исходя из сообщений, Microsoft скорее возродила, нежели придумала заново. Конференция, судя по содержанию старается покрыть все основные области использования языка, это мультиплатформенность, веб, десктоп, доставка приложений, интеграция с Xamarin, будущее .NET, .NET Core, Roslyn Analyzer и другие темы. На мой взгляд, это генеральная репетиция перед конференцией //build, которая состоится в конце апреля-начале мая.

Про золотые молотки

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

Я долгое время был разработчиком систем для десктопа. Сначала это был WinForms, потом более мощный и гибкий WPF. С тех пор прошло много времени и курсирует множество слухов и мнений о том, что WPF завершает свою жизнь, ведь сейчас столько разговоров о том, что можно писать настольные приложения на JS. А еще Microsoft усиленно двигает в массы платформу WinRT для разработки новых приложений. Это не могло меня и коллег оставить равнодушным.

Так почему же мы, команда GoSharp конференции (да, да, это о C#), решили сделать акцент на десктопной разработке в разрезе WPF? Далее я хочу показать какие светлые и темные моменты есть в существующем положении фреймворка и почему все же стоит в него вкладывать силы и время.



Существует мнение, что развитие десктопной разработки остановилось в своем развитии и для этого есть несколько предпосылок. Одна из них – остановка, или даже лучше сказать стагнация, в самой базе, в визуальном фреймворке WPF. Значительных обновлений для него не было вот уже лет 5, как может показаться. Официальный тулкит давно не обновлялся, точнее с февраля 2010 года, т.е. вот как раз те самые 5 лет. При этом компании, специализирующиеся на кастом-компонентах, как например DevExpress и Telerik успешно выпускают обновления и составляют планы на будущее относительно WPF. Даже если вы ориентированы на новинки, то компоненты для WinRT все равно используют концепции и общую структуру XAML, который никуда не уходит.
Далее мы хотим представить причины, по которым WPF некоторые считают неактуальным, и опровержение этих причин.

Привет, коллеги!

Совсем недавно мы провели конференцию, посвященную ASP.NET технологиям и всему что с ними связанно. Она имела успех, о чем можно судить по полному залу и звонкам с вопросами: «Может еще билетик будет все же?». Более подробно мы расскажем позже, но можно посмотреть фотоотчет, а сейчас хочется рассказать о двух новых конференциях, которые мы планируем провести в апреле.

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



Первая конференция UI Desktop & Business Application (11 апреля) посвящается «невидимым» с облаков разработчикам настольных корпоративных приложений и в целом всем, кто занимается разработкой и поддержкой бэкенда или разработкой сложного корпоративного интерфейса.

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

Тематика докладов:

• разработка системы обновлений
• системы плагинов — MEF
• интересные бизнес-кейсы связанные со стационарной разработкой
• фреймворки для UI, тестирование UI
• встраивание в систему
• особенности или какие-то интересные возможности связанные с EF
• и так далее, все что специфично для Windows программ

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

Всем привет!

В начале марта с 11 по 17 число, Гаэль Фрэтёр (Gael Fraiteur) приезжает в Россию и хочет провести мастер-классы и вечерние беседы в Москве и Питере. Гаэль известен как человек хорошо разбирающийся в недрах .NET и с большим опытом в сфере аспектно-ориентированного программирования. Мероприятия бесплатные, но требуется регистрация.

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

Москва:

• 12 марта (четверг) — Taking Design Patterns to the Next Level — Evening Lecture (Msk) — ФРИИ сити холл
• 13 марта (пятница) — PostSharp One-day Training (MSK) — Кампус Microsoft

Питер:

• 16 марта (понедельник) — Taking Design Patterns to the Next Level — Evening Lecture (SPB) — Бизнес-инкубатор «Ингрия»
• 17 марта (вторник) — PostSharp One-day Training (SPB) — Бизнес-инкубатор «Ингрия»

Я надеюсь, что .NET сообществу это будет интересно.

Создание и запуск окружений

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

Однако, существует ряд задач, когда требуется получить «студию, которая словно только что установилась». Что это за задачи?

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

… Или как автоматизировать некоторые действия в 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, и вся история ставится в состояние ожидания.

В прошлый раз я рассказал о том, как, на мой взгляд, должны выглядеть карты процессов для пользовательской истории, задачи, бага (UserStory, Task, Bug). В этот раз я хочу рассказать, как все это настроить в Visual Studio.  Все описанные манипуляции производятся над TFS2010 с установленным пакетом TFS Power Tools. Предполагаю так же, что вам понадобятся права администратора TFS.

После установки TFS Power Tools, в VS должен появиться новый пункт в меню Tools.



На скриншоте уже показано, что необходимо сделать для того, чтобы начать редактировать элементы задач. Tools > Process Editor > Work Item Types > Open WIT from Server. Такой выбор позволит сразу получить изменения на сервере. В целом все пункты последнего меню говорят сами за себя и с минимальными экспериментами можно получить представление об их действии.

Я хочу рассказать о том, как можно расширить стандартный процесс (workflow) для некоторых элементов в TFS 2010 (про 2011 будет позже) при выборе шаблона Agile для проекта. Так же интересно услышать мнение хабрасообщества по поводу донастройки шаблонов, кто как настраивает workfolw. Расскажите, как это делаете вы, очень интересно.

Стандартные настройки проекта out-of-box на мой взгляд достаточно бедны и не обеспечивают должной прозрачности, если необходимо отслеживать/контролировать работу над проектом распределенной команды, либо когда управляющий (менеджер или еще какой-нито начальник) желает видеть как идут дела с задачами. Стандартные настройки не позволяют, на мой взгляд, уверенно говорить о текущем состоянии задач.

Обычная рабочая доска (task board) имеет больше состояний, нежели базовые настройки типичных артефактов управления проектом из которых строится процесс Agile: UserStory, Task, Bug. Мне кажется это базовые вещи, которые стоит рассмотреть и дополнительно настроить, что собственно я и сделал для себя и команды.  В рассказе ниже я затрону только настройку процесса перехода состояний, не затрагивая свойства элементов. Т.е. никаких кастомизаций внешнего вида и свойств не будет.

Прежде чем двигаться дальше, расскажу, какие инструменты вам понадобятся. Все описанные манипуляции производятся над TFS2010 с установленным пакетом TFS Power Tools. Предполагаю так же, что вам понадобятся права администратора TFS.

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


Большинство разработчиков, скорее всего, представляют себе архитектуру только в приложении к конкретному проекту, т.е. можно часто услышать от них «архитектура ПО», однако это лишь малая часть того, что входит в общее понятие. Условно можно разделить глобальное понятие на несколько частей, от общего к частному. Можете представить их в виде пирамиды:

• Бизнес архитектура
• Архитектура информационных систем (потоки данных)
• Технологическая архитектура

Таким образом, разработчики чаще всего говорят о технологической архитектуре приложения.

Бизнес архитектура, она же Enterprise, является представлением того, как эффективно воспроизвести цели бизнеса и стратегию путем создания, улучшения и объединения ключевых требований, принципов и моделей для успешного развития бизнеса и достижения поставленных целей. Определение взято из английской википедии.  Архитекторы уровня Enterprise должны ориентироваться на бизнес потребности и проводить анализ потоков данных, т.е. покрывают два указанных пункта. Архитекторы уровня Solution занимаются технологическими аспектами проектов. Так же стоит упомянуть не обозначенных здесь Infrastructure Architect, людей, которые занимаются глобальным развитием и анализом технических возможностей по реализации проектов.

Краткое описание базы

База данных Eloquera с самого начала была написана для хранения объектов  на основе .Net Framework, что сделало возможным попытаться вобрать в себя все лучшее от объектных и реляционных баз данных одновременно, преодолев многие их различия. Теоретически Eloquera может работать с любыми языками из семейства .Net Framework, однако на практике работа проверялась пока только с C#. Главная ориентированность разработчиков на enterprise сегмент (100+ ГБ), а не на embedded решения, хотя последние тоже не обделены вниманием.

Отличительные особенности Eloquera весьма внушительны и постоянно пополняются, вот их очень краткий список:

• Сохраняет C# объекты (любые объекты любого языка на .Net платформе) без необходимости реализации специальных интерфейсов и адаптеров.
• Сохраняет Dynamic объекты с любыми полями\свойствами и может сопоставить их объектам любого типа.
• Язык запросов максимально приближен к SQL, при этом не требуется наличие какой либо реляционной SQL базы. Плюс поддержка LINQ.
• Возвращает объекты в том виде, в котором они были сохранены (включая перечислимые типы)
• Поддержка параметров в виде списков и массивов
• Регулярные выражения в запросах.
• Поддержка шаблонных объектов.
• Восстановление Read-only полей и свойств.
• Поддерживается частичный возврат объектов. Например, если вам требуется класс ForumTopic, тогда можно не подтягивать все ссылки на ForumMessages.
• Можно указать глубину объекта для возврата в запросе.
• Хранимые процедуры.