• Фантастическая статья о технологиях, Getting Real about NoSQL and the SQL-Isn’t-Scalable Lie. В продолжение темы: HBase vs Cassandra: why we moved и Brewer’s CAP Theorem
• Интересный пример как нестандартный UI-дизайн может быть эффективнее принятых best practices, LukeW | “Mad Libs” Style Form Increases Conversion 25-40%
• Вышел свежий номер “журнала для 1% программистов”, Журнал «Практика функционального программирования» Выпуск 4, февраль 2010
• Интервью с разработчиком GitHub, Scott Chacon | The Geek Talk. Его чувство юмора напоминает Линуса
• Попытка сделать “кросс-платформенную” среду исполнения для современных смартфонов (iPhone, Blackberry, Android), PhoneGap | Cross platform mobile framework. Об особенностях разработки веб-приложений для этих платформ есть пара интересных книжек, Building iPhone Apps with HTML, CSS, and JavaScript и APRESS.COM : Pro Smartphone Cross-Platform Development
• Подборка ссылок на онлайн-курсы по программированию, типа МТИ
• Похороны IE6, Announcement | IE6 Funeral

Мероприятие достаточно масштабное: три дня идут доклады (keynotes и lightning talks в большом зале и затем пять потоков для “обычных” докладов, полная программа). Плюс open spaces: неформальные “кружки по интересам”, где обсуждаются конкретные темы как например GIL, django или distribute. Плюс два дня мастер-классов, где за дополнительные деньги можно получить быстрое “погружение” по выбранной теме. Плюс четыре дня спринтов, где разработчики садятся вместе и программируют, например, новую реализацию того же GIL или закрывают тикеты в django.

Все доклады снимались на видео, которое уже доступно на pycon.blip.tv. Рекомендую начать с keynotes и lightning talks (1, 2, 3), они интересные. Мне понравился доклад Threading not a model и Understanding The Python GIL. Хотелось бы больше докладов “продвинутого” уровня и вообще более качественной подготовки от докладчиков (ну да это камень и в мой огород).

Из услышанного и увиденного:

• В Python 3.2 был кардинально переделан алгоритм работы GIL, впервые за 15 (!) лет. Теперь не будет sys.setcheckinterval() и “check counter”, вместо этого используется ожидание с таймаут и принудительная передача при превышении таймаута. Остается добавить логику по динамическому управлению приоритетами потоков, как это делает ОС
• Переход на Python 3 понемногу становится реальностью. Идет работа над 2to3, появился и (альфа-качества) 3to2 для авто-сборки под Python 2. Появляется документация с описанием процесса перевода.
• distutils & setuptools идут в утиль, всех призывают переходить на pip (distribute) плюс virtualenv. Хорошая иллюстрация слов GvR, “включенный в stdlib код перестает развиваться”
• Бикинг взялся делать silver lining (toppcloud), утилиту развертывания Python-приложений для унифицированного хостинг-окружения на базе Ubuntu+Apache+mod_wsgi
• coverage.py научилась понимать “условное покрытие” (т.е. когда ветка else не исполняется) и рисовать красивые html отчеты
• У reddit 3 разработчика, при этом на новые фичи работает только “0.5 девелоперов”. Остальным видимо хватает работы в поддержке существующего. Весь деплоймент reddit происходит в Amazon cloud, ежемесячный счет за хостинг – около $20К. По словам разработчика, это значительно дешевле затрат сравнимых по посещаемости проектов

Самое наверное ценное в такого рода мероприятиях это не сами доклады, которые есть на видео, а возможность знакомства и общения с другими разработчиками. Всегда приятно “развиртуализоваться” с человеком, с которым общался чуть ли не десяток лет в списках рассылки. Главное не переборщить. Неожиданно для себя получил, например, пару серьезных разговоров насчет возможной контрактной работы.

Из Киева было аж четыре человека, один парень был из СПб, других людей из России/Украины замечено не было. Поляков и других европейцев было много. Для наших широт поездка на PyCon удовольствие не из дешевых, $1000 стоит перелет плюс еще примерно столько же на проживание и еду/развлечения. Вряд ли я поеду на следующий, вместо этого лучше попробуем провести EuroPython в Киеве.

Честно говоря не знаю, что еще написать. Кому интересен был ход событий, мог следить за ними в твиттере. Про видео написал. О впечатлениях от поездки в Штаты написал у себя в блоге. Если есть еще вопросы — отвечу в комментариях.

Так как все это делается для Вас, нам важно узнать Ваши мысли.

Не секрет, что в данный момент существует проблема покупки жилья. Также, проблема с тем, что на пенсию, которую выплачивает государство выжить весьма проблематично. Есть вариант решения одновременно и первой и второй проблемы путем создания негосударственного пенсионного фонда ИТ-индустрии.

1. Пенсия. Участники фонда, ежемесячно отчисляя пенсионные взносы, в течение своего работоспособного возраста накапливают себе пенсию. Размер пенсии в будущем (при расчете – 30 лет накапливаю, 15 лет получаю) будет в два раза больше чем ежемесячные отчисления в текущем. Это при условии, что доходность фонда покрывает только инфляцию. Т.е. отчисляя сейчас 1000 грн/мес пенсия будет 2000 грн (эквивалент этих денег по своей покупательной способности на момент выдачи).

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

Данная ситуация дает следующие возможности:

1) Фонд покупает недвижимость (условно – жилой дом) – это актив его вкладчиков, который ежегодно растет в цене (т.е. приносит прибыль для их пенсий). Однако этот дом стоит и в нем никто не живет. Фонд может сдавать его в аренду. Если речь идет о фонде индустрии, цель которого – создание условий для жизни вкладчиков, то стоимость такой аренды может быть, значительно ниже рыночной.

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

По предварительным расчетам каждый из участников фонда в течение 10 лет сможет претендовать на получение жилья по одной из схем (при условии ежемесячных отчислений на уровне 1300-1500 грн).

Если коротко – это общая идея.

Актуальны ли для Вас перечисленные проблемы?
Было бы Вам интересно участвовать в такой программе?
Какие предостережения у Вас могут возникнуть?
Иные вопросы?

• Современная версия “RU.PROGRAMMING FAQ” на reddit, reddit.com: FAQ — Must-read programming books? 220+ comments (best comment: “Yes, you must.”)
• JavaScript на сервере, CommonJS/JSGI: The Emerging JavaScript Application Server Platform
• Учебник по JavaScript, Contents — Eloquent JavaScript
• Oracle, Sun, Java, Светлое будущее Java
• Большая подборка тулов для веб-разработки под Firefox, IE, Opera, Codefusion Lab: 43 In-Browser Web Development Tools That Will Make You A Better Web Developer
• Разработка под Android sucks? oleg andreev – Android vs. iPhone: the good, the bad and the ugly
• “Sometimes, when arranging home screen icons, you feel sad and you’re not sure why”, Android Bug Reports, Songs, Rovers « xkcd
• Вице-президент Майкрософт пишет о том, как в компании “давят” творчество. Почему-то пишет об этом в NYTimes, Op-Ed Contributor – Microsoft’s Creative Destruction – NYTimes.com

• Оказывается, использовать хеш-функции типа md5 или даже sha1 для паролей это уже некомильфо — слишком быстро подбирается, How To Safely Store A Password | codahale.com
• Если вас зовут в стартап, вот готовый “калькулятор” для ваших опционов, payout.py – startupequitysimulator
• Марк Пилгрим опубликовал новую главу из своей книги HTML5, на этот раз про geolocation, You Are Here (And So Is Everybody Else) – Dive Into HTML5. Прекрасно, как и всегда.
• Следующий мажорный релиз PostgreSQL будет поддерживать репликацию, Waiting for 9.0 – Streaming replication
• Nine Things Developers Want More Than Money | Software by Rob — многовато слов, но в общем верно
• Facebook выложил в Open Source свой транслятор PHP->C++, HipHop for PHP: Move Fast
• На JavaScript уже делают вещи, которые нормальному девелоперу не понять, (fab) – a pure javascript DSL
• В прошлую субботу в Киеве прошел pycamp. Мои впечатления и отзывы других участников, http://maxua.posterous.com/-pycamp

Динамика изменений минимальной (10й перцентиль), средней (медиана), и максимальной (90й перцентиль) зарплаты.

Что же будет с зарплатами в этом году?

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

Что будет в итоге — куда качнется баланс спроса и предложения — сказать пока сложно. Я думаю рост на уровне 10-15% в долларах вполне реален. Но только для тех компаний, которые получают доходы в валюте. Это вероятно приведет к тому, что эти компании будут “перетягивать” к себе сильных программистов, которые будут появляться на рынке. Для остальных — рост с небольшим опережением гривневой инфляции (т.е. до 20% в гривне). Точно плохо будет разве что тем, кто работает в госструктурах и бюджетных организациях — с госбюджетом на 2010 все очень мрачно.

По нашим инсайдерским данным, отдельные компании уже начали “охоту” за специалистами, “перебивая” встречные предложения по зарплате от конкурентов. Количество вакансий (по нашему сайту) растет, как бесплатных, так и платных. Безработица программистам в любом случае пока не грозит — спрос высокий. Даже если сменить работу “с прибавкой” получится не у всех, то найти работу, урезав свои притязания или согласившись на гривневую зарплату.

количество вакансий на нашем сайте

Чтобы ослабить давление на зарплаты и справиться с дефицитом кадров, компании будут снова запускать учебные центры. Ходят слухи, что несколько крупных компаний собираются “вскладчину” построить отдельный УЦ широкого профиля.

Комментарии компаний

Земницкий Дмитрий, Pragmasoft (Харьков)

Зарплаты в 2009 стали более реальными. В определенный момент, примерно весной, на рынке появилось определенное количество неплохих программистов из развалившихся компаний за вполне внятные деньги. Мы приняли на работу двух джавистов с опытом в этом году. В 2008 году такое было маловероятно, приходилось воспитывать самим.

Прогноз на 2010 очень сильно зависит от экономической ситуации в мире, прежде всего. Если пошатнется американская и европейская экономика, не будет заказов, зарплаты могут обвалиться вплоть до 50%. Думаю что так и будет, но не обязательно в 2010, возможно на год-два позже. Если все будет как сейчас, зависит от заказчиков. У компаний с успешными заказчиками возможно небольшое повышение зпл, и наоборот.

Вадим Михневич, U-Wiss BV (Нидерланды)

В 2009 компании не было смысла повышать зарплату в евро, поскольку за счет роста курса гривневый эквивалент увеличивался автоматически. В 2010 году за счет увеличения спроса из-за окончания кризисного периода, компаниям будет смысл немного увеличить зарплату, до 10% в евро. Есть общая тенденция роста курса, и давать более значительный прирост смысла нет — просто чтобы “отметить” лояльное отношение к сотрудникам и предотвратить “расползание” кадров (”О, зарплату подняли — ништяк, можно еще тут поработать, вдруг еще поднимут”).

Артем Савотин, ameria.de (Германия)

В целом, особенно по Киеву, в 2009 заметно упал спрос на высокие зарплаты в валюте и люди начали себя более адекватно оценивать. Можно спокойно договариваться о гривне учитывая индексацию к покупательской способности. По сравнению с другими специальностями, очень многие Project Manager-ы и Technical Writers находятся в поиске работы, несмотря на то, что у них есть постоянное рабочее место.

На 2010 прогнозируем рост +20-30% в гривне при условии, что национальная валюта останется на таком же уровне к иностранной, как сейчас. Если будет обвал, тогда мы будем очень оперативно реагировать и зарплаты в гривне могут вырасти намного выше. Мы видим очень большой спрос на опытных PHP разработчиков. Довольно сложно найти хороших и свободных специалистов по Plone/Zope на рынке Украины. По этому, возможно, что будем обучать ребят знающих Python.

Дмитрий Сохач, ISD (Днепропетровск)

Я считаю, что зарплаты по Киеву возрастут незначительно, но в регионах будет значительный в процентном отношении рост зарплат по сравнению с предыдущим годом, на 5-10% больше (в долларах).

На условиях анонимности (Харьков)

IT рынок в 2010 по-прежнему будет оставаться неоднородным. Какие-то компании усилят свое положение на рынке, будет оставаться часть компаний, которые не смогут дальше продолжить свой бизнес. Возможно, в 2010 году услышим о каких-то крупных слияниях или приобретении более мелких компаний. 2010 год ожидает быть более стабильным нежели уходящий. Наш прогноз — вырастут на 5-15% (в долларах) для разных категорий программистов. Общая тенденция рынка — з/п медленно будут продолжать расти. Сохранится большой спрос на профессионалов, который и будет двигать повышение з/п.

Востребованными программистами в этом году будут оставаться .Net Developers, Java Developers, на тестировщиков будет оставаться стабильный спрос. Возобновится интерес к менеджерам высшего звена. Как всегда будут востребованы менеджеры по продажам, маркетологи, которые смогут представить компанию в более выгодном свете, увеличить объемы продаж в перспективе. В 2010 году ожидается интерес к мобильным, переносным устройствам (и программистов, способных под них писать).

Марина Вышгородских, Ciklum (Киев)

Уже сейчас заметна тенденция к тому, что в 2010 запросы на специалистов будут более узкоспециализированными. Возможно, это связано с тем, что в результате кризиса с одной стороны появилась возможность найти экспертов в mainstream технологиях и в Европе, с другой – клиенты в меньшей мере готовы тратить время и ресурсы на обучение, хотят в Украине получить уже готовых специалистов.

В настоящий момент много запросов на iPhone and Android developers, IBM WebSphere supporters and developers, специалистов со знанием Drupal, МОSS, Google Web Toolkit, etc — причем, в качестве основных, а не «желательных» требований.

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

Что касается зарплат, думаю, возвращающийся после кризиса спрос их слегка подогреет, но не думаю, что в 2010 мы вернемся к временам зарплатного бума 2007-2008 годов.

Что такое Alfresco?

Зайдя на wiki.alfresco.com мы можем скачать Community-версию, она бесплатна, на момент написания статьи выпущена версия 3.2. Как система управления веб-контентом, она достаточно просто интегрируется с open-source порталом Liferay и призвана взвалить на себя нагрузку по управлению сложным веб-содержимым. Скачав инсталлятор, можно быстро установить уже сконфигурированную связку MySQL + Alfresco server + Alfresco virtual server. Для портала Liferay можно скачать Alfresco portlet из репозитория и развернуть Alfresco server на том же сервере приложений, что и портал.

Alfresco — это файло-ориентированная CMS, которая может как представлять собой файловую систему, так и расширять общепринятую функциональность через мета-данные, закрепляемые за каждым файлом и папкой.

Первое знакомство

При старте запускается MySQL и Tomcat с Alfresco server (занимает порт 8080, 21), а еще можно запустить Virtual Server (занимает порт 8180). Виртуальный сервер — удобное средство для предпросмотра сайта с наполнением, он обязательно должен быть запущен при работе с WCM.

При изучении документации встречаются обе аббревиатуры ECM и WCM. Enterprise Content Management — это ядро системы. Здесь можно создавать собственные типы данных Custom Content Model, например, тип Сотрудник с полями Имя, Фамилия, Отчество, Кабинет и Дата рождения. Эту часть системы я рассматривал поверхностно, больше копаясь в WCM, который создан как настройка над ECM.

Alfresco имеет свой веб-интерфейс (http://localhost:8080/alfresco/), который на самом деле является клиентом к сервисам ECM и от того позволяет выполнять лишь наиболее популярные действия, 90% конфигурирования и управления системой выполняется в .xml файлах, расположенных в 2х местах: <alfresco_dir>/tomcat/webapps/alfresco/WEB-йINF/classes/alfresco и <alfresco_dir>/tomcat/shared/classes/alfresco/extension. Там же есть множество примеров, и чаще всего эти файлы — конфигурации Spring framework, что сразу означает, что они отнюдь не прозаичны и требуют понимания архитектуры всей системы.

Web Content Management (WCM)

Как сказано в документации — специально для управления веб-содержимым в Alfresco разработан AVM (Advanced Versioning Manager). Это специальная модель, созданная на основе ECM, и представляющая собой версионные Файлы и Папки, плюс дополнительные сервисы. Основная идея состоит в следующем. Есть сайт (Site) и его наполнение. Каждый автор создает содержимое в его собственном хранилище, которое как слой наложено на содержимое сайта. После того как автор создал статью, он делает ей Submit и она идет по потоку утверждения. Когда статья окончательно утверждается, она переносится в общее хранилище и становится видимой всем остальным участникам работы над сайтом. Таким же образом поддерживается версионность документов. Локальные изменения каждого пользователя только после утверждения попадают в общее хранилище.

Этот подход имеет огромные достоинства: каждый автор имеет свой репозиторий, который всегда содержит последние общие обновления и одновременно может видеть свои изменения прямо на сайте. Добавив новость, автор может увидеть ее сразу же на своем виртуальном сайте, а другие участники могут ее увидеть только после утверждения. Однако есть и минусы. На текущий момент не решена проблема конфликтов. При появлении конфликта нет понятия merge, можно только откатить свои изменения. Таким образом, кто первый засабмитил — того и тапки. В версии 3.2 налюдается еще и глюк, когда без отката изменений нельзя засабмитить и другие, не конфликтные, файлы и еще одна проблема сабмита большого количества файлов (опытным путем установлено, что первой волной надо засабмитить только .xml файлы, выждать время, а после — все остальные).

Общее хранилище не является финальным для отображения, для него предусмотрена еще и публикация (deployment) на production-сервер через FSR (File System Receiver). Работает это так. При выполнении команды Deploy, создается событие отправки последних изменений. Дальше не совсем прозаично. У вас должен быть настроен получатель события, а это отдельный java-процесс (.jar и все необходимое можно скачать с официального сайта), который подписывается на deployment-события и выкладывает полученные изменения в локальную файловую систему.

Файловая структура

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

При использовании WCM eсть нюанс. Через CMIS (протокол SMB, подключение удаленной папки) не доступны репозитории WCM, а только ECM, что означает отсутствие возможности заливать веб-контент через удаленную папку в Windows. Удаленный доступ к репозиториям AVM возможен только через FTP (этот сервис автоматически доступен при старте Alfresco), который корректно работает с русскими буквами.

Web Forms

Главная функция для веб-CMS, это создание и отображение содержимого сайта. Для этого в Alfresco используются веб-формы. Структура контента определяется в xml-схемах (.xsd файлы), наполнение сохраняется в формате xml, соответствующим этим схемам, а представление может быть отрендерено в разные форматы, чаще всего в html.

А теперь важный архитектурный момент. Рендеринг введенных пользователем данных осуществляется в момент ввода, — то есть когда пользователь создал контент типа Новость и заполнил все поля, создается несколько файлов. Например, novogodnie-skidki.xml, novogodnie-skidki.html, novogodnie-skidki-short.html, где первый содержит наполнение в xml (исходные данные), второй — “новость подробно” и третий — “новость кратко”, скажем, для главной страницы. Для рендеринга используются FreeMarker template или XSLT преобразования. С успехом мы можем рендерить и .jsp страницы, располагать их в разных директориях и пр.

Процесс рендеринга — на удивление медленный и ресурсоёмкий. Если выполнить перегенерацию всего контента, это может происходить минут 5 для 100 элементов.

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

Важно понимать, что рендеринг наполнения происходит на этапе создания контента, а это говорит о следующем: созданный .html контент статичен (исключение — рендеринг .jsp страниц).

Еще один минус — при работе с репозиторием через стандартный веб-клиент Alfresco автор видит как нужные ему файлы (.xml), так и их представление .html, а чаще — еще и вспомогательные, .jsp и другие ресурсы. Как этого избежать, я так и не нашел.

Архитектура веб-приложения

Alfresco создает статический контент. На этом ее функции по созданию веб-сайтов заканчиваются. Alfresco предлагает свой Web Framework, но он крайне сложный. Чтобы упростить работу с ним, выпущен визуальный построитель сайтов Alfresco Surf platform, но даже в релизе(!) он глючит и не может получить из Alfresco список веб-контента. За разумное время мне не удалось сделать ничего толкового и было принято решение отказаться от его использования. Дальше описаны несколько наиболее применимых архитектур веб приложений.

Первый вариант создания сайта — чистый plain text и отсутствие динамики, который хорошо подойдет к маленьким сайтам-визиткам, где достаточно отрендерить всё в html и, возможно, сделать часть динамических страниц через .jsp. При этом деплоиться сайт может, например, в /tomcat/webapps/ROOT. Списки новостей могут так же рендериться на этапе добавлении новости и отображаться как статическая страница. Скорость работы такого сайта стремится к первой космической, а нагрузка на сервер — к нулю.

Второй вариант — использование фреймворка, который хорошо бы работал с уже сгенерированными страницами, например SiteMesh. В этом случае достаточно просто создавать страницы .html с уже сформированными на основе контента мета-данными (title, description, keywords).

Третий вариант — использование Alfresco web-scripts для формирования страниц.

Поиск

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

• Open Search — доступен из веб-интерфейса, ищет только по репозиторию ECM, поэтому даже не пытайтесь найти свой первый helloworld.html в WCM репозитории;
• Lucene — наиболее мощный вид поиска, досупен только из web scripts или джавы;
• XPath — последовательный обход дерева элементов, что означает низкую производительность
• CQL — обещают возможность описывать поисковые запросы по модели данных ECM в синтаксисе SQL — практического применения не видел.

Из всего списка реально применим только Lucene, у него широкие возможности поиска по атрибутам и метаданным документа, но по умолчанию содержимое всех документов (и даже xml) считается сплошным текстом, что создает сложности, если мы хотим найти наличие определенного поля в документе. С другой стороны, сразу можно искать по таким полям как имя, путь к файлу, дата создания/модификации и некоторым другим.

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

Web scripts

Веб-скрипты в Alfresco заслуживают отдельного внимания. Это модель MVC, один из немногих удобных механизмов а Alfresco, который представляет собой связку javascript + FreeMarker templates. Каждый скрипт имеет привязку к шаблону URL, наподобие grails, например /news/{year}?/{newsName}?. При запросе этого адреса выполняется javascript, в котором доступны почти все сервисы Alfresco. Результат рендерится в шаблонах FreeMarker.

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

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

Самое время обрадоваться наличию такой технологии, но и тут ложка дегтя — очень тупо реализованный <include> джаваскрипта. Если хочется хоть какую-то архитектуру создать, то придется делать включения нескольких javascipt-файлов, что реализовано … простым добавлением всех скриптов в один большой StringBuffer в памяти и ошибки выполнения содержат неожиданные номера строк. В этой ситуации выручает имеющийся javascript-debugger — отдельное Swing приложение, где даже можно посмотреть все сигнатуры сервис-методов.

Metadata extraction

Представим такую ситуацию. У нас есть тип веб-контента Новости, нам необходимо указать отображать ли эту новость на главной странице сайта или же только в общем списке. Другими словами нам нужно добавить к контенту некий признак, наличие которого означало бы необходимость опубликовать новость на главной странице. Мы можем добавить этот признак в метаданные документа, либо сделать его полем xsd структуры Новости. Если мы добавим признак в метаданные, то он будет потерян при копировании через FTP или деплое в файловую систему через FSR. Если мы добавим поле в тип Новости, то его нельзя будет найти поиском. В этом случае на помощь приходит механизм Metadata extraction — возможность настроить Lucene таким образом, чтобы при индексации контента он изымал некоторые поля из xml, чтобы можно было написать в поисковом запросе что-то вроде “+ASPECT:{cm}showOnHomePage” и найти только те новости, которые нам нужны. Идея хороша, но достаточно сложна в реализации несмотря на наличие описаний.

Alfresco + Liferay

Alfresco, собранную для развертывания на сервере Liferay, можно скачать из репозитория Liferay. Эта сборка включает в себя Alfresco сервер, веб-клиент, портлеты для отображения контента, администрирования и задач пользователя. Сложностей с запуском — никаких, но интеграция не полная. Не поддерживается единый вход в систему SSO (Single Sign-on). В гугле можно найти примеры полной интеграции — при регистрации пользователя в портале, он создается в Alfresco и есть возможность отображать веб-скрипты и контент под правами текущего пользователя портала. Но как показывает практика, часто это и не нужно.

Выводы

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

• можно легко и быстро создавать контент, тяжело из него сделать сколь-нибудь удобный сайт;
• автоматическое тестирование практически невозможно;
• очень слабые возможности при работе с уже созданным содержимым — только обзор директорий, файлов и поиск;
• заявлено много рекламных решений, которые на проверку оказываются пустышками
• наличие большого количества багов в самой системе, что свидетельствует об отношении к тестам разработчиков, и сразу же о вашей возможности тестировать свой продукт, построенный на Alfresco.

Мой личный рейтинг CMS Alfresco — 3/5.

• CoffeeScript — попытка создать выразительный язык высокого уровня, который компилируется в JavaScript. Движок V8 дает одну из самых быстрых реализаций среди “скриптовых” языков (via)
• How to Find and Hire Amazing People, Part 4 – blog.adamsmith.cc
• В продолжение прошлой темы про continuous deployment, Lessons Learned: Case Study: Continuous deployment makes releases non-events
• Очень интересный инструмент для “ускорения” сайта, Кеширование страниц сайта при помощи Varnish + ESI
• Для фрилансеров пригодится, шаблон договора на оказание услуг по разработке ПО или веб-сайта.
• Пятничное видео, Записки одного программиста — ВНЕДРЯЙ!

По мере роста размера проекта тесты принимают все более важное значение, т.к. в большом проекте возникает проблемы с изменением кода. В большом проекте очень сложно менять код, не внося при этом ошибок. Чем он больше – тем сложнее понять, на что повлияет изменение, и тем выше шанс что-то сломать. При росте размера проекта важность тестов растет экспоненциально. Юнит-тесты – отличный помощник в такой ситуации.

Michael Feathers в его книге Working Effectively with Legacy Code вводит понятие «Унаследованный код» (Legacy code). Унаследованный код – это код без тестов, изменение которого может быть сложным из-за отсутствия автоматических регрессионных тестов. Объективно, это существенная часть кода в тех компаниях, где мы работаем (см. опрос – более 70% имеет ограниченное покрытие тестами, либо не пишут тесты совсем). Не секрет, что многие проекты в начале представляют собой простые и понятные системы, над которыми работают 1-2 программиста. В таких проектах написание тестов часто считается тратой времени. Но по мере роста проекта и возрастания сложности все более ощущается отсутствие автоматического регрессионного тестирования. Дизайн все более усложняется, и становится все труднее поддерживать и развивать проект. Так появляется унаследованный код…

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

Я бы хотел показать некоторые методики разрыва зависимостей, которые я использовал в работе.

Их автор – Michael Feathers. В книге Working Effectively with Legacy Code он описал больше методик, чем я здесь привожу. Я считаю, что описанные здесь методики наиболее востребованные и эффективные:

• Parameterize constructor
• Parameterize method
• Introduce static setter
• Extract and override call
• Extract and override factory method

Все методики я привожу на языке C#, так как я на нем пишу. Надеюсь, он будет всем понятен =)

1. Parameterize constructor

Эта методика предназначена для выноса зависимости при помощи конструктора. Основная ее идея – создание нового конструктора, который принимает в качестве параметра интерфейс класса, от которого зависит «унаследованный код».

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

namespace ParameterizeConstructor.LegacyCode
{
    public class ClassWithDependency
    {
        public ClassWithDependency()
        {
            //some initialization
        }

        public bool DoSomething()
        {
            //...
            int caseCount = WebServiceFacade.Instance.GetCaseCount();
            if (caseCount > 0)
            {
                //...
                return true;
            }
            //...
            return false;
        }
    }
}

using System.Diagnostics;

namespace ParameterizeConstructor.LegacyCode
{
    public class WebServiceFacade
    {
        private static WebServiceFacade instance;

        public static WebServiceFacade Instance
        {
            get
            {
                if (instance == null)
                {
                    instance = new WebServiceFacade();
                }
                return instance;
            }
        }

        public int GetCaseCount()
        {
            //make call to real web service
            Debug.Fail("This code makes call to real web serviсe. This is not acceptable for unit test.");
            return 42;
        }

        //...
    }
}

Нам необходимо внести изменения в код этого метода и мы должны сначала написать тест. Но мы не можем написать юнит-тест, потому что метод будет обращаться к веб-сервису во время запуска теста. Это неприемлемо. Для разрыва зависимости нам необходимо извлечь интерфейс (Extract Interface) в классе WebServiceFacade:

namespace ParameterizeConstructor.BrokenDependency
{
    public interface IWebServiceFacade
    {
        int GetCaseCount();
    }
}

using System.Diagnostics;

namespace ParameterizeConstructor.BrokenDependency
{
    public class WebServiceFacade : IWebServiceFacade
    {
        private static IWebServiceFacade instance;

        public static IWebServiceFacade Instance
        {
            get
            {
                if (instance == null)
                {
                    instance = new WebServiceFacade();
                }
                return instance;
            }
        }

        public int GetCaseCount()
        {
            //make call to real web service
            Debug.Fail("This code makes call to real web serviсe. This is not acceptable for unit test.");
            return 42;
        }
    }
}

Теперь мы добавляем новый конструктор, не забыв оставить старый:

namespace ParameterizeConstructor.BrokenDependency
{
    public class ClassWithDependency
    {
        /// <summary>
        /// We preserved original constructor
        /// </summary>
        public ClassWithDependency()
            : this(WebServiceFacade.Instance)
        {
        }

        /// <summary>
        /// This constructor has been created for testing purposes. You can inject your dependency using this constructor
        /// </summary>
        public ClassWithDependency(IWebServiceFacade webService)
        {
            this.webService = webService;
            //some initialization has gone here
        }

        private IWebServiceFacade webService;

        public bool DoSomething()
        {
            //...
            int caseCount = webService.GetCaseCount();
            if (caseCount > 0)
            {
                //...
                return true;
            }
            //...
            return false;
        }
    }
}

В старом конструкторе мы вызываем новый конструктор с параметром WebServiceFacade.Instance это сделано для того, чтобы гарантировать сохранение интерфейса класса для всех, кто это класс будет использовать.

Теперь мы можем написать тест, используя мок:

#if TEST
using NUnit.Framework;
using Rhino.Mocks;

namespace ParameterizeConstructor.BrokenDependency
{
    [TestFixture]
    public class TestClassWithDependency
    {
        [Test]
        public void DoSomething()
        {
            var webService = MockRepository.GenerateMock<IWebServiceFacade>();

            webService.Expect(x => x.GetCaseCount()).Return(20);

            var classWithDependency = new ClassWithDependency(webService);
            bool result = classWithDependency.DoSomething();
            Assert.IsTrue(result);

            //...

            webService.VerifyAllExpectations();
        }
    }
}
#endif

2. Parameterize method

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

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace ParameterizeMethod.LegacyCode
{
    public class ClassWithDependency
    {
        public bool DoSomething()
        {
            //...
            int caseCount = WebServiceFacade.Instance.GetCaseCount();
            if (caseCount > 0)
            {
                //...
                return true;
            }
            //...
            return false;
        }
    }
}

using System.Diagnostics;

namespace ParameterizeMethod.LegacyCode
{
    public class WebServiceFacade
    {
        private static WebServiceFacade instance;

        public static WebServiceFacade Instance
        {
            get
            {
                if (instance == null)
                {
                    instance = new WebServiceFacade();
                }
                return instance;
            }
        }

        public int GetCaseCount()
        {
            //make call to real web service
            Debug.Fail("This code makes call to real web serviсe. This is not acceptable for unit test.");
            return 42;
        }
    }
}

Для разрыва зависимости нам необходимо извлечь интерфейс (Extract Interface) в классе WebServiceFacade:

namespace ParameterizeConstructor.BrokenDependency
{
    public interface IWebServiceFacade
    {
        int GetCaseCount();
    }
}

using System.Diagnostics;

namespace ParameterizeConstructor.BrokenDependency
{
    public class WebServiceFacade : IWebServiceFacade
    {
        private static IWebServiceFacade instance;

        public static IWebServiceFacade Instance
        {
            get
            {
                if (instance == null)
                {
                    instance = new WebServiceFacade();
                }
                return instance;
            }
        }

        public int GetCaseCount()
        {
            //make call to real web service
            Debug.Fail("This code makes call to real web serviсe. This is not acceptable for unit test.");
            return 42;
        }
    }
}

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

namespace ParameterizeMethod.BrokenDependency
{
    public class ClassWithDependency
    {
        /// <summary>
        /// We preserved original signature
        /// </summary>
        public bool DoSomething()
        {
            return DoSomething(WebServiceFacade.Instance);
        }

        /// <summary>
        /// This method has been created for testing purposes
        /// </summary>
        public bool DoSomething(IWebServiceFacade webService)
        {
            //...
            int caseCount = webService.GetCaseCount();
            if (caseCount > 0)
            {
                //...
                return true;
            }
            //...
            return false;
        }
    }
}

Теперь мы можем написать тест:

#if TEST
using NUnit.Framework;
using Rhino.Mocks;

namespace ParameterizeMethod.BrokenDependency
{
    [TestFixture]
    public class TestClassWithDependency
    {
        [Test]
        public void DoSomething()
        {
            var webService = MockRepository.GenerateMock<IWebServiceFacade>();

            webService.Expect(x => x.GetCaseCount()).Return(20);

            var classWithDependency = new ClassWithDependency();
            bool result = classWithDependency.DoSomething(webService);
            Assert.IsTrue(result);

            //...

            webService.VerifyAllExpectations();
        }
    }
}
#endif

3. Introduce static setter

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

namespace IntroduceStaticSetter.LegacyCode
{
    public class ClassWithDependency
    {
        public bool DoSomething()
        {
            //...
            int caseCount = WebServiceFacade.Instance.GetCaseCount();
            if (caseCount > 0)
            {
                //...
                return true;
            }
            //...
            return false;
        }
    }
}

using System.Diagnostics;

namespace IntroduceStaticSetter.LegacyCode
{
    public class WebServiceFacade
    {
        private static WebServiceFacade instance;

        public static WebServiceFacade Instance
        {
            get
            {
                if (instance == null)
                {
                    instance = new WebServiceFacade();
                }
                return instance;
            }
        }

        public int GetCaseCount()
        {
            //make call to real web service
            Debug.Fail("This code makes call to real web service. This is not acceptable for unit test.");
            return 42;
        }
    }
}

Для разрыва зависимости нам необходимо извлечь интерфейс (Extract Interface) в классе WebServiceFacade а также создать статический метод – setter:

namespace IntroduceStaticSetter.BrokenDependency
{
    public interface IWebServiceFacade
    {
        int GetCaseCount();
    }
}

using System.Diagnostics;

namespace IntroduceStaticSetter.BrokenDependency
{
    public class WebServiceFacade : IWebServiceFacade
    {
        private static IWebServiceFacade instance;

        public static IWebServiceFacade Instance
        {
            get
            {
                if (instance == null)
                {
                    instance = new WebServiceFacade();
                }
                return instance;
            }
        }

        /// <summary>
        /// This method has been created for testing purposes
        /// </summary>
        public static void SetInstance(IWebServiceFacade webService)
        {
            instance = webService;
        }

        public int GetCaseCount()
        {
            //make call to real web service
            Debug.Fail("This code makes call to real web service. This is not acceptable for unit test.");
            return 42;
        }
    }
}

Класс с зависимостью остается без изменений, но теперь можно смело писать юнит-тест:

#if TEST
using NUnit.Framework;
using Rhino.Mocks;

namespace IntroduceStaticSetter.BrokenDependency
{
    [TestFixture]
    public class TestClassWithDependency
    {
        [Test]
        public void DoSomething()
        {
            var webService = MockRepository.GenerateMock<IWebServiceFacade>();

            webService.Expect(x => x.GetCaseCount()).Return(20);

            WebServiceFacade.SetInstance(webService);

            var classWithDependency = new ClassWithDependency();
            bool result = classWithDependency.DoSomething();
            Assert.IsTrue(result);

            webService.VerifyAllExpectations();
        }
    }
}
#endif

4. Extract and override call

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

namespace ExtractAndOverrideCall.LegacyCode
{
    public class ClassWithDependency
    {
        public bool DoSomething()
        {
            string customerName = string.Empty;
            //...
            //here we somehow retrieve and assign result to customerName
            customerName = "Anton Martynenko";
            //...

            int caseCount = CaseCountCalculator.CalculateCaseCount(customerName);
            if (caseCount > 0)
            {
                //...
                return true;
            }
            //...
            return false;
        }
    }
}

using System.Diagnostics;

namespace ExtractAndOverrideCall.LegacyCode
{
    public class CaseCountCalculator
    {
        public static int CalculateCaseCount(string customerName)
        {
            //make call to real web service
            Debug.Fail("This code makes call to real web service. This is not acceptable for unit test.");
            return 42;
        }
    }
}

Для разрыва зависимости мы добавим публичный виртуальный метод в класс с зависимостью:

namespace ExtractAndOverrideCall.BrokenDependency
{
    public class ClassWithDependency
    {
        public bool DoSomething()
        {
            string customerName = string.Empty;
            //...
            //here we somehow retrieve and assign result to customerName
            customerName = "Anton Martynenko";
            //...

            int caseCount = CalculateCaseCount(customerName);
            if (caseCount > 0)
            {
                //...
                return true;
            }
            //...
            return false;
        }

        public virtual int CalculateCaseCount(string customerName)
        {
            return CaseCountCalculator.CalculateCaseCount(customerName);
        }
    }
}

Теперь мы можем написать тест, используя мок класса с зависимостью и подменяя во времени выполнения результаты вызова метода public virtual int CalculateCaseCount(string customerName):

#if TEST
using NUnit.Framework;
using Rhino.Mocks;

namespace ExtractAndOverrideCall.BrokenDependency
{
    [TestFixture]
    public class TestClassWithDependency
    {
        [Test]
        public void DoSomething()
        {
            var classWithDependency = MockRepository.GenerateMock<ClassWithDependency>();
            classWithDependency.Expect(x => x.CalculateCaseCount(Arg<string>.Is.Equal("Anton Martynenko")))
                .Return(31);

            bool result = classWithDependency.DoSomething();
            Assert.IsTrue(result);

            classWithDependency.VerifyAllExpectations();
        }
    }
}
#endif

5. Extract and override factory method

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

namespace ExtractAndOverrideFactoryMethod.LegacyCode
{
    public class ClassWithDependency
    {
        public bool DoSomething()
        {
            string customerName = string.Empty;
            //...
            //here we somehow retrieve and assign result to customerName
            customerName = "Anton Martynenko";
            //...
            var caseCountCalculator = new CaseCountCalculator(customerName);

            int caseCount = caseCountCalculator.CalculateCaseCount();
            if (caseCount > 0)
            {
                //...
                return true;
            }
            //...
            return false;
        }
    }
}

using System.Diagnostics;

namespace ExtractAndOverrideFactoryMethod.LegacyCode
{
    public class CaseCountCalculator
    {
        public CaseCountCalculator(string customerName)
        {
            //customerName is used for initialization
        }

        public int CalculateCaseCount()
        {
            //make call to real web service
            Debug.Fail("This code makes call to real web service. This is not acceptable for unit test.");
            return 42;
        }
    }
}

Экземпляр класса CaseCountCalculator создается на основе customerName, которое вычисляется в процессе выполнения метода. В этом случае мы извлечем интерфейс в классе CaseCountCalculator и используем паттерн «фабричный метод»:

namespace ExtractAndOverrideFactoryMethod.BrokenDependency
{
    public interface ICaseCountCalculator
    {
        int CalculateCaseCount();
    }
}

using System.Diagnostics;

namespace ExtractAndOverrideFactoryMethod.BrokenDependency
{
    public class CaseCountCalculator : ICaseCountCalculator
    {
        public CaseCountCalculator(string customerName)
        {
            //customerName is used for initialization
        }

        public int CalculateCaseCount()
        {
            //make call to real web service
            Debug.Fail("This code makes call to real web serviсe. This is not acceptable for unit test.");
            return 42;
        }
    }
}

namespace ExtractAndOverrideFactoryMethod.BrokenDependency
{
    public class ClassWithDependency
    {
        public bool DoSomething()
        {
            string customerName = string.Empty;
            //...
            //here we somehow retrieve and assign result to customerName
            customerName = "Anton Martynenko";
            //...
            var caseCountCalculator = CreateCaseCountCalculator(customerName);

            int caseCount = caseCountCalculator.CalculateCaseCount();
            if (caseCount > 0)
            {
                //...
                return true;
            }
            //...
            return false;
        }

        public virtual ICaseCountCalculator CreateCaseCountCalculator(string customerName)
        {
            return new CaseCountCalculator(customerName);
        }
    }
}

Теперь мы можем написать тест, используя мок класса с зависимостью и подменяя во времени выполнения результаты вызова метода public virtual ICaseCountCalculator CreateCaseCountCalculator(string customerName):

#if TEST
using NUnit.Framework;
using Rhino.Mocks;

namespace ExtractAndOverrideFactoryMethod.BrokenDependency
{
    [TestFixture]
    public class TestClassWithDependency
    {
        [Test]
        public void DoSomething()
        {
            var caseCountCalculator = MockRepository.GenerateMock<ICaseCountCalculator>();
            caseCountCalculator.Expect(x => x.CalculateCaseCount())
                .Return(31);

            var classWithDependency = MockRepository.GenerateMock<ClassWithDependency>();
            classWithDependency.Expect(x => x.CreateCaseCountCalculator(Arg<string>.Is.Equal("Anton Martynenko")))
                .Return(caseCountCalculator);

            bool result = classWithDependency.DoSomething();
            Assert.IsTrue(result);

            caseCountCalculator.VerifyAllExpectations();
            classWithDependency.VerifyAllExpectations();
        }
    }
}
#endif

Конечно, стоит отметить, что в реальной жизни все намного сложнее, чем в примерах. Но комбинируя эти методики с остальными приемами Inversion of Control можно добиться значительного увеличения покрытия тестами и улучшения дизайна классов. Всем, кто заинтересован увеличением покрытия тестами унаследованного кода я рекомендую прочитать книгу Working Effectively with Legacy Code. Она содержит множество полезных советов для работы с тем, с чем множество из нас сталкивается каждый день =)

В примерах использовались:

• .NET 3.5
• Rhino Mocks 3.5
• NUnit 2.5.2.9222

Исходники тут.