воскресенье, 30 ноября 2008 г.

Тестирование при помощи JUnit и Spring-Tests

При разработке веб-приложений с помощью связки Spring+Hibernate тестирование становится достаточно нетривиальной задачей, если подходить к ней в лоб. В процессе запуска теста необходимо выполнить следующие шаги: поднять контекст Spring'a, произвести необходимые dependency-injection, обеспечить открытую сессию Hibernate на протяжении выполнения теста (в веб-приложениях эту работу выполняет OpenSessionInViewFilter, который держит сессию открытой на период обслуживания запроса пользователя). Рассмотрим как это сделать на примере использования распространенного фреймворка для тестирования JUnit версии 4.4 (более новая версия 4.5 имеет проблемы совместимости со Spring) и модуля Spring-tests из SpringModules (spring-test.jar). Класс простейшего теста приведен ниже:

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = { "classpath:spring-config.xml" })
public class MessageServiceTest {

private MessageStringDataServiceInterface messageStringDataService;
private DefaultWebConfig defaultWebConfig;
private SessionFactory sessionFactory;

@Autowired
public void setDefaultWebConfig(DefaultWebConfig defaultWebConfig) {
this.defaultWebConfig = defaultWebConfig;
}

@Autowired
public void setMessageStringDataService(
MessageStringDataServiceInterface messageStringDataService) {
this.messageStringDataService = messageStringDataService;
}

@Autowired
public void setSessionFactory(SessionFactory sessionFactory) {
this.sessionFactory = sessionFactory;
}

@Test
public void onSetUp() {
TransactionSynchronizationManager.bindResource(sessionFactory,
new SessionHolder(sessionFactory.openSession()));
}

@Test
public void testMessageDataService() throws DomainException {
assertNull(messageStringDataService.getMessageString("test.message",
defaultWebConfig.getDefaultLanguage()));
}

@Test
public void onTearDown() {
TransactionSynchronizationManager
.unbindResourceIfPossible(sessionFactory);
}
}
Для того, чтобы при запуске теста поднимался контекст Spring'a необходимо аннотировать класс при помощи следующих аннотаций:
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = { "classpath:spring-config.xml" })
Первая из них сообщает Spring'у, что надо использовать специальный wrapper для запуска этого теста в JUnit, а вторая указывает имя конфигурационного файла контекста. Все конфигурационные файлы, на которые есть ссылки в конфиге контекста должны находиться также в classpath для корректного запуска теста. После этого можно устанавливать все зависимости при помощи аннотации @Autowired. Аннотация @Test относится к JUnit и ей маркируются собственно методы для тестирования. Выполняются они в порядке следования в коде, поэтому методы onSetUp() и onTearDown() будут выполнены соответственно в первую и в последнюю очередь. Это мы и используем для демаркации сессии при помощи менеджера транзакций Spring. Примерно так же работает и OpenSessionInViewFilter, который при старте обработки запроса пользователя открывает сессию и затем привязывает ее к сессии, а при окончании обработки запроса - освобождает ресурс. Два вышеописанных метода выполняют аналогичную функцию. На этом интеграционную часть можно считать раскрытой, а по новым возможностям JUnit рекомендую краткий обзор с примерами.

среда, 26 ноября 2008 г.

Hibernate и танцы с бубном

Иногда возникают такие ситуации, когда программа на ровном месте не работает, причем потом причина оказывается более чем прозаической. Так было и сейчас - никак не мог понять, почему не генерится таблица в БД при старте приложения (есть у Хибернейта такая милая возможность - создавать все таблицы при старте). Все остальные - преспокойно, а одна никак не хочет. После получаса шаманских плясок у ноутбука оказалось, что не нравится Хибернейту поле (и колонка в аннотации) с именем "key".  Естесственно это зарезервированное ключевое слово в MySQL, поэтому использовать его как имя колонки никак  нельзя, но создавая классы доменной модели, об этом как-то забываешь, а Хибернейт не считает нужным перенаправить в лог ошибку сервера.  Так что мораль сей басни - товарищи, будьте бдительны! :))

Современная украинская литература

Я вообще стараюсь не постить политические сообщения, потому как маразм, именуемый у нас в стране политикой, достал до крайности. Но тут на днях наткнулся так сказать... на новые тенденции в родном образовании. Как - вы еще не знаете, что такое патриотическое воспитание в наших школах?! Теперь в моде изучение в школах Украины альтернативной Красной Шапочки (украинский римейк), которая курит, бухает, отнимает у бабушки пенсию, но при этом поет песенки... конечно же на русском языке.  Смотрим сканы и телерепортаж на тему. Как бы без комментариев, особенно учитывая гордую надпись "Рекомендовано министерством образования" на обложке. По-моему четко показывает уровень развития наших министров, о каком еще выходе из экономического кризиса может идти речь... про так называемую творческую интеллигенцию, пишущее такое, как бы и говорить не хочется.

понедельник, 24 ноября 2008 г.

Что в планах

Собираюсь написать что-нибудь на тему асинхронного взаимодействия и best-practices на тему организации обмена сообщениями в enterprise приложениях, BASE vs ACID транзакциях и что по этому поводу говорят в научных работах на Западе. Так же хочу сделать пару постов на тему Apache SOLR (поисковый движок, очень серьезный) и что-нибудь на тему Spring (вчера вот наткнулся на валидацию бинов посредством аннотаций, понравилось)..

вторник, 18 ноября 2008 г.

Под Невелем найден "Як-7" времен войны


В Невельском районе Псковской области найден самолет "Як-7" времен Великой Отечественной войны, сообщает во вторник агентство "Интерфакс". 

В истребителе, который был сбит 5 ноября 1943 года, обнаружены останки пилота, младшего лейтенанта Николая Пискулова. Его личность поисковики группы "Рубеж" установили по комсомольскому билету. 

Пискулов будет похоронен в Hевеле. Планируется организовать поиск его родственников. Обломки самолета разместят в Музее боевой славы, который будет открыт в Псковской области к 65-летию Победы. 

"Як-7" был найден в том месте, в котором члены "Рубежа" расчитывали найти другой самолет - "Як-1". Этот самолет, по некоторым данным, пропал в районе поисков 10 ноября 1943 года. Им управлял младший лейтенант Василий Попов. Поиски "Як-1" будут продолжены.

http://lenta.ru/news/2008/11/18/remains/

О Маккейне и русских зенитчиках

"Он ненавидел русских"
Советский ветеран рассказал, как он сбил самолет Маккейна…

Американский летчик Джон МаккейнСоветский ветеран, подполковник в отставке Юрий Трушечкин, принимавший участие во вьетнамской войне, признался, что это именно он в 1967 году сбил самолет, в котором находился кандидат в президенты США Джон Маккейн, сообщает Newsru.com. Как рассказал ветеран, которого журналисты разыскали в 442-м госпитале на Суворовском проспекте в Санкт-Петербурге, он до сих пор ни о чем не жалеет и продолжает ненавидеть этого человека. 

Подполковник Трушечкин радуется, что Маккейну не удалось войти победителем в Белый дом. "К счастью, он не стал президентом. Он ненавидел русских. Он знал, что его самолет сбила наша ракета", – говорит ветеран. Несмотря на то, что до последнего времени русские не признавались, что принимали участие в военной кампании, 70-летний Трушечкин убежден, что скрывать, а тем более стыдиться ему нечего. Он рассказал, что попал во Вьетнам, будучи 28-летним капитаном, в то время, когда там уже были смешанные подразделения с вьетнамцами. Служил офицером наведения в ракетном расчете. День, в который был сбит самолет Маккейна, ветеран помнит хорошо. Капитан Трушечкин вместе с другими военными менял позицию ракетной установки, которая должна была прикрыть от американцев стратегический мост Хам Жонг. Военные уже уезжали, когда услышали сигнал воздушной тревоги и увидели, как подлетают два Phantom F-4. По цели были выпущены две оставшихся ракеты – остальные четыре были расстреляны раньше. Одна из оставшихся двух ракет из-за плохой наводки взорвалась в джунглях, а второй – был сбит самолет. "Один самолет огибал холмы, а другой – пошел прямо через мост. В него мы и стреляли", – говорит Трушечкин, который был офицером наведения. Летчик, которым, по словам Трушечина, и был Джон Маккейн, катапультировался, и его взяли в плен вьетнамские солдаты. Как считает ветеран, Маккейну повезло. Правда его отправили в страшную тюрьму, которую с сарказмом называли Hanoi Hilton. "Самыми ценными трофеями считались летный шлем и "флаг нищего" – нашивка с надписью: "Я американский гражданин, терплю бедствие, прошу оказать мне помощь" – на пяти языках, – говорит Юрий Петрович. – А в парашютной сумке нашли "корочку" серую. Это парашютная книжка оказалась. Я переводчика попросил посмотреть, что там написано. Помню слова: "Джон Маккейн". Парашют ему за день до этого собрали…" 

Кандидат в президенты США от республиканской партии сенатор Джон МаккейнВетеран узнал пилота, когда увидел в телерепортаже о кандидате в президенты США кадры, на которых сенатор от Аризоны был еще молодым военным летчиком. Он не испытал никакого энтузиазма, когда узнал его. "Тюремные охранники говорили, что он ненавидел русских. Если бы он стал президентом США, отношения между Россией и Америкой, несомненно, стали бы хуже", – убежден ветеран. 

Как сообщают американские источники, 6 октября 1967 года Маккейн в составе эскадрильи из 20 самолетов вылетел на бомбардировку и был сбит. Летчик катапультировался и приземлился в озеро, он сломал обе руки и ногу и был жестоко избит вьетнамскими солдатами. На допросе он, в соответствии с американским военным уставом, назвал только краткие сведения о себе, по фамилии вьетнамцы установили, что они взяли в плен сына высокопоставленного американского офицера. Всего Маккейн провел в плену пять с половиной лет – 1967 дней – и был освобожден 15 марта 1973 года после подписания Парижских мирных соглашений между США и Вьетнамом.

воскресенье, 16 ноября 2008 г.

О Saitekе и Ил-2

Приобрел всего за 300$ полный комплект - Saitek X-52 и педали этой же марки. Надо сказать, с педалями летать намного интереснее, конечно, привыкнуть к ним также необходимо. Жалко, что огромная разница во времени обламывает полеты онлайн на российских и украинских серверах, нормально получается только днем на выходных - тогда на серверах вечер и полный аншлаг. Пока не нашел нормальных площадок в своей временной зоне :( По большей части летаю в офлайне, с ботами. 
Сама матчасть нравится, несмотря на множественные о ней негативные отзовы, в т.ч. о пресловутой нелинейности. Если раньше половину косяков в полете можно смело было списывать на джой, то теперь виноваты только мои пока еще недостаточно прямые руки :)  С учетом бесконтактных датчиков надеюсь, что прослужит сие приобретение хотя бы год-полтора.

О масштабируемости систем(ч.3)

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

Но если организовать взаимодействие между ними посредством асинхронных вызовов и организовать взаимодействие, напрмер, через очередь, то масштабировать их можно будет уже независимо друг от друга. Более того, теперь у них будут независимые характеристики доступности - отказ одного из них вовсе не будет означать отказ другого, поскольку такого тесного взаимодействия, как при синхронных вызовах, у них больше нет.

Такой подход имеет отражение в некоторых научных работах, в частности SEDA(Stage Event-Driven Architecture for highly concurrent server applications). 

Из этого следует, что как можно большую часть бизнес-процессов следует реализовывать именно асинхронным образом, поскольку в системах, где время реакции ситсемы на запрос критично, это может существенно снизить время ответа системы. Например, в e-commerce системах время получения ответа пользователем намного важнее, чем время, за которое время запрос будет реально обработан системой. Это позволит пользователю не терять время на ожидание ответа системы, а заняться другими делами, в то время как его запрос будет поставлен в очередь на обслуживание и обработан. В подобных системах нужно придерживаться принципа - "все, что может подождать - должно подождать".

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

Создание необходимых уровней абстракции
Не буду подробно на этом останавливаться, и так понятно, что все функциональные слои должны иметь свои уровни абстракции - то есть например, работа с БД должна производиться при помощи ORM или иного интерфейса, который возьмет на себя все функции по взаимодействию с БД, распределению нагрузки между серверами БД(в случае распределенных серверов БД, какие были описаны выше) и т.д. Абстрагирование резко упростит жизнь при последующем масштабировании системы, поскольку будет отсутствовать жесткая привязка к конкретным типам системных ресурсов, а так же можно на соответсвующем уровне абстракции организовать управление физическими ресурсами.

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

Вообще, эффективность кэширования определяется как максимальное cache hit ratio при ограничениях на объем кэшируемой информации, ее доступность и определенным уровнем толерантности к неактуальной информации.

Чаще всего кэшируются по большей части read-only или редко модифицируемые данные, такие как: метаданные, конфиги, словари и т.д. Гораздо более сложными в плане кэширования являются часто обновляемые и часто читаемые данные, поэтому следует хорошо подумать, прежде чем их кэшировать.

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

На днях наткнулся на интересную white-paper, в ней описывается, как снизить нагрузку на сервер БД при использовании Hibernate. Используется технология под названием Terracotta, достаточно известная в настоящее время.

среда, 12 ноября 2008 г.

О масштабируемости систем(ч.2)

Отказ от распределенных транзакций
В связи с двумя предыдущими пунктами сразу приходит на ум мысль - как в условии функциональной декомпозиции и горизонтального разбиения будет обеспечиваться поодержка транзакций, ведь практически любая операция влечет за собой изменение более чем одной сущности. Стандартный ответ подразумевает создание распределенной транзакции, которая включает в себя все модифицируемые ресурсы и использование two-phase commit для того, чтобы быть уверенным в том, что транзакция прошла успешно, либо же была отменена для всех вовлеченных в нее сущностей. Однако, у всего есть своя цена, и подобный подход резко ухудшает масштабируемость, производительность и увеличивает время ожидания. Также ограничивается и доступность системы - ведь при создании распределенной транзакции все вовлеченные в нее ресурсы должны быть свободны. Это может привести к тому, что при увеличении нагрузки на систему и росте ресурсов, вовлеченных в распределенные транзакции, система перестанет справляться с обслуживанием клиентов. 

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

Около 10 лет назад профессор Eric Brewer сформулировал CAP-теорему, согласно которой, среди трех требуемых характеристик распределенной системы: consistency(C), availability(A) и performance(P) одновременно можно выбрать только 2 варианта. Для 24x7 доступной веб-системы, работающей под большой пользовательской нагрузкой придетсся выбрать 2 последние, иначе система не сможет выполнять свое предназначение. Следовательно, consistency придется пожертвовать.

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

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

понедельник, 10 ноября 2008 г.

GoogleMaps и русские ракеты

Расположение шахт российских МБР с точностью до 50 метров. Масштаб впечатляет, данные вряд ли старее 2х лет.

О масштабируемости систем(ч.1)

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

Система считается масштабируемой, если ее производительность растет как минимум линейно в зависимости от увеличения производительности аппаратной части (увеличили количество серверов вдвое - производительность как минимум вдвое выросла). Чтобы добиться таких показателей, необходимо закладывать определенные архитектурные решения в проект с самого начала. Неправильно спроектированную систему в будущем будет крайне трудно, а то и просто невозможно масштабировать. Рассмотрим основные best-practices, которые мне известны на текущий момент.

Разделение фунциональности
В соответствии с этим необходимо строить систему исходя из того, что отдельные независимые функции системы должны быть автономны друг от друга  и не иметь между собой связей. Подобный принцип реализуется, например, в SOA, и еще именуется принципом функциональной декомпозиции. Это позволит разместить соответствующие части системы на автономные друг от друга группы серверов(например, поиск будет на одном сервере, обслуживание заказов - на другом и т.д.) и регулировать их мощность так же можно будет независимо в зависимости от нагрузки на тот или иной сегмент. Так же это позволит оптимизировать зависимость системы от внешних ресурсов - каждый пул серверов будет иметь доступ только к необходимым для работы ресурсам.
Подобному принципу так же желательно следовать и на уровне БД - распределенные вычислительные мощности будут гораздо лучше себя чувствовать, работая не с одним сервером БД,  а с определенным их множеством. Из этого следует, что одной большой схемы БД не будет - на разных пулах серверов БД будут хоститься только те таблицы, которые нужны для обеспечения работы соответствующего пула серверов приложений, которые имеют к ним доступ. То есть каталог для поисковой подсистемы будет размещен на одном сервере БД, а данные по поставкам или заказам - на другом, в соответствии с функциональным разделением на уровне сервреров приложений.

Горизонтальное разбиение функциональности
Функциональная декомпозиция позволяет достичь определенного прогресса в масштабируемости, однако это далеко не все. Мы должны также иметь возможность разделять общую входящую нагрузку на функциональный блок системы и иметь возможность сбалансированно ее распределять между серверами пула. Для этого можно использовать стандартный load-balancer на уровне серверов приложений, который распределит нагрузку более-менее равномерно. Подразумевается, что каждый экземпляр сервера приложений содержит идентичную и автономную от других функциональность, так что можно просто увеличивать их количество в случае возросшей нагрузки. На уровне БД все обстоит несколько сложнее. Тут необходимо организовывать данные как т.н. "осколки" (shards). Это значит, что например, данные по пользователям равномерно распределены между N серверами БД, аждый из которых хранит свою часть. При этом есть механизм, который автоматически определяет, к какому серверу необходимо обратиться, чтобы получить нужные данные. Естесственно для сервреров приложений это должно быть совершенно прозрачно и они должны быть абстрагированы от деталей реализации. Есть специальные стратегии построения БД для такой конфигурации серверов, как правило, особым образом формируется первичный ключ таблицы, который идентифицирует, на каком сервере будет храниться запись. Хотя наверняка есть и другие варианты, я пока этим вопросом глубоко не занимался.

воскресенье, 9 ноября 2008 г.

Радиоперехват переговоров корабля ВМС США "Mount Whitney" и украинской службы береговой охраны. Комментарии излишни, искренний респект ребятам! :)
.

пятница, 7 ноября 2008 г.

Полезные фреймворки и технологии

Раз уж пока руки не доходят написать за жизнь в Канаде, напишу про джаву :) Узнал парочку весьма полезных в корпоративных проектах фреймворков. Сначала то, что мне, как аналитику по образованию точно бы крайне понравилось. Называется технология OpenRules и предназначена для описания бизнес-правил. Как известно, в реальной жизни редко когда (да практически никогда) бизнес-процессы компании остаются неизменными, так как зачастую зависят от большого количества внешних факторов. Соответственно, если логику зашивать в джава-код, то через достаточно небольшой промежуток времени проблема поддержки приложения станет достаточно остро, т.к. заказчик естесственно захочет иметь автоматизацию своих актуальных бизнес-процессов на текущий момент. Соответственно, нужно будет привлекать как бизнес-аналитика(либо кому-то выполнять его функции), так и разработчиков. Использование же данной технологии позволит все модификации бизнес-правил возложить только на аналитика. И никакой модификации существующего кода! :) Как не трудно догадаться, это происходит потому что бизнес-правила не кодируются, а выносятся на конфигурационный уровень, где их потом можно смело менять и не трогать код. А если точнее - то OpenRules реализует связку Java+MS Excel, где сами правила описываются в интуитивно понятной форме в Excel файле, а потом при помощи движка интегрируются в саму систему. Конечно, есть и техническая часть, но она в большинстве случаев реализуется единожды - при начальном создании набора правил, когда аналитик и разработчик наверняка будут работать в паре. В дальнейшем аналитик как правило будет работать только со своей частью, но конечно при кардинальном изменении требований может обратиться за помощью к tech-guys. Если конечно не осилит внести необходимые изменения самостоятельно. В общем все ясно из картинки:



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

И еще один, не столь глобальный, но очень полезный фреймворк - Dozer. Он умеет.. мапить POJO на POJO :) Может возникнуть вопрос - а на.. зачем это надо? Все просто - эта фича очень плоезна при построении DTO, особенно если DTO содержит в себе информацию из нескольких классов. Написание методов для получения таких объектов вручную лично меня всегда крайне напрягало, поскольку это тупая и обезьянья работа. А при использовании этого фреймворка можно обойтись парой строк вместо пары десятков (сама библиотека достаточно умная и при использовании определенных соглашений количество необходимых телодвижений для получения DTO сводится к минимуму). За что он мне и нравится. Детали - как всегда на сайте производителя :)

воскресенье, 2 ноября 2008 г.

Фотографии из Ванкувера

Доступны в моей страничке ВКонтакта[http://vkontakte.ru/id3522353], на данный момент уже более 25 :) Выкладывать буду там, альбом называется "Maple Country". Тут думаю в скором времени писать собственно заметки, только текст. Все картинки в вышеназванном альбоме.