• Оказывается, использовать хеш-функции типа 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

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

• Split testing он же A/B тестирование — интересная штука. Позволяет оценивать эффективность различных элементов веб-интерфейса не “с потолка”, а на основе статистики от живых пользователей.
  Готовая подборка хороших ссылок по этой теме: 15+ Free A/B Split Testing Resources
• Как вам идея, что каждый успешный чек-ин идет сразу в продакшн? Безумие? InfoQ: Beyond Continuous Integration: Continuous Deployment
• Как сделать маркетинг почти инженерной задачей, Engineering Your Way To Marketing Success: MicroISV on a Shoestring
• Balsamiq, о которой я когда-то писал, продолжает свой фантастически успешный путь, A look back at 2009. Там же: Tools we use for running our startup.
• Пара ссылок от читателей:
  Набор трюков C (чуток Java), которые работают, но лучше их не использовать, ZIP File Quine — This is the ZIP file that never ends

• История успеха львовского разработчика,  Путь Индейца или как моя игра стала featured в apple app store. Кстати, с Максимом Гриневым можно будет пообщаться вживую в понедельник на внеочередной встрече Lviv StartUp Club
• Подборка нетривиальных советов для пользователей мускула, MySQL Tips
• Зачетная статья от COTOHA, Половой отбор профессионалов at Мысли с самого низа
• Иллюстрированный отчет с LeWeb Paris 09 / task.ly / StartupPoint.ru

• Выступления Питера Зибела (автора книги Coders at Work) в офисе Google, YouTube – Authors@Google: Peter Seibel
• Маленькая утилита, которая поможет оценить вам видимость “первого экрана” сайта для разных пользователей, Browser Size
• Несколько open-source проектов, которые привлекли к себе внимание в 2009, 2009 Open Source Top Ten
• Обзор (скриншоты) библиотек для визуализации данных (веб), 28 Rich Data Visualization Tools
• Пара неприятных историй о небольших компаниях-разработчиков: “Is PayPal good for your microISV business?” A short PayPal horror story и Microsoft China rips off Plurk
• Анонс: в конце января будет PyCamp Kyiv, ищем докладчиков.

(Как и Макс, я получил эту книгу в подарок от издательства, и обещал написать рецензию на нее. Не обязательно хорошую, но честную. Очень рад, что мне не пришлось стоять перед таким выбором, книга мне понравилась.)

Боб Волш в прошлом программист с огромным опытом, а теперь автор нескольких книг и консультант в области стартапостроения.  Его предыдущие книги касаются двух направлений – социальных медиа и идее micro ISV – то есть, «компаний», состоящих из одного человека, программиста. Не знаю, как насчет социальных медиа, но идея micro ISV для Боба явно выстрадана и проверена личным опытом. И да – нет, Боб не является автором нескольких удачных стартапов, хотя опыт у него крайне богат, но это тот прекрасный пример, когда даже очень умный и талантливый человек вовсе не обязательно добивается мгновенного успеха в стартапе. Впрочем, он продолжает пытаться – посмотрите на его проект startuptodo.com (говорят, в золотую лихорадку больше всех заработали продавцы лопат).

Уверен, многие программисты так или иначе задумывались об идее micro ISV (только, конечно, не называли ее так). Идея довольно простая: что же это я пишу-пишу, а миллионы на моем коде зарабатывает кто-то другой? Или, например, так: что за дурацкие задания мне дают, кто так пишет софт! Я сам гораздо лучше понимаю, как его писать, не вырваться ли мне из-под гнета «дяди», который ничего не понимает в толковом софте?  Боб Волш прошел этот путь, набил свои шишки, натер свои мозоли, получил свои уроки, и пообщался с целой кучей умных людей на эту тему. И он написал об этом книгу!

То, чего, как правило, не видят программисты, это огромный мир бизнеса, в котором не так уж важно, какой именно продукт ты делаешь. Очень быстро оказывается, что блестящий код и смелые решения – это только часть, и далеко не самая большая. Что продажи и маркетинг, пожалуй, важнее интерфейса и отсутствия багов. Что для победы в конкурсе красоты мало быть красивым – нужно еще и принять участие в конкурсе красоты. Как же быть? Один из вариантов – найти себе партнера, который сможет выполнить эти функции, и тогда, вдвоем, или втроем, вы сможете быть сильной командой, имеющей таланты по всем важным для молодой компании направлениям. Второй вариант, micro ISV – стать специалистом и в остальных, недостающих областях. Почему бы одному человеку не быть и программистом, и маркетологом, и продавцом, и многими другими виртуальными работниками в своей компании-одного-человека? Конечно же, Боб Волш не знает, что такое ведение бухгалтерии и налогового учета в Украине, поэтому считает, что все это возможно совместить в одном талантливом человеке.

Что вы найдете в этой книге? Ни слова о программировании, вы сами решите какой продукт и как создавать. Гораздо важнее понимать ценность вашего продукта, а это не так уж очевидно. Если вы делаете стартап, micro ISV, назовите как вам удобно – вы начинаете игру в деньги. Их надо заработать, и тот, кто делает это лучше, вовсе не обязательно лучше программирует. Он лучше понимает, кто их заплатит и почему. Он лучше знает, как найти потребность и удовлетворить ее. Как говорить со своими клиентами, и, хотя бы, дать им знать, что продукт существует.  Как найти деньги в тот момент, когда они нужны. Как быть очень-очень продуктивным, ведь успех дается только упорным и кропотливым трудом. Почему инвесторы делают инвестиции, и кому они их не дадут.

В книге не только размышления Боба на эти темы, в ней также множество интервью с теми, кто преуспел в этом. Не все имена известны в наших широтах, но Гай Кавасаки и Джоел Спольски одобряют и дают интервью этому человеку. Это не то, чтобы гарантия качества, но все-таки – авторитеты, что называется, тянут мазу. Отдельно я хочу упомянуть выдающуюся подборку эпиграфов к каждой главе – это очень емкие и интересные цитаты.

Я считаю, что каждый программист, который больше трех раз думал о том, чтобы сделать что-нибудь эдакое, стартапчик там, или еще какой замут, мог бы потратить двадцать баксов и пару дней, чтобы прочитать эту книгу, стать умнее, и, возможно, никогда больше не думать об этом. Или продолжать думать,  но уже гораздо более трезво. Это гораздо дешевле и быстрее, чем набивать все те же шишки самостоятельно. Неспроста самая первая фраза на обложке гласит: from developer to founder.  И, конечно, не стоит забывать, что самые смелые и громкие проекты сделаны скорее вопреки, чем благодаря книгам, учебникам и наставлениям. Для чего их, разумеется, надо прочитать.

Знание – сила!

Алексей Колупаев,

kolupaev.com