среда, 22 сентября 2010 г. - www.msmirnov.ru

Лекция Андрея Маркеева "Введение в SharePoint 2010"

В прошлую пятницу по моей просьбе Андрей Маркеев прочитал нам вводную лекцию "Введение в SharePoint 2010".
Андрей имеет большой опыт разработки под SharePoint 2007 и 2010 и за банку меда с моей пасеки он любезно согласился прочитать нам обзорную лекцию, посвященную архитектуре SharePoint 2010, способам разработки в Visual Studio 2010 для SharePoint 2010, области его применения, его достоинствам и недостаткам.

Видео лекции, которое снимал Андрей Гребенщиков, доступно здесь:

Мой сайт - www.msmirnov.ru

36 комментариев:

  1. Кстати, а еще доклады кто-нить будет читать? Или вы уже все прочитали?

    ОтветитьУдалить
  2. Слушай, даже не знаю. Вроде все основное прочитали.

    Вот хочу заняться подготовкой новых тем.

    ОтветитьУдалить
  3. Намечается первая UG в Костроме? ;)

    Я Максу предлагал организовать лет этак несколько назад...

    ОтветитьУдалить
  4. у нас тут уже чо-та около 4х контор .Net-чиков, можно в принципе и организовать, тока собираться придется в дотальфе. там самая большая кухня ) разрешат ли?

    ОтветитьУдалить
  5. @Andrey Markeev Здесь посмотрел на UGs, они строятся на основе какой-то компании и как средство развития работников этой компании.. То есть, раз в какое-то время (месяц обычно) один-два человека делают доклады по каким-нибудь интересным темам, чтобы другие подтягивались, были в курсе либо просто открывали глаза на какие-то вещи. Средство обучения.

    Архитекторы объясняют принципы и модели построения архитектуры, DBA - какие-то новшества в базах данных (NoSQL например), дивелоперы - ну, тут понятно... :)



    Иногда устраивают какие-то штуки типа "а вот давайте напишем такую задачку, с разными подходами" (на таких никогда не был, врать не буду).



    Смысл в том, что организаторы UG в основном "работают" для "своих". Но может приходить кто угодно, кто угодно может делать доклады, и тогда получается комьюнити и делёж знаниями вне рамок компании, и "работа для своих" переростает в более интересную работу для комьюнити. Иногда бывают приглашённые чуваки.



    Здесь собираются либо в офисах, либо, как я был вчера, в каких-то публичных местах типа митинг-рума отеля...

    В Костроме реально это делать на базе университета. Всем удобно и, думаю, в доступе к аудитории не откажут.

    Оборудование простое: проектор да ноутбук - большего-то, в общем-то, и не надо.

    ОтветитьУдалить
  6. согласен, на базе университета было бы удобно. это можно устроить, мне кажется (благо у нас 2 ктн работают)

    ОтветитьУдалить
  7. Это всегда можно было устроить :)

    Было бы желание.

    ОтветитьУдалить
  8. пардон, 1 ктн, второй в октябре защищается



    поговорил, оказывается, устроить это весьма легко

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



    с другой стороны, проектор и вместительная аудитория, это тоже большой плюс. и плюс, студенты/преподы тоже могут приходить, т.е. народу потенциально тоже будет немало.



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



    т.е. как бы в качестве теста, пойдет/не пойдет. если не пойдет дак и бог с ним.



    @Michael Smirnov, ты как на это смотришь? ну, чтобы в универе с проектором почитать?

    ОтветитьУдалить
  9. Андрей, проектор однозначно не помешал бы, он точно нужен, но вот мне кажется, что в университет народ будет слабо подтягиваться.



    В рамках нашей кухни это проводить я думаю можно.

    ОтветитьУдалить
  10. Тогда предлагаю агитировать Романа закупить проектор!

    Мы подтянемся. Седня весь день обсуждали, пришли к выводу что универ это пока что-то не то.

    ОтветитьУдалить
  11. Я с ним уже говорил на счет проектора.

    Поговорю еще.

    ОтветитьУдалить
  12. Я слышал он периодически порывается его купить:)

    ОтветитьУдалить
  13. В общем, в итоге, мы посоветовались, поголосовали, решили пока провести у себя этакую мини-конференцию, с 4мя докладами, из них 3 на SharePoint-тематику, и один по юнит-тестам, мокам и иокам.

    ОтветитьУдалить
  14. В общем, чем больше аудитория, тем, по-видимому, более общими должны быть темы для докладов. Т.е. к примеру, особенности багов шарепойнта нам интересны, а вам мне кажется, не слишком:)

    Но вы если организуетесь, пишите, у вас всё-таки специфики меньше.

    ОтветитьУдалить
  15. @Andrey Markeev А из иоков что используете? Moles?

    ОтветитьУдалить
  16. у нас иоки, вроде, ни в одном проекте на работе не используются, к сожалению. вот после доклада надеюсь начнем исправляться.

    ОтветитьУдалить
  17. может последний доклад у нас проведете?

    ОтветитьУдалить
  18. :) очень смешно))

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

    ОтветитьУдалить
  19. Кстати, мы в пятницу заказали проектор...

    Надеюсь на той неделе получим

    ОтветитьУдалить
  20. отлично. если вдруг будет не хватать докладчиков, зовите, расскажу про анемичную модель и BLToolkit :)

    ОтветитьУдалить
  21. Я знаю куда ходить кино смотреть в Костроме :-)

    ОтветитьУдалить
  22. а мы решили следующий конф проводить через месяц в гостинице "Волга"

    ОтветитьУдалить
  23. без лентяйки, наскока я понял?) эх...

    ОтветитьУдалить
  24. Без нее...



    Кстати, я уже анонсировал твой возможный доклад про анемичную модель и BLToolkit

    ОтветитьУдалить
  25. Анемичная модель - это здорово, конечно.

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



    Поэтому лично я считаю, что с "моделями" этими надо очень осторожно обходиться. Иначе возникают соблазны идти не от логики и смысла, а от терминов типа "щас мы сделаем анемичную модель, там воооот такущие плюсы!" и "Вася, какого хрена ты делаешь! Мы же договорились, что у нас анемичная модель!".

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

    ОтветитьУдалить
  26. В докладе как раз подробнейшим образом рассматривается, какие достоинства и недостатки у обоих подходов - у анемичной модели и у рич-модели. Лично я пока больше стремлюсь к анемичной. На первый взгляд да, про неё нужно больше знать, однако она более строгая, ну и безусловно позволяет лучше контролировать работу с БД/внешними источниками данных, а как мы видим на примере шарпа, дисциплина есть непременный атрибут хорошей жизни программистов.



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

    ОтветитьУдалить
  27. @Andrey Markeev Отчасти согласен. От той, чем надо руководствоваться :)

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

    В реальности же вопрос о выборе модели достаточно странен. То есть, достаточно странно сказать "Ну вот, мы 5 дней думали и надумали, что наша модель будет а-не-мич-на. Решение окончательно и обжалованию не подлежит".

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

    И это - нормально. :)

    Это я и назвал подходом "от логики". Просто при таком подходе вопрос об анемичности-неанемичности отпадает сам собой: в данном конкретном аспекте используется наиболее удобный и логичный вариант решения. Его даже не надо как-то определять: "а, тут я 'анемичность' использовал", "о, тут у меня рич-модель будет" :)

    Думать об этом будет не надо, вот о чём я :)

    ОтветитьУдалить
  28. Можно сказать, что вообще вопрос о выборе архитектуры довольно странен. Все равно в итоге всё выливается в конкретную архитектуру конкретного проекта. Мы ж ведь от логики отталкиваемся:)



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



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



    Да, анемичную модель Фаулер называет вообще антипаттерном. Опять же, важно понимать, почему. Важно понимать, когда её можно использовать а когда не стоит.



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

    ОтветитьУдалить
  29. К тому же вторая часть доклада описывает BLToolkit и его использование с анемичной моделью, т.е. это применение на практике, это пример использования, и плюс обзор очень перспективной орм. В общем, надеюсь, всем будет интересно и полезно :)

    ОтветитьУдалить