В прошлую пятницу по моей просьбе Андрей Маркеев прочитал нам вводную лекцию "Введение в SharePoint 2010".
Андрей имеет большой опыт разработки под SharePoint 2007 и 2010 и за банку меда с моей пасеки он любезно согласился прочитать нам обзорную лекцию, посвященную архитектуре SharePoint 2010, способам разработки в Visual Studio 2010 для SharePoint 2010, области его применения, его достоинствам и недостаткам.
Видео лекции, которое снимал Андрей Гребенщиков, доступно здесь:
Кстати, а еще доклады кто-нить будет читать? Или вы уже все прочитали?
ОтветитьУдалитьСлушай, даже не знаю. Вроде все основное прочитали.
ОтветитьУдалитьВот хочу заняться подготовкой новых тем.
Намечается первая UG в Костроме? ;)
ОтветитьУдалитьЯ Максу предлагал организовать лет этак несколько назад...
Посмотрим :)
ОтветитьУдалитьДавно пора ИМХО :)
ОтветитьУдалитьу нас тут уже чо-та около 4х контор .Net-чиков, можно в принципе и организовать, тока собираться придется в дотальфе. там самая большая кухня ) разрешат ли?
ОтветитьУдалить@Andrey Markeev Здесь посмотрел на UGs, они строятся на основе какой-то компании и как средство развития работников этой компании.. То есть, раз в какое-то время (месяц обычно) один-два человека делают доклады по каким-нибудь интересным темам, чтобы другие подтягивались, были в курсе либо просто открывали глаза на какие-то вещи. Средство обучения.
ОтветитьУдалитьАрхитекторы объясняют принципы и модели построения архитектуры, DBA - какие-то новшества в базах данных (NoSQL например), дивелоперы - ну, тут понятно... :)
Иногда устраивают какие-то штуки типа "а вот давайте напишем такую задачку, с разными подходами" (на таких никогда не был, врать не буду).
Смысл в том, что организаторы UG в основном "работают" для "своих". Но может приходить кто угодно, кто угодно может делать доклады, и тогда получается комьюнити и делёж знаниями вне рамок компании, и "работа для своих" переростает в более интересную работу для комьюнити. Иногда бывают приглашённые чуваки.
Здесь собираются либо в офисах, либо, как я был вчера, в каких-то публичных местах типа митинг-рума отеля...
В Костроме реально это делать на базе университета. Всем удобно и, думаю, в доступе к аудитории не откажут.
Оборудование простое: проектор да ноутбук - большего-то, в общем-то, и не надо.
согласен, на базе университета было бы удобно. это можно устроить, мне кажется (благо у нас 2 ктн работают)
ОтветитьУдалитьЭто всегда можно было устроить :)
ОтветитьУдалитьБыло бы желание.
пардон, 1 ктн, второй в октябре защищается
ОтветитьУдалитьпоговорил, оказывается, устроить это весьма легко
ну единственное, что ездить куда-то, может быть кому-то будет влом. т.е. на базе одной какой-то конторы с этим проще, т.к. есть некая постоянная аудитория, которой ездить никуда не нужно и которая гарантированно есть. а там уж, подтянется народ и сколько будет народа - уже не настолько важно.
с другой стороны, проектор и вместительная аудитория, это тоже большой плюс. и плюс, студенты/преподы тоже могут приходить, т.е. народу потенциально тоже будет немало.
у нас командир выходит из отпуска в начале октября, и мы гарантированно будем читать доклады, штуки 4 вроде запланировано. ну вот, можно скооперироваться с докладами дотальфы.
т.е. как бы в качестве теста, пойдет/не пойдет. если не пойдет дак и бог с ним.
@Michael Smirnov, ты как на это смотришь? ну, чтобы в универе с проектором почитать?
Андрей, проектор однозначно не помешал бы, он точно нужен, но вот мне кажется, что в университет народ будет слабо подтягиваться.
ОтветитьУдалитьВ рамках нашей кухни это проводить я думаю можно.
Тогда предлагаю агитировать Романа закупить проектор!
ОтветитьУдалитьМы подтянемся. Седня весь день обсуждали, пришли к выводу что универ это пока что-то не то.
Я с ним уже говорил на счет проектора.
ОтветитьУдалитьПоговорю еще.
Я слышал он периодически порывается его купить:)
ОтветитьУдалитьДык да.
ОтветитьУдалитьВ общем, в итоге, мы посоветовались, поголосовали, решили пока провести у себя этакую мини-конференцию, с 4мя докладами, из них 3 на SharePoint-тематику, и один по юнит-тестам, мокам и иокам.
ОтветитьУдалитьну давайте...
ОтветитьУдалитьВ общем, чем больше аудитория, тем, по-видимому, более общими должны быть темы для докладов. Т.е. к примеру, особенности багов шарепойнта нам интересны, а вам мне кажется, не слишком:)
ОтветитьУдалитьНо вы если организуетесь, пишите, у вас всё-таки специфики меньше.
дык ладно :)
ОтветитьУдалить@Andrey Markeev А из иоков что используете? Moles?
ОтветитьУдалитьу нас иоки, вроде, ни в одном проекте на работе не используются, к сожалению. вот после доклада надеюсь начнем исправляться.
ОтветитьУдалитьможет последний доклад у нас проведете?
ОтветитьУдалить:) очень смешно))
ОтветитьУдалитькстати, мы даже проектор нашли. так что будет по высшему разряду (надеюсь)
Кстати, мы в пятницу заказали проектор...
ОтветитьУдалитьНадеюсь на той неделе получим
отлично. если вдруг будет не хватать докладчиков, зовите, расскажу про анемичную модель и BLToolkit :)
ОтветитьУдалитьАндрей, ловлю на слове!
ОтветитьУдалитьВот он: http://uti-projector.ru/product146455300/
ОтветитьУдалитьЯ знаю куда ходить кино смотреть в Костроме :-)
ОтветитьУдалитьа мы решили следующий конф проводить через месяц в гостинице "Волга"
ОтветитьУдалитьбез лентяйки, наскока я понял?) эх...
ОтветитьУдалитьБез нее...
ОтветитьУдалитьКстати, я уже анонсировал твой возможный доклад про анемичную модель и BLToolkit
Анемичная модель - это здорово, конечно.
ОтветитьУдалитьНо, к сожалению, и требует достаточного уровня понимания, которого часто просто нет. В этих случаях "анемичная модель" вырождается в "элементарный бардак".
Поэтому лично я считаю, что с "моделями" этими надо очень осторожно обходиться. Иначе возникают соблазны идти не от логики и смысла, а от терминов типа "щас мы сделаем анемичную модель, там воооот такущие плюсы!" и "Вася, какого хрена ты делаешь! Мы же договорились, что у нас анемичная модель!".
Если идти от смысла - то модель становится тем, что получается в качестве следствия и она будет в каждом конкретном месте такой, какой её логично и правильно там иметь :) То есть, как-то даже и не обязательно задумываться над тем, насколько она таки кошерна, анемична.
В докладе как раз подробнейшим образом рассматривается, какие достоинства и недостатки у обоих подходов - у анемичной модели и у рич-модели. Лично я пока больше стремлюсь к анемичной. На первый взгляд да, про неё нужно больше знать, однако она более строгая, ну и безусловно позволяет лучше контролировать работу с БД/внешними источниками данных, а как мы видим на примере шарпа, дисциплина есть непременный атрибут хорошей жизни программистов.
ОтветитьУдалитьИ кошерность тут ни при чем. Просто нужно знать, какие есть варианты, и в чем их отличия. И выбирать, руководствуясь знаниями, а не измышлениями вида "это кошерно, значит используем".
@Andrey Markeev Отчасти согласен. От той, чем надо руководствоваться :)
ОтветитьУдалитьНе согласен от той части, что это, на самом-то деле, ещё поискать задачу надо такую, где именно нужно выбирать что-то одно.
В реальности же вопрос о выборе модели достаточно странен. То есть, достаточно странно сказать "Ну вот, мы 5 дней думали и надумали, что наша модель будет а-не-мич-на. Решение окончательно и обжалованию не подлежит".
Ибо, в реальной-то жизни, вот тут вот удобно и логично использовать "анемичный" подход, а вот здесь, рядом, можно не городить огород, а вполне себе удачно работает то, что было названо как "рич".
И это - нормально. :)
Это я и назвал подходом "от логики". Просто при таком подходе вопрос об анемичности-неанемичности отпадает сам собой: в данном конкретном аспекте используется наиболее удобный и логичный вариант решения. Его даже не надо как-то определять: "а, тут я 'анемичность' использовал", "о, тут у меня рич-модель будет" :)
Думать об этом будет не надо, вот о чём я :)
Можно сказать, что вообще вопрос о выборе архитектуры довольно странен. Все равно в итоге всё выливается в конкретную архитектуру конкретного проекта. Мы ж ведь от логики отталкиваемся:)
ОтветитьУдалитьОднако, как показывает практика, что получается... Я сам, да думаю и многие другие - неоднократно ценой проб и ошибок приходил в итоге к архитектурным решениям которые на самом деле являются общепризнанными паттернами, просто я об этом не знал. После того как я обнаружил такие вещи несколько раз, я начал интересоваться: ого, если мне понадобилось столько проб и ошибок (читать - рефакторинга, а значит кучи времени), чтобы к этому придти, значит паттерны это правильно и их стоит изучить. Дальше я начал изучать паттерны и по возможности с тех пор стараюсь их применять. Чтобы не изобретать велосипеды и не терять время.
Также с моделями. По сути, анемичная модель и рич-модель это подходы, это архитектурные решения в чистом виде. Это своеобразные паттерны.
Да, анемичную модель Фаулер называет вообще антипаттерном. Опять же, важно понимать, почему. Важно понимать, когда её можно использовать а когда не стоит.
Поэтому я посчитал, что осветить такой архитектурный аспект, как модель, весьма полезно, хотя бы для общего развития. Поделиться опытом, и изложить существующую теорию.
К тому же вторая часть доклада описывает BLToolkit и его использование с анемичной моделью, т.е. это применение на практике, это пример использования, и плюс обзор очень перспективной орм. В общем, надеюсь, всем будет интересно и полезно :)
ОтветитьУдалить