Чем больше читаю дискуссий про SharePoint, тем больше утверждаюсь во мнении, что самое понятие «SharePoint» несёт с собой пачку мифов и заблуждений. Часть из них живет в головах тех, кто раздумывает о применении этой платформы, часть (и она самая опасная) – у тех, кто только недавно начал создавать сайты на SharePoint. Поскольку вторую часть описывать сложнее (а сегодня еще и пятница), я, будучи жутко ленивым, лучше расскажу о первой. Итак, мифы. Или заблуждения? Неважно. Описываю в том порядке, который пришел в голову, а не потому, что какой-то миф «страшнее» другого.
Миф 1. SharePoint на самом деле разработан на другой планете и передан Microsoft гуманоидами с одного НЛО, чтобы сломать мозг людям.
Иногда мне кажется, что это правда ;-)
Миф 2. SharePoint – это дорого.
Об этом уже писали на Хабре. Если использовать бесплатный в рамках промо-компании Windows Web Server 2008 вместе с бесплатным же Windows SharePoint Services и Windows Internal Database (или SQL Server Express), то затраты на серверный софт становятся практически нулевыми. Ограничения, свойственные подобным конфигурациям вполне укладываются в потребности маленьких проектов. Просто нужно адекватно оценивать требования на начальном этапе и предпосылки роста. SharePoint хорош еще и тем, что позволяет безболезненно расти – как в направлении масштаба решения, так и в части используемых фич.
Совершенно логично, что по мере роста проекта (и его монетизации, как принято говорить) встает необходимость в использовании и адекватной конфигурации. Здесь затраты на ПО конечно же возрастают, как и все остальные расходы: серверы, аренда канала и, наконец, персонал. Именно последняя статья расходов является самой ощутимой, но ее часто рассматривают отдельно. Это простительно для небольших начинающих команд, но когда серьезные опытные компании не включают в бюджет проекта расходы на зарплату людей, призванных решение разработать, а затем и поддерживать его – это удивляет.
Я убежден во мнении, что преимущества, которые дает платформа и поддерживающие ее средства разработки, включая бесплатный ныне SharePoint Designer (для целей что-то по-быстрому поправить), оправдывают цену такого ПО. Это же касается и SharePoint Server (MOSS). Последний далеко не бесплатен и в варианте для Интернет-сайтов стоит ощутимо, но я еще раз повторю: пресекайте максимализм в выборе конфигурации и оценивайте весь проект с точки зрения реальных потребностей и дохода. Смешно слышать о дороговизне Internet-лицензии MOSS из уст человека, зарабатывающего на сайте несколько тысяч долларов в день. Опять же, если планируется создать сайт community с доходом, едва покрывающим расходы и хостинг, сперва нужно подумать о том, что SharePoint может дать в своей минимальной конфигурации.
Как к резюме к «мифу», озвучу вроде бы очевидную мысль. В проектах любого масштаба, начните с обдумывания того, что дадут вам самые базовые возможности SharePoint. Возможность сэкономить на разработке системы хранения, авторизации, управления инфраструктурой сайтов и шаблонами верстки, интеграция с приложениями Office и встроенные средства развёртывания содержимого – это уже очень много.
Миф 3. SharePoint – это медленно и требовательно к железу.
Это мой любимый миф. А возник он от странного непонимания многих людей того факта, что даже легкий в установке и первоначальной настройке продукт требует знания и применения ряда правил, позволяющих пользоваться им в тех или иных условиях. Да, естественно определенный overhead по ресурсам у платформы есть – заложенная в нее «универсальность» никогда не проходит даром. Но в конечном итоге можно сказать, что в части требований SharePoint ничем не тяжелее, чем типичное ASP.NET-приложение, хранящее контент в SQL Server. А таких в мире – ох как много. И нагружены они – ого-го! Просто в случае с такими проектами никому не приходит в голову просто развернуть решение – и пусть себе работает, как есть. Но ведь и SharePoint – тоже не волшебник, чтобы догадаться, в каких условиях работает. Он, между тем, позволяет многое сделать через удобный веб-интерфейс, что, правда, не отменяет ковыряния в конфигах. Матерясь в очередной раз на тормозящий SharePoint вспомните следующие ключевые слова:
· Балансировка нагрузки
· Ouput Cache
· BLOB-cache
· Object cache
Для интересующихся ссылки: technet.microsoft.com/en-us/library/cc298466.aspx и "Разгоняем Sharepoint до скорости Highload интернет сайта". «Зубры» ASP.NET, обратите внимание на последний раздел в посте MissUFO (IHttpModule и жесткая оптимизация). При аккуратном подходе и ответственном отношении с помощью этой методики можно сделать из страниц действительно гоночные болиды.
Заканчивая эту тему, расскажу о своих первых впечатлениях после покупки автомобиля. Едва сев за руль, я понял, что авто жутко ограничивает свободу передвижения. Теперь я вынужден планировать и изучать, где разрешены повороты, где чаще бывают пробки, как объехать и как не попасть на улицу с односторонним движением, двигаясь при этом в противоположную сторону. А еще бензин, заботы об «омывалке», давление в шинах. Автомобилисты, знакомо, не так ли? Прошло несколько месяцев. Недовольства поубавилось, я начинал понимать свои преимущества. Спустя несколько лет, могу сказать, что автомобиль дает свободу передвижения и удовольствие от него. Пешком – отлично, экологично и недорого. Но медленно. Можно на мотоцикле. Но imho — небезопасно, да и по темпераменту не подходит :-)
Миф 4. SharePoint – только для больших компаний и корпоративных сайтов.
В это мифе виновата сама Microsoft. Отчасти от того, что все «тяжелые» фичи SharePoint больше нацелены на корпоративные порталы. Отчасти – из-за соответствующих маркетинговых усилий.
Действительно, не очень то много есть готовых сценариев и шаблонов, которые можно использовать при разработке классических Интернет-порталов или столь модных сегодня сайтов социальных сетей. Но много ли сейчас портальных платформ, которые это предлагают? Между тем, по слухам Microsoft осознала пробелы в этом направлении и активно работает над включением соответствующих возможностей в следующих версиях.
Этот миф проистекает от убежденности многих заказчиков типа: «SharePoint наверняка должен иметь шаблоны на все случаи жизни. Сделайте ка мне сайт за пару дней! Я слышал, что с SharePoint это – раз плюнуть». Смешно? Скорее грустно.
Наконец, мой опыт (наверняка ваш – тоже) показывает, что понятие «готовый шаблон от Microsoft» слабо применимо для серьезных интернет-сайтов. Начинаете разрабатывать свои решения в этом направлении – делайте свои шаблоны. И здесь мы плавно переходим к следующему мифу.
Миф 5. Для создания сайта на SharePoint не нужны веб-разработчики и дизайнеры.
Ответ краткий: неправда, нужны и еще как! В комментариях к одному из постов прочитал, что Microsoft недальновидно игнорирует дизайнеров в вопросах макетирования страниц SharePoint. Ну, неправда же! Ничто не мешает использовать свой дизайн. Мешает верстка стандартных элементов – переопределите его. Мешает табличная верстка на мастер-страницах – используйте свои собственные. Беда в SharePoint в ожиданиях от него. А между тем ни одна технология ни в одном серьезном веб-проекте не отменяет нужды в хороших дизайнерах и веб-разработчиках.
Одно скажу совершенно точно. SharePoint-ом нужно проникнуться всем членам команды. Он позволяет многое, но требует уважения к некоторым своим ожиданиям от вашего дизайна. И ожидания эти чаще всего продиктованы вопросами безопасности (как ни странно) и поддержки всего богатого функционала платформы.
А в целом SharePoint, как я уже и говорил, ASP.NET-приложение с его особенностями и хитростями.
Миф 5.5. SharePoint ограничивает свободу творчества, а навязываемые фичи часто только усложняют жизнь.
Это продолжение предыдущего мифа, но речь идет о заблуждениях программистских.
Часто разработчики (особенно российские) ругают SharePoint за странные на их взгляд особенности работы некоторых подсистем. Возьмем для примера две – хранение элементов списков и Business Data Catalog.
По спискам в недоумение приводит тот факт, что ведут они себя не как таблицы БД. Запросы более-менее сложные не поддерживают, ссылочной целостности нет. Ответ простой: списки — не базы данных. Если хотите использовать SharePoint в качестве frontend-а к БД, то используйте его именно так. Для списков и библиотек документов есть простые правила:
1. В библиотеках документов хранятся файлы, с которыми работают пользователи, как с документами. Вроде бы просто, да? Но о выделенном курсивом часто забывают и планируют хранить, например, дистрибутивы программ. Уходить от «файловых шар» — хорошая идея, но все всем нужен здравый смысл. Отдельный класс хранения – файлы aspx-страниц. С ними вопросов обычно не возникает.
2. В списках хранится информация, связанная со структурами коллективной работы пользователей, прямой публикации информации (статьи, новости и т.п.) и метаданными файлов (из первого правила). Ничего другого не нужно хранить в списках. Правило можно нарушить, если данных немного, но на больших объемах вы быстро почувствуете провалы в производительности и сложности с запросами данных.
Второй пример – Business Data Catalog. Вроде бы идея хороша – абстрагировать источники данных и связать их с существующими структурами, хранящимися в SharePoint. Но разработчики жалуются: очень сложный формат описания. Ответ прост и базируется на идее, заложенной в BDC. Сложный XML-подобный формат описания призван решить одновременно две задачи:
1. Быть достаточно гибким, чтобы описывать все необходимые сущности и операции, позволяя приложениям SharePoint не оперировать напрямую данными в БД.
2. Иметь читабельный формат, позволяющий чтение и редактирование без специальных программных средств.
Для кого-то не очень убедительно, но попробую прояснить. Изначально подразумевается, что такой профиль источника данных создается один раз разработчиком исходной информационной системы с целью обеспечения доступа к ней со стороны SharePoint Server. Это довольно быстро было сделано для таких систем, как SAP, Siebel или сервисов Amazon. Также формат описания позволяет, кроме всего прочего, еще и специфицировать объекты таким образом, чтобы можно было производить поиск по сущностям из используемого источника данных без разработки специализированных компонентов.
Когда думаю об этом мифе, в голову снова приходит аналогия с автомобилем.
А расскажите про ваши «Пастернака не читал, но осуждаю». Впечатления людей опытных тем более приветствуются. Хорошие идеи, как известно, приходят не в голову, а «между головами».
