All about IT

Из микрософтовского KB949468:

Это ревизия 1.0 от 10-го марта 2008г. Наверное, скоро исправят.

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

На сервере установлен MOSS 2007, там же VS 2008. Работа ведется локально (или через терминал, значения это не имеет).

Создаём новый проект SharePoint Workflow (любого типа), запускается мастер создания. В нем надо указать адрес узла, на котором будет отлаживаться этот рабочий процесс.
Например, у нас есть site collection по адресу http://portal/helpdesk/, в нем есть сайт с адресом requests. Таким образом, полный путь к сайту выглядит как http://portal/helpdesk/requests/. Сайт без проблем открывается в браузере и в SharePoint Designer’е.

Если ввести адрес такого сайта в качестве отладочного, то VS 2008 станет ругаться, что сайта с указанным адресом не существует:

SharePoint site location entered is not valid. The SharePoint site at http://portal/helpdesk/requests/ could not be found. Verify that you have typed the URL correctly…

Путём ковыряния в логах удалось выяснить, что студия по одним ей ведомым причинам пытается найти сайт по адресу http://portal/helpdesk/helpdesk/requests, т.е. вставляет путь «/helpdesk» два раза:

03/25/2008 14:28:13.44 devenv.exe (0×1380) 0×1068 Windows SharePoint Services General 8e2r Medium Possible mismatch between the reported error with code = 0×81070504 and message: “There is no Web named “/helpdesk/helpdesk/requests”.” and the returned error with code 0×80070002.

Ошибки можно избежать, если указывать в качестве отладочного сайта корень коллекции узлов (в нашем примере http://portal/helpdesk). Или не пользоваться VS2008, а работать на 2005-й :).

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

Как говорится, «a picture is worth a thousand words». Одна простенькая схема может быть гораздо более выразительной и понятной, чем подробное описание на десяток страниц. Есть масса программ, облегчающих задачу построения схем и диаграмм, но в повседневной жизни я обычно пользуюсь только двумя: Mindjet
MindManager и Microsoft Visio. При этом первая практически идеальна для построения всевозможных иерархий, таксономий, тематических карт (mind maps) и т.п. конструкций. Ну а вторая, я думаю, в представлении не нуждается.

Недавно благодаря одному своему коллеге я узнал, что есть набор шаблонов (stencils) для Visio, облегчающих задачу проектирования интерфейсов для SharePoint 2003. Коллега прислал этот шаблон в архиве, но я решил найти его первоисточник и, заодно, проверить, не появилось ли что-нибудь подобное для WSS 3.0/MOSS 2007. В процессе поисков обнаружилось еще несколько интересных шаблонов для Visio, ссылками на которые я с радостью готов поделиться с вами. Итак:

• Первоисточник шаблонов для проектирования интерфейсов SharePoint 2003. Автор обещал выложить аналогичные шаблоны для 2007-го семейства продуктов, но то ли забыл, то ли не захотел. Жаль, конечно, но и то, что есть уже неплохо.
• Шаблоны для проектирования структуры портала. Содержат узнаваемые иконки, обозначающие различные объекты портала (списки, библиотеки, узлы и т.п.)
• Шаблоны для проектирования структуры портальной фермы (прямая ссылка). Даю прямую ссылку, т.к. на самой странице ни одна из двух ссылок не работает. Пришлось немного повозиться и вычислить ссылку методом научного тыка.
• Visio-шаблоны для информационных архитекторов. Не привязаны конкретно к SharePoint’у, но позволяют проектировать интерфейсы приложений, карты сайтов и процессы взаимодействия пользователя с интерфейсами.

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

Если где-то на просторах интернета вам попадется хороший набор шаблонов для Visio, так или иначе связанный с SharePoint’ом или любым другим продуктом из Microsoft Office Family, оставляйте ссылку в комментариях к этой записи. Будем пополнять список совместными усилиями.

Наконец-то появился хотфикс для проблемы, на которую я в своё время потратил уйму времени и нервов, да так и не решил. Симптомы этого «заболевания» выглядят так:

• Ошибка №6482 в журнале событий: «Application Server Administration job failed for service instance Microsoft.Office.Excel.Server.ExcelServerSharedWebServiceInstance (fdcef81f-582b-4af1-a5ef-ab74fe9f623a). Reason: The path specified cannot be used at this time. (Exception from HRESULT: 0×80070094)» (и то же самое для Microsoft.Office.Server.Search.Administration.SearchAdminSharedWebServiceInstance)
• Ошибка №7076 вида «Attempted to read or write protected memory. This is
  often an indication that other memory is corrupt, System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.»
  
• Ошибка №6398 вида «Windows SharePoint Services 3 …
  Microsoft.Office.Server.Administration.ApplicationServerAdministrationServiceJob. Exception from HRESULT: 0×80005006»
• При попытке обратиться к IIS’у через его MMC, вываливается сообщение «the path specified cannot be used at this time».

При этом сам IIS и SharePoint работают нормально, никаких проблем не наблюдается.

Указанные выше симптомы устранялись перезапуском IIS’а (иногда – несколько раз подряд!), либо перезагрузкой сервера. Как вы понимаете, для production-среды это неприемлемо.

В официальном описании этого хотфикса на сайте Microsoft KB сказано, что для его получения необходимо обратиться в службу поддержки. К счастью, у нас есть замечательный сайт The Hotfix Share, где его можно скачать (x86, x64).

Трудности перевода слова Pattern в русской версии MOSS 2007.

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

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

1. Приоритет задачи, как правило, напрямую зависит от её срочности. Чем раньше надо выполнить эту задачу, тем выше её приоритет.
2. «Если все важно, то не важно ничего».

Поясню второй пункт. Если задачу ставит не профессиональный руководитель проекта (и вообще не профессиональный руководитель), то его ход мысли обычно выглядит примерно так: «Берем задачу «А». Она важная? Конечно! Теперь «Б». Важно ли выполнить эту задачу? Еще бы! А вот у нас есть «С»… О, это вообще надо сделать в первую очередь!» и т.д. В итоге мы получаем список из n-дцати задач, и у всех в поле «Важность» жирная красная надпись - «Высокая». Ну и что прикажете делать бедолаге-исполнителю? За что хвататься? А что делать постановщику задач, если действительно все задачи крайне важные?

Очевидно, что с исполнителя в такой ситуации спросу нет. А вот постановщику надо задуматься: какие же задачи среди текущих являются наиболее приоритетными? Какие среди текущих не так уж и важны? Если выделить высоко- и низкоприоритетные задачи не получается, лучше все оставить на «среднем» уровне по умолчанию. Хотя бы потому, что красный цвет раздражает и вызывает (у исполнителя) агрессию (направленную на постановщика).

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

Намедни обновился «убийца Google Docs» в исполнении компании Microsoft – Office Live Workspace, о котором я писал пару месяцев назад.

Чем же нас может порадовать новая версия?

• Новая панель Activity. Представляет собой список событий, произошедших в данном рабочем пространстве (обновления документов и списков, комментарии, отправка уведомлений почты и т.п.). По сути это что-то типа журнала изменений, весьма полезная и удобная вещь.
• Загрузка нескольких документов в рабочее пространство одним махом.
• Постоянные ссылка (permalinks) на документы и рабочие пространства. Требуется, например, если вы хотите отправить прямую ссылку на документ по электронной почте или через IM. Это так же означает, что теперь можно добавлять в закладки ссылки непосредственно на рабочие пространства.
• Улучшенный пользовательский интерфейс, через который рассылаются приглашения. Теперь в нем можно быстро выбрать коллегу/товарища из адресной книги Live Mail и списка контактов Live Messenger’а (который, к слову, тоже недавно обновился). Интеграция налицо.

Так же обновился модуль для MS Office, обеспечивающий прямое сохранение и загрузку документов в рабочее пространство. Предыдущая версия у меня работать не захотела, а вот с новой все ОК!

Может ли Office Live Workspace претендовать на лавры Google Docs? И да и нет. На стороне GD – полноценный доступ к документам (просмотр и редактирование) из веб-интерфейса, версии для полноценных браузеров и для мобильных устройств, включая яблочный телефон. OLW выигрывает за счет интеграции с наиболее популярным на данный момент офисным пакетом, который дает существенно более широкие возможности при создании документов (особенно таблиц и презентаций), чем веб-клиент Google Docs. На сегодняшний день это решения для разных групп пользователей. Google Docs подойдет людям, которым не требуется 90% возможностей MS Office и достаточно базовой фукнциональности редактирования документов. Office Live Workspace – это рабочий инструмент для людей, которые не расстаются с ноутбуком (с установленным MS Office, разумеется).

Не думаю, что сейчас стоит делать какие-либо окончательные выводы по поводу дальнейшей судьбы OLW. Пусть в текущем варианте оно вряд ли станет крайне популярным, но у Microsoft наверняка припасено еще несколько козырей в рукаве, и часть из них наверняка будет пущена в ход до окончания бета-тестирования.

Под катом - пара скриншотов из новой версии.
Читать полностью »

Возможно, кому-то из подписчиков и посетителей показалось, что сразу после того, как IE8 прошел Acid2, автор сего окончательно забросил блог (посчитав свою задачу выполненной?). Конечно, это совсем не так! Я все еще alive and ready to kick some ass. Так что приступим.

Недавно я совершенно случайно наткнулся на обсуждение термина CMS, а так же Drupal‘а и SharePoint’а в контексте этого термина. Началось все с того, что Берт Боерлэнд заявил в своём блоге, что в ближайшие 3 года (запись датирована 22 декабря 2006 г.) CMS будет означать «Community Management System». Контент перестает быть ключевым элементом успешного сайта (как в интернете, так и, с некоторым запаздыванием, в интранете).

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

Тему нового взгляда на расшифровку аббревиатуры CMS развил в своём блоге Друи Буйтэ - лидер проекта Drupal. С его точки зрения, CMS – это «Collaboration Management System», т.е. система управления совместной работой. В качестве примера он приводит SharePoint и ближайший его аналог с открытым исходным кодом – систему Alfresco (последней, правда, не хватает именно «портальных» функций). Дри так же сетует, что, в отличии от этих двух систем, Drupal не поддерживает интеграцию с офисным ПО, таким, как MS Office и OpenOffice. Дискуссия продолжается в комментариях к записи, но постепенно скатывается к банальному holy war между любителями SharePoint’а и Drupal’а.

Так чем же, на самом деле, отличается система управления контентом от системы управления сообществом или системы управления совместной работой (последняя, в какой-то мере, является частным случаем второй, наиболее характерным в бизнес-среде)? На мой взгляд, отличие состоит в направлении информационных потоков. Традиционные CMS’ки обеспечивают, по сути, однонаправленную передачу информации – от редактора (он может быть как автором, так и «собирателем» информации) к читателю (посетителю сайта). Редактор, среди прочего, должен обладать навыками ввода и изменения информации в используемой CMS. По мере развития веб-приложений, использующих DHTML, процесс ввода в систему текста даже со сложной разметкой значительно упрощается, но по возможностям все еще не дотягивает до полноценных десктопных офисных пакетов. Что уж говорить о табличных данных и графических схемах, весьма часто используемых в бизнес-среде. Ручная же верстка страниц зачастую представляет собой слишком сложную для большинства пользователей задачу.

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

Итак, подводя итоги:

1. Система управления контентом должна обеспечивать поток информации от редактора к читателю. Система совместной работы должна обеспечивать двусторонний поток информации – от сайта к участнику, и от участника – к сайту. При этом технические средства, с помощью которых пользователь вводит информацию в систему должны, с одной стороны, обладать широкими функциональными возможностями, а с другой – быть простыми и/или привычными для пользователя.
2. Для того, чтобы сделать «убийцу SharePoint’а», надо в первую очередь реализовать простую, безглючную, прозрачную интеграцию системы с тем или иным (а лучше и тем и другим) офисным пакетом.

Комментарии и альтернативные точки зрения на сей счет приветствуются – пишите отзывы