Комментарии 190
к сожалению всё не так радужно как вы описываете…
инфраструктура компаний зачастую не вписывается в те рамки, которые предлагает sharepoint (ведь он позиционируется как корпоративный портал) и тут начинаются проблемы :-(
инфраструктура компаний зачастую не вписывается в те рамки, которые предлагает sharepoint (ведь он позиционируется как корпоративный портал) и тут начинаются проблемы :-(
Можете привести пример?
мы используем SP в нашем университете… и увы… тот пример сайта для IT управления нам соврешенно не подходит… приходится писать свой софт для этого
тот же
mlg нуждается в существенной доработке под стандарты образования и подгонке под каждый вуз специалистами
увы… но процесс дистанционного образования там слишко идеализирован
хотя… университеты и институты это в сфере it это вообще отдельный разговор.
тот же
mlg нуждается в существенной доработке под стандарты образования и подгонке под каждый вуз специалистами
увы… но процесс дистанционного образования там слишко идеализирован
хотя… университеты и институты это в сфере it это вообще отдельный разговор.
ооо!!! я не однинок в этом мире :))
правда я то уже отучился
правда я то уже отучился
да… видел… мы всё ещё в процессе выбора системы дистанционного обучения
увы, ввиду уникальной структуры образовательного процесса в каждом вузе, любой программный продукт требует адаптации, но moodle на первый взгляд требует меньше работы в этом направлении.
увы, ввиду уникальной структуры образовательного процесса в каждом вузе, любой программный продукт требует адаптации, но moodle на первый взгляд требует меньше работы в этом направлении.
Для наших условий ИМХО, хорошим вариантом является open-платформа с соответствующей обвязкой под национальные особенности. Мне нравилось, что на эту тему «Наумен» делал и теперь соответственно Tandem, куда ушла девелоперская команда. Если не смотрели этот вариант, то попробуйте — может действительно подойдет.
Ставил я в свое время… Возился с Zope… Помню что мне эта платформа снесла мозг — т.е. было очень интересно в ней разбираться, но как-то все было довольно сложно, связался с компанией Наумен, к нам приехал парень про платформу рассказывать… А потом через месяц переехал в Москву и занялся внедрением систем на том же Sharepoint…
Не… Мне нравится Zope и платформа… Но ситуация была именно такая…
Не… Мне нравится Zope и платформа… Но ситуация была именно такая…
Ну вы же не заточены под рынок образования, верно? Вот и занялись системами «усреднёнными». Именно в этом качестве ваш шарик и не плох, но когда начинается специализированная заточка вылезают вилы и грабли. Да и бог с ними, не интересно это.
А вот ваши сведения подустарели — в Tandeme уже платформа своя, связка zope/pyton себя не оправдала на проектах масштаба хотя бы ВУЗа, оказалось что и девелопить и внедрять можно ощутимо проще и эффективнее.
А вот ваши сведения подустарели — в Tandeme уже платформа своя, связка zope/pyton себя не оправдала на проектах масштаба хотя бы ВУЗа, оказалось что и девелопить и внедрять можно ощутимо проще и эффективнее.
мы не по до что не заточены, у нас одна платформа — разработчик на .NET может и робота запрограммировать и скрипт для Exchange написать и веб-сайт сделать и вышивать крестиком… :)
Вилы и грабли вылезают везде — надо на конкретный случай смотреть и спрашивать у специалистов.
Унификация программной платформы снижает вероятность появления этих граблей, что верно замечено в отчете, ссылку на которую я дал в статье.
Вилы и грабли вылезают везде — надо на конкретный случай смотреть и спрашивать у специалистов.
Унификация программной платформы снижает вероятность появления этих граблей, что верно замечено в отчете, ссылку на которую я дал в статье.
да, в принципе с помощью электробритвы можно ухаживать за газоном. Но газонокосилка предпочтительнее.
«разработчик на .NET может и робота запрограммировать и скрипт для Exchange написать и веб-сайт сделать и вышивать крестиком… :)»
Ну не так категорично :) Все-таки, .NET-разработчик не сможет сходу начать работать с MOSS и другими более узкоспециализированными технологиями. Нужно их изучать. Но первоначальная идея «унификации пространства разработки» .NET набирает обороты — и es ist sehr gut (к вопросам о перспективах технологии).
Ну не так категорично :) Все-таки, .NET-разработчик не сможет сходу начать работать с MOSS и другими более узкоспециализированными технологиями. Нужно их изучать. Но первоначальная идея «унификации пространства разработки» .NET набирает обороты — и es ist sehr gut (к вопросам о перспективах технологии).
www.wssdemo.com/Pages/topwebsites.aspx
Вот здесь есть несколько сайтов в сфере образования. Но мне трудно судить насколько они актуальны для России. В статье, как раз связка Silverlight + Sharepoint на примере образовательного учреждения рассматривается.
Вообще говоря, сайт школы, как внешний так и внутренний можно легко сделать на простом шаблоне Sharepoint на Windows Web Server 2008 + WSS + SQL Express — все бесплатно получается.
Вот здесь есть несколько сайтов в сфере образования. Но мне трудно судить насколько они актуальны для России. В статье, как раз связка Silverlight + Sharepoint на примере образовательного учреждения рассматривается.
Вообще говоря, сайт школы, как внешний так и внутренний можно легко сделать на простом шаблоне Sharepoint на Windows Web Server 2008 + WSS + SQL Express — все бесплатно получается.
вот за это и недолюбливаю общаться с MS-евангелистами — из-за предельной сконцентрированности на объекте собственных увлечений и слабой соотнесенности объекта с привходящими обстоятельствами, например контекстом разговора.
Тот же тандем, хоть и просто к слову пришелся, это никак не «вообще говоря сайт школы», это система управления учебными заведениями. Но вы посчитали, что и в этом контексте можно воткнуть 5 коп. вашего шарика.
Офтоп получается, давайте завязывать. А то честное слово, когда-то дискуссии с неким PTO (который Крючков) на zdnet.ru на тему апологетики МС ещё были интересны в силу яркости и изворотливости этого персонажа, а сейчас подобное же скучно и бессмысленно.
Тот же тандем, хоть и просто к слову пришелся, это никак не «вообще говоря сайт школы», это система управления учебными заведениями. Но вы посчитали, что и в этом контексте можно воткнуть 5 коп. вашего шарика.
Офтоп получается, давайте завязывать. А то честное слово, когда-то дискуссии с неким PTO (который Крючков) на zdnet.ru на тему апологетики МС ещё были интересны в силу яркости и изворотливости этого персонажа, а сейчас подобное же скучно и бессмысленно.
А не МЭСИ ли случайно?
Sharepoint — это не готовый вертикальный продукт, это платформа, которую вы можете как угодно расширять с помощью API, Event Handlers, PowerShell и прочее. Я собственно это и стараюсь донести в статье.
То же самое можно сказать вообще про что угодно. Про какой-нибудь ja va-framework, например.
Пока что больше похоже на навязчивую рекламу, увы.
«Как угодно» — я бы говорить не стал. Я бы сказал, что где-то под 90% задач типового интранета.
Согласен, фреймворков множество, уже готовых и довольно неплохих. Сужествует множество программистов уже с корнями ушедших в эти языки и фреймворки, не очень понятно зачем майкрософту сюда лезть. Точнее все ясно, ясно что все из-за денег, но имхо пересадить хоть малую долю программистов на такой продукт будет не просто.
На какой? На MOSS? Вы поинтересуйтесь в московских компаниях-интеграторах, с чем они сейчас в основном работают. Что ни задача на .NET, так в 90% случаев связана с MOSS. Так что уже пересаживают :)
Откуда данные про 90%?
Собственный опыт как аутсорсинговой компании. Работали почти весь прошлый год с московскими компаниями в режиме аутсорсинга. 90% проектов на .NET — SharePoint. Мы, честно говоря, сами удивлялись (поначалу) тому, «что же они там, блин, нашли!». Сами были нацелены на работу в стиле Agile на ASP.NET MVC, но большую часть проектов пришлось сделать на SharePoint.
Более того, эту тенденция уже была в одном некогда крупном интеграторе в Питере ещё два года тому назад. А там без малого 600+ человек работало на тот момент.
А пересаживаются на эту платформу не потому что она удобнее или понятнее. А просто потому, что на ней можно срубить больше денег.
можно вопрос по поводу лицензирования. Как я понял, допустим у меня WSS на 5 пользователей. Я правильно понимаю. что эти пользователи управляют сайтом? А как быть с теми пользователями, которых можно создать через sqlmembershipprovider? Ну т.е. сайт размещать в инете, а какие-нить странички делать доступными только конкретным группам пользователей
У вас есть внутренние пользователи в количестве 5 человек. На них должны быть Windows Server CAL.
Вы знаете, что у вас 100 партнеров по продаже рогов — вы можете создать для них 100 аккаунтов (ну или они сами могут зарегистрироваться) и купить для этого еще 100 Windows Server CAL.
Если вы не знаете сколько будет партнеров — можете купить External Connector или заказать или найти у друзей бесплатный Windows Web Server 2008.
Доступ к спискам, страницам и прочее управляется через интерфейс или API Sharepoint.
Вы знаете, что у вас 100 партнеров по продаже рогов — вы можете создать для них 100 аккаунтов (ну или они сами могут зарегистрироваться) и купить для этого еще 100 Windows Server CAL.
Если вы не знаете сколько будет партнеров — можете купить External Connector или заказать или найти у друзей бесплатный Windows Web Server 2008.
Доступ к спискам, страницам и прочее управляется через интерфейс или API Sharepoint.
ну вот я уже заказал виндовс сервер, уже даже пришел. Я не понимаю только одного. Мне нужно сделать forms аутентификацию на сайте. пусть даже те ползователи, которые будут логиниться не будут зарегистрированы в винде. Просто, залогинился — иди смотри страницу. Зачем таким пользователям CAL?
Если вы заказали Windows Web Server 2008 — то можете вообще не думать о Windows Server CAL для интернет пользователей.
а если я выбираю виртуальный хостиг? как тут быть с пользователями? мне для каждого посетителя тоже нужна лицензия?
с Вашего сайта
Щас, вроде, в вин веб сервер 2008 нет ограничения на установку MS SQL
Если мы рассматриваем интернет/экстранет сценарий то, любой аутентифицированный пользователь должен иметь Windows Server лицензию. Если таких пользователей несколько десятков – купите на них Windows Server CAL, они недорогие. Если пользователей может быть много и непонятно сколько CAL нужно покупать – купите External Connector для Windows Server. Также вы можете использовать Windows Web Server 2008 (который был доступен бесплатно по акциям на сайте microsoftweb.ru) для интернет/экстранет сценария и не думать о CAL для внешних пользователей. Правда на Windows Web Server нельзя по лицензионному соглашению установить SQL сервер, но его (SQL Express) можно поставить на соседнюю машину – т.е. можно сохранить нулевые инвестиции…
Щас, вроде, в вин веб сервер 2008 нет ограничения на установку MS SQL
но server 2008 бесплатен не на вю жизнь по акциям… просто процесс лицензирования откалывается на время получается.
Установить, то вы его можете и он даже будет работать. Но это будет против соглашения и на вашей совести :)
Smerig, вы — правы, а я не прав. Лицензирование действительно, блин, запутанно :(
Ставится SQL Express на Windows Web Server — так что все лучше, чем я изначально написал. Поправил в блоке про лицензирование, что SQL Express можно ставить и тогда инвестиции — нулевые.
Ставится SQL Express на Windows Web Server — так что все лучше, чем я изначально написал. Поправил в блоке про лицензирование, что SQL Express можно ставить и тогда инвестиции — нулевые.
technet.microsoft.com/en-us/library/ms143506(SQL.90).aspx
Вот здесь это написано.
Вот здесь это написано.
Я проконсультировался с вашими коллегами: в этом случае для интернет пользователей нужен Windows External CAL (стоит 20000$)
Как зачем? Вам же объяснили — НУЛЕВЫЕ ИНВЕСТИЦИИ.
Серьезно: И вот на этой платформе предлагается строить интернет-представительство? Лицензии на аутентифицированных пользователей? А права «первой ночи» лицензия не предусметривает? — какое упущение…
Серьезно: И вот на этой платформе предлагается строить интернет-представительство? Лицензии на аутентифицированных пользователей? А права «первой ночи» лицензия не предусметривает? — какое упущение…
Вы почитайте внимательно… Сюда посмотрите
habrahabr.ru/blogs/microsoft/52194
CAL нужно только при использовании MOSS, в случае WSS, который в большинстве случаев достаточно, использование + Windows WEb Server — не требуются CAL
habrahabr.ru/blogs/microsoft/52194
CAL нужно только при использовании MOSS, в случае WSS, который в большинстве случаев достаточно, использование + Windows WEb Server — не требуются CAL
Т.е. для того, чтобы партнер заделал аккаунт на моем сайте, мне надо заслать денег в Микрософт???
Слишком большая статья… Только картинки посмотрел =)
Респект, сильная статья. Теперь хоть знаю, что такое SP и для чего он нужен.
Вот обилие готовых шаблонов, по-вашему — это минус или плюс? Плюс — уже почти всё сделано, осталось подогнать под свои нужды. Минус — разработчик может не понимать, как там оно всё устроено — работает, и ладно.
Вот обилие готовых шаблонов, по-вашему — это минус или плюс? Плюс — уже почти всё сделано, осталось подогнать под свои нужды. Минус — разработчик может не понимать, как там оно всё устроено — работает, и ладно.
Если разработчик — не понимает как все устроено — конечно минус, но это не про Sharepoint. В данном случае — плюс.
Потому что эти шаблоны представляют собой набор типов данных, определения списков, расположения веб-партов. Т.е. каждый предложенный шаблон может собрать пользователь, до разработчика дело не доходит.
Но вот разработчик может вдохнуть жизнь в эти шаблоны реализовав EventHandlers, сложные Workflow и прочее.
Реализовать это в виде таких же шаблонов и начать продавать.
Вот, например, компания wss-consulting.ru очень преуспела в этом и быстро делает отличные порталы, в которых шаблоны заточены под российские требования. При этом они смело утверждают, что внедренное ими решение будет развиваться вместе с выходом новых релизов Sharepoint (уже совсем скоро).
Потому что эти шаблоны представляют собой набор типов данных, определения списков, расположения веб-партов. Т.е. каждый предложенный шаблон может собрать пользователь, до разработчика дело не доходит.
Но вот разработчик может вдохнуть жизнь в эти шаблоны реализовав EventHandlers, сложные Workflow и прочее.
Реализовать это в виде таких же шаблонов и начать продавать.
Вот, например, компания wss-consulting.ru очень преуспела в этом и быстро делает отличные порталы, в которых шаблоны заточены под российские требования. При этом они смело утверждают, что внедренное ими решение будет развиваться вместе с выходом новых релизов Sharepoint (уже совсем скоро).
Бесплатен и входит в состав Windows Server только WSS 3.0
Использовать то его можно, но как нормальный CMS рассматривать нельзя.
А ради пары страничек нафига этот огород не нужен.
Вот MOSS тот да, можно делать хоть интранет хоть интернет портал, с утверждением страниц и т.п.
Использовать то его можно, но как нормальный CMS рассматривать нельзя.
А ради пары страничек нафига этот огород не нужен.
Вот MOSS тот да, можно делать хоть интранет хоть интернет портал, с утверждением страниц и т.п.
Согласен.
Как CMS — WSS не очень :)
Хотя есть решения сообщества с открытым кодом codeplex.com/cks — можно в принципе делать на нем.
WSS особенно хорош, когда нет особой надобности заморачиваться со сложным контентом, но в требованиям присутствует интерактивность, формы, процессы и прочее.
Как CMS — WSS не очень :)
Хотя есть решения сообщества с открытым кодом codeplex.com/cks — можно в принципе делать на нем.
WSS особенно хорош, когда нет особой надобности заморачиваться со сложным контентом, но в требованиям присутствует интерактивность, формы, процессы и прочее.
А, к примеру, на друпале описанную задачу тоже можно решить за считанные часы, не особо торопясь. И плюсы в этом случае будут такие:
— Огромное количество ДЕШЕВЫХ PHP-специалистов для расширения функционала в случае необходимости. Не будем уточнять, сколько сейчас стоит SharePoint-специалист.
— Про аппаратные и программные требования даже не будем говорить, и так все понятно. Про стоимость покупки тоже промолчим.
— Нормальный интерфейс нормального веб-сайта. Такой, каким этот интерфейс привыкли видеть все.
А интерфейс пользователя у SharePoint — это вообще просто тихий ужас. Все эти непонятные сущности типа узлов, совершенно неинтуитивная навигация… знаем, плавали. Даже мне, программисту, разобраться с этим всем было непросто.
С интеграцией в windows-окружение, у друпала, конечно, все сложнее. К примеру, событие в Outlook так просто создать не удастся. Но в данном случае можно обойтись обычным email-уведомлением.
— Огромное количество ДЕШЕВЫХ PHP-специалистов для расширения функционала в случае необходимости. Не будем уточнять, сколько сейчас стоит SharePoint-специалист.
— Про аппаратные и программные требования даже не будем говорить, и так все понятно. Про стоимость покупки тоже промолчим.
— Нормальный интерфейс нормального веб-сайта. Такой, каким этот интерфейс привыкли видеть все.
А интерфейс пользователя у SharePoint — это вообще просто тихий ужас. Все эти непонятные сущности типа узлов, совершенно неинтуитивная навигация… знаем, плавали. Даже мне, программисту, разобраться с этим всем было непросто.
С интеграцией в windows-окружение, у друпала, конечно, все сложнее. К примеру, событие в Outlook так просто создать не удастся. Но в данном случае можно обойтись обычным email-уведомлением.
Мы с позиции заказчика или php-разработчика обсуждать будем? :)
C точки зрения PHP-разработчика:
— думаю он не сильно рад что вокруг «Огромное количество ДЕШЕВЫХ PHP-специалистов»
С точки зрения заказчика:
— заказчики с большими деньгами — они может конечно и лузеры (как написали в комменте ниже), но лично мне они нравились и до работы в Microsoft и теперь. И они смотрят на прогнозы типа Gartner и прочее, и там Drupal далеко позади. Я не специалист в Drupal и сравнивать не буду — пусть этим занимаются эксперты.
По поводу навигации. Насколько помню, мне тоже так сначала казалось… Сейчас все очень понятно… Ну и что-то мне подсказывает, что в следующей версии, которая будет вот-вот, над этим поработают.
C точки зрения PHP-разработчика:
— думаю он не сильно рад что вокруг «Огромное количество ДЕШЕВЫХ PHP-специалистов»
С точки зрения заказчика:
— заказчики с большими деньгами — они может конечно и лузеры (как написали в комменте ниже), но лично мне они нравились и до работы в Microsoft и теперь. И они смотрят на прогнозы типа Gartner и прочее, и там Drupal далеко позади. Я не специалист в Drupal и сравнивать не буду — пусть этим занимаются эксперты.
По поводу навигации. Насколько помню, мне тоже так сначала казалось… Сейчас все очень понятно… Ну и что-то мне подсказывает, что в следующей версии, которая будет вот-вот, над этим поработают.
Ну и собственно, как я показал, Sharepoint как решение доступно любой компании, не только «лузерам» :)
По поводу оффтоп — так, по-моему, во всем мире, а не только в мире windows.
Я бы согласился по поводу красивости разработки на Perl (PHP не в счет) по сравнению с Sharepoint если говорить только об API. Но когда начинаешь думать о сценариях совместного использования с Silverlight + PowerShell — всплывает много _очень_ красивых архитектурных решений.
Я вот не задумывался можно ли эффективно использовать MVC + Sharepoint… Для разных разделов сайта например…
Я бы согласился по поводу красивости разработки на Perl (PHP не в счет) по сравнению с Sharepoint если говорить только об API. Но когда начинаешь думать о сценариях совместного использования с Silverlight + PowerShell — всплывает много _очень_ красивых архитектурных решений.
Я вот не задумывался можно ли эффективно использовать MVC + Sharepoint… Для разных разделов сайта например…
Как же Вы не понимаете… Большим корпорациям вроде MS, Sun, IBM, SAP насрать на проблемы заказчиков.
Бабла они хотят, вот и все. Или, может, Вы мне скажете, какую такую проблему решает .NET, Java, SP, etc.?
Тактика-то простая: придумать проблему, убедить заказчика, что это его проблема, всучить свой продукт. Вот и все.
Бабла они хотят, вот и все. Или, может, Вы мне скажете, какую такую проблему решает .NET, Java, SP, etc.?
Тактика-то простая: придумать проблему, убедить заказчика, что это его проблема, всучить свой продукт. Вот и все.
Следуя вашей логике получается, что заказчики тупые и сами не знают своих проблем.
А мы, не учитывая реальных проблем заказчиков, умудряемся продавать им решения, которые им на самом деле не нужны.
Я правильно вас понимаю?
А мы, не учитывая реальных проблем заказчиков, умудряемся продавать им решения, которые им на самом деле не нужны.
Я правильно вас понимаю?
> Следуя вашей логике получается, что заказчики тупые и сами не знают своих проблем.
Нет, они не тупые, и даже иногда знают о какой-то части своих проблем. Они не знают, чего хотят.
> А мы, не учитывая реальных проблем заказчиков, умудряемся продавать им решения, которые им на самом деле не нужны.
Да, примерно так оно и есть. Скажите, зачем заказчику тот же SP + много bloatware + лицензионные соглашения в придачу, если ему нужна «всего лишь» возможность предоставить какую-то информацию?
ЗЫ я сам вообще-то занимаюсь SAP*, так что мне известна вся эта кухня.
* а чо, деньги же!
Нет, они не тупые, и даже иногда знают о какой-то части своих проблем. Они не знают, чего хотят.
> А мы, не учитывая реальных проблем заказчиков, умудряемся продавать им решения, которые им на самом деле не нужны.
Да, примерно так оно и есть. Скажите, зачем заказчику тот же SP + много bloatware + лицензионные соглашения в придачу, если ему нужна «всего лишь» возможность предоставить какую-то информацию?
ЗЫ я сам вообще-то занимаюсь SAP*, так что мне известна вся эта кухня.
* а чо, деньги же!
Смысл статьи не впарить MOSS, а показать что с минимальными затратами можно решить широкий спектр задач, включая и веб-сценарии.
Я это доказываю в примерах и демонстрации.
Заказчик впоследствии сможет решать более сложные задачи и масштабировать систему — докупая MOSS и прочее. Если ему это надо.
В противном случае, сделав сейчас шаг в направлении какого-то узкоспециализированного продукта или опенсоурсного проекта он рискует оказаться через 3 года в полнейшем зоопарке.
Вы почитайте обзорную статью про лучшие интранет порталы, ссылку на которую я дал в статье… Они стали лучшими потому, что унифицировали платформу и сократили количество всяких системок в инфраструктуре. Это не наше мнение. Это мнение экспертов-аналитиков.
Я это доказываю в примерах и демонстрации.
Заказчик впоследствии сможет решать более сложные задачи и масштабировать систему — докупая MOSS и прочее. Если ему это надо.
В противном случае, сделав сейчас шаг в направлении какого-то узкоспециализированного продукта или опенсоурсного проекта он рискует оказаться через 3 года в полнейшем зоопарке.
Вы почитайте обзорную статью про лучшие интранет порталы, ссылку на которую я дал в статье… Они стали лучшими потому, что унифицировали платформу и сократили количество всяких системок в инфраструктуре. Это не наше мнение. Это мнение экспертов-аналитиков.
> В противном случае, сделав сейчас шаг в направлении какого-то узкоспециализированного продукта или опенсоурсного проекта он рискует оказаться через 3 года в полнейшем зоопарке.
Ну а в Вашем случае заказчик рискует оказаться в зависимости от MS. Точнее, от одного продукта, к которому ничего полезного не прицепишь, кроме других продуктов MS. Это еще хуже.
> Вы почитайте обзорную статью про лучшие интранет порталы, ссылку на которую я дал в статье…
Хорошо, почитаю.
> Это мнение экспертов-аналитиков.
Это, случайно, не с linux.org.ru аналитики? :)
Ну а в Вашем случае заказчик рискует оказаться в зависимости от MS. Точнее, от одного продукта, к которому ничего полезного не прицепишь, кроме других продуктов MS. Это еще хуже.
> Вы почитайте обзорную статью про лучшие интранет порталы, ссылку на которую я дал в статье…
Хорошо, почитаю.
> Это мнение экспертов-аналитиков.
Это, случайно, не с linux.org.ru аналитики? :)
Точнее, от одного продукта, к которому ничего полезного не прицепишь, кроме других продуктов MS. Это еще хуже.
Вы в этом точно уверены? :) Мне кажеься поддержка web services и portlets делает платформу Sharepoint интероперабельной.
blogs.msdn.com/sharepoint/archive/2008/12/05/announcing-the-wsrp-toolkit-for-sharepoint.aspx
Вы можете как-то обосновать свою точку зрения с фактами?
Вы в этом точно уверены? :) Мне кажеься поддержка web services и portlets делает платформу Sharepoint интероперабельной.
blogs.msdn.com/sharepoint/archive/2008/12/05/announcing-the-wsrp-toolkit-for-sharepoint.aspx
Вы можете как-то обосновать свою точку зрения с фактами?
> Вы в этом точно уверены? :)
Да.
> Мне кажеься поддержка web services и portlets делает платформу Sharepoint интероперабельной.
Вы еще скажите, что XML это серебряная пуля. :) Вебсервисы это всего лишь модное название, пользы от них ноль. Вот сами подумайте: неужели ради того, чтобы организовать взаимодействие между двумя машинами в сети, нужно высасывать из пальца килотонны стандартов, а потом писать килотонны кода, кое-как реализующего это ill-defined, informally specified месиво?
По ссылке сходил. Пять buzzword'ов в одном посте как бы намекают на атакующих маркетоидов. Опять вода, короче.
Да.
> Мне кажеься поддержка web services и portlets делает платформу Sharepoint интероперабельной.
Вы еще скажите, что XML это серебряная пуля. :) Вебсервисы это всего лишь модное название, пользы от них ноль. Вот сами подумайте: неужели ради того, чтобы организовать взаимодействие между двумя машинами в сети, нужно высасывать из пальца килотонны стандартов, а потом писать килотонны кода, кое-как реализующего это ill-defined, informally specified месиво?
По ссылке сходил. Пять buzzword'ов в одном посте как бы намекают на атакующих маркетоидов. Опять вода, короче.
Вот сами подумайте: неужели ради того, чтобы организовать взаимодействие между двумя машинами в сети, нужно высасывать из пальца килотонны стандартов, а потом писать килотонны кода, кое-как реализующего это ill-defined, informally specified месиво?
Подумал… честно говоря не придумал что написать. Так что же вы имели в виду, какова серебная пуля?
А что не вода тогда?
Подумал… честно говоря не придумал что написать. Так что же вы имели в виду, какова серебная пуля?
А что не вода тогда?
> Подумал… честно говоря не придумал что написать. Так что же вы имели в виду, какова серебная пуля?
Ее нет. :) Самое главное — это использовать инструменты по назначению.
Что же касается веб-сервисов… Вот здесь, например, здравое рассуждение о протоколах: savingtheinternetwithhate.com/design.html О взаимодействии по сети можно почитать в публикациях о Newsqueak.
А веб-сервисы таки все усложняют…
Ее нет. :) Самое главное — это использовать инструменты по назначению.
Что же касается веб-сервисов… Вот здесь, например, здравое рассуждение о протоколах: savingtheinternetwithhate.com/design.html О взаимодействии по сети можно почитать в публикациях о Newsqueak.
А веб-сервисы таки все усложняют…
Ну это это все слова…
Вот вы говорите, что Sharepoint подвяжет заказчика насмерть…
А я говорю, что если у заказчика есть Lotus Notes, то через те же веб-сервисы мы можем сделать поиск в Лотусе из Sharepoint. Или можем вытащить информацию на портал на Sharepoint с WebSphere…
А с вашей точки зрения этим заказчикам что надо делать?
Вот вы говорите, что Sharepoint подвяжет заказчика насмерть…
А я говорю, что если у заказчика есть Lotus Notes, то через те же веб-сервисы мы можем сделать поиск в Лотусе из Sharepoint. Или можем вытащить информацию на портал на Sharepoint с WebSphere…
А с вашей точки зрения этим заказчикам что надо делать?
Вообще-то именно так и есть почти всегда. Очень, очень редко заказчик понимает, что ему нужно. Потому и расплодилось такое гигантское множество консалтинговых контор и системных интеграторов, цель которых одна — впарить. И MS им очень помогает в этом плане.
Я знаю о чем говорю, уже 5 лет работаю с Аксаптой. Вот и товарищ выше с SAP то же самое говорит…
Я знаю о чем говорю, уже 5 лет работаю с Аксаптой. Вот и товарищ выше с SAP то же самое говорит…
Да, нередки, особенно в России и в гос органах, к огромному сожалению, случаи когда заказчику с партнерами надо попилить бабла и придумать какую-нибудь проблему. Вот например миллиард долларов попилить…
itoday.ru/12033.html
Но времена меняются и рынок саморегулируется. Заказчики и партнеры в подавляющем большинстве начинают сильно думать. В 10 победителей конкурса вряд ли вошли компании, которые не решали задачу, а просто пилили бабло.
itoday.ru/12033.html
Но времена меняются и рынок саморегулируется. Заказчики и партнеры в подавляющем большинстве начинают сильно думать. В 10 победителей конкурса вряд ли вошли компании, которые не решали задачу, а просто пилили бабло.
А вы скажите, какую такую проблему решают шницели и красная икра? Да тупо, производители хотят бабла. Придумали проблему, что люди якобы любят флорентийский шницель и красную икру — и впаривают…
Короче говоря, про все, что угодно можно сказать это же. Компы тоже продают, потому что денег хотят. Как и все остальное. MS — не исключение, такая же коммерческая организация.
Короче говоря, про все, что угодно можно сказать это же. Компы тоже продают, потому что денег хотят. Как и все остальное. MS — не исключение, такая же коммерческая организация.
По большому счёту, целью всех коммерческих организаций является единственно извлечение бабла.
Проблемы заказчика интересуют только в контесте того, что заказчик даёт это бабло и что если заказчик будет удовлетворён, то он со своим баблом будет приходить ещё много-много раз.
Проблемы заказчика интересуют только в контесте того, что заказчик даёт это бабло и что если заказчик будет удовлетворён, то он со своим баблом будет приходить ещё много-много раз.
> Проблемы заказчика интересуют только в контесте того, что заказчик даёт это бабло и что если заказчику хорошенько запудрить мозги, то он со своим баблом будет приходить ещё много-много раз.
an obvious fix.
an obvious fix.
Извлечение бабла — да.
Только заказчик никуда не пойдет и бабла не даст — если у него ничего не болит.
Если компания хорошо исследовала рынок, поняла больное место этих заказчиков, реализовала платформу и предлагает зарабатывать на этом своим многочисленным партнерам — честь этой компании и хвала.
Разве нет?
Только заказчик никуда не пойдет и бабла не даст — если у него ничего не болит.
Если компания хорошо исследовала рынок, поняла больное место этих заказчиков, реализовала платформу и предлагает зарабатывать на этом своим многочисленным партнерам — честь этой компании и хвала.
Разве нет?
>Только заказчик никуда не пойдет и бабла не даст — если у него ничего не болит.
Пойдет, и даст. Надо только грамотно провести предварительную обработку. Презентации, статьи и т.п. Маркетинговые отделы свой хлеб не зря едят. Вот и ваша статья служит той же цели.
Пойдет, и даст. Надо только грамотно провести предварительную обработку. Презентации, статьи и т.п. Маркетинговые отделы свой хлеб не зря едят. Вот и ваша статья служит той же цели.
Еще раз, цель статьи одним предложением — заказчики и программисты, вы можете с минимальными инвестициями использовать платформу Sharepoint для решения своих задач и в веб тоже, при возникновении в будущем более критических и важных задач вы сможете докупить и использовать MOSS при этом все будет жить на одной платформе — не понравится, не будете докупать. Честно и понятно?
Вы тоже самое называете «Подсадить на MS» и «ПЕАР». Если вам так комфортнее — ради бога :)
Вы тоже самое называете «Подсадить на MS» и «ПЕАР». Если вам так комфортнее — ради бога :)
И рынок исследуют и больные места понимают (или навязывают точку зрения о болезненности места) как раз таки потому, что ожидают, что тут будет бабло.
А крупные компании такие лузеры. тратят сотни тысяч баксов микрософту, чтобы он им сделал инфраструктуру на шарепоинте. А всего-то нужно пару программистов нанять. Лузеры.
сорри. s/тратят/платят/
А вот это уже оскорбление для человека, который 4 года писал на Perl для Web и вел open source проекты :)
Ну мне наверное было бы неприятно, если бы я внутренне, хотя бы частично, разделял с Вами эту точку зрения по поводу должности пеарщика.
А так по факту получается, что я знаю что такое регэксп, знаю и Perl и .NET и могу сравнивать, работаю в лучшем работодателе в России, выражаясь вашим языком — имею заниженное чувство такта и меры, чем наверное отличаюсь от остальных, что тоже неплохо, в программисты я периодически хожу, когда даю какие-то архитектурные советы или сам что-то делаю для демонстраций…
Ну и что в результате? Почему я должен расстраиваться и огорчаться? :)
А так по факту получается, что я знаю что такое регэксп, знаю и Perl и .NET и могу сравнивать, работаю в лучшем работодателе в России, выражаясь вашим языком — имею заниженное чувство такта и меры, чем наверное отличаюсь от остальных, что тоже неплохо, в программисты я периодически хожу, когда даю какие-то архитектурные советы или сам что-то делаю для демонстраций…
Ну и что в результате? Почему я должен расстраиваться и огорчаться? :)
Ну да Вы выбрали оптимальную тактику для цели идти путем наименьшего сопротивления, чтобы с вами не спорили… Мне не хотелось бы, чтобы моя статья была «ровной». Я в начале статьи сделал утверждение и попросил аргументированно прокомментировать свое мнение.
Мне оказались полезными комментарии с конструктивной критикой. По заданным вопросам в этом форуме (например по поводу цен на External Connector который конечно же не стоит $20k) работают коллеги и готовят ответ, который поможет читателям впоследствии. Т.е. мы работаем над тем, чтобы решить те проблемы, которые здесь поднялись.
Ну и вы распинаетесь опять же… Ничего зря не бывает.
Мне оказались полезными комментарии с конструктивной критикой. По заданным вопросам в этом форуме (например по поводу цен на External Connector который конечно же не стоит $20k) работают коллеги и готовят ответ, который поможет читателям впоследствии. Т.е. мы работаем над тем, чтобы решить те проблемы, которые здесь поднялись.
Ну и вы распинаетесь опять же… Ничего зря не бывает.
Фигово вы значит писали на Perl, если теперь приходится заниматься пиаром продуктов MS. Хотя, понимаю, деньги всем нужны…
Мне не приходится… :)
Могу не заниматься… :)
Толька я для себя это называю не пеар — я рассказываю о технологиях и люди могут ими пользоваться или не пользоваться, но теперь они уже имеют представление. Я считаю, если чем-то занимаешься, то должен любить свое дело и технологии про которые рассказываешь тоже должен любить. У меня складывается впечатление, что людей очень раздражает, что мне действительно нравятся технологии про которые я рассказываю и это видно из текста.
Могу не заниматься… :)
Толька я для себя это называю не пеар — я рассказываю о технологиях и люди могут ими пользоваться или не пользоваться, но теперь они уже имеют представление. Я считаю, если чем-то занимаешься, то должен любить свое дело и технологии про которые рассказываешь тоже должен любить. У меня складывается впечатление, что людей очень раздражает, что мне действительно нравятся технологии про которые я рассказываю и это видно из текста.
Да и собственно не прерогатива разработчиков на Unix :)
msdn.microsoft.com/ru-ru/library/hs600312.aspx
msdn.microsoft.com/ru-ru/library/hs600312.aspx
Судя по всему, подобными задачами вы не занимались никогда.
Меня всегда умиляли вот эти высказывания про двух «программистов-супергероев», которые «какой-нибудь такой SharePoint и сами на коленке за пол-вечера с пивом сделают».
Меня всегда умиляли вот эти высказывания про двух «программистов-супергероев», которые «какой-нибудь такой SharePoint и сами на коленке за пол-вечера с пивом сделают».
Конечно SharePoint можно использовать в интернете, только между ним и интернетом надо поставить линукс с кеширующим вебсервером. А между линуксом и SharePoint не помешает OpenBSD :)
Хотя SharePoint, это частный случай. Всё вышесказанное в целом к Windows Server относится.
Хотя SharePoint, это частный случай. Всё вышесказанное в целом к Windows Server относится.
Между вами и вашими мозгами тоже не помешает вставить какую-нибудь прослойку.
Давайте оставите холиварные высказывания при себе.
Давайте оставите холиварные высказывания при себе.
холивары возникают когда человек верит во что-то одно и не приемлет другое.
если смотреть с точки зрения маркетологов Microsoft, то безусловно нельзя портить «расово-чистую инфраструктуру» конкурирующими продуктами, но реалии жизни таковы, что приходится использовать различные инструменты в комплексе.
выше я описал работающую конфигурацию, для Windows Server с SharePoint выставленного в интернет.
если смотреть с точки зрения маркетологов Microsoft, то безусловно нельзя портить «расово-чистую инфраструктуру» конкурирующими продуктами, но реалии жизни таковы, что приходится использовать различные инструменты в комплексе.
выше я описал работающую конфигурацию, для Windows Server с SharePoint выставленного в интернет.
Компания в которой я работаю пишет бизнес-приложения и корпоративные порталы на SharePoint. Развернуть WSS или MOSS легко. Но сложности возникают при заточке их под определенные нужды.
Огромный плюс шарика, это совместная работа с документами и интеграция с Microsoft Office.
А так вообще на нем можно сделать абсолютно все, так как эта платформа гибкая и расширяемая во все плоскости.
Для примера можно сделать документооборот, с настраиваемыми Workflow, библиотеками для общих документов и прочие вещи которые нужны современному бизнесу.
Ну и что хочется сказать, для тех кто привык писать сайты на PHP и сопуствующими ему CMS — концепция Sharepoint может показаться бредом и несусветным говном. Видимо потому что это сложно понять, сложно выучить и сложно под него разрабатывать.
Огромный плюс шарика, это совместная работа с документами и интеграция с Microsoft Office.
А так вообще на нем можно сделать абсолютно все, так как эта платформа гибкая и расширяемая во все плоскости.
Для примера можно сделать документооборот, с настраиваемыми Workflow, библиотеками для общих документов и прочие вещи которые нужны современному бизнесу.
Ну и что хочется сказать, для тех кто привык писать сайты на PHP и сопуствующими ему CMS — концепция Sharepoint может показаться бредом и несусветным говном. Видимо потому что это сложно понять, сложно выучить и сложно под него разрабатывать.
Мой опыт показывает, что производительность у шарепоинта недостаточна для интернет-сайта. Ну, если 300 человек в день будут ходить, то да. 3000 — возможно. Но уже зависит от того, какие возможности откроете пользователям.
Для интранета прекрасное решение, моим клиентам установил в 2004 году, уже 5 лет работает, проблемы редки.
Для интранета прекрасное решение, моим клиентам установил в 2004 году, уже 5 лет работает, проблемы редки.
А можете рассказать о вашем опыта для интернет-сайта? Интересно.
С производительностью есть ряд сложностей, которые обходятся правильным планированием содержимого, фермой, кешированием, индексированием, распределенной нагрузкой и т.д.
Вот несколько ссылок:
blogs.msdn.com/arpans/archive/2008/10/21/things-to-consider-for-sharepoint-performance.aspx
msdn.microsoft.com/en-us/library/bb727371.aspx
technet.microsoft.com/en-us/library/cc298550.aspx
articles.techrepublic.com.com/5100-10878_11-5032922.html
Производительность — это один из основных приоритетов новой версии.
С производительностью есть ряд сложностей, которые обходятся правильным планированием содержимого, фермой, кешированием, индексированием, распределенной нагрузкой и т.д.
Вот несколько ссылок:
blogs.msdn.com/arpans/archive/2008/10/21/things-to-consider-for-sharepoint-performance.aspx
msdn.microsoft.com/en-us/library/bb727371.aspx
technet.microsoft.com/en-us/library/cc298550.aspx
articles.techrepublic.com.com/5100-10878_11-5032922.html
Производительность — это один из основных приоритетов новой версии.
По поводу производительности могу говорить только за версию 2003. Собственно, речь идёт об ограничениях, которые были озвучены для версии 2003 на размер списков (по моему, порядка 2000 элементов).
Мы тогда делали систему заявок на базе шарепоинта. Задача интересная, потребовала нескольких нетривиальных решений. Работала шустро, но при разработке был такой момент, когда работала очень медленно. Пока оптимизировали, заодно стали узнавать ограничения. Выяснилось, что порядка 2000 элементов.
Мы тогда делали систему заявок на базе шарепоинта. Задача интересная, потребовала нескольких нетривиальных решений. Работала шустро, но при разработке был такой момент, когда работала очень медленно. Пока оптимизировали, заодно стали узнавать ограничения. Выяснилось, что порядка 2000 элементов.
Честно говоря всерьез про Sharepoint начали говорить только начиная с 2007.
Это совершенно известная проблема, подробно описанная с решениями на msdn
technet.microsoft.com/en-us/library/cc262813.aspx
Это совершенно известная проблема, подробно описанная с решениями на msdn
technet.microsoft.com/en-us/library/cc262813.aspx
Ну да, наверное. Своих клиентов, правда, даже на 2007 пока перевести не удалось — автоматом не подхватился портал, и вручную, пользуясь подсказками из интернета, не удалось.
В любом случае, если проблема с производительностью решается, значит, и в интернет сайт можно будет выводить.
В любом случае, если проблема с производительностью решается, значит, и в интернет сайт можно будет выводить.
Готовы выложить 45000 долларов за интернет лицензию? или как-нибудь так?..
«Как-нибудь так» — это не ко мне. Но про стоимость я вообще ничего не знаю.
Когда внедляри первый шарепоинт в 2003-4 годах, стоимость внедрения (без железа и софта) составила порядка 30000 долларов. Сейчас, с учётом инфляции, пожалуй как раз 50 тысяч и составила. Если 50 тысяч лицензирование и 50 тысяч внедрение, это, пожалуй, дороговато выходит.
Информация проверенная?
Когда внедляри первый шарепоинт в 2003-4 годах, стоимость внедрения (без железа и софта) составила порядка 30000 долларов. Сейчас, с учётом инфляции, пожалуй как раз 50 тысяч и составила. Если 50 тысяч лицензирование и 50 тысяч внедрение, это, пожалуй, дороговато выходит.
Информация проверенная?
Мой опыт показывает что крупные российские компании работают на Шарипоинт и пользуется в день такими решениями десятки тысяч их сотрудников.
Ну я просто не могу не сказать пару слов в такой теме :)
Итак, SharePoint. Большая и тяжелая абстракция, платформа, построенная на ASP.NET.
Мое личное мнение таково, что для каждой отдельно взятой задачи нужно подбирать подобающий инструмент. В частном случае — для простого корпоративного сайтика, как по мне, так лучше использовать тот же ASP.NET MVC Framework (который даже «легковеснее» ASP.NET WebFroms), ибо задача такая — нужно, чтобы все было «быстро, легко, и с красивыми URL-ами», в то время как MOSS будет выглядеть там как «пушка и воробьи».
Но, вернемся к SharePoint'у.
Во-первых, решение продается с подачи вендора (MS) и это просто супермегакруто (те, кто не занимался продажей и внедрением порталов — даже не представляют). Во-вторых, быстрое решение типовых решений (это тоже суперпупер, но не так важно, как первое). В-третьих, MOSS — это достаточно дешевое решение (для сравнения можно посмотреть, сколько стоит, к примеру, портал на основе WebSphere). Ну и отдельно хочу сказать, что я вижу MOSS как решение именно для интранет/экстранет.
Еще по-поводу перечисленных мной первых двух пунктов и высказываний по типу «На Друпале такое можно сделать одним мизинцем левой ноги менее, чем за 10 секунд».
Скорее всего, те, кто так говорит, просто никогда не занимались серьезными проектами порталов. И не понимают, что клиенту зачастую нужно отнюдь не «очень дешево на бесплатном Друпале», а ему нужно надежно. И как бы там ни было, MS уже делает пол-работы, рекламируя MOSS (который готов и работает), и это очень гуд, когда заказчик обращается с тем, что «нужно решить задачу на SharePoint», уже представляя возможности платформы (не будем здесь пока о частных недостатках и достоинствах).
Более того, заказчик ожидает снижения издержек с внедрением платформы и совокупную стоимость владения (TCO) с низким коэффициентом. Это значит, что в случае необходимости расширения портала, всегда можно найти спецов соответствующего направления, которые знают, как правильно разворачивать портал, как его поддерживать, масштабировать и наращивать функционал программных частей и веб-частей. При этом, все это должно быть организовано (считаю это положительным моментом — появление на рынке труда вакансий именно MOSS-разработчиков — от этого выигрывают заказчики и, в итоге, конечные пользователи).
По поводу быстрого решения типовых задач — SharePoint именно для этого и сделан. Да, там неинтуитивный интерфейс, в MOSS заложено довольно тяжелое бремя ASP.NET WebForms, и работает это нормально только в IE, но как бы там ни было — это готовое и, главное, рабочее решение.
Как и во всем, есть свои преимущества и недостатки. Лично мне, чтобы понять всю прелесть платформы, пришлось научиться смотреть на нее только с организационной точки зрения (а не с технологической — ибо меня не устраивали структура, архитектура, дизайн итд итп).
Из основных технических недостатков хотелось бы выделить следующие (все по опыту работы с MOSS):
— Относительная сложность введения оригинального функционала (часто приходится отходить от средств MOSS, например стандартных списков и использовать механизмы обмена бизнес-данными (BDC) или вообще внешние data-сервисы);
— Очень сложно, как это часто требуется заказчикам, «немного модифицировать дизайн-шаблон» (На практике — приходилось просто выделять нужные placeholder'ы контента и размещать полностью в своих шаблонах);
— Действительно ощутимая неинтуитивность интерфейса (говорить, что в SharePoint «перейдет опыт работы в приложениях MS Office» — как нам пришлось убедиться, по меньшей мере лукаво :), все это требует серьезного обучения пользователей работе с порталом (с другой стороны, конечно, у команды внедрения должно быть «поставлено» управление подготовкой);
— Нужно быть серьезным адептом в MOSS, для того чтобы суметь «вставить» туда свои особые рабочие процессы (workflows);
— Расширение программной составляющей MOSS происходит несколько хаотичным образом — «поправить тут, добавить здесь, заменить тут и там» (если вы — команда, работающая по agile-методикам, то — увольте, здесь вам этого всего не применить);
— Непредсказуемость поведения MOSS в ответ на отдельные модификации (например, на перехват и применение собственных обработчиков внутренних событий MOSS). Зачастую, поиски таких «небольших недоразумений» могут ох как существенно расширить объем работ по проекту.
Итак, SharePoint. Большая и тяжелая абстракция, платформа, построенная на ASP.NET.
Мое личное мнение таково, что для каждой отдельно взятой задачи нужно подбирать подобающий инструмент. В частном случае — для простого корпоративного сайтика, как по мне, так лучше использовать тот же ASP.NET MVC Framework (который даже «легковеснее» ASP.NET WebFroms), ибо задача такая — нужно, чтобы все было «быстро, легко, и с красивыми URL-ами», в то время как MOSS будет выглядеть там как «пушка и воробьи».
Но, вернемся к SharePoint'у.
Во-первых, решение продается с подачи вендора (MS) и это просто супермегакруто (те, кто не занимался продажей и внедрением порталов — даже не представляют). Во-вторых, быстрое решение типовых решений (это тоже суперпупер, но не так важно, как первое). В-третьих, MOSS — это достаточно дешевое решение (для сравнения можно посмотреть, сколько стоит, к примеру, портал на основе WebSphere). Ну и отдельно хочу сказать, что я вижу MOSS как решение именно для интранет/экстранет.
Еще по-поводу перечисленных мной первых двух пунктов и высказываний по типу «На Друпале такое можно сделать одним мизинцем левой ноги менее, чем за 10 секунд».
Скорее всего, те, кто так говорит, просто никогда не занимались серьезными проектами порталов. И не понимают, что клиенту зачастую нужно отнюдь не «очень дешево на бесплатном Друпале», а ему нужно надежно. И как бы там ни было, MS уже делает пол-работы, рекламируя MOSS (который готов и работает), и это очень гуд, когда заказчик обращается с тем, что «нужно решить задачу на SharePoint», уже представляя возможности платформы (не будем здесь пока о частных недостатках и достоинствах).
Более того, заказчик ожидает снижения издержек с внедрением платформы и совокупную стоимость владения (TCO) с низким коэффициентом. Это значит, что в случае необходимости расширения портала, всегда можно найти спецов соответствующего направления, которые знают, как правильно разворачивать портал, как его поддерживать, масштабировать и наращивать функционал программных частей и веб-частей. При этом, все это должно быть организовано (считаю это положительным моментом — появление на рынке труда вакансий именно MOSS-разработчиков — от этого выигрывают заказчики и, в итоге, конечные пользователи).
По поводу быстрого решения типовых задач — SharePoint именно для этого и сделан. Да, там неинтуитивный интерфейс, в MOSS заложено довольно тяжелое бремя ASP.NET WebForms, и работает это нормально только в IE, но как бы там ни было — это готовое и, главное, рабочее решение.
Как и во всем, есть свои преимущества и недостатки. Лично мне, чтобы понять всю прелесть платформы, пришлось научиться смотреть на нее только с организационной точки зрения (а не с технологической — ибо меня не устраивали структура, архитектура, дизайн итд итп).
Из основных технических недостатков хотелось бы выделить следующие (все по опыту работы с MOSS):
— Относительная сложность введения оригинального функционала (часто приходится отходить от средств MOSS, например стандартных списков и использовать механизмы обмена бизнес-данными (BDC) или вообще внешние data-сервисы);
— Очень сложно, как это часто требуется заказчикам, «немного модифицировать дизайн-шаблон» (На практике — приходилось просто выделять нужные placeholder'ы контента и размещать полностью в своих шаблонах);
— Действительно ощутимая неинтуитивность интерфейса (говорить, что в SharePoint «перейдет опыт работы в приложениях MS Office» — как нам пришлось убедиться, по меньшей мере лукаво :), все это требует серьезного обучения пользователей работе с порталом (с другой стороны, конечно, у команды внедрения должно быть «поставлено» управление подготовкой);
— Нужно быть серьезным адептом в MOSS, для того чтобы суметь «вставить» туда свои особые рабочие процессы (workflows);
— Расширение программной составляющей MOSS происходит несколько хаотичным образом — «поправить тут, добавить здесь, заменить тут и там» (если вы — команда, работающая по agile-методикам, то — увольте, здесь вам этого всего не применить);
— Непредсказуемость поведения MOSS в ответ на отдельные модификации (например, на перехват и применение собственных обработчиков внутренних событий MOSS). Зачастую, поиски таких «небольших недоразумений» могут ох как существенно расширить объем работ по проекту.
Как же мне прочитать README.docx, если моя версия офиса его не поддерживает? Купить новую версию?
Это какая у вас версия офиса-то?
Скачать бесплатный viewer
office.microsoft.com/en-us/downloads/ha010449811033.aspx
office.microsoft.com/en-us/downloads/ha010449811033.aspx
… или Compatibility Pack
Спасибо за статью, более-менее раскрыли мне глаза на сущность SharePoint и современное состояние серверных продуктов от Microsoft. К несчастью, большинство комментов — неаргументированная «вонь» против нелюбимой всеми компании.
Работаю с SharePoint со времен v2beta. Прогресс, конечно, на лицо и я бы сейчас ставил его везде, где есть необходимость в средстве совместной работы, обмена документами и пр. (интересующиеся найдут в презентациях об этом много инфы). Последним моим заданием была как разработка корпоративного сайта на базе SharePoint. Идею использования корпоративного портала в качестве сайта я отмел сразу, ибо пускать в корп. домен внешних юзеров не особо нравилась + офис не на площадке хостера расположен (не самый быстрый инет, перебои со светом, сервер не только под SharePoint использовался), поэтому решили синхронизировать выборочный контент с внешним сервером, на котором стоит WSS. Под это дело написали EventHadnler, прикрученный к нужным спискам (библиотекам). А затем самое веселое — design customization. Ох и крови он у меня выпил! После нескольких месяцев использования «кастомизированного дизайна» SharePoint, решили забить на это дело, т.к. планы по развитию сайты были и остаются довольно большие, а кастомизировать его уже небыло ну никаких вообще сил и желания. В итоге быстро написали обертку над WSS WebServices на обычном ASP.NET + дизайн через XSL. И работает быстро, и менять легко и удобство изменения данных через SharePoint сохранили.
Посему резюмирую — как платформа для интранет-порталов — 5 баллов, а для интернет-сайтов — 2 (ну ладно, 3 с минусом). :)
Очень хочется посмотреть, что нового будет предложено в новой версии.
Посему резюмирую — как платформа для интранет-порталов — 5 баллов, а для интернет-сайтов — 2 (ну ладно, 3 с минусом). :)
Очень хочется посмотреть, что нового будет предложено в новой версии.
А какой чудный был у меня опыт перевода слегка модифицированного WSSv2 на v3. 2 безутешных попыток апгрейда + 2 недели помощи техподдержки МС по инциденту так ни к чему и не привели! Остановились на том, что пусть будут 2 портала, пока старый сам собой не отомрет. Так что если использовать SharePoint — то ТОЛЬКО v3 или выше.
Я не пытался рассматривать WSS как CMS, он действительно не очень для этого годится — я показал, что при желании можно сделать любой вид.
Но вот если расширить интранет портал до экстранет сайта для работы с партнерами, ну и сбор каких нибудь данных с клиентов — милое дело, imho!
Но вот если расширить интранет портал до экстранет сайта для работы с партнерами, ну и сбор каких нибудь данных с клиентов — милое дело, imho!
Статья хорошая понравилась. Но есть пара комментариев:
1. Ну откуда столько ошибок? Это же кошмар куда не кинь всюду клин. Только и успеваешь хотфиксы ставить. Реально есть ощущение, что его пишут в Индии.
2. Работает нормально только под IE.
3. XML hell. Хотите извращений? Тогда шарепоинт для вас. :-) Все на XML забудьте про автоматический рефакторинг и тому подобное.
4. Хотите чтобы вас уволили с работы? Попробуйте пойграться с контент тайпами на продакшн.
5. Я в корне не понимаю многих архитектурных решений. Например зачем контент тайпы сделали в XML_ почему нельзя было использовать понятную модель классов дот нета а потом просто их сериализовать?
После определенного времени использования мое мнение таково. Для интранета то, что доктор прописал если без дикой кустомизации, для интернета однозначное нет.
1. Ну откуда столько ошибок? Это же кошмар куда не кинь всюду клин. Только и успеваешь хотфиксы ставить. Реально есть ощущение, что его пишут в Индии.
2. Работает нормально только под IE.
3. XML hell. Хотите извращений? Тогда шарепоинт для вас. :-) Все на XML забудьте про автоматический рефакторинг и тому подобное.
4. Хотите чтобы вас уволили с работы? Попробуйте пойграться с контент тайпами на продакшн.
5. Я в корне не понимаю многих архитектурных решений. Например зачем контент тайпы сделали в XML_ почему нельзя было использовать понятную модель классов дот нета а потом просто их сериализовать?
После определенного времени использования мое мнение таково. Для интранета то, что доктор прописал если без дикой кустомизации, для интернета однозначное нет.
Спилить рога? — Просто.
Очистить комп от вирусов проще простого!
Новый Micrso…
Очистить комп от вирусов проще простого!
Новый Micrso…
Да вдогонку. Хотелось бы чтобы: 1. выкинули дебильный CAML и дали LINQ. 2. Выкинули фичи и солюшены( это кошмар какой то). Очень надеюсь что в будущем будет что то типа MEF
Ну я думаю, вас обрадует новая версия, только у меня есть вопросы
— в чем проблема с фичами и солющенами?
— что такое MEF?
— в чем проблема с фичами и солющенами?
— что такое MEF?
Извините за грамматические ошибки с этим у меня плохо а ворд не установлен :-). Одним словом. Сложно!!! Результат => непонятно как это вобще может работать. Проще надо быть.
Изначально идея не плохая, но реализация хромает. Раньше вообще все плохо было, особенно с добавление файлов
которые надо включить в солюшн. В данный момент есть WSPBuilder и это уже большое достижение и облегчение в работе.
И за это мс должна сказать спасибо коммьюнити.
С моей точки зрения солюшн и фичи это механизм расширений. То есть конечный пользователь покупает или скачивает
чтолибо и это добавляет новую функциональность.
Думаю надо в начале рассмотреть, что надо сделать в шарепоинт, чтобы добавить функциональность.
1. Обновить DLL ки в GAC. Соответственно сделать сброс IISа или реткракт пулам.Ключевое слово рестарт :-)
2. Обновить содержимеое web.config и возможно скопировать файлы ресурсов. Также если надо, то обновить dll ки в bin
папочке.
3. Папка 12 кудаже без нее. Здесь нас ждет царство XML. Точнее не царство а АД. Суда копируем килограммы файлов.
Фичи, сайт темплейты и т.п. Да и возможно придеться скопировать папку Layouts и во все веб приложениях поменять
виртуальную директорию, чтобы ссылалаось на нее.
Что можно отметить сразу так это размазанность расширения по куче мест. На мой взгляд было бы логичнее все держать
в одном месте. Казалось бы можно просто сделать солюшн с помощью WSPBuider и оно само все сделает. Но здесь нас ждет
суровая действительность, что как обычно, что то сломалось. И начинается беготня по папкам смотреть где что не
обновилось, где случайно ид совпали где референсы поломались. Даже не буду говорить про малоинформативность сообщений
об ошибках. Например при инсталляции солюшна без прав на контент базу, шарепоинт выведет Object reference ошибку. Что самое
забавное так это сообщение на странице ошибки «решить это проблему с помощью чегототам» которая выводит всякий бред
уж лучше бы сразу ссылку на гугль. В общем основной недостаток так это то что этот механизм не работает как должно.
И не все из вышеперечисленных задач можно решить с помощью солюшена. Да я могу использовать сторонние продукты и
скрипты, но это лишь подтверждает несостоятельность солюшенов. Хотя тут проблема даже не в солюшене а в шарепоинте.
Ведь что такое по сути солюшн. Это архив с файлами и манифестом. В принципе все правильно. Как и должно быть
минимально и просто. Но сама архитектура странновата. Нету гибкого механизма миграции данных. Тоесть если хочеться
поменять фиелды или контент тайпы на живых данных это очень нетривиальная задача.
В общем ситуация напоминает времена DLL Hell и потом о слава богу пришел GAC. У мс уже есть много решений для той
же версионности.
Конечно же, это в основном проблемы разработки, а не проблемы конечного пользователя. Опять же я повторюсь. Сложно
все. Надо много папок. СЛОЖНО. Напоминает C++, я никгода не вернусь с C# на C++ :-) Всегода есть возможность ошибиться и сама
архитектура создает возможность ошибки.
Надо много писать xml, причем очень легко ошибиться. Эти идентификаторы везде и референсы по
ним. Почему нельзя использовать в некоторых местах что то типа неймспейсов. Или вобще сделать все конфигурирование не в xml, а описывать все прямо в C#. Например реализуем ISharepointPlugin. И допустим метод GetAllSiteTemplatesConfigs. Для красоты еще придумать Sharepoint internal DSL. Типа как в StructureMap.
И получиться вместо тонны xml фалов одна дллка у которой и с версиями проблем нет. Все статик фалы в ресурсы дллки кладем. При проблемах с производительностью можно эти ресурсы при инсталяции из длл взять и закешировать в файловой системе. Контент тайпы заменяем на классы C#. Получаем из коробки наследование и т.п. И все опять же храниться в дллке. Эти длл можно динамически подгружать и т.п. Зависимости будут решаться стандартными референсами дллек. Из коробки рефакторинг и компиль тайм ошибки.
В идеале механизм расширений должен удовлетворять следующим требованиям: иметь возможность обновления и
версионности расширений, миграции существующих данных, управления зависимостями.Есть же толковые разработки типа
OSGI en.wikipedia.org/wiki/OSGi. Надеюсь, что возможно в будущем все будет намного лучше в мире шарепоинта.
В данный момент мс пишет MEF www.codeplex.com/MEF. Основная цель сделать стандартный плагин фреймворк.
Например его будет использовать VisualStudio. И учитывая сколько отличных разработчиков мс бросила на этот проект я
уже заранее рад результату. Конечно не факт, что его возможно будет применять в шарепоинт так как здесь веб
специфика но думаю какието идеи вполне применимы.
Ой чо то я разошелся, а толкового ничего и не сказал :-) Конец рабочей недели ждем отдыха :-)
Изначально идея не плохая, но реализация хромает. Раньше вообще все плохо было, особенно с добавление файлов
которые надо включить в солюшн. В данный момент есть WSPBuilder и это уже большое достижение и облегчение в работе.
И за это мс должна сказать спасибо коммьюнити.
С моей точки зрения солюшн и фичи это механизм расширений. То есть конечный пользователь покупает или скачивает
чтолибо и это добавляет новую функциональность.
Думаю надо в начале рассмотреть, что надо сделать в шарепоинт, чтобы добавить функциональность.
1. Обновить DLL ки в GAC. Соответственно сделать сброс IISа или реткракт пулам.Ключевое слово рестарт :-)
2. Обновить содержимеое web.config и возможно скопировать файлы ресурсов. Также если надо, то обновить dll ки в bin
папочке.
3. Папка 12 кудаже без нее. Здесь нас ждет царство XML. Точнее не царство а АД. Суда копируем килограммы файлов.
Фичи, сайт темплейты и т.п. Да и возможно придеться скопировать папку Layouts и во все веб приложениях поменять
виртуальную директорию, чтобы ссылалаось на нее.
Что можно отметить сразу так это размазанность расширения по куче мест. На мой взгляд было бы логичнее все держать
в одном месте. Казалось бы можно просто сделать солюшн с помощью WSPBuider и оно само все сделает. Но здесь нас ждет
суровая действительность, что как обычно, что то сломалось. И начинается беготня по папкам смотреть где что не
обновилось, где случайно ид совпали где референсы поломались. Даже не буду говорить про малоинформативность сообщений
об ошибках. Например при инсталляции солюшна без прав на контент базу, шарепоинт выведет Object reference ошибку. Что самое
забавное так это сообщение на странице ошибки «решить это проблему с помощью чегототам» которая выводит всякий бред
уж лучше бы сразу ссылку на гугль. В общем основной недостаток так это то что этот механизм не работает как должно.
И не все из вышеперечисленных задач можно решить с помощью солюшена. Да я могу использовать сторонние продукты и
скрипты, но это лишь подтверждает несостоятельность солюшенов. Хотя тут проблема даже не в солюшене а в шарепоинте.
Ведь что такое по сути солюшн. Это архив с файлами и манифестом. В принципе все правильно. Как и должно быть
минимально и просто. Но сама архитектура странновата. Нету гибкого механизма миграции данных. Тоесть если хочеться
поменять фиелды или контент тайпы на живых данных это очень нетривиальная задача.
В общем ситуация напоминает времена DLL Hell и потом о слава богу пришел GAC. У мс уже есть много решений для той
же версионности.
Конечно же, это в основном проблемы разработки, а не проблемы конечного пользователя. Опять же я повторюсь. Сложно
все. Надо много папок. СЛОЖНО. Напоминает C++, я никгода не вернусь с C# на C++ :-) Всегода есть возможность ошибиться и сама
архитектура создает возможность ошибки.
Надо много писать xml, причем очень легко ошибиться. Эти идентификаторы везде и референсы по
ним. Почему нельзя использовать в некоторых местах что то типа неймспейсов. Или вобще сделать все конфигурирование не в xml, а описывать все прямо в C#. Например реализуем ISharepointPlugin. И допустим метод GetAllSiteTemplatesConfigs. Для красоты еще придумать Sharepoint internal DSL. Типа как в StructureMap.
И получиться вместо тонны xml фалов одна дллка у которой и с версиями проблем нет. Все статик фалы в ресурсы дллки кладем. При проблемах с производительностью можно эти ресурсы при инсталяции из длл взять и закешировать в файловой системе. Контент тайпы заменяем на классы C#. Получаем из коробки наследование и т.п. И все опять же храниться в дллке. Эти длл можно динамически подгружать и т.п. Зависимости будут решаться стандартными референсами дллек. Из коробки рефакторинг и компиль тайм ошибки.
В идеале механизм расширений должен удовлетворять следующим требованиям: иметь возможность обновления и
версионности расширений, миграции существующих данных, управления зависимостями.Есть же толковые разработки типа
OSGI en.wikipedia.org/wiki/OSGi. Надеюсь, что возможно в будущем все будет намного лучше в мире шарепоинта.
В данный момент мс пишет MEF www.codeplex.com/MEF. Основная цель сделать стандартный плагин фреймворк.
Например его будет использовать VisualStudio. И учитывая сколько отличных разработчиков мс бросила на этот проект я
уже заранее рад результату. Конечно не факт, что его возможно будет применять в шарепоинт так как здесь веб
специфика но думаю какието идеи вполне применимы.
Ой чо то я разошелся, а толкового ничего и не сказал :-) Конец рабочей недели ждем отдыха :-)
Что то проблемы с форматированием текста вылезли. Скопировал из нотепада и вот так все разъехалось
Еще добавлю про русскую локализацию:
у полей списков есть отображаемое имя и внутреннее имя. если создаешь поле на русском языке, то внутреннее имя — это какой-то код непонятный, похожий на обфусцированные переменные, потом по этим именам приходиться обращаться из программного кода.
у полей списков есть отображаемое имя и внутреннее имя. если создаешь поле на русском языке, то внутреннее имя — это какой-то код непонятный, похожий на обфусцированные переменные, потом по этим именам приходиться обращаться из программного кода.
Это да :(
Я в скринкасте когда создаю списки обращаю на это внимание. Безобразие конечно. Но обходной маневр есть.
Я в скринкасте когда создаю списки обращаю на это внимание. Безобразие конечно. Но обходной маневр есть.
А вот вопрос. Я как разработчик вынужден иметь на локальной машине несколько различных проектов. Иногда это вызывает конфликты. Да можно делать виртуальные машины для каждого проекта но это не очень удобно. Вопрос. Возможно ли использовать APP V для шарепоинта. То есть я инсталлирую на локальную машину шарепоинт. После этого ставлю апп в. Далее я каждый проект инсталирую в виртуальное окружение. Я не знаю возможно ли это и было бы интересно узнать. По логике такое возможно мы виртуализируем папку 12, а остальное все можно использовать совместно.
А как будет IIS с привязкой к IP и портам в APP V разбираться?
Чтобы не конликтовали приложения, возможно, достаточно будет их разнести по разным AppPool. Поможет это? хотелось бы побольше конкретики.
Чтобы не конликтовали приложения, возможно, достаточно будет их разнести по разным AppPool. Поможет это? хотелось бы побольше конкретики.
Не знаю, а возможно ли каждому пулу сделать свою папку 12 в смысле чтоб сам шарепоинт думал, что это его родная папка? С папкой лейоутов все понятно а вот с 12 не совсем Мне все устраивает за исключением папки 12. Ну вот допустим пример. У меня есть файлы в 12\1033\XML в котором описываются доступные сайт темплейты, то есть при создании сайт коллекции то, что увидит юзер. И вот допустим я из 2х солюшенов имею в этой папке 2 разных файла но к сожалению в них прописаны одинаковые id. И при создании сайт коллекции произойдет ошибка. Причем делаем мы это из централ администрейшн(хм получается надо делать несколько вариантов централ админа для каждой виртуальной папки 12). Да я мог бы исправить ситуацию добавлением символа "_" перед ненужным в данный момент файлом и после создания сайт коллекции вернуть все назад. Ну в общем в данный момент в подобных случаях надо делать руками и это как бы неудобно. Да и можно поменять идентификаторы но опять же это надо делать руками. Хотелось бы найти что нибудь типа virtualPC но только более легковесное. Воркараунд не интересует, хочется нормального решения. Хотя я понимаю, что по большому счету виртуалки это то, что доктор прописал. Просто там свой геморрой при копировании виртуальных машин с установленным шарепоинтом. Вот, вот что я хочу, статью на хабре про копирование виртуальных машин с шарепоинтом :-))). Хотя я знаю, что в гугле это есть :-) И еще от мс было бы интересно больше узнать про решения виртуализации например хороший обзор Hyper V, Med V, App V. Что то я уже в злобного потребителя превратился. В нескольких словах мой фидбек к статье: В данный момент этот продукт имеет свои геморрои но очень надеюсь, что мс превратит в будущем это в более достойное. Примеры уже есть IE8, DotNet, GAC и это радует.
Фичи и солюшены почти нормальные решения, нужно просто научиться с ними работать.
генерировать солюшен стандартными утилитами — это ужс, это усложняет разработку, делает ее менее удобной и удорожает проект. MS следовало бы больше внимания уделять инструментам. продукт на мой взгляд сыроват.
генерировать солюшен стандартными утилитами — это ужс, это усложняет разработку, делает ее менее удобной и удорожает проект. MS следовало бы больше внимания уделять инструментам. продукт на мой взгляд сыроват.
Это отвратительно, я считаю. Sharepoint видел вблизи и это не самый достойный продукт от Microsoft. Жаль, что вам приходится его продвигать.
Давайте посмотрим на стоимость:
WSS распространяется под лицензией Windows CAL ~ 20$
для использования WSS в интернет придется купить лицензию Windows External Conn ~20000$
MOSS это отдельный продукт, стоимость его следующая:
сервер ~ 5000$
клиентская стандартная лицензия ~100$
клиентская расширенная лицензия (в дополнении к стандартной) ~ 85$
интернет лицензия ~ 45000$
WSS позволяет делать некоторые простые узлы, по функциональности что-то вроде простой структурированной таблицы, простой рабочий процесс утверждения и библиотеки документов с доп. атрибутами.
полезно то, что некоторые элементы можно интегрировать в Outlook (если вы этим пользуетесь).
чтобы сделать что-то более сложное нужно пользоваться Sharepoint designer ~200$ или Visual Studio ~600$
В MOSS есть больше наворотов: Поиск, профили пользователи, аудитории, сквозной поиск, итеграция с внешними источниками данных…
самое примечательное, что в MOSS 14 должна быть встроена бизнес аналитика (Мониторинг и анализ) которые были в performancepoint
Использовать WSS и/или MOSS в качестве платформ для интернет порталов слишком дорого. для этого нужна специальная лицензия, которая стоит чрезвычайно дорого, я просто не могу понять, по какому принципу была определена столь запредельная цена.
WSS и MOSS — это портальная платформа, а не платформа ERP.
там нет строгих отношений между списками и библиотеками, поля списков не обновляются, если связанная сущьность обновляется. портальная технология расчитана на то, что сущьности, которые хранятся будут сами по себе и редактироваться будут независимо и не будут меняться потом. хорошо делать на этих технологиях поиск и просмотр той информации, к которой пользователь не сможет обратиться просто так.
Например: в автосалоне есть сервис, в котором ремонтируют авто. информация о том на какой стадии ремонта автомобиль хранится и редактируется в спец. системе (MS Dynamics CRM, например:). для того, чтобы секретарша на ресепшене могла сообщить клиенту, на какой стадии ремонт, можно синтегрировать CRM с Sharepoint'ом и предоставить простой доступ к информации. а делать систему управления ремонтным цехом на MOSS — неоправданная и провальная затея.
на мой взгляд. если куплен Windows то можно для простых задач (простых приложений, когда нужно вбить несколько полей в строку и потом сделать протую обработку) пользоваться WSS, для более сложных вещей — нужно готовить денежки, потому что специалисты, которые умеют работать с Sharepoint в VS не дешевы.
WSS распространяется под лицензией Windows CAL ~ 20$
для использования WSS в интернет придется купить лицензию Windows External Conn ~20000$
MOSS это отдельный продукт, стоимость его следующая:
сервер ~ 5000$
клиентская стандартная лицензия ~100$
клиентская расширенная лицензия (в дополнении к стандартной) ~ 85$
интернет лицензия ~ 45000$
WSS позволяет делать некоторые простые узлы, по функциональности что-то вроде простой структурированной таблицы, простой рабочий процесс утверждения и библиотеки документов с доп. атрибутами.
полезно то, что некоторые элементы можно интегрировать в Outlook (если вы этим пользуетесь).
чтобы сделать что-то более сложное нужно пользоваться Sharepoint designer ~200$ или Visual Studio ~600$
В MOSS есть больше наворотов: Поиск, профили пользователи, аудитории, сквозной поиск, итеграция с внешними источниками данных…
самое примечательное, что в MOSS 14 должна быть встроена бизнес аналитика (Мониторинг и анализ) которые были в performancepoint
Использовать WSS и/или MOSS в качестве платформ для интернет порталов слишком дорого. для этого нужна специальная лицензия, которая стоит чрезвычайно дорого, я просто не могу понять, по какому принципу была определена столь запредельная цена.
WSS и MOSS — это портальная платформа, а не платформа ERP.
там нет строгих отношений между списками и библиотеками, поля списков не обновляются, если связанная сущьность обновляется. портальная технология расчитана на то, что сущьности, которые хранятся будут сами по себе и редактироваться будут независимо и не будут меняться потом. хорошо делать на этих технологиях поиск и просмотр той информации, к которой пользователь не сможет обратиться просто так.
Например: в автосалоне есть сервис, в котором ремонтируют авто. информация о том на какой стадии ремонта автомобиль хранится и редактируется в спец. системе (MS Dynamics CRM, например:). для того, чтобы секретарша на ресепшене могла сообщить клиенту, на какой стадии ремонт, можно синтегрировать CRM с Sharepoint'ом и предоставить простой доступ к информации. а делать систему управления ремонтным цехом на MOSS — неоправданная и провальная затея.
на мой взгляд. если куплен Windows то можно для простых задач (простых приложений, когда нужно вбить несколько полей в строку и потом сделать протую обработку) пользоваться WSS, для более сложных вещей — нужно готовить денежки, потому что специалисты, которые умеют работать с Sharepoint в VS не дешевы.
А можно пруфлинк про «для использования WSS в интернет придется купить лицензию Windows External Conn»?
Когда я полгода назад искал информацию на этот счет, то помнится, что выяснил отсутствие ненадобности в приобретении «External Connector».
Когда я полгода назад искал информацию на этот счет, то помнится, что выяснил отсутствие ненадобности в приобретении «External Connector».
Еще веселье с лицензированием, когда интегрируешь продукты MS с чем то еще. Для этого необходима лицензия External Conn.
и еще не забывайте об эффекте мультиплексирования
и еще не забывайте об эффекте мультиплексирования
Я бы выделил, что преимущество MOSS как раз не в том, что у него какая-то особая бизнес-логика, а как раз в том, что это «портал». Т.е. с ERP я бы не стал даже сравнивать. Сильно разные измерения. По идее, на MOSS можно построить современную ERP (НЕ встроенными средствами, конечно же), CRM, и так далее. Но MOSS хорош тем, что сразу задает архитектуру всего решения, иерархии, права, принципы доступа к объектам и все такое прочее. В этих рамках что-то прикладное реализуется намного быстрее (и априори «логично» с точки зрения общей архитектуры).
P.S. Думаю, это достаточно правильно выбранный уровень абстракции. Хотя текущая реализация MOSS мне пока самому не нравится, но нравится направление развития. Идея платформы — очень хорошая. Если MS придумает, как сделать все это легковеснее, интерфейсы «out-of-the-box» более интуитивными, кроссбраузернее и как совместить с RIA (Silverlight) для более «богатого» UX — цены такой платформе не будет.
P.P.S. Кстати, отдельная точка зрения на основу SharePoint — ASP.NET. В частности — WebForms, реализующие паттерн Page Controller. Т.е. получается, мало того, что MOSS — сама по себе платформа — абстракция над ASP.NET, так в ASP.NET еще и WebForms используется, который также является той еще тяжеловесной абстракцией поверх протокола HTTP. Все это временами наводит на мысль «а в чем же преимущество перед реализацией в виде WPF-приложения (ну кроме необходимости в последнем случае иметь .NET на клиенте)». Если бы MS удалось как то «разгрузить» вот этот слой между HTTP и конечным UI…
P.S. Думаю, это достаточно правильно выбранный уровень абстракции. Хотя текущая реализация MOSS мне пока самому не нравится, но нравится направление развития. Идея платформы — очень хорошая. Если MS придумает, как сделать все это легковеснее, интерфейсы «out-of-the-box» более интуитивными, кроссбраузернее и как совместить с RIA (Silverlight) для более «богатого» UX — цены такой платформе не будет.
P.P.S. Кстати, отдельная точка зрения на основу SharePoint — ASP.NET. В частности — WebForms, реализующие паттерн Page Controller. Т.е. получается, мало того, что MOSS — сама по себе платформа — абстракция над ASP.NET, так в ASP.NET еще и WebForms используется, который также является той еще тяжеловесной абстракцией поверх протокола HTTP. Все это временами наводит на мысль «а в чем же преимущество перед реализацией в виде WPF-приложения (ну кроме необходимости в последнем случае иметь .NET на клиенте)». Если бы MS удалось как то «разгрузить» вот этот слой между HTTP и конечным UI…
И для PS и для PPS отвечает совершенно официальная уже стратегия дальнейшего развития связки Silverlight + Sharepoint. Ссылки на доклады — в статье
Вот насчет приближению к миру RIA я более-менее в курсе (сама идея витает в воздухе — очевидно, что нужно реализовывать), но боюсь вот чего — как бы не вышло, что Silverlight будет еще одной (уже третьей по счету!) тяжелой абстракцией вокруг всего этого. Поэтому, второй момент (мой P.P.S.) волнует меня гораздо больше. Ровно как и то, насколько изменится (в лучшую, надо думать, сторону) сам workflow разработки на MOSS. С точки зрения бизнеса в ИТ-консалтинге, это очень перспективная платформа и все вот эти моменты очень важны.
Надеюсь скоро будут официальные анонсы MOSS vNext.
Надеюсь скоро будут официальные анонсы MOSS vNext.
Вопрос к вам, как к знатоку шарепоинта и легальности его использования. Если я, к примеру, напишу на PHP RPC-интерфейс на свой сайтик, который будет имитировать Sharepoint достаточно хорошо, чтобы, скажем, из Excel табличку можно было туда залить и Excel думал, что заливает её в таблицу на Sharepoint. Я этим нарушу какие-нибудь права MS?
Excel использует открытый URL протокол для работы с табличными и списковыми данными, реализованный в FrontPage extensions и соответственно в Sharepoint.
www.sharepointblogs.com/dwise/archive/2008/01/10/accessing-sharepoint-list-data-as-xml.aspx
Реализовывайте на здоровье — там ссылка на msdn документацию.
www.sharepointblogs.com/dwise/archive/2008/01/10/accessing-sharepoint-list-data-as-xml.aspx
Реализовывайте на здоровье — там ссылка на msdn документацию.
В свое время создал небольшой инструмент для юзабилити-тестирования сайтов по данным от мыши, и сами понимаете, какие результаты по юзабилити получились у SharePoint. Абсолютно неинтуитивная система.
Изучать виндовые технологии можно только при условии что с помощью этого знания можно в ближайшие 5 лет гарантированно заработать на них большие деньги.
В остальных случаях ни в коем случае нельзя изучать виндовые технологии — они слишком быстро устаревают и ваши знания будут не удел через пару лет.
В остальных случаях ни в коем случае нельзя изучать виндовые технологии — они слишком быстро устаревают и ваши знания будут не удел через пару лет.
У меня вопрос к автору: корректно ли сравнивать SharePoint с GoogleApps и, если сравнение корректно, выделить основные преимущества SP перед GA?
Некорректно.
Возможно будет корректно сравнивать Sharepoint Services, но они пока не вышли
blogs.msdn.com/sharepoint/archive/2008/10/27/pdc-2008-announcing-azure-services-platform-and-microsoft-sharepoint-services.aspx
Возможно будет корректно сравнивать Sharepoint Services, но они пока не вышли
blogs.msdn.com/sharepoint/archive/2008/10/27/pdc-2008-announcing-azure-services-platform-and-microsoft-sharepoint-services.aspx
Ндя, пообщался с виндовым товарищем. Его мнение — SharePoint классная штука для отмыва бабла. Там и с лицензиями непонятки и консультанты-девелоперы не дешево стоят… А в комплексе так вообще огого.
Так что ссылочки на инфобокс и паркинг весьма в тему. Видимо ребят кризис уже поджал, раз пишут на хабре о SharePoint.
Так что ссылочки на инфобокс и паркинг весьма в тему. Видимо ребят кризис уже поджал, раз пишут на хабре о SharePoint.
Статье — респект. Её польза не только и не столько в быстром обзоре платформы, но и прежде всего — в хорошей возможности высказать конструктивные замечания, до которых руки не доходят, если работа с SharePoint — не ежедневное занятие и сидеть на соответствующих формуах особой нужды нет.
Мне приходится ежедневно иметь дело с разработкой под SharePoint и все мои претензии и впечатления выстраданы, а не рождены первым взглядом или и чьим-то мнением.
Что же касается некоторых претензий к продукту, то мои впечатления такие…
Претензии к солюшенам с одной стороны обоснованы, а с другой — Razbezhkin правильно говорит:
"Фичи и солюшены почти нормальные решения, нужно просто научиться с ними работать.
генерировать солюшен стандартными утилитами — это ужс, это усложняет разработку, делает ее менее удобной и удорожает проект. MS следовало бы больше внимания уделять инструментам. продукт на мой взгляд сыроват."
С одной стороны есть большое количество разных решений, которые инсталлируются методом «a la setup.exe» и требуют после этого обычно только настройки через интерфейс администрирования, с которым успешно интегрируются.
Средства разработки под SharePoint — пока слабое место, но справедливости ради — Microsoft это понимает и над этим работает: blogs.technet.com/vladkol/archive/2009/01/12/visual-studio-2008-extensions-for-sharepoint-v1-3.aspx
В целом девтулы у MS — лучшие и я готов это мнение отстаивать.
По content types…
Менять филды контент-тайпы на живых данных, как и менять схему БД на живых данных — всегда процесс нетривиальный и очень индивидуальный для каждого случая. Сделать этот механизм «простым и однозначным» — верный способ привести к неработоспособности реальных решений.
В целом, объем проблем при развертывании и поддержке решений на SharePoint (и не только) больше зависит от культуры разработки, чем от функционала продукта.
Если человек сразу не потратил 15 минут на создание солюшена, а решил делать все «ручками», то потом даже после создания солюшена его компоненты, развернутые «ручками» уже не так тривиально будут обновляться.
Каюсь, сам иногда страдаю такой псевдоэкономией времени.
Замороченность платформы на xml — унаследованное стремление дать возможность тонкой настройки людям, незнакомым с программированием.
Сейчас — во времена PowerShell, это кажется анахронизмом, но вспомните, когда зарождался SharePoint v1 (TeamServices он назывался при рождении).
Однако, коллеги, давайте будем честны. Если вы так любите все делать на C#, то никто и не запрещает! ЛЮБЫЕ операции по манипулированию контентом или шаблонами, включая размещение элементов управления на страницах, можно делать с помощью объектной модели.
Я так регулярно делаю!
А путь к успеху во всем этом — понимание архитектуры и, если хотите, идеологии SharePoint.
С наскоку не получится, но зато после – усердие будет вознаграждено. Когда-то я и до истинной пользы классов в C++ доходил несколько дней ;-)
SharePoint как платформа для ИНТЕРНЕТ-сайта — более, чем рабочее решение. Просто в этом случае для разработчика есть больше работы и простора для мысли ;-), чем в интранет-сценарии. Нужно быть аккуратным и не думать, что все решается «мышкой». Если у кого-то есть конкретные вопросы, готов пообщаться лично на эту тему (в разумных пределах, конечно).
Напоследок — ложка дёгтя. SharePoint — действительно чемпион по количеству хотфиксов.
Но пообщавшись с компетентными товарищами, я понял, что проблема в необычайной популярности продукта.
Изначально в Microsoft не были готовы к такому росту продаж и использования платформы. Ресурсы на нее были брошены совсем другие, чем требовались.
Недавно на какой-то конференции Гейтс сказал, что SharePoint — самый быстрорастущий (по кол-ву клиентов) серверный продукт Microsoft.
Ждём следующией версии, а вместе с тем — понимаем, что взяв на вооружение такую платформу мы:
а — даем совему клиенту изначально мощную платформу, где много чего уже сделано и ему не нужно тратиться на изобретение велосипедов
б — почти всегда оставляем простор для развития решения в угоду потребностям бизнеса
в — обеспечиваем себя работой ;-) (для понимающих) :-)
А! Еще… лицензирование.
По ценникам тема мутная, все это понимают и, судя по каментам, готовится всеобъемлющий ответ.
По схемам же лицензирования можно почитать тут blogs.technet.com/vladkol/archive/2009/01/11/office-sharepoint-server-2007.aspx
Мне приходится ежедневно иметь дело с разработкой под SharePoint и все мои претензии и впечатления выстраданы, а не рождены первым взглядом или и чьим-то мнением.
Что же касается некоторых претензий к продукту, то мои впечатления такие…
Претензии к солюшенам с одной стороны обоснованы, а с другой — Razbezhkin правильно говорит:
"Фичи и солюшены почти нормальные решения, нужно просто научиться с ними работать.
генерировать солюшен стандартными утилитами — это ужс, это усложняет разработку, делает ее менее удобной и удорожает проект. MS следовало бы больше внимания уделять инструментам. продукт на мой взгляд сыроват."
С одной стороны есть большое количество разных решений, которые инсталлируются методом «a la setup.exe» и требуют после этого обычно только настройки через интерфейс администрирования, с которым успешно интегрируются.
Средства разработки под SharePoint — пока слабое место, но справедливости ради — Microsoft это понимает и над этим работает: blogs.technet.com/vladkol/archive/2009/01/12/visual-studio-2008-extensions-for-sharepoint-v1-3.aspx
В целом девтулы у MS — лучшие и я готов это мнение отстаивать.
По content types…
Менять филды контент-тайпы на живых данных, как и менять схему БД на живых данных — всегда процесс нетривиальный и очень индивидуальный для каждого случая. Сделать этот механизм «простым и однозначным» — верный способ привести к неработоспособности реальных решений.
В целом, объем проблем при развертывании и поддержке решений на SharePoint (и не только) больше зависит от культуры разработки, чем от функционала продукта.
Если человек сразу не потратил 15 минут на создание солюшена, а решил делать все «ручками», то потом даже после создания солюшена его компоненты, развернутые «ручками» уже не так тривиально будут обновляться.
Каюсь, сам иногда страдаю такой псевдоэкономией времени.
Замороченность платформы на xml — унаследованное стремление дать возможность тонкой настройки людям, незнакомым с программированием.
Сейчас — во времена PowerShell, это кажется анахронизмом, но вспомните, когда зарождался SharePoint v1 (TeamServices он назывался при рождении).
Однако, коллеги, давайте будем честны. Если вы так любите все делать на C#, то никто и не запрещает! ЛЮБЫЕ операции по манипулированию контентом или шаблонами, включая размещение элементов управления на страницах, можно делать с помощью объектной модели.
Я так регулярно делаю!
А путь к успеху во всем этом — понимание архитектуры и, если хотите, идеологии SharePoint.
С наскоку не получится, но зато после – усердие будет вознаграждено. Когда-то я и до истинной пользы классов в C++ доходил несколько дней ;-)
SharePoint как платформа для ИНТЕРНЕТ-сайта — более, чем рабочее решение. Просто в этом случае для разработчика есть больше работы и простора для мысли ;-), чем в интранет-сценарии. Нужно быть аккуратным и не думать, что все решается «мышкой». Если у кого-то есть конкретные вопросы, готов пообщаться лично на эту тему (в разумных пределах, конечно).
Напоследок — ложка дёгтя. SharePoint — действительно чемпион по количеству хотфиксов.
Но пообщавшись с компетентными товарищами, я понял, что проблема в необычайной популярности продукта.
Изначально в Microsoft не были готовы к такому росту продаж и использования платформы. Ресурсы на нее были брошены совсем другие, чем требовались.
Недавно на какой-то конференции Гейтс сказал, что SharePoint — самый быстрорастущий (по кол-ву клиентов) серверный продукт Microsoft.
Ждём следующией версии, а вместе с тем — понимаем, что взяв на вооружение такую платформу мы:
а — даем совему клиенту изначально мощную платформу, где много чего уже сделано и ему не нужно тратиться на изобретение велосипедов
б — почти всегда оставляем простор для развития решения в угоду потребностям бизнеса
в — обеспечиваем себя работой ;-) (для понимающих) :-)
А! Еще… лицензирование.
По ценникам тема мутная, все это понимают и, судя по каментам, готовится всеобъемлющий ответ.
По схемам же лицензирования можно почитать тут blogs.technet.com/vladkol/archive/2009/01/11/office-sharepoint-server-2007.aspx
Хм…
liberatum.ru/news/kompanii-ingres-i-alfresco-sozdali-otkrytogo-konkurenta-microsoft-sharepoint
Я думаю, обойдется подешевле чуток…
liberatum.ru/news/kompanii-ingres-i-alfresco-sozdali-otkrytogo-konkurenta-microsoft-sharepoint
Я думаю, обойдется подешевле чуток…
Я решил попробовать и сделал форму, привязанную к паре созданных в SP списков.
Форма будет отвечать за создание, предположим, нового поставщика с полями «Имя», «Страна» и «Город». Два последних поля привязаны к отдельным спискам «СписокГородов» и «СписокСтран», чтобы пользователь мог выбрать предустановленную страну и город (они уже связаны нужным образом 1: М).
Проблема: надо как-то отфильтровать список городов в одном дропдауне, когда пользователь выбирает одну из стран в другом.
Честно говоря после гугления ничего не нашел. Да и вообще я не видел в стандартном функционале sharepoint динамически обновляемых полей. Это вообще возможно как-нибудь безболезненно сделать? Я использовал SP Designer, для создания формы элемент «Настраиваемая форма списка»…
Форма будет отвечать за создание, предположим, нового поставщика с полями «Имя», «Страна» и «Город». Два последних поля привязаны к отдельным спискам «СписокГородов» и «СписокСтран», чтобы пользователь мог выбрать предустановленную страну и город (они уже связаны нужным образом 1: М).
Проблема: надо как-то отфильтровать список городов в одном дропдауне, когда пользователь выбирает одну из стран в другом.
Честно говоря после гугления ничего не нашел. Да и вообще я не видел в стандартном функционале sharepoint динамически обновляемых полей. Это вообще возможно как-нибудь безболезненно сделать? Я использовал SP Designer, для создания формы элемент «Настраиваемая форма списка»…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
SharePoint – отличная платформа для веб-сайтов. Разве нет?