Видимо, моё расписание на PDC будет примерно таким. График достаточно плотный, учитывая  то, что всё начинается в 8:30 утра с Keynotes, потом секции, а после них всякие мероприятия до 9 вечера. Кроме последнего дня, когда всё просто заканчивается в 4:00.

Вообще весь PDC, похоже, приурочен к выходу Windows Azure и большинство докладов связано с ним.
Но, поскольку Microsoft решили ограничить объем базы данных на Azure 10-ю гигабайтами, что для нашего проекта крайне мало… В общем, Azure пока не слишком актуальна и я решил посмотреть “более другие” вещи.

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

Ну, в общем, получается как-то вот так:

Monday
    10:00 AM - 5:45 PM
        Patterns of Parallel Programming: A Tutorial on Fundamental Patterns and Practices for Parallelism

Tuesday
    11:00 AM
        Software + Services Identity Roadmap Update
        OR
        Data Programming and Modeling for the Microsoft .NET Developer

    12:30 PM
        Concurrency Fuzzing & Data Races

    01:30 PM
        Agile – Tales of Triumph, Tribulation, Tools, and Teams
        OR
        Microsoft ASP.NET Futures

    03:00 PM
        Microsoft ASP.NET 4 Core Runtime for Web Developers
        OR
        Evolving ADO.NET Entity Framework in Microsoft .NET Framework 4 and Beyond

    04:30 PM
        Code Contracts and Pex: Power Charge Your Assertions and Unit Tests
        OR
        Behavior-Driven Development vs. Test-Driven Development: What’s What?

Wednesday
    11:30 AM
        Microsoft Perspectives on the Future of Programming
        OR
        Building Data-Driven Applications Using Microsoft Project Code Name "Quadrant" and Microsoft Project Code Name "M"

    01:00 PM
        Microsoft Project Code Name “M”: The Data and Modeling Language
        OR
        Making Microsoft SQL Server 2008 Fly

    02:00 PM
        ADO.NET Data Services: What’s New with the RESTful Data Services Framework
        OR
        Spice Up Your Applications with Windows Workflow Foundation 4

    03:15 PM
        Windows Workflow Foundation 4 from the Inside Out
    
    04:30 PM
        Exception Management – Handling and Reporting Exceptions Effectively

Thursday
    08:30 AM
        Building Hybrid Cloud Applications with Windows Azure and the Service Bus
        OR
        Patterns for Building Scalable and Reliable Applications with Windows Azure

    10:00 AM
        Axum: A .NET Language for Safe and Scalable Concurrency
        OR
        Microsoft Visual Studio Lab Management to the Build Setup Rescue

    11:30 AM
        Workflow Services and “Dublin”

    12:45 PM
        Microsoft Semantic Engine

    01:45 PM
        Application Server Extensibility with Microsoft Project Code Name “Dublin” and Microsoft .NET Framework 4

    03:00 PM
        Automating "Done Done" in the Team Workflows with Microsoft Visual Studio Ultimate and Team Foundation Server 2010

В .NET Framework 4.0 планируется (и в Beta 1 уже есть) некоторая поддержка параллельных вычислений. Что, конечно, не может не радовать в свете того, что я уже писал здесь по поводу многопроцессорности, многоядерности и человеческих способностей всё это эффективно использовать.

В частности, в .NET 4.0 появляются такие вещи, как статический класс Parallel:

Parallel.For()
Parallel.For<>()
Parallel.ForEach<>()
Parallel.Invoke()

и статический класс ParallelEnumerable со всеми его благами в виде .Cast<>, .All, .Where, .GroupBy и прочее, прочее.

Кроме того, IEnumetable теперь тоже имеет метод-расширение (или как это по-русски? придумали термин? extension method, в общем) .AsParallel, позволяющий распараллелить операции над элементами последовательности.

Очень здорово: если у меня есть цикл, обрабатывающий немереное количество данных и я знаю, что обработка каждого элемента независима (например, я увеличиваю стоимость каждого продукта на 20% и выбираю все, ценою до 50 долларов), то все, что мне нужно сделать, чтобы эта часть приложения работала эффективнее – это просто воспользоваться соответствующей конструкцией.

Насколько оно эффективно?
Ну, если верить словам разработчикам pLINQ (parallel LINQ), выступление которых я смотрел еще на TechEd 2008 Australia, то достаточно эффективно: “параллелит” оно учитывая количество процессоров/ядер, данные, что-то еще… Плюс там предусмотрено несколько стратегий работы (как именно парраллелить данные), используются lock-free алгоритмы… Словом, это гораздо, гораздо эффективнее того, что делает большинство из нас даже в лучшем случае (создать 1-2 потока на ядро). В обычном же (даже не в худжем) случае мы даже не думаем о параллельности, просто пуская привычный for/foreach, правда?

Ну, и эксперимент. Простой цикл на 1000 итераций, я не придумал, что делать в каждой из итераций, поэтому просто сделал там задержку в 100 милисекунд.
Результат:
 
Первая цифра - “обычный” for, вторая - Parallel.For().

Вчера (или позавчера) в публичный доступ выложили Visual Studio 2010 Beta 1 и .NET Framework 4.0 Beta 1.
Поскольку я из своего личного опыта знаю, что начиная с бета-версии со студией уже можно вполне нормально работать, да и сам статус “Бета” означает, в отличие от CTP, что архитектура фреймворка устоялась и даже если и будет меняться, то будет меняться незначительно… В общем, нет повода не начать присматриваться к будущему инструменту. И нет повода не начать изучать инфраструктуру, с которой придется работать, опять таки в будущем.
Ну а чтобы было не так скучно, буду писать по ходу дела. Сегодня – только про “студию”, дальше – глубже.

Про установку рассказывать не буду. Установка – как установка, времени сколько заняла – не считал, не принципиально. Самое интересное – после.

Нужно сразу сказать, что UI у Visual Studio теперь сделан на WPF. Даже редактор кода. Отсюда много всяких интересностей (а то, на самом деле, для всех людей программы развиваются, принципиально эволюционируют, а программисты до сих пор в примитивных, в общем-то, текстовых редакторах сидят). Но пойдем по порядку.

При первом запуске на обновленной стартовой странице я увидел возможность загрузить расширения.
Про расширения – отдельная история. Расширения к новой “студии” делаются и подключаются до безобразия элементарно (фактически атрибут навесить да в папку скопировать), не то, что раньше. Над extensibility поработали тоже неслабо. В общем, наверное, стоит ожидать большого количества плагинов на любой вкус, начиная от визуализаторов (те же комментарии показывать не в виде xml comments, а более красиво и функционально, как это показывали на MIX) и каких-то очень функциональных вещей.

Итак, расширения. Конечно, стало интересно. И, конечно, их пока не много – всё же бета, да и комьюнити не подключилась… Но полезного я себе уже нашел:

Полезным показался Regex Editor (возможно будет альтернатива глючному “The Regulator” и волшебному “ConsoleApplication1”), Italic Comments (интересно попробовать) и Image Insertion для вставки картинок в комментарии (я уже говорил, что UI написан на WPF и редактор стал более продвинутым?). Комментарии я люблю (в том числе и писать). Советую.

Что приятно, очень приятно - “студия” “научилась” строить sequence-диаграммы! То есть, можно кликнуть мышкой на любой метод, ограничить уровень вложенности и получить такую вот диаграмму:

Или вот так:

Это как раз то, чего не хватает в повседневной работе! Не слишком-то это удобно – отслеживать Call Flow с помощью Find All References / Go To Definition. Или в дебаге по call stack’у, тоже не всегда удобно.

О дебаге, кстати. Появился новый (во всяком случае я такого раньше не видел) инструмент: Debug History:

Очень удобно! На каждом шаге можно посмотреть и autos и call stack. Ну и обратите внимание на значки на второй картинке: тоже, на мой взгляд удобно.

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

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

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

Плюс в составе студии (team suit я ставил конечно) появились очень полезные инструменты для работы с базами данных, из картинки хорошо видно, что там.

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

Инструментов рефакторинга, кстати, в Visual Studio 2010 не добавили. Жаль. Ибо ReSharper, например, глючен неимоверно, так и пришлось его снести чуть ли не всей командой. Самые стойкие еще держатся (таких у нас один). Из категории “мыши плакали, кололись, но продолжали есть кактус” :)

Это был мой первый запуск Visual Studio 2010, так сказать, знакомство с интерфейсом. На более функциональные вещи как студии, так и 4-го фреймворка посмотрим чуть позже.

Вышел ASP.NET MVC 1.0. Наконец-то.

Качать где всегда - http://www.asp.net/mvc/

Вообще-то я давненько уже писал:
- “О пользе IEnumerable”
- “Еще о коллекциях и многопоточности.”

Сегодня встретил вот постинг Эрика Люпперта (человек имеет прямое отношение к созданию C#) относительно того, когда же стоит пользоваться массивами (которые Array).
По его мнению – никогда. Причины перекликаются с теми, о которых писал и я, но почитать интересно.

Ссылка: http://blogs.msdn.com/ericlippert/archive/2008/09/22/arrays-considered-somewhat-harmful.aspx

Почти год назад я уже писал о том, для чего нужны DTO(и это не только веб-севисов касается, это вплоть до контрактов между бизнес-логикой и UI, если нужно) и какие проблемы решаются с их помощью. Тогда я говорил об этом в связи с тем, что использовать объекты бизнес-модели в качестве этих самых DTO вредно и вообще плохо.
Однако, в последнее время столкнулся с другой крайностью, которую я бы обозвал DTO Driven Development. Ситуация получается тоже странная. Я объясню.

Представьте себе достаточно крупное приложение: различные там слои, подсистемы, WCF-сервисы, UI и т.д. Теперь в общем виде представьте себе физическую структуру этого приложения: всякие там веб-сайты, WCF-сервисы, куча DLL с разными логиками, все как обычно. А среди всей этой толпы DLL есть одна с названием MyCompany.DTO.dll. В этой библиотеке сложены DTO для всего приложения. Ну, там, UserDTO, CompanyDTO, ProductDTO (суффиксы только для примера). И все “слои” и подсистемы этого приложения пользуются этими DTO для того, чтобы обмениваться данными. Делается это для того, чтобы, дескать, не увеличивать сложность приложения, не “плодить” “лишних” классов, и еще куча-кучей благих побуждений.

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

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

Если еще не понятно, то мы получаем навязанный нам “третьей” стороной контракт.
По идее мне нужно вернуть имя/фамилию пользователя и его почтовый адрес, а приходится возвращать пару UserDTO+AddressDTO, при этом и тот и другой объект будут содержать либо кучу совершенно ненужной в рамках данного контекста информации (какие-нибудь поля CompanyID, ManagerID, Age, LoginName для пользователя и какие-нибудь PhoneNumber, FaxNumber для адреса), либо же “ненужные” поля будут незаполнены, что вообще бред полнейший, так как получатель имеет на руках непонятно почему “недозаполненный” объект.
Если же нужно в этих данных изменить и отправить назад – то вообще полный кошмар: как заполнять эти объекты, где брать недостающую информацию, что я обязан заполнить, а что – нет?
По сути нам говорят “вы будете укладывать свои данные вот в эту структуру. Ах не лезет?! Нет уж, упихивайте!”

На стороне же клиента, который обращается к заданной подсистеме, вообще “непонятки”: вместо одного простого объекта, просто содержащего необходимую информацию и укладывающегося в его бизнес-модель, ему приходит два каких-то “левых”. Лично я бы не обрадовался на месте программиста, работающего с таким API.

Кроме того – потенциальный “косяк” на будущее. Если нам вдруг срочно потребуется где-то изменить имеющийся DTO, то это немедленно затронет ВСЕ подсистемы, где он был использован. И ВСЕХ клиентов этих подсистем. Даже если мы всегда точно знаем все места использования этого объекта, всех этих клиентов, то, согласитесь, править (да и хотя бы просто заново тестировать) все это дело как-то не очень-то и хочется.

Это все как-то уже и не очень сочетается с посылом “не увеличивать сложность”, не правда ли? Ведь один из главных столпов ООП – инкапсуляция. А что рекомендуется инкапсулировать? Правильно, инкапсулировать нужно изменения. Ну, чтобы можно было что-то где-то в одном месте поменять, а в других местах это и не аукнулось бы никак. Вот тогда и сложности никакой не будет.

Итак, какая ситуация была бы правильной:

1. Каждая подсистема, имеющая внешний API, имеет собственный, ни от кого не зависящий набор DTO, который по смыслу подходит этому API.
2. Изменения, вносимые в API подсистемы, затрагивают только этот API и, возможно, его прямых клиентов и НЕ затрагивают никаких других частей приложения. На самом деле, то, что вы передаете из API-функции своей подсистемы – дело только этой самой API-функции и тех, кто именно ее использует. Это и называется “контрактом”.
3. Ваши подсистемы будут действительно независимы (к чему мы и стремимся).

Как этого добиться:

1. Никогда не используйте объекты бизнес-модели в качестве контрактов данных (DTO) и наоборот. DTO – это только DTO. Они передают данные – и только, такая у них работа. Это опять сюда, плюс инкапсуляция потенциальных изменений. Плюс, опять же, в OOP укладывается: каждая сущность делает что-то одно.
2. Пусть каждая подсистема имеет собственный набор DTO, относящийся только к этой подсистеме.
3. Наплюйте на количество классов. Поверьте, никто вас в количестве классов не ограничивает, можно создать столько, сколько нужно. Честно. Легче поддеживать два или три маленьких специализированных класса, чем поддерживать и всюду притягивать за уши один большой и унивесальный. Даже и чисто по времени легче.
4. Попробуйте оценить свои DTO именно как средство транспортировки данных между вашим подсистемой и ее непосредственным клиентом. То есть, ваш DTO не должен служить средством связи дяди Васи с дядей Петей, если вы сами не один из них :) Иначе однажды к вам придет Петя и скажет “хочу, чтобы Вася мне еще и сплясал, а твой убогий транспорт этого не позволяет! Меняй!” И будете менять, и менять везде, ибо переводить Васю с Петей на другой, собственный, транспорт может быть уже слишком накладно.
5. DTO должен пересекать только одну желтую линию границу: границу той подсистемы, в которой он создан. Других границ (между дядей Васей и дядей Петей) он пересекать не должен.

Все гораздо проще, чем вам бы того хотелось :)

Готовится к выходу первый сервиспак для VS2008 и .NET Framework 3.5.

Очень много багфиксов, обещают поднять производительность. Впрочем и список нововведений впечатляет.

С сегодняшнего дня доступна бета-версия сервиспака.

Подробнее здесь: http://weblogs.asp.net/scottgu/archive/2008/05/12/visual-studio-2008-and-net-framework-3-5-service-pack-1-beta.aspx

Вот здесь можно скачать бесплатный training kit по новшествам ASP.NET 3.5.

Kit содержит материалы и примеры следующих технологий:

1. ADO.NET Data Services
2. ADO.NET Entity Framework
3. ASP.NET MVC
4. ASP.NET Dynamic Data
5. ASP.NET AJAX History
6. ASP.NET Silverlight Controls

Вышел релиз сразу большого количества Application Blocks, ориентированных на разработку web-приложений на ASP.NET.

Точнее, видимо, оно релизится прямо сейчас, так как некоторые ссылки еще не доступны для скачивания :)

Web Client Search Application Block for .NET Framework 2.0
Web Client Search Application Block for .NET Framework 3.5

Web Client Validation Application Block for .NET Framework 2.0

Web Client Composite Automation for .NET Framework 2.0

Web Client Modularity Application Block for .NET Framework 3.5

Web Client Model View Presenter Application Block for .NET Framework 2.0
Web Client Model View Presenter Application Block for .NET Framework 3.5

Web Client Contextual AutoComplete Application Block for .NET Framework 3.5
Web Client Contextual AutoComplete Application Block for .NET Framework 2.0

Web Client Composite Library for .NET Framework 2.0
Web Client Composite Library for .NET Framework 3.5

А так же примеры использования.

Web Client Responsive Composite Reference Implementation for .NET Framework 3.5
Web Client Responsive Composite Reference Implementation for .NET Framework 2.0

Сегодня в Бельгии состоялась встреча VISUG (я уже немного рассказывал, когда была встреча со Scott Guthrie), единственным докладчиком которой был сам Juval Lowy - человек, который написал книжку, обложку которой вы сейчас видите справа.

Сразу скажу, что книжку я не читал. Но теперь обязательно добуду и прочитаю. Но речь не об этом (обложку книжки я вставил только потому, что не нашел в интернете адекватной фотографии автора ;))

Juval оказался очень хорошим докладчиком. Он отлично раскрыл тему и показал, что WCF - это далеко не "новое поколение веб-сервисов". Причем показал на очень простых, но очень впечатляющих примерах, уделяя внимание совершенно не коду (его-то как раз было мало), а именно проблематике.

Вообще, о много о чем он там говорил, этот "человек-легенда", в частности он назвал WCF "улучшенным .NET'ом", называя его именно платформой для разработки. Он даже обвинил Майкрософт в том, что они, дескать, не могут нам сейчас сказать: "все, что вы сейчас делаете - устарело. Они [microsoft] специально говорят 'WCF? О, это для веб-сервисов!'. Вспомните, то же самое они говорили когда появился .NET 1.0" :)

В общем, интересность и полезность выступления можно оценить на 12 баллов из 10 возможных.
Автор отлично показал, зачем нужен WCF, какие проблемы он решает, какова парадигма этих решения проблем в "привычном" подходе...

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

P.S. Забавно он начал свое выступление: "WCF - это удивительно просто для программиста. Пара атрибутов и две строчки кода для создания хоста - все, что нужно 95% разработчиков. Но давайте попробуем ответить на вопрос, почему об этом пишут книги в 750 страниц?!". На вопрос ответил превосходно. Что называется "раньше я не думал, теперь я знаю" :)