Sunday, August 16, 2009

Быстрый взгляд на NDC 2009

В начале июня в Норвегии прошла Norwegian Developers Conference 2009 (NDC). И по-моему, прошла достаточно незаметно для многих из нас. Вместе с тем, список докладчиков и темы докладов были на очень высоком уровне, поэтому нужно срочно исправлять положение.

Просто для примера, докладчики (те, что у меня на слуху):

  • Robert C. Martin
  • Ayende Rahien
  • Scott Hanselman
  • Ted Neward
  • Phil Haack
  • Jeremy D. Miller
  • Tim Huckaby
  • Rockford Lhotka
  • Roy Osherove
  • Glenn Block
  • Scott Bellware
  • и многие другие

Каждый день был разбит на треки. Треки были самые разные, от общих вопросов программирования и инженерии ПО до разработки веб-приложений, TDD и Scrum/Lean. Каждый доклад пронумерован уровнем (100-400). Доклады очень практичные, мало рекламы, в отличие от многих Microsoft'овых конференций, поэтому must see.

Примеры самых сложных докладов (Level 400):

  • Automatic Recommendation Engine Based on Data Mining
  • Create Compelling Sharepoint Uls Using Silverlight
  • Writing Custom Windows Presentation Foundation Pixel Shader Effects
  • Building Maintainable Enterprise Applications with Silverlight and WPF
  • Asynchronous Systems Architecture for the Web
  • Mocking on the Edge - Isolation at the System Level

На сайте NDC 2009 можно посмотреть видео большинства докладов. Для этого вам придется обзавестись плагином Media Player 11 (например, мне для FF пришлось) и смириться с тем, что первые несколько минут доклада вы не увидите (вот уж не знаю, баг это или фича). Но надо сказать, что ради таких докладов можно пойти на любые жертвы.

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

Думаю, NDC можно спокойно поставить на один уровень с PDC, Mix/ReMix, TechEd, DevConnections, ALT.NET и другими известными конференциями и следить за ней в следующем году - она этого 100% заслуживает.

PS. Roy Osherove выложил ссылки на торренты для скачивания докладов.

Monday, August 10, 2009

Новые возможности LINQ to SQL в .NET 4.0

Вдогонку к моей предыдущей заметке предлагаю посмотреть список новых возможностей LINQ to SQL в .NET 4.0. Переводить не буду, просто дам ссылку на заметку Damien Guard из Microsoft, который работает над этим продуктом:

LINQ to SQL changes in .NET 4.0

Приятно, что L2S тоже развивается, пусть и не такими семимильными шагами как EF, NH и некоторые другие ORM. Я уже когда-то писал на тему развития этих технологий, а именно почему EF больше повезло в плане развития (и, соответственно, финансирования). По всей видимости, L2S будет тихим сапом поддерживаться и понемногу развиваться еще пару версий, а потом просто остановится, когда EF станет достаточно взрослым, продвинутым и быстрым, чтобы удовлетворить требования разработчиков, использующих L2S вместо EF или NH.

Sunday, August 9, 2009

Entity Framework 4.0: выходим на зрелый уровень

Я уже полгода не работаю с Entity Framework, но по былой памяти интерес все равно сохраняется. Как-то совсем упустил из виду, что вместе с выходом Visual Studio 2010 Beta 1 вышла и первая бета Entity Framework 4.0. Более того, спустя месяц ADO.NET team выпустил еще и Entity Framework 4.0 Feature CTP 1 (скачать можно здесь). В CTP 1 вошли еще три новые фичи, которые не успели довести до выхода VS 2010 Beta 1: Self Tracking Entities (о которых я уже немного рассказывал), POCO Template и Code Only.

Что это значит? Это значит, что в релизной версии 2010-й студии в составе .NET 4.0 этих фич тоже не будет. Daniel Simmons в подкасте .NET Rocks #451 как-то достаточно неясно сказал, что они вроде бы войдут в какой-то следующий релиз после VS 2010, хотя сам EFv4 будет релизиться вместе со студией. Ну, да это не так важно.

А важно вот что: в следующей версии EF разработчики проделали достаточно серьезную работу. Они действительно учли многие комментарии и критику, которые обрушились на первую версию EF, поэтому вторая версия EF с физическим номером 4.0 (Microsoft снова извратила нумерацию с целью упростить жизнь своим sales) будет ощутимо солиднее. Что же мы получим в новой версии:

1) Model First development approach

В EFv1 была лишь возможность сгенерировать модель по базе данных, а EFv4 обладает и обратной возможностью - сгенерировать базу данных по модели. Теперь вы можете сами выбрать, какой подход вам удобнее и работать, используя его. На мой взгляд, может подойти людям, работающим в рамках DDD, где база данных воспринимается как инфраструктура - средство для хранения (persistence) состояния объектов системы.

Подробнее о фиче:
Sneak Preview: Model First in the Entity Framework 4.0

2) Code Only development approach

Конечно, Database First и Model First подходы к разработке покрывают потребности почти всех разработчиков. Однако, также есть люди, которым нравится создавать свою модель прямо в коде. При чем делают они это, как правило, при помощи так называемых fluent-интерфейсов, то есть максимально читабельного кода, который заменяет конфигурирование при помощи XML (то есть EDMX-файлы уходят в прошлое). На данный момент еще не все возможности EDMX-конфигурации обзавелись своими аналогами, да и текущий API сложно назвать fluent, но к релизу, думаю, будет покрыт максимум возможных операций.

Подробнее о фиче:
Code Only design
Code Only enhancements
Feature CTP Walkthrough: Code Only for the Entity Framework
Next version of EF Code Only Design laid out by MS

3) Persistence Ignorance (POCO) support

То о чем так долго говорили и писали, наконец свершилось: ADO.NET team добавил в EFv4 поддержку Persistence Ignorance (PI). В EFv1 все сущности были унаследованы от EntityObject и таким образом "знали" о том, что где-то есть EF контекст, а EF контекст, в свою очередь, мог отслеживать изменения в этих объектах и использовать их в других целях. Такая привязка сущностей к инфраструктуре создавала много проблем с тестируемостью и реализацией сценариев, где нужны чистые POCO-объекты. Теперь же эта проблема решена: вы можете создавать POCO-объекты и при этом у вас сохраняться все инфраструктурные возможности EF: отслеживание и сохранение изменений, lazy/deferred loading, и др. Кроме того, у вас есть выбор, какой способ отслеживания изменений выбрать: snapshot-based или proxy-based, также вы можете создать свои собственные шаблоны для генерации POCO. Фича очень серьезная, возможностей много.

Подробнее о фиче:
Sneak Preview: Persistence Ignorance and POCO in Entity Framework 4.0
POCO in the Entity Framework: Part 1 - The Experience
POCO in the Entity Framework : Part 2 – Complex Types, Deferred Loading and Explicit Loading
POCO in the Entity Framework : Part 3 – Change Tracking with POCO
Feature CTP Walkthrough: POCO Templates for Entity Framework

4) Customization of Code Generation

После описания POCO и Code Only, разумно рассказать немного о механизме, который они частично (или полностью) используют. Если вы помните, первая версия EF генерировала код при помощи такой штуки, как CodeDOM. Надо сказать, что хотя это и мощная технология кодогенерации, кастомизировать ее невероятно сложно. Мы пробовали вклиниваться в процесс генерации EF сущностей на одном из проектов, но возможности там достаточно поверхностные. EFv4 генерирует сущности и класс контекста при помощи T4 (Text Template Transformation Toolkit), что позволяет просто отредактировать существующие текстовые шаблоны или написать и подключить свои - и все готово. Кроме того, переход на более простой способ генерации позволил реализовать и некоторые другие новые возможности, например, POCO или Code Only. Да и вообще, теперь вы можете генерировать все что угодно на основании своей модели - различные адаптеры, DTO, POCO-объекты, возможности кодогенерации почти безграничны.

Подробнее о фиче:
Sneak Peek – Using Code Generation Templates with the Entity Framework 4.0

Как кастомизировать шаблоны T4 в EF:
Customizing T4 Templates
Customizing EDM Code Gen in EF4
Feature CTP Walkthrough: POCO Templates for Entity Framework

5) Testability Improvements

Здесь, в принципе, все понятно. Все вышеназванные улучшения и еще пара новых наконец-то дают возможность писать нормальный код с поддержкой тестирования. Да и нормальная поддержка различных паттернов вроде Repository тоже не помешает.

Подробнее о фиче:
Sneak Preview: Entity Framework 4.0 Testability Improvements

6) Self-tracking entities

Идея проста - появились новые шаблоны T4, которые позволяют генерировать специальные сущности, не зависящие от ObjectContext и EF, но зато умеющие сами трекать изменения внутри себя. Когда это может пригодится? Например, когда вы хотите сериализовать свои сущности, отправить их куда-то в другое место (на SL-клиент или в другое приложение при помощи WCF-сервиса), сделать там в них изменения (добавить новые, изменить, удалить), вернуть назад и сохранить изменения в базу. Описанный здесь сценарий было очень сложно реализовать в EFv1, теперь это вопрос намного более тривиальный.

Подробнее о фиче:
Self-Tracking Entities in the Entity Framework
Feature CTP Walkthrough: Self Tracking Entities for Entity Framework

7) Deferred loading

В EFv1 в отношении lazy/eager loading было две опции: eager loading, доступный через Include(), и explicit (явный) lazy loading, доступный через метод Load() классов EntitySet и EntityReference. При этом если вам хотелось реализовать неявную поддержку lazy loading, вам приходилось достаточно серьезно извращаться (мы, например, хакали кодогенерацию EF), хотя в LINQ to SQL эта возможность была с самого начала. Теперь же все стало на свои места - все три сценария поддерживаются, причем третий сценарий для отличия от уже существующего lazy loading назвали deferred loading. Зачем - не знаю.

Подробнее о фиче:
Sneak Preview: Deferred Loading in Entity Framework 4.0
A Look at Lazy Loading in EF4

8) Model Defined Functions

MDF - это специальные функции, добавляемые к сущностям, которые описываются на уровне CSDL, то есть концептуальной модели данных. Эти функции могут принимать параметры, выполнять любой eSQL-код внутри себя, и потом возвращать результат. Благодаря такой возможности их можно использовать в eSQL-запросах, а также в LINQ-запросах (если вывести их наверх). В каких случаях они будут полезны в жизни? Сложно сказать, не могу подобрать реальный пример. Разработчики говорят что-то про Reporting Services, Web Services и т.д. - они необходимы там. Поэтому это больше внутренняя фича, которая будет полезна, если вы начнете делать шаги в сторону от стандартных сценариев. Поживем - увидим.

Подробнее о фиче:
Model Defined Functions
Sneak Preview: Model Defined Functions
EF4: Model-Defined Functions Level 1 & 2

Немного больше об истории и причинах их появления:
Update on Computed Properties

9) Foreign Keys support

EFv4 поддерживает новый тип ассоциации, т.н. FK Association. Старый тип ассоциации теперь принято называть Independent Association. FK Association будет полезен в тех случаях, когда вам удобнее работать со связями через первичные ключи, а не с коллекциями и ссылками на реальные объекты - все-таки это иногда намного более производильные операции. При этом надо сказать, что эта фича далась разработчикам очень нелегко, так как она должна поддерживаться не только на уровне EntityObject, но также на уровне proxy-based POCO, snapshot-based POCO, IPOCO и других способов создания модели.

Подробнее о фиче:
Foreign Keys in the Entity Framework

10) SQL Generation Improvements: readability and performance

Здесь все достаточно просто: генерируемый SQL стал более шустрым и более читабельным, сам процесс генерации тоже ускорился.

Подробнее о фиче:
Improvements to the Generated SQL in .NET 4.0 Beta1
Checking for EF to TSQL Query Compilation Changes in VS2010 Beta1

Об остальных фичах более кратко:

Checking out one of the new stored procedure features in EF4
A big step for Stored Procedures in EF4
Pluralization support
The much improved EDM Wizard Pluralization in VS2010
Complex Types in the EDM Designer in EF4 and a look at updating complex types in code
More Designer Improvements - Deleting Entities from the model and from the store schema

Также ADO.NET team выпустил пару статей по "правильному" написанию кода для поддержки Repository, Unit of Work и даже N-Tier applications. Почитать можно, но все же, на мой взгляд, там лучше почитать комментарии и ссылку, которые в них:

Using Repository and Unit of Work patterns with Entity Framework 4.0
Sneak Preview: N-Tier development with Entity Framework 4.0

Ну, а утрамбовать это все стоит отличным подкастом .NET Rocks #451, где происходит интервью с уже упомянутым Daniel Simmons, который более детально рассказывает о реализации некоторых вышеуказанных фич.

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

Удачи!

Sunday, August 2, 2009

Ошибки технических менеджеров проектов

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

Об общих ошибках управления проектами написано уже очень много, поэтому я не хотел бы повторяться. Об этом можно почитать здесь, здесь, а также в куче других мест - достаточно лишь погуглить по ключевым словам. Я же хотел бы остановиться на некоторых ошибках, которые свойственны именно бывшим техническим лидам, ставшим менеджерами проектов или начинающим выполнять эту роль в дополнение ко своим текущим обязанностям. Причем говорить я буду о бывших программистах, а не о QA, BA или ком-то другом, потому что:

  • я на практике сталкивался в основном с PM, которые в прошлом были программистами, а не QA или BA - банально нет подобного опыта, поэтому мало о чем могу сказать
  • на мой взгляд, PM из бывших QA и BA не будут совершать часть из перечисленных ниже ошибок, просто по тому что они специфичны для программистов
  • я сам - программист, поэтому мне проще основываться еще и на своем личном опыте и своих ошибках :)

Думаю, любой человек, работая под началом разных менеджеров, видел различия в отношении и подходах. У каждого PM свой уровень знания и умений, менталитет, психология, поэтому стили управления отличаются. Но если посмотреть на PM, которые в прошлом были программистами, можно заметить некоторые общие черты и типичные ошибки, которые те совершают. Основная причина этих "типичных" ошибок - менталитет, установленные подходы и шаблоны работы в бывшей роли программиста, а не просто недостаток знаний или понимания процесса управления проектами. Почти любой программист, при условии хороших технических знаний и наличии лидерских качеств, может стать хорошим лидером, но это еще не значит, что он может стать хорошим менеджером. Между "управлением" продуктом, которым, по сути, занимаются DL или TL, и управлением проектом и командой, которым занимается PM есть большая разница.

Ошибка №1. Непонимание целей и задач роли PM

Я уже упоминал, что цели и задачи ролей DL и PM отличаются. Основная задача DL - реализовать продукт технически. Это его сфера ответственности. Основная задача PM - успешно завершить проект в рамках запланированных сроков, бюджета, объема функционала и его качества, таким образом сделав клиента довольным и счастливым. Попутно можно сказать, что основная задача QAL состоит в том, чтобы удостовериться, что полученный в результате выполнения проекта продукт - это именно то, что нужно клиенту и что качество этого продукта соответствует предъявленным требованиям, но QA мы пока что трогать не будем. Таким образом, обязанности PM состоят не только в том, чтобы общаться с клиентом, давать всем подзатыльники, а также писать спецификации и отчеты (изверги, бумажной работы навалили, ужас!), а в том, чтобы создать условия и наладить процесс работы, в рамках которых команда достигнет результата, попутно эффективно управляя требованиями, рисками, различного рода ресурсами (в том числе и человеческими) и т.д. И это все нужно понимать и делать, даже если PM - всего лишь дополнительная роль, которую вам приходится выполнять по долгу службы, а не настоящая должность.

Ошибка №2. Неумение смотреть на проект и продукт с точки зрения клиента (бизнеса)

Менеджер проекта в какой-то степени является промежуточным звеном между командой и клиентом. Поэтому если программист и DL могут позволить себе думать только о реализации и проблемах, связанных с ними, быть "по эту сторону баррикад", то PM уже должен думать не только о команде, но еще и о клиенте, его целях, желаниях и проблемах. Любой продукт, разрабатываемый в рамках проекта, несет для клиента какую-то выгоду (не обязательно финансовую). Если же мы в угоду желания попробовать новую технологию, реализовать эту фичу "по-своему" или даже просто по глупости убиваем эту выгоду - клиент не будет доволен. И PM иногда является единственным носителем полной информации о целях и желаниях клиента. Да, в какой-то степени это еще и обязанность QA, но зачастую они не могут принять решение в момент разработки, а лишь тогда, когда что-то уже сделано. Поэтому лишь PM может вовремя остановить разработку и направить ее в правильное русло. Нужно помнить, что PM является не только адвокатом команды перед клиентом, но и адвокатом клиента перед командой.

Ошибка №3. Считать себя самым умным и самым главным

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

Ошибка №4. Злоупотребление делегированием-исполнением, а не делегированием-руководством (микроменеджментом)

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

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

Ошибка №5. Боязнь показать свое незнание

У программистов это чувство развито очень сильно :) Поэтому довольно часто менеджеру сложно спросить какие-то детали, попросить о помощи - ведь он вроде бы как самый главный в команде (см. ошибку №3), негоже перед подчиненными показывать свою слабость, вдруг перестанут уважать. Достаточно глупо и, к сожалению, иногда весьма критично для проекта. У PM есть куча других обязанностей, поэтому ему часто некогда вникать в детали, новые технологии и подходы разработки. Немудрено, что некоторые люди на проекте, которых вы раньше учили сами, вдруг окажутся осведомлены в чем-то техническом больше вас. Это нормально, не обращайте на это внимания, развивайтесь в свою сторону, и старайтесь наоборот стимулировать профессиональный рост своей команды, ведь чем сильнее команда - тем успешнее будет ваш проект.

Ошибка №6. Поверхностное отношение к команде и ее интересам

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

Ошибка №7. Остановка технического роста

Казалось бы, какое отношение это имеет к управлению проектом? Никакого. Но зато это имеет самое прямое отношение к реалиям жизни. Если бывший программист, став PM, полностью останавливает свой технический рост по принципу "я уже и так достиг всего чего мог в техническом плане, могу забить", то это, по сути, рубание ветки, на которой сидишь. Да, технические навыки не обязательны для того, чтобы быть эффективным менеджером, но тем не менее кто вам даст гарантию, что один из ваших следующих проектов, который будет через год или два, не потребует от вас занятия должности PL, который будет руководить и технической, и организационной частью проекта? Или что на вашем следующем месте работы это не будет обязательным требованием? А будете ли вы тогда достаточно подкованы в новых технологиях или подходах для того, чтобы довести подобный проект до успешного завершения? На мой взгляд, если уж вам так повезло, и вы прошли весь путь от падавана до мастера Йоды в программировании, то не забрасывайте свои технические знания в темный чулан, развивайте их, хотя бы на поверхностном уровне изучайте новые технологии и подходы к разработке ПО, совершенствуйтесь!

Успехов вам и вашим проектам!