Ускоряем SharePoint-разработку

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

Однако, тестировать SharePoint-решения не так-то просто. Их ведь надо еще задеплоить. А пока деплоишь, заснуть можно!... И потом сиди вспоминай, что вообще протестировать-то хотел...

И ведь все знают, что нередко бывает так: правишь пару символов - это занимает буквально секунды, и потом деплоишь пять минут, чтобы посмотреть результат. Потом видишь что не помогло - и по новой, еще пять минут деплоя... И не думайте, что концентрация от этого не теряется. Еще как.

Смешно сказать, но я до сих пор вспоминаю SPVisualDev, расширение для Visual Studio для работы с SharePoint 2007. Мгновенное развертывание в 12 hive, отличная поддержка удаленной разработки и отладки, всё удобно, быстро и просто. Этого в SharePoint Developer Tools нет и в помине даже сейчас, в 2014!...

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

Тем временем во "внешнем мире"...

1. Проект IDE Light Table набрал $300k на Kickstarter. Основная идея проекта - в "живой разработке", когда IDE всегда находится в режиме отладки (!). Т.е. обычного режима не-отладки просто не бывает. Только начали писать код - тут же можно смотреть состояние переменных, и т.д.
2. Многие современные IDE поддерживают режим "live development". Пример - опенсурсная IDE Brackets. Вот одноминутная демка:
   
   
3. Visual Studio и ASP.Net развивают проект "Browser Link". Идея состоит в том, чтобы инжектить Signal-R скрипт на страницу, что позволяет в дальнейшем этой страницей управлять: релоадить целиком или частями, изменять, и т.д. "Browser Link" можно расширять с помощью Visual Studio extensions. В составе Web Essentials есть несколько крайне интересных расширений такого плана. Скотт Хансельман в этом 4х-минутном видео подробно все это демонстрирует:
   
   
4. Visual Studio "14" CTP 4 по умолчанию использует open source компилятор Roslyn, который имеет расширенные средства для работы с неполными синтаксическими деревьями, благодаря чему им удалось сделать on-fly incremental compilation. Идея в том, чтобы пропустить шаг Build. Т.е. меняем код, сохраняем, переходим в браузер, F5 - и смотрим изменения.
5. Помимо общеизвестного jsFiddle, появляется все больше и больше других Fiddle'ов, крайне интересных! Например, проект dotNetFiddle не только позволяет писать C# код онлайн, но также предоставляет режим, в котором можно тестировать полномасштабное ASP.Net MVC приложение (выберите Project Type: MVC)!

И т.д., список можно продолжать. Но я думаю вы поняли идею: все осознают, что чем меньше задержка между написанным кодом и увиденным результатом, тем лучше. И к этому идут. Но что можем сделать мы, SharePoint-разработчики?

Оказывается, и в SharePoint тоже можно сделать немало!

Для начала, продолжая мысль из поста про скрытую прелесть provider-hosted Apps, ну как бы все современные вещи можно там использовать без ограничений :) Так что всё что выше описано, нам по большому счету тоже доступно. Надо просто не забыть воспользоваться.

Во-вторых, кратко вернусь к SPVisualDev. Это open source расширение было написано ОДНИМ человеком в 2008 году. Получается, не настолько уж это и сложно?... ;)

Дальше. Давайте подумаем про BrowserLink. Можно ли что-то похожее использовать в SharePoint? Я думаю - да. Ведь BrowserLink это ни что иное, как банальный SignalR. Если заинжектить аналогичный SignalR скрипт в masterpage SharePoint-сайта, то мы получим точно такое же "живое" соединение Visual Studio и SharePoint. Я думаю можно просто выдрать из страницы то, что Visual Studio инжектит, и запихнуть в SharePoint, и оно будет работать. Не успел проверить пока.

Дальше. А что насчет jsFiddle и ASP.Net MVC fiddle? Можно ли сделать собственный SharePoint fiddle? ДА БЕЗ ПРОБЛЕМ! Вот например оцените, проект JSON fiddle:

• Блог пост: Introducing JSOM fiddle SharePoint app
• В Office Store: JSOM fiddle app
• Исходный код на Github

Опять же. Сделано буквально на коленке, какой-то мужик посидел пару вечеров и написал. Вы, дорогой читатель, тоже могли бы такое написать, даже в одиночку. И вас, дорогие читатели, смею заметить, дофига.

Моя попытка: CamlJs-Console

Вообще, на удивление, многие вещи не настолько сложные, как кажутся. Примерно в середине сентября я начал работать над крайне интересным проектом под названием CamlJs-Console. Это расширение для хрома, позволяющее создавать CamlJs-запросы в режиме live development, очень похожем на пример выше про Brackets. Пишешь - и сразу же видишь результат.

Оказалось, что Chrome Extensions пишутся на HTML+CSS+JavaScript. Очень просто. При желании можно даже создавать Chrome Extension + Web App (или даже SharePoint App) из одного исходного кода...

БЛИН! Я когда только-только сделал самую первую версию у себя на локальной машине в 3 часа ночи :), я сидел тестировал и не мог остановиться. Это настолько отличалось от вот этого "поправил-5 минут деплой", что чувствовалось как магия какая-то. Серьезно :)

Общий вид:

А вот live preview данных из списка:

Мне даже удалось подцепить туда интеллисенс (на основе TypeScript Language Service - ведь как известно, TS является расширением над JS, т.е. любой валидный JS-код является также и валидным TS-кодом):

И более того, мне даже удалось сделать интеллисенс лучше, чем TS-интеллисенс в Visual Studio! Потому что ведь у меня были живые списки. И их поля... :)

Мне кажется, получилось здорово! И заняло каких-то пару недель, причем большую часть времени возился с интеллисенсом.

Преимуществ у Chrome Extension немало: не надо аутентифицироваться, не надо ничего ставить на сайт (в отличие от того же SharePoint App). Можно тестировать и онлайн сайты, и на dev виртуалке, и что особенно ценно - зайти на production и там проверить запрос, на реальных данных (!). Интеграция работает через JSOM, но можно реализовать вариант на веб-сервисах (через SPServices например), и тогда будет работать даже с SharePoint 2007 (сейчас только SP2010 и SP2013).

Что дальше?

Ооооо... у меня полно идей, просто миллион! Можно делать extension'ы наподобие CamlJs - для работы с конкретным API, решения конкретных проблем. Можно делать более широкопрофильные, наподобие JSOM fiddle, но именно в виде Chrome extension. Можно копать в сторону интеграции Visual Studio и SharePoint, создания чего-то похожего на BrowserLink. Можно подумать о гибридных решениях, Visual Studio -> Chrome Extension -> SharePoint.

И это все может значительно улучшить наш процесс работы с SharePoint. Значительно!

Коллега с работы делает сейчас потрясающую штуку, как раз под впечатлением от CamlJs-Console. Крайне легко делается, но возможности открываются потрясающие. Смысл в том, что в Chrome через F12 можно редактировать файлы, подгруженные на страницу. Но конечно эти изменения никуда не сохраняются. Ну а вот он сделал так, что сохраняются, обратно в SharePoint :) И кода там - 50 строк :))). Проект пока на супер-начальной стадии, поэтому если захочется потестировать, тестируйте аккуратно и только на dev-окружении please :) Ссылка вот.

Заключение

Я из всей этой истории главное вот что понял: все в наших руках. Не надо ждать MS или еще кого. Мы сами можем.

P.S. Если у кого есть идеи/мысли на этот счет, с удовольствием поучаствую в обсуждении - кидайте комментарии! :)

3 простых способа подружить KnockoutJs и SharePoint

Попал на старый проект, SharePoint 2010. Бывает, что тут сделаешь! Спасаюсь от скуки только благодаря KnockoutJs :) Всвязи с чем - этот пост.

KnockoutJs как MVVM фреймворк на самом деле ничем не уступает тому же Angular'у. Единственная вещь, которую нужно очень хорошо изучить и вызубрить в Knockout - это когда скобки () нужны, а когда нет, и как этот ko observable wrapping вообще работает. Преодолев этот порог, больше с Knockout проблем не возникает. Angular конечно помощнее, более фундаментальный, но и всякой магии в нем намного больше, траблшутить крайне сложно, и модель освоения Angular действительно вот такая (проверено на собственном опыте):

Так что, в своих SharePoint-проектах я преимущественно использую именно Knockout. И в этом посте я опишу три простых техники использования Knockout совместно с SharePoint.

Как я исправил невоспроизводимую ошибку SharePoint с помощью UX-паттерна

В прошлый раз я теоретизировал о необходимости знаний по UX у SharePoint разработчиков. Сегодня хочется рассказать об интересном прецеденте использования UX-паттерна для исправления невоспроизводимой ошибки SharePoint.

Дано

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

Иногда один или несколько сайтов не создаются по неизвестной причине. Ошибка валится на Webs.Add и она плавающая: то есть, то нет. Более того, по закону подлости она возникает исключительно на production environment. И это еще не всё, когда ко мне попала эта задача, логи с последней ошибкой уже потерлись, поэтому я даже не располагал сообщением об ошибке!...

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

Стандартный подход

Стандартным подходом было бы поочередное исследование кода решения и затем кода Webs.Add через рефлектор, и попытка понять в чем может быть дело (скорее всего неудачная, т.к. Webs.Add довольно быстро уходит в Unmanaged код).

Можно конечно пробовать разные варианты параметров или порядка или какие-нибудь задержки... Но поскольку ошибка не воспроизводится нигде кроме production, а production можно обновлять только раз в 1-2 месяца, да еще и используется этот модуль не интенсивно... В общем методом "тыка" можно было бы растянуть проблему на годы. Собственно, это и происходило - когда я взялся за проблему, она существовала уже больше года.

UX подход

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

В моих любимых Apple UX Guidelines есть следующий пункт:

Display an informative, actionable alert message when something goes wrong. An alert should clearly convey what happened, why it happened, and the options for proceeding. Describe a workaround if one is available and do whatever you can to prevent the user from losing any data. Avoid using an alert to deliver information that the user can’t act upon.

В этих четырех предложениях - буквально всё, что вам нужно знать об обработке ошибок! На всякий случай по-русски:

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


Что это означает в нашем случае?

1. Нельзя "глотать" ошибки создания сайтов.
2. При отображении ошибки, необходимо предоставить не только информацию о том, что случилось и почему, но также необходимо предоставить возможность действия.

Решение

Решение очень простое, но при этом надежное и удобное.

Во-первых, я добавил информацию об ошибке: в случае, если один или несколько сайтов не были созданы, отображается таблица со статусом по каждому из сайтов (Success/Failure).

Во-вторых, рядом с Failure я добавил кнопку Retry. ВСЁ!

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

Такие улучшения интерфейса безусловно повлекли за собой некоторое количество работы и немного рефакторинга, т.к. для того, чтобы сделать возможность Retry, пришлось отделить код создания сайтов в обособленный метод, но в любом случае вся работа заняла 2 дня - с большими перерывами на чай и бильярд. Стоит ли говорить, что investigation мог бы занять практически сколько угодно времени и ни к чему не привести?

Отдельно отмечу: это решение полностью закрывает задачу. ПОЛНОСТЬЮ. С точки зрения пользователя, проблемы больше нет. Нажать пару раз кнопку Retry, при том что интерфейс используется пару раз в месяц - да это вообще не вопрос, верно же?

Выводы

1. Ошибку можно исправить, не исправляя ее
2. Я уже писал, что знания по UX меняют сам подход к разработке. И к исправлению ошибок - тоже. Всё, что мы с вами видели выше - это просто подход к решению с другой стороны. Много раз я убеждался, что это реально работает и дает плоды.

Так что вот. И да пребудет с вами UX! :)

Usability и UX в SharePoint

SharePoint далеко не идеален с точки зрения Usability, и это ни для кого ни секрет. Однако я заметил, что как ни странно, клиенты в большинстве случаев довольно спокойно относятся к "страшным", медленным и неудобным интерфейсам в интранете. Более того, когда я предлагаю даже незначительные UX-усовершенствования которые не занимают много времени на реализацию, клиенты склонны отказываться...

Клиенты нормально относятся к страшным и неудобным интерфейсам

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

Права доступа в SharePoint

Сделать какие-то кастомные права доступа в SharePoint - это одна из самых частых задач в SharePoint, однако, к сожалению, 90% разработчиков решают эту задачу неоптимально.

Русскоязычные SharePoint-блоггеры

К сожалению, людей, хорошо пишущих про SharePoint на русском языке — единицы. Под «хорошо» я имею в виду уникальный, интересный контент, грамотно оформленный и представляющий практическую ценность. Впрочем, несколько человек всё-таки есть, и сегодня мне хочется о них рассказать и обратить на них внимание общественности, потому что, к сожалению, нередко эти блоги далеко не настолько популярны, насколько они этого заслуживают (возможно, причина в том, что многие SharePoint-разработчики свои запросы в гугле набирают исключительно по-английски?...).

Итак, поехали...

SharePoint и XSLT: Почему XSLT - это важно?

Начинаю серию статей по XSLT в SharePoint.

XSLT в SharePoint - чрезвычайно мощный инструмент, глубоко интегрированный в систему. Даже в предыдущей, 2007й версии, роль XSLT была довольно велика - преобразования использовались при отображении результатов поиска (CoreResultsWebPart), а также для кастомизаций отображения представлений и форм списков (DataViewWebPart и DataFormWebPart).

В 2010м SharePoint'е XSL-преобразования используются еще более интенсивно. Отображение представлений всех стандартных списков, кроме календарей, осуществляется теперь именно через XSLT (XsltListViewWebPart). Формы внешних списков также отображаются через XSLT (XlstListFormWebPart), так что тенденция видна невооруженным взглядом: поскольку данные в SharePoint представляются в виде списков, на которые завязано всё, то можно смело сказать:

Практически всё отображение данных в SharePoint'e осуществляется с помощью XSLT

SMS и SharePoint

Уже больше года назад, мы писали на работе очень интересное решение, которое впоследствии вошло в состав нашего портала DeskWork - по отсылке оповещений, в том числе SMS. И вот в который раз убеждаюсь, насколько важно изучать SharePoint и его внутренности, потому что ценой минимальных усилий, оказывается, можно было бы глубоко сынтегрировать ту систему SMS-рассылок с SharePoint, получив массу вкусных бонусов (а может быть, мы это еще сделаем в будущем).

Я имею в виду встроенную в SharePoint возможность отсылать SMS и даже MMS по протоколу Office Mobile Service Protocol. Протокол вполне продуманный: предусмотрена пакетная отправка сообщений и интерфейс для получения статусов доставки... В этом посте я расскажу, как можно этот самый OMS использовать в своих решениях, и какие бонусы можно получить.

Работа с XML в SharePoint из Javascript

SharePoint очень тесно связан с XML. Все эти схемы полей и списков, определения элементов Ribbon, SharePoint Batch API, запросы SPQuery/CamlQuery - и многое другое. И если на стороне сервера всё более-менее понятно, там есть XmlReader/XmlWriter, XmlSerializer, XDocument и т.д., то что делать на стороне клиента?

Как обрабатывать XML, формировать или изменять его, и какие для этого есть функции в SharePoint EcmaScript  - всю эту информацию я постарался собрать в сегодняшней статье.

Как правильно изменять внешний вид List Form в SharePoint

Всё в SharePoint'е можно делать разными способами. Но в последнее время, очень хочется делать правильно...

На этот раз, мне потребовалось внести изменения на формы стандартного SharePoint'овского списка. Таких форм существует три вида, и вы все их прекрасно знаете:

1. DisplayForm - форма отображения элемента списка
2. EditForm - форма изменения элемента списка
3. NewForm - форма создания нового элемента списка

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

1. Чтобы сохранилась возможность добавлять новые поля в список
2. Чтобы можно было перемещать поля из одной вкладки в другую, и менять порядок их следования
3. Чтобы поля рендерились стандартными средствами 

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

И вот, после долгих исследований и поиска в интернетах, мне-таки удалось понять, как же это делается правильно, и воплотить в жизнь вот такую вот красивую форму:

Как видите, часть полей (ФИО и фотография) здесь рендерятся по-особому. Остальные поля рендерятся обычным образом, но разбиваются на вкладки (пользователь может менять порядок полей и принадлежность полей разным вкладкам).

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

SharePoint: что такое хорошо, и что такое плохо

Всё-таки полезно иногда, когда у тебя вырезают всякий мусор из тела :) После аппендицита, в мозгах словно перещелкнуло: довольно серьезно изменил манеру программирования под SharePoint.

Теперь, я гораздо больше времени трачу на поиск решения. На воплощение - как правило, примерно столько же, сколько раньше. Но зато, на порядок меньше времени - на поддержку созданного решения. И решение получается значительно качественнее.

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

Банальный пример: вам требуется как-то по-своему отобразить список. 9 из 10 просто сядут и напишут веб-часть, которая забирает данные из списка и их отображает. И потеряют гигантское количество возможностей, которые они могли бы поиметь, если бы не поленились разобраться с возможностями XsltListViewWebPart.

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

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



Это решение поведенчески полностью соответствует обычным представлениям списков: к примеру, можно выделять одну или несколько записей; работают контекстные вкладки Ribbon'а, и т.д.

И еще, как видите, здесь поля могут быть различных типов: E-mail, ссылка, телефон, мобильный телефон. Дак вот, я добился, чтобы при добавлении пользователями портала в представление новых полей, поля эти естественным образом отображаются, и для них можно даже задать тип и отобразить в правой колонке с соответствующей иконкой. Впрочем, это тема для отдельного поста.

Мораль: не ленитесь изучать SharePoint, интегрируйтесь глубже. Оно того стоит!

Интеграция SharePoint с внешними приложениями через SSIS

Стандартными средствами интеграции SharePoint-списков и сторонних приложений являются BCS (Business Connectivity Services, в 2007й версии - Business Data Catalog). Я думаю, большинство SharePoint-разработчиков не раз и не два имели дело с BCS. И вот по проcшествии некоторого времени, всегда оказывается, что для некоторых задач BCS не подходят! :(

Фактически, BCS без проблем позволяет решать только примитивные задачи, ну к примеру заCRUDить табличку SQL в список SharePoint. А чуть более сложные задачи требуют либо больших телодвижений, либо ну ОЧЕНЬ больших телодвижений... :(

Не вдаваясь в подробности, можно сказать, что BCS по-прежнему не идеален.

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

Способ заключается в использовании SQL Server Integration Services (SSIS) совместно с SharePoint List Source and Destination из OpenSource-проекта Microsoft SQL Server Community Samples: Integration Services.

Хочется немного рассказать об этом способе "на уровне теории", надеюсь эта информация будет полезна.

Те, кто видел DTS или работал уже с его обновленной версией - SSIS, наверняка представляют, что это такое. Если вкратце, SSIS позволяет задать источники данных, затем совершить над ними какие-нибудь преобразования, и конечный результат поместить в некий приемник данных.

Пример схемы преобразования данных в SSIS

В качестве преобразований данных могут выступать, к примеру:

• Разделение и соединение данных - как вертикально (по столбцам), так и горизонтально (аналогично union all).
• Сортировка
• Группировка
• Подведение итогов
• Создание сводных таблиц (Pivot table)
• Собственные виды преобразований

В качестве источника данных и приемника данных могут выступать, в простейших случаях, таблицы и базы данных MS SQL, но также это могут быть Excel-таблицы, соединения OLE DB и  ADO.Net, и т.д. Помимо встроенных источников и приемников, можно создавать собственные.

Источник и приемник для списков SharePoint в состав SSIS не входят, они были написаны отдельно и представляют собой решение Visual Studio, частично на C#, частично на VB.Net. Причем, это решение подойдет даже для 2007го SharePoint'а, поскольку не использует Client Object Model, а действуют через веб-сервис lists.asmx.

Следует отметить, что сделано все довольно дотошно. В частности, ребята постарались озаботиться такой немаловажной штукой, как производительность:

• Источник данных списка SharePoint запрашивает не весь список, а только затребованный его объем. Выборку колонок можно ограничить через дизайнер, а также можно задавать произвольные CAML-запросы.
• Есть настройка, которая позволяет задать количество строк "за этап". Для некоторых "широких" (с большим числом столбцов) списков такое вот блочное чтение позволяет увеличить итоговую производительность.
• Приемник данных обновляет только нужные колонки и только нужные строки (через Batch API).

И все это - не забываем, Open Source. Есть возможность допилить.

Если решите попробовать, пример по созданию SSIS-проекта для интеграции с SharePoint описан на MSDN.

P.S. Сам пока не пробовал, так что это все пока только в теории, но думаю, этот способ вполне имеет шансы на успех. Надеюсь, будет возможность где-нибудь попробовать на рабочем проекте, если это удастся - я отпишусь! :)

Cruise Control .Net и развертывание SharePoint-продуктов

Благодаря Cruise Control .Net (далее - CCNet) недавно удалось решить несколько важных проблем на работе, поэтому спешу поделиться!

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

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

Экзамены по SharePoint

Готовлюсь к 70-542, MOSS 2007. Почему 2007? Потому что у меня по нему большой и хороший опыт, а буду ли работать вообще с SharePoint Server 2010 - неизвестно.

Хочу такой :)

Вообще, нас хотели отправить на сертификацию массово, еще зимой, но по ряду причин (главным образом из-за авралов) - не отправили. А в июле 2010го (почти одновременно с появлением экзаменов по 2010-му шарику), как выяснилось, обновились вопросы экзамена 70-542. И их дампов, между прочим, до сих пор нигде нет!

Вы скажете, - "Ага, злобный дампер"?