SharePoint 2010 Beta доступен для закачки TechNet и MSDN подписчикам

Дождались, наконец-то SharePoint Server 2010 Beta доступен для скачивания
подписчикам TechNet и MSDN.
https://msdn.microsoft.com/en-us/subscriptions/securedownloads/default.aspx

Напоминаю вам, что доступен он только в x64 редакциях, а так же есть Русская
редакция.

Так же выложенны все продукты линейки Office 2010.

Можно также посмотреть выступления с конференции «Платфторма 2010″, посвященные SharePoint 2010:

  1. Microsoft SharePoint Server 2010: первое знакомство
    http://www.techdays.ru/videos/1522.html
  2. Архитектура идеального предприятия, внедрившего у себя все компоненты Microsoft Office System
    http://www.techdays.ru/videos/1524.html

SharePoint

Ноябрь 16, 2009. Метки: , , . Uncategorized. Оставить комментарий.

Скринкаст о Test-Driven SharePoint Development

Записал скринкаст о том, как разрабатывал Sapphire REPL WebPart.

Октябрь 27, 2009. Метки: , , , , , , . Uncategorized. Оставить комментарий.

Первые шаги с Unity: DI/IoC & AOP

Введение

 

Если Вы когда-нибудь слышали такие слова, как IoC, DI, AoP, но не имеете четкого понимания этих терминов, надеюсь, эта статья поможет в них разораться на примере работы с Microsoft Unity контейнером.

Итак, приступим к теории:

Inversion of Control (IoC) и Dependency Injection (DI)

За определением IoC обратимся к википедии:

Обращение контроля* (Inversion of Control, IoC) — важный принцип объектно-ориентированного программирования, который используется для уменьшения связности в компьютерных программах.

IoC также известен как Dependency Injection Principle. Приём Dependency Injection используется почти во всех framework’ах. Он применяется программистами использующими такие объектно-ориентированные языки программирования как Smalltalk, C++, Java или языки платформы .NET.

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

За определением DI так же обратимся к википедии:

Внедрение зависимости (англ. Dependency injection) обозначает процесс предоставления внешней зависимости программному компоненту и является специфичной формой «обращения контроля (англ. Inversion of control)», где изменение порядка связи является путём получения необходимой зависимости.

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

Для разрешения проблем зависимостей одного объекта от другого обычно на объект, имеющий зависимость возлагают ответственность за создание/получение необходимого ему объекта (Хотелось бы к слову обратить Ваше внимание на такие шаблоны, как Factory, Registry).

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

Думаю, тут будет полезно привести список .NET DI/IoC контейнеров:

Aspect-oriented programming (AoP)

Признаю, я дотошный почитатель википедии:

Аспектно-ориентированное программирование (АОП) — парадигма программирования, основанная на идее разделения функциональности, особенно сквозной функциональности, для улучшения разбиения программы на модули.

Хотелось бы добавить, что Аспектно-ориентированное программирование (АОП) так же призвано прийти на помощь ООП для того, чтобы сократить количество написанного в приложениях кода.

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

Известные framewоrk’и:

О Microsoft Enterprise Library

Как известно, в октябре 2008 года Microsoft обновили версию Enterprise Library до 4.1, соотвественно одну из её составляющих Unity Application Block до версии 1.2. Разработкой Microsoft Enterprise Library занимается группа patterns & practices. Microsoft Enterprise Library представляет собой набор функциональных блоков, призваных помочь разработчикам в выполнении обычных рутинных задач. Функциональные блоки – что-то типа руководства, предоставляемый в их составе исходный код можно использовать "как есть", расширять или изменять разработчикам в соответствии с их нуждами. Microsoft Enterprise Library состоит из следующих блоков:

  • Caching Application Block. Разработчики могут использовать этот блок для реализации кэширования в своих приложениях. Поддерживает так же подключаемые кэш провайдеры .
  • Cryptography Application Block. Разработчики могут использовать этот блок для реализации хеширования и симметричного шифрования в приложениях.
  • Data Access Application Block. Разработчики могут использовать этот блок для реализации стандартных действий с базой данных в своих приложениях.
  • Exception Handling Application Block. Разработчики и редакторы правил могут использовать этот блок для реализации последовательной стратегии обработки исключений, которые происходят на всех архитектурных слоях корпоративных приложений.
  • Logging Application Block. Разработчики могут использовать этот блок для реализации стандартных функций логирования.
  • Policy Injection Application Block. Разработчики могут использовать этот блок для реализации политик перехвата для того, чтобы насытить приложение такими возможностями, как логирование, кеширование, обработка исключений и валидация на уровне всего приложения.
  • Security Application Block. Разработчики могут использовать этот блок для реализации механизма авторизации и безопасности приложений.
  • Unity Application Block. Разработчики могут использовать этот блок, как легковесный, расширяемый dependency injection контейнер с поддержкой внесения зависимостей в конструктор, свойство и вызов методов, таким же образом, как и реализация перехвата, через расширения.
  • Validation Application Block. Разработчики могут использовать этот блок для реализации правил валидации для бизнес-объетов, используемых в приложении.

О Unity Application Block

легковесный, расширяемый dependency injection контейнер с поддержкой внесения зависимостей в конструктор, свойство и вызов методов, таким же образом, как и реализация перехвата, через расширения. Вы можете использовать его вместе с Enterprise Library (EntLib) для генерации объектов, как ваших собсвенных, так и Enterprise Library. Однако, Unity Application Block отличается от остальных функциональных блоков EntLib в нескольких ключевых моментах:

  • Вы можете использовать Unity Application Block как автономный механизм внесения зависимостей, не нуждаясь в установленной EntLib.
  • Unity Application Block может быть сконфигурирован как с помощью спецализированных файлов конфигурации, так и в run-time режиме с помощью вашего кода.
  • Unity Application Block независим от ядра EntLib, ровно как от системы конфигурации EntLib. Он содержит свой собственный механизм для конфигурирования, хотя, при желании вы можете использовать механизм конфигурации EntLib.

Долгожданный In Action

Можно увидеть по адресу http://butaji.habrahabr.ru/blog/50845/

Материалы

  • Написание это статьи было инициировано просмотром небольшого скринкаста от David Hayden. Примеры кода с небольшими поправками позаимствованы из него.
  • При написании статьи, в основном, я руководствовался базовыми знаниями, почерпнутыми когда-то из замечательной книги “Applying Domain-Driven Design and Patterns” by Jimmy Nilsson.
  • Так же замечательной кладезью знаний Википедия.

В завершение

Надеюсь в данной статье дано хорошее начало для ваших изысканий в области качественного кода.

P.S. Это мой первый пост на хабре, поэтому немного о себе: горизонт моих интересов очень широк, в технической его составляющей это .NET-разработка (ASP.NET, Sharepoint, WWF, Silverlight), методики разработки (Agile, Scrum, XP), техники разработки (TDD, DDD, MDA, AOP).

Февраль 2, 2009. Uncategorized. 1 комментарий.

IDE на прокачку (Pimp My IDE): Часть 1. Работаем с цветом

Введение

1170880900_pimp_my_ride_all[1] Наверное все прочли сегодня про ASP.NET MVC RC1 в блоге у ScottGu. Ну и наверное некоторым из вас приглянулась его цветовая схема Visual Studio. Так что думаю в этой статье я побуду немного XZibit’ом и под качёвый биток мы совершим действо над вашей немного потрепанной IDE.

«IDE на прокачку от butaji»: Идея поста придется по душе всем разработчикам, у которых желания фатально не совпадают с возможностями! Хозяин волшебного гаража (он же известный блогер butaji) подыскивает счастливчика, которому не повезло быть владельцем максимально «убитой» IDE и повезло встретиться рэпперу на пути. Любовь к музыке, наличие ржавой консервной банки на колесах и невозможность своими силами превратить ее во что-нибудь более достойное – это ваш отличный шанс попасть в программу «IDE на прокачку!» Счастливчик получает из ремонта самый настоящий красавец-IDE и из всеобщего посмешища превращается во всеобщий объект зависти, причем совершенно бесплатно. (С) MTV

Суть да дело

Итак, как мы решили, у нас есть IDE и желание преобразить её немного.

Займёмся же производственным процессом:

  1. Посмотрим, какими же цветовыми схемами пользуются коллеги http://www.hanselman.com/blog/VisualStudioProgrammerThemesGallery.aspx
  2. Так же посмотрим географическую привязку счастливых обладателей эффектных схем http://idehotornot.ning.com/
  3. Если ничего подходящего не нашлось, не стоит расстраиваться, подобрать нужные цвета и сгенерить из них схему можно здесь http://www.frickinsweet.com/tools/Theme.mvc.aspx

Мои предпочтения

Буду честным, на пост меня подвигло то, что у Скотта цветовая схема немного походит на ту, что использую я:

image

Называется моя цветовая схема Distant Shores 2008.

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

Январь 28, 2009. Uncategorized. Оставить комментарий.

Первый пост

check, check, microphone checkin

Июль 27, 2008. Uncategorized. Оставить комментарий.