Xоккей

Сегодня мне внезапно дали лишний билетик на хоккей :) Будут играть Vancouver Canucks и Philadelphia Flyers, матч в 19-00 at General Motors Place. Никогда не был на хоккее, должно быть весело :))

Три правила

Неоднократно последнее время думал, что называется, "за жизнь". И вот попалась вот такая вот любопытная статейка, которая практически один-в-один отражает мои размышлизмы. Полезно не только ИТ-шникам, хоть писано одним из них и для них же. Продолжая эту тему, уже давно думаю над вопросом - а что бы такого оригинального можно было сделать (сайт, например, или сервис), чтоб и полезно было (как себе в плане опыта, так и людям требовалось), и не слишком большой объем работы требовался (исходя из того, что работать придется в одиночку, ибо мало кто из хороших программистов сейчас согласится тратить свое время для написания чего-то just for fun)? Хорошие мысли в голову приходили, но они как правило требовали больших трудозатрат, в одиночку это бы затянулось на годы... Все-таки очень неплохо быть специалистом еще в какой-нибудь предметной области помимо ИТ, тогда видишь эту область изнутри и подмечаешь те моменты, которые действительно можно автоматизировать и возникают идеи, как и что можно сделать. Тем более, что все типовое и очевидное уже давным-давно реализовано, и требуются действительно оригинальные идеи... А вообще было бы замечательно организовать команду из человек трех-четырех и замутить что-нибудь эдакое.. 

Еще интересный блог

Блог офицера-двухгодичника, который получал специальность ПВО-шника, пошел добровольно в армию на 2 года служить, а попал в мотострельцы в СКВО, в 58-ю армию. Очень познавательно для тех, кто хочет почитать про то, как оно в армии на самом деле. По ходу блога видно, как меняется человек, как меняется его стиль изложения. Только отмотать надо на самое начало, там за 2+ года постов накопилось немало.

Юмор

Интересно, что это за девайс и как он собирается ездить (и тем более стрелять) при такой высоте? :)) Кажется, тема боевых человекоподобных роботов в России набирает обороты :))

Происхождение медведа

Вот оказывается, "с чего есть пошел" легендарный Русский Превед-Медвед!
С войны еще... Это эмблема 36й гвардейской танковой бригады, входившей в состав 4го гвардейского механизированного корпуса :)))

Политические шахматы

Немного позитива среди стаи полярных лисиц))

Украина в картинках

Нормальные финансовые эксперты (а не эти из нашего нацбанка) прогнозируют к весне дефолт и обвал до 20-30 гривен за доллар... welcome back to 1990s

Spring Security - kick start

Отличная статья для тех, кто хочет максимально быстро разобраться в интеграции этой технологии в свой проект. Помимо собственно интеграции, также рассматривается модификация стандартной схемы БД для jdbc-user-service, что позволит изменить дефолтную схему по своему усмотрению. На мой взгляд, намного информативнее и полезнее аналогичного примера с сайта Spring.

http://www.mularien.com/blog/2008/07/07/5-minute-guide-to-spring-security

Spring tricks (несколько propertyConfigurer)

Иногда может возникнуть необходимость использовать несколько разных бинов для чтения конфигурации из properties, но если просто объявить их несколько штук, то работать ничего не будет - вылетит эксепшн типа "Could not resolve placeholder 'xxx.yyy". Чтобы все нормально заработало, необходимо переопределить префикс и суффикс, которые используются для обращения к подгруженным properties -  ${xxx.yyy} (выделено красным). Это делается для каждого добавленного 

org.springframework.beans.factory.config.PropertyPlaceholderConfigurer бина (для того, что имеет по умолчанию name="propertyConfigurer" не надо), причем все они должны быть уникальны. Это делается так:

<bean id="propertyAnotherConfigurer" 
 class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="locations">
 <list>
  <value>classpath:another.properties</value>
 </list>
</property>
<property name="placeholderPrefix" value="#{"/>
<property name="placeholderSuffix" value="}"/>
</bean>

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

Как выполнить sql скрипт из java-программы (mysql)

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

Тестирование при помощи 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 рекомендую краткий обзор с примерами.

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

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

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

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

Что в планах

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

Под Невелем найден "Як-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 года после подписания Парижских мирных соглашений между США и Вьетнамом.

http://www.rusk.ru/newsdata.php?idar=729205

О 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, достаточно известная в настоящее время.

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

Отказ от распределенных транзакций

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

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

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

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

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

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

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

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

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

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

Разделение фунциональности

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

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

Горизонтальное разбиение функциональности

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

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

.

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

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

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

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

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

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

Вылет

Ну вот и все, все документы оформлены, билеты получены, завтра вылетаю в Канаду. Пересадка в Амстердаме, оттуда прямой рейс до Ванкувера. Это будет первый Новый Год, который я встречу за границей :)

Отличные фотки

militaryphotos.net(c)

Большое американское шоу

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

http://www.americanshow.ru/

В Днепропетровске "воин света" гонялся за милиционерами на тракторе

В Днепропетровске тракторист называл себя "воином света" и угрожал милиционерам. Как позже выяснило следствие, перед этим он выкурил три сигареты с наркотическим веществом. 

Инцидент произошел во вторник, 8 октября в 4:00. Охранник автосалона в Днепропетровске обратился в милицию, сообщив, что на стоянку автомобилей заехал тракторист и стал бегать между машинами, размахивая ножом и выкрикивая  нечто, похожее на заклинания.

На автостоянку был направлен ближайший экипаж ГАИ. Заметив их автомобиль, хулиган поспешил скрыться на своем тракторе марки JCB. Началось преследование. Однако через некоторое время тракторист развернул свою машину на 180 градусов и опустил ковш, после чего скрываться от преследования вынуждены были инспекторы ГАИ.

С переменным успехом обеих сторон погоня продолжалась около 10 минут. Тракторист периодически выкрикивал из окна, что милиционеры - воины тьмы и демоны. Те, в свою очередь, вызвали на подмогу сотрудников Красногвардейского РОВД. Те прибыли на место происшествия на автомобиле УАЗ. Однако к тому времени трактор, врезавшись в ворота комбайнового завода, заглох.

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

На допросе мужчина назвался именем персонажа Золотого теленка - Адамом Казимировичем Козлевичем.

Арестованный заверил милиционеров, что он не употреблял алкоголь. Вместо этого он курил "дурь, примерно три папиросы". Он упомянул, что покупает наркотик у "Ваньки из Перепещино".

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

Мужчина рассказал, что ранее четыре года провел в тюрьме. "А то, кто не сидел, то типа и не мужик!", - также отметил он.

Теперь нарушителю общественного порядка грозит лишение свободы по обвинению в злостном хулиганстве и нападении на правоохранителей при исполнении теми служебных обязанностей. "На все есть воля свыше!" - прокомментировал это задержанный.

http://korrespondent.net/strange/613765

Кокпит Су-35 БМ

В настоящее время этот самолет является переходным звеном перед поступлением в войска истребителя 5го поколения Т-50. В его конструкции используются многие элементы, которые будут присущи Т-50, такие, как оснащение кабины, например.

Блог генерала-танкиста

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

http://vim152.livejournal.com

Сайт правительства Украины для детей

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

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

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

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

Наверное, это из-за верстки. Она заслуживает твердой "двойки". Там, где дело касается шрифтов, оформления структуры страниц, компоновки - все плохо. Особенно мне не ясно, на кой было запихивать каталог с иконками подразделений кабмина в iframe?! Может, поэтому и иконки пришлось ужимать до такого размера? Ну и совершенно феерический бред - делать ссылки на главные разделы (страничка по кнопке "Мiй уряд") картинками!.. Кстати, это не единственное место, где используется это "гениальное" решение. 

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

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

http://children.kmu.gov.ua/

Боевая машина поддержки танков(Об. 199 "Рамка")

Финансовый кризис для чайников (в картинках)

Доходчиво и с юмором объясняется, как это все было организовано. Рекомендую :)) (при открытии первой страницы сверху есть ссылка "Следующая", для просмотра нажимать там)

http://superinvestor.ru/sub/

Америка! Тебе есть чего бояться

Весьма занимательная статья. Поклонникам американской демократии - к прочтению обязательно. Не думал, что у них все НАСТОЛЬКО далеко зашло. 

http://www.warandpeace.ru/ru/exclusive/view/28244/

"Возвращение Ганса/Hansu no Kikan"

Редко встретишь мангу, где хорошо отрисована классическая военная техника, и вот сегодня наткнулся на сие произведение. Манга была нарисована Хаяо Миядзаки в 1994 году для журнала стендового моделизма по мотивам мемуаров немецких военных. Действо происходит в конце войны, когда немецкая армия вовсю сдается в плен, а на территории Германии хозяйничают русские и американцы. Главные герои (немцы и русские) изображены как свиньи, потому что автор очень любит свиней и всюду их старается нарисовать(Миядзаки и себя рисует как свинью), а вот американцев он не любит, поэтому они такие, какие есть(тупые обезьяны). В общем, мне понравилось, кто в теме - рекомендую :)

http://mangaproject.ru/cgi-bin/viewer/picpost.pl?num_pic=0&dir=Singles/Hans

Возврат нескольких значений из метода

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

Для каждого кортежа значений создается специальный типизированный класс:

public class TwoTuple {

    public final A first;

    public final B second;

    public TwoTuple(A first, B second) {

        this.first = first;

        this.second = second;

    }

}

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

...

TwoTuple rslt = new TwoTuple(1L, "example");

return rslt;

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

Жизнь, как она есть

Анекдот

Идут стрельбы. Дали автоматы, патроны, показали куда стрелять.
Админ отстрелялся, подводят итоги. Мишень админа чистая.
Командир: - ??????!!!!!..
Админ, проверяя автомат: - С моей стороны пули вылетели. Проблемы у вас.. 

Tarja в Киеве!

Сегодня внезапно! узнал замечательную новость - оказывается, 3.XI в Киеве будет вот такой вот концерт. На фоне отмененного концерта Nightwish в Москве, на который я бы хотел поехать, но все равно возможности не было, это просто замечательно. Сразу же были забронированы 2 билета в 1й зоне(цена удовольствия 350 UAHей за штуку). Несмотря на практически только начавшуюся рекламную кампанию, более 90% мест были уже разобраны. Знающие камрады предупредили, что для того, чтобы пробиться в эту самую первую зону к сцене, нужно прийти где-то за час, протолкаться на свои места и не вылазить, а не то потом это сделать будет весьма проблематично. Будем учитывать это при планировании и надеяться, что меня не отправят в командировку до означенной даты :)

JMX+Spring+Hibernate

Хибернейт поддерживает сбор самой разнообразной информации и метрик, которые могут быть весьма полезны при отладке и разработке. При использовании широко распространенной связки Spring+Hibernate можно очень легко получить доступ к этим данным следующим образом:

1) в конфигурации SessionFactory указываем: 

<property name="hibernate.generate_statistics">true</property>

это включает собственно сбор статистики.

2) регистрируем следующие бины в Spring:

<bean id="jmxExporter" class="org.springframework.jmx.export.MBeanExporter">

        <property name="autodetect" value="false" />

        <property name="assembler">

            <bean id="jmxAssembler"                class="org.springframework.jmx.export.assembler.MetadataMBeanInfoAssembler">

                <property name="attributeSource">

                    <bean               class="org.springframework.jmx.export.annotation.AnnotationJmxAttributeSource" />

                </property>

            </bean>

        </property>

        <property name="beans">

            <map>

                <entry key="org.hibernate:name=statistics">

                    <bean class="org.hibernate.jmx.StatisticsService">

                        <property name="statisticsEnabled" value="true" />

                        <property name="sessionFactory">

                            <ref bean="sessionFactory"/>

                        </property>

                    </bean>

                </entry>

            </map>

        </property>

    </bean>

Этот бин предоставляется нам Spring'ом и делает всю работу по экспорту статистики посредством JMX и сам выполняет все необходимые действия, нам нужно только передать ему нашу SessionFactory(выделено жирным).

3) В Томкате добавляем следующие параметры JVM:

-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=8004 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false

Здесь важен порт - туда мы будем коннектиться JConsole'ю, которая и отобразит всю статистику.

4) Запустив Томкат и убедившись, что ошибок и эксепшенов нет, идем в JAVA_HOME/bin и запускаем отттуда jconsole.exe. Когда поднимется форма, идем на вкладку Remote (удаленные соединения с JMX-сервером) и указываем host(Томката) и port(8004 в нашем случае). После успешного соединения можно смотреть самую разнообразную статистику по JVM вообще и Hibernate в частности.

JDBC Logging Driver

В процессе девелопмента часто бывает необходимо посмотреть, какие запросы выполняются, причем обычное логирование помогает мало - вместо реальных параметров, используемых в SQL, стоят малоинформативные знаки вопроса. Чтобы это обойти и все-таки увидеть те запросы, которые реально исполняются, можно использовать сабж. Скачать его можно по адресу  www.rkbloom.net/logdriver

Конфигурировать его достаточно просто, на примере это выглядит так: 

hibernate.connection.driver_class=net.rkbloom.logdriver.LogDriver
#hibernate.connection.driver_class=oracle.jdbc.OracleDriver
hibernate.connection.url=jdbc:log:oracle.jdbc.OracleDriver:oracle:thin:@192.168.32.29:1521:UTF8
#hibernate.connection.url=jdbc:oracle:thin:@192.168.32.29:1521:UTF8

жирным выделено подклюение логирующего драйвера, нежирным - типовое подключение к JDBC.

Также необходимо сконфигурировать log4j примерно следующим образом:

## Hibernate logging

log4j.appender.HibernateAppender=org.apache.log4j.FileAppender

log4j.appender.HibernateAppender.file=D:/temp/hibernate.log

log4j.appender.HibernateAppender.layout=org.apache.log4j.PatternLayout

log4j.appender.HibernateAppender.layout.ConversionPattern=[%d] %-5p - %m%n

log4j.additivity.org.hibernate=true

log4j.additivity.net.rkbloom.logdriver=true

# Turn this up to DEBUG to get detailed logging info

log4j.logger.org.hibernate.SQL=info,HibernateAppender

log4j.logger.org.hibernate=info,HibernateAppender

log4j.logger.net.rkbloom.logdriver.LogPreparedStatement=DEBUG,HibernateAppender

log4j.logger.net.rkbloom.logdriver.LogStatement=DEBUG,HibernateAppender

log4j.logger.net.rkbloom.logdriver.LogCallableStatement=DEBUG,HibernateAppender

log4j.logger.net.rkbloom.logdriver.LogConnection=DEBUG,HibernateAppender

Переезжаем с "записок" ВКонтакта

Оказывается, мои заметки в контактах все-таки оказались кому-то полезны. Но так как читать (и писать кстати тоже) их там не то чтобы очень удобно, было принято решение завести уютненькую жежешечку, что и было сделано. В ближайшие сутки-двое перенесу сюда всю полезную информацию из контакта и отныне писать всякую полезную и не очень информацию буду здесь. Добро пожаловать :)