Активно продолжается подготовка к 6-й конференции ведущих web-разработчиков PHPConf 2007 (Москва 24-25 мая 2007)

В связи с большим потоком интересных докладов — прием тезисов продлен до 5 февраля.

Новые тезисы:

• Практика независимой WEB-разработки (freelance)
• Достоинства применения служб LDAP на предприятии
• Аспектно-ориентированное программирование(AOP) в PHP
• Управление зависимостями в программном коде

Введение

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

Не трудно догадаться, что многие разработчики стремятся к совершенствованию в своём любимом деле (разве нет?). Многие из вас постоянно слышат о новых для себя технологиях и методологиях разработки программного обеспечения, однако, не все находят время и стимул для того, чтобы ознакомиться с ними (примером тому являются методологии TDD, BDD, DDD, ORM, DSL, AOP, Design Patterns и т.д., а так же сопутствующие им инструменты).

1. Введение

В данной статье я хотел бы рассказать об этих трёх буквах, постоянно находящихся на слуху, но для многих являющихся тайной за семью печатями, а так же привести ряд ресурсов, с которыми неплохо было бы познакомиться при желании продолжить развитие в проектировании на основе предметной области (DDD: Domain Driven Design).

В .net-е есть несколько серьезных AOP-фреймворков, но ни один их них не «рулит» так как PostSharp. Будучи большим фанатом (а также пользователем) сего фреймворка, хочу представить сообществу несколько «рецептов». Некоторые из них я создал сам, другие нашел в интернете и адаптировал под свои нужды. Тут я покажу несколько самых «сочных» рецептов. А если вы не знакомы с фреймворком или идеологией AOP, могу порекоммендовать вот этот вебкаст. Итак, начнем?

Иногда возникает необходимость кэширования результатов исполнения методов. Одно из возможных решений для java описано здесь. Всё, в принципе, тривиально: EHCache, Spring AOP для перехвата вызовов, немножко кода.

Рассмотрим, как мне кажется, более элегантное решение на scala.

При разработке cloud платформы веб-приложений был реализован сервис серверной логики на базе java scripting технологии для более гибкого управления другими сервисами платформы.

Соответственно «стал ребром» вопрос контроля над порождением, жизнью и использованием ресурсов платформы дочерними потоками создаваемыми из скриптинга. Потоки через скриптинг могут создаваться всеми доступными способами. В GoogleAppEngine проблему дочерних потоков решили простым запретом их порождения. В нашем случае хочется иметь более гибкое решение. Поэтому необходимо иметь контроль над дочерными потоками создаваемыми из главного потока запроса.

Изначально предполагалось что задача тривиальна и что в Java есть стандартные для этого средства. Но ожидания не оправдались.

Сей опус появился в связи со статьей habrahabr.ru/blogs/java/74208

UPD. Гораздо более подходящий вариант решения и его обсуждение — habrahabr.ru/blogs/java/74208/#comment_2141270

Ниже приведена информация как оно задумано, но пока не работает (может быть и вообще не заработает :( ). Нам нужно сделать 3 вещи:

Во-первых, мы создаем интерфейс и хотим, чтобы класс java.lang.Thread его реализовывал:

public interface TreeInfo {
    public Thread getParentThread();
}

Во-вторых, нам необходимо где-то сохранять значение Thread.currentThread() при вызове конструктора класса Thread.

В-третьих, нужно каким-то образом «взлететь со всей этой херней».

Интро

В последнее время решил немного освежить свои знания в ASP.NET, в связи с чем углубился в процессы генерации кода контролов по разметке (*.ascx, *.aspx) и обнаружил что можно делать очень интересные решения, о которых  о хочу поведать. Итак сегодня мы узнаем, как подружить наш Dependency Injection контейнер с генерируемым контролами кодом.

Цель данной статьи — написание мини контейнера-фреймворка, который возьмет на себя задачи авторизации и аутентификации пользователя, позволяя писать минимум кода в клиентской программе. Сразу оговорюсь, в реальной жизни я использую Spring Security (ранее проект назывался Acegi).
Статья предназначена для тех кто хочет демистифицировать для себя магию работы подобных решений, либо для тех кто по каким либо причинам не считает целесообразным использование общедоступных решений и планирует создать собственную имплементацию системы безопасности. Одна из таких причин — ограниченный размер оперативной памяти и невозможность запуска «взрослых» фреймворков, например в такой Java среде как Android (у меня пока нет данных об успешном использовании AspectJ на платформе Android, но это лишь вопрос времени).

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

Парадигмы программирования

В современном мире IT-разработки существует довольно большое множество различных подходов к написанию программ. Так, например, кому-то нравиться представлять программу в виде последовательности действий, а кто-то считает, что программа должна представлять собой множество объектов, общающихся друг с другом. Совокупности этих идей и понятий образуют своего рода стиль написания программы, который принято назвать – парадигма программирования.

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

• инструкция (императивное программирование, FORTRAN/C/PHP),
• функция (функциональное программирование, Haskell/Lisp/F#/Scala),
• прототип (прототипное программирование, JavaScript),
• объект (объектно-ориентированное программирование, С++/Java),
• факт (логическое программирование, PROLOG).

Стоит заметить, что в общем случае язык программирования однозначно не определяет используемую парадигму: на том же PHP можно писать как императивные, так и объектно-ориентированные программы.

В этой статье я хочу рассказать о сравнительно молодой, но крайне, на мой взгляд, полезной парадигме программирования – аспектно-ориентированном программировании.

В моем разговоре с Андресом Хейлсбергом о страхах, неуверенности и сомнений относительно Аспектно-Ориентированного программирования я упомянул про общую путаницу и непонимание что АОП и DI – это конкурирующие концепции. В этой статье я попробую объяснить вам обо всех различиях и сходствах в этих двух подходах.Недавно я прекрасно провел время за чтением статьи Дино Эспосито: «Аспектно-ориентированное программирование, interception и unity 2.0», в декабрьском номере MSDN Magazine. Это великолепная статья и я настоятельно советую любому разработчику, вовлеченному в .NET разработку прочитать ее полностью. Как и многие DI фреймворки, и некоторые основные фреймворки (WCF, ASP.NET MVC), Unity предлагает похожую на АОП возможность: interceptors.

Давным-давно я достаточно хорошо исследовал PostSharp и даже начал использовать его в своих разработческих целях. Умудрился даже написать скринкаст и пару-тройку статей на эту тему. К сожалению, с PostSharp’ом у меня в последствии совсем не сложилось и, по причинам периодических воспросов со стороны комьюнити на тему “как? почему?”, я решил написать этот пост чтобы расставить все точки над i.

Иногда попадаются такие ситуации, в которых нет никакой возможности ускорить работу некоторой операции. Она может зависеть от какого-то сервиса, который располагается на внешнем web сервере, или это может быть операция, которая дает высокую нагрузку на процессор. Или же это могут быть быстрые операции, однако, их параллельная работа может высосать из вашего компьютера все ресурсы производительности. Существует огромное количество причин чтобы использовать кэширование. Следует отметить, что PostSharp, изначально не предоставляет решений для вас какого-либо фреймворка кэширования, просто он позволяет сделать эту задачу на порядки быстрее, без каких-либо занудных действий, типа расстановки кода, отвечающего за кэширование по всему исходному тексту программы. Он позволяет решить эту задачу элегантно, вынося задачи в классы и позволяя их повторно использовать.

И снова здравствуйте! В прошлый раз при обсуждении АОП, мы с вами говорили о решении задач кэширования. Сегодня мы поговорим о не менее часто встречающейся задаче – задаче логгирования и аудита. Нам часто приходится сталкиваться с такими ситуациями, как, например, анализ чужого кода. Представьте себе, что вам дали задачу интеграции с библиотекой стороннего производителя. Основной инструментарий чуть ли не каждого разработчика — .net reflector, ILSpy, dotPeek дают отличное представление о коде программы. О ее алгоритмах, структуре, возможных местах ошибок. И покрывают большой процент вопросов к программному продукту. Однако так происходит до тех пор, пока вы не начинаете ее активно использовать. Тут могут возникнуть как проблемы с производительностью, так и с непонятными «багами» внутри стороннего продукта, которые, если не иметь дизассемблера с функцией отладчика, не так-то просто найти. Или, например, вам необходимо просто следить за значениями переменных, не останавливая продукт в точках останова, real-time. Такие места часто необходимо срочно и быстро исправлять. А как при исправлении этого кода не написать программу, которая потом будет в топе сайта govnokod.ru? О таких ситуациях мы сейчас и поговорим.

Кусок кода, представленный ниже, вы наверняка писали не один раз. А что более вероятно – десятки раз. Обычно это пишется, когда необходимо использовать некий репозиторий, который будет предоставлять данные для вашего приложения. Если у вас мало времени, и вы торопитесь, это отличный способ получить что-либо таким образом, что это будет загружено в память только тогда, когда это вам понадобится, но не раньше (например, операция сохранения повлекла за собой обращение к подсистеме сериализации, однако до этого она не была нужна). И ведь на самом деле получается, что этот кусок кода с одной стороны одинаков, а с другой – его приходится писать не один раз.
Как правило, я и многие программисты, предпочитаем использовать в данном месте IoC контейнер, чтобы решать задачи такого рода. Однако это не всегда так просто сделать, особенно когда я программирую в рамках отсутствия Dependency Injection в библиотеке, которую я использую (WinForms, WebForms, …). Давайте разберемся, почему решая эту задачу без использования PostSharp, вы потратите гораздо больше времени и проделаете больше работы.

Когда в последний раз я консультировал одну компанию, мы обсуждали внутренний SOA фреймворк, который должен взаимодействовать с базами данных предприятия. Этот фреймворк был SOA только разве что по названию, полностью доморощенный, и что самое грустное, он был «любимым проектом» начальника отдела ИТ. Он был не безопасным и построен на сомнительных технологиях и решениях. В общем он был сделан для решения некоторой проблемы, которой либо не существует, либо она не могла была разрешима боле простыми средствами. Моя команда была крайне разочарована структурой этого фреймворка. Но, в качестве консультанта, очень часто приходится сначала продумать пути решения проблемы, нельзя порсто сказать заказчику что его продукт «плохой», необходимо сначала построить его доверие к себе, и только потом решать более серъезные проблемы. Так или иначе такой процесс может занять годы, и все зависит от фирмы, в которой будут происходить такого рода изменения. Тогда я и задумался над тем чтобы начать использовать аспектно-ориентированный фреймворк чтобы решить эту проблему

Итак, доступна для скачивания новая версия продукта – релиз кандидат PostSharp 2.1, с нашего веб-сайта и с репозитория NuGet.

PostSharp 2.1  — это незначительное обновление PostSharp 2.0. Причина выхода этой версии в основном – правка некоторых ошибок, которые мы допустили в разработке предыдущей версии.

Релиз-кандидат обещает быть высококачественным продуктом, который практически не содержит ошибок, которые нам известны и необходимо чтобы он был протестирован обществом прежде чем он будет помечен как стабильный и выпущен как релиз. Также была проделана работа над обновлением документации. Так что теперь она отражает весь функционал продукта.

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

void SomeMethod(IEmployee lazyguy)
{
    if(lazyguy == null) throw new ArgumentException(“lazyguy”);
    // Do something with lazy guy. Fire him, for example.
}

Кто-то пытался превратить это в:

void SomeMethod(IEmployee lazyguy)
{
    UniversalValidator.CheckNotNull(lazyguy);
    // Meet with him and talk about motivations
}

Кто-то превращал это во что-то похожее. Однако у всех, я могу поспорить, оставался осадок что что-то тут не так. Красивее было бы как-то по другому. А что в итоге? Огромное количество велосипедов с квадратными колесами! Как сделать по-другому?