Быстрая набивка тестовой таблицы в 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