Валидация по схеме в Jaxb2Marshaller

Для маршаллинга soap-объектов используем org.springframework.oxm.jaxb.Jaxb2Marshaller - удобный и быстрый.

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

Установка maven 3

Как установить maven 3 на компьютер: простой чек-лист.

Снятие блокировки в oracle

В посте http://itech-notes.blogspot.com/2013/07/select-for-update.html был рассказ о работе с конструкцией select for update в oracle. И был там такой текст: "если ... обнаруживается, что на какой-то строке уже имеется лок от другой сессии, то текущая сессия будет ожидать - бесконечно! - пока лок не будет снят, и только после этого продолжит выполнение".

Интересный вопрос - собственно, а как и когда снимается лок (т. е. блокировка)?

Design patterns GoF от luxoft-training

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

А о том, что есть в учебном центре luxoft-training такой курс - Шаблоны проектирования (Gang of Four). Вот об этом курсе и своих впечатлениях от посещения оного и пойдёт пост.

liquibase + spring

Для удобства интеграции с spring-фреймоворком есть специальная оболочка liquibase.integration.spring.SpringLiquibase (с версии 3.0.5).

Пример бина:

    <bean id="liquibase" class="liquibase.integration.spring.SpringLiquibase">
        <property name="dataSource" ref="dataSource"/>
        <property name="changeLog" value="classpath:changelog.xml"/>
        <property name="contexts" value="test, production"/>
    </bean>

При старте конфигурации с таким бином liquibase-скрипт будет автоматически загружен из changelog.xml, а затем применён к хранилищу javax.sql.DataSource dataSource.
 

Опциональные параметры можно посмотреть в javadoc'е (http://www.liquibase.org/javadoc/liquibase/integration/spring/SpringLiquibase.html).

Конструкция select for update

Есть такие примечательные sql-конструкции:

• oracle: select ... from table where ... for update
• ms sql server: select ... from table with (updlock, rowlock) where ...

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

Вероятно, отличия между ними есть. Однако, после столкновения "здесь и сейчас" именно с oracle-вариантом, дальнейшее описание будет посвящено этой конструкции - select for update.

Быстрая набивка тестовой таблицы в oracle

Мелкая заметка. Иногда надо быстренько заполнить данными какую-нибудь тестовую табличку в базе данных; в последний раз таковой оказалась rdbms oracle, а потому весь процесс для неё решил зафиксировать на будущее.

Загрузка классов jdk на jboss as 7

jboss 7 "из коробки" не видит некоторые пакеты jdk

В прикладном коде приложения используются классы из пакета com.sun.net.httpserver - обычные классы jdk из rt.jar. На сервере приложений jboss 7 попытка запуститься привела к ошибке:

StandardWrapper.Throwable: java.lang.NoClassDefFoundError: com/sun/net/httpserver/HttpHandler
jvm 1    |     at java.lang.Class.getDeclaredConstructors0(Native Method) [rt.jar:1.7.0]
jvm 1    |     at java.lang.Class.privateGetDeclaredConstructors(Class.java:2404) [rt.jar:1.7.0]
...
jvm 1    | Caused by: java.lang.ClassNotFoundException: com.sun.net.httpserver.HttpHandler from [Module "deployment.easygeo-1.0-SNAPSHOT.ear.front-1.0-SNAPSHOT.war:main" from Service Module Loader]
jvm 1    |     at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)
jvm 1    |     at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
jvm 1    |     at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
jvm 1    |     at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
jvm 1    |     at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)
jvm 1    |     ... 32 more

Казалось бы, jboss запускается же ведь на указанной jdk (запуск выполняется с помощью wrapper.tanukisoftware.com, и во wrapper.conf установлено верное значение JAVA_HOME; да и вообще - всё остальное же работает!). Почему сервер не видит стандартный пакет?

Решение оказалось простым. Файл jboss_home\modules\sun\jdk\main\module.xml содержит перечней тех пакетов jdk, которые деплоятся. Выглядит так:

<module xmlns="urn:jboss:module:1.1" name="sun.jdk">

...

    <dependencies>

        <system-export="true">

            <paths>

                <path name="com/sun/script/javascript"/>

                <path name="com/sun/indi/..."/>

                <path name="com/sun/security/..."/>

                <path name="sun/io"/>

                <path name="sun/util"/>

... и т. д.

Дописал там:

<path name="com/sun/net/httpserver" />

и всё чудесным образом стало хорошо! Аналогично можно подключить и пакеты из resources.jar.

P. S. Хотя это выглядит несколько странным, когда требуется править внутренние конфиги сервера приложений. Возможно, есть более красивое решение?

javasimon и метрики производительности

Производительность приложения, её тестирование и оценка. Многие наверняка слышали (если не слышали, то начать можно с wiki).

Так вот, если отвлечься от всяких методик и подходов и просто немного подумать. Есть приложение, для которого требуется оценить/проверить скорость работы, надёжность и пр. Ок, берём приложение, засовываем его в ящик, подаём на вход нагрузку, на выходе снимаем какие-то данные (время отклика на запрос, время фиксации транзакций в БД или чего-то там ещё), анализируем их, делаем выводы.

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

Можно добавить в код вывод отладочной информации по интересующим действиям. Но в таком логе легко "закопаться" (например, при многопоточной работе может оказаться нелёгким делом идентифицировать нужные события из общей массы). Да и само по себе работающее "на бою" приложение с отладочной печатью - mauvais tone.

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

• Иметь возможность "снимать" нужные статистические данные изнутри (а сколько объектов лежит в очереди? сколько времени занял очередной цикл или его часть?).
• Задача по анализу должна быть отделена от основной логики.
• Минимальный оверхэд и влияние на производительность приложения.
• Простота и понятность, минимальное количество дополнительного кода. 
• Что-то ещё?

Как часто бывает, кто-то об этом уже подумал. И даже разработал и предложил решения. Например, Java Application Monitor и Java Simple Monitoring API.

О патриотизме в компании

Жила-была некая IT-компания. Как и прочие, она появилась на свет в виде стартапа, который затеяли и развивали несколько человек.

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

Каждый сотрудник-новичок быстро осваивался, воспринимал эту атмосферу, в определённой мере подстраивался и одновременно вносил что-то новое для всех.

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

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

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

К чему это всё? Ах да! К тому, что в результате такого взрывного роста и расширения особенная атмосфера попросту рассеялась и расплылась. А от коллег встречаются слова (не дословное цитирование, но близко к тексту): "Я не патриот компании. Я просто делаю работу, за которую мне платят".

Возможно, это естественный процесс. Но как "старожилу и патриоту" от понимания этого становится грустно.

Пост о времени :)

Когда-то уже давно Джоэл Спольски написал отличный пост в своём блоге - "Абсолютный минимум, который каждый разработчик программного обеспечения обязательно должен знать о Unicode и наборах символов". Приведу небольшую цитату - самое главное о кодировках:

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

Так вот, нечто подобное - весьма подобное - можно сказать и о времени и датах. Сколько ошибок и нестыковок обнаруживается в софте, написанном теми программистами, которые (почему-то) считают, что есть просто дата и время. Абсолютные, везде и всюду, без учёта часовых поясов, без перевода часов на летнее/зимнее время, без високосных лет и корректировочных секунд.

В этом посте я не буду вдаваться в технические детали или в особенности реализации на конкретном языке разработки, но постараюсь объяснить базовые принципы.

Управление ресурсами

Тайм-менеджмент и контроль личных денег: что общего?

Уже неоднократно встречал у разных людей негативное восприятие и отношение к тайм-менеджменту. При этом один из аргументов contra - само понятие планирования и бюджетирования времени. Мол, как же так, если я буду планировать каждый свой день и затем жить по этим планам, мне останется ещё меньше свободы. Ещё меньше возможности сделать что-то не по плану, случайно. Ещё меньше "воздуха" в и так связанной по рукам и ногам жизни.
Аргумент понятный и на первый взгляд достаточно сильный. Ведь при быстром темпе жизни, когда задачи возникают регулярно и словно ниоткуда, когда эти задачи зачастую привязаны ко времени и требуют оперативного решения, не хочется навязывать себе ещё какие-то дополнительные планы.

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

Про опыт и стаж

Первоначальные материалы в "старой, но актуальной теме про коллектив" Евгения Охотникова и по ссылкам далее.

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

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

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

Да, это позволяет получить новый опыт и расширить знания. Да, это советуют психологи. Да, это может статься интересным.

Но описанный пример отлично иллюстрирует тот факт, что не всё - далеко не всё - можно проверить, отладить, описать в документации и пр. и пр. И только сотрудники, работающие в компании длительное время, в состоянии в нужный момент вспомнить, почему конкретный участок кода выглядит так странно, компоненты взаимодействуют каким-то удивительным образом, а в конфигах встречаются вроде бы нигде не используемые параметры. Вспомнить и удержать от попыток переписать код "по-красивому", подключить компоненты напрямую, а параметры вчистую выкосить. И избежать тем самым epic fail'ов и просто глупых и неожиданных проблем.

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

Тема особенно актуальна, когда коллектив регулярно теряет своих "старожилов". Вот бы ещё руководство компаниями это хорошо понимало...

update: оставлю ещё ссылку на http://one-in.livejournal.com/68355.html

Именования в java и не только?

На самом деле, речь пойдёт не только об именовании, но и в более общем смысле об оформлении кода. Стандарт оформления кода (стандарт кодирования, стиль программирования - англ. coding standards, coding convention или programming style) - набор правил и соглашений, используемых при написании исходного кода на некотором языке программирования. Зачем это всё вообще надо и что можно почитать по теме?

javax.net.debug: отладка ssl в java

При разработке и настройке защищённых ssl/tls соединений полезен режим отладки. В java для получения такой отладочной информации поможет параметр javax.net.debug.  Далее в посте подробнее о возможностях и результатах.

keytool: управление ключами и сертификатами

keytool - это утилита для работы с ключами и сертификатами из стандартного дистрибутива java. Она позволяет генерировать новые пары закрытых/открытых ключей, управлять ими, создавать запросы на подпись, экспортировать и импортировать сертификаты; иными словами, она умеет делать практически всё, кроме подписывания запросов на подпись сертификата.

Далее в посте - перечень наиболее часто используемых и самых полезных команд этой классной утилиты.

java keystore и его особенности

Данные надо защищать. А важные данные надо защищать хорошо! Одним из самых распространённых способов защиты - во все времена и в различных сферах - является шифрование данных. Криптография, симметричное и асимметричное шифрование, ключи, сертификаты и многое другое связано с этой задачей. Далее в посте немного о так называемом keystore - месте хранения ключей и сертификатов в java.
 

Акторная модель для java

Акторная модель - математическая модель параллельных вычислений, которая трактует понятие «актор» как универсальный примитив параллельного численного расчёта: в ответ на сообщения, которые он получает, актор может принимать локальные решения, создавать новых акторов, посылать свои сообщения, а также устанавливать, как следует реагировать на последующие сообщения. Модель акторов возникла в 1973 году. (http://ru.wikipedia.org/wiki/Модель_акторов). Имеется реализация модели на java (http://akka.io/).