понедельник, 22 октября 2012 г.

Сравнение Oracle и MS SQL Server

Oracle и MS SQL Server – де-факто стандарты СУБД корпоративного уровня. У каждой из них имеются свои преданные сторонники и ярые противники. Обе СУБД выполняют примерно одинаковые задачи для примерно одинаковых пользователей и управляются примерно одинаковыми dba. В чём же разница? Далее в этом посте предлагаю экспресс-сравнение функциональности Oracle и SQL Server, пусть достаточно поверхностное и без залезания в глубокие дебри на уровень "прожжёных админов", зато пригодное для начального сопоставления.

среда, 19 сентября 2012 г.

ДОделывать или ПЕРЕделывать?

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

четверг, 23 августа 2012 г.

lifeline vs. deadline

Выражение "дэдлайн" (deadline) прочно вошло в it сленг. Означающее буквально "мёртвая линия", в сленге его значение превратилось в "крайний срок" - дату релиза, выпуска продукта, завершения проекта.
Также это выражение закрепилось и в сфере управления временем/задачами/жизнью. Используете to do list - и для перечисленных дел указываете крайний срок, когда дело должно быть сделано? Вот он, крайний срок, к которому задача должна быть решена и вычеркнута. Вычёркивание задач из списка дел в конечном итоге завершится вычёркиванием всей вашей жизни - самым крайним и неоспоримым дэдлайном.
Может, стоит мыслить по-другому - "не deadline и не конец, а lifeline и начало"? Мыслить в терминах нового дня, новой недели и нового старта.
Возможно, от перемены слов суть не изменится. Но ведь "назовёшь его корытом, так оно и поплывёт"! Так что пусть будет lifeline, хотя бы иногда.

пятница, 17 августа 2012 г.

liquibase servlet listener: пример и настройка

liquibase может быть запущен (среди прочих способов) с помощью servlet listener. А значит, можно автоматизировать запуск liquibase и приурочить проверку/обновление БД к моменту деплоя приложения. Далее в посте рассматривается пример того, как "подружить" liquibase и сервер приложений jboss, настроить эту связку и сделать так, чтобы миграция выполнялась при запуске приложения.

четверг, 16 августа 2012 г.

Работа с liquibase

Программы и приложения обладают одним интересным свойством склонностью к эволюционированию: появляются новые возможности, старые и ненужные фичи исчезают, меняются внешние интерфейсы и внутренние взаимосвязи. И если программа или приложение использует базу данных, то этот процесс неизменно сопровождается развитием и БД.
Для разработчиков развитие БД выливается в задачи по рефакторингу модели данных, отслеживанию изменений, синхронному обновлению баз и поддержанию совместимости версий; особенно это касается "боевых" приложений, для которых ошибка может стоит дорого. Как решать возникающие задачи? Можно полагаться на память. Можно связаться с текстовыми файлами, чтобы помечать в них, когда и какие поля в БД были изменены, и что нужно сделать на сервере БД заказчика, чтобы обновление версии программы прошло без проблем.
Механизмом для оптимизации этого сложного, но неизбежного процесса является инструмент liquibase, лозунг которого "Database Change Management" управление изменениями баз данных. Полное описание функциональности можно получить на сайте проекта; далее же в посте описываются некоторые конкретные возможности и процедуры использования данного инструмента с небольшими примерами.

пятница, 10 августа 2012 г.

Hyperic Sigar: мониторинг ресурсов в java

Иногда важно собирать информацию об использовании приложением системных ресурсов. Например, для сбора требуемой статистики. Или для обязательного совмещения с профилем нагрузки при нагрузочном тестировании. Или потому, что просто интересно :)
SIGAR (http://support.hyperic.com/display/SIGAR/Home) предоставляет переносимый интерфейс для сбора информации о системе и потреблении системных ресурсов:
* системная память, размер swap-файла, загруженность cpu, продолжительность работы;
* потребление памяти и cpu, а также состояние, окружение, параметры и используемые файлы по отдельным процессам;
* данные по файловой системе, очереди на запись/чтение, количество write/read байт, размеры дискового пространства;
* данные по сетевому интерфейсу, его конфигурации;
* таблица tcp/udp соединений, для них локальные/удалённые адреса, очереди на чтение/запись;
* таблица сетевых маршрутов и пр., и пр.

четверг, 2 августа 2012 г.

Joda time

Joda-time - наиболее известная и активно поддерживаемая/используемая библиотека проекта joda. Как гордо говорится на её странице, это "де-факто стандартная библиотека для работы с датами и временем в java". Реализация как Date, так и Calendar в java core имеют серьёзные недостатки, из-за чего joda-time и стала такой популярной. В качестве подтверждения популярности и качества библиотеки можно рассматривать предложения о включении её в состав jdk 7 (правда, эти ожидания так и не оправдались, зато появились новые - о включении в jdk 8).

Вот несколько причин, по которым joda-time появилась и стала востребованной: простота в использовании, лёгкая расширяемость, большой перечень возможностей, 100% совместимость со стандартными классами jdk, улучшенные характеристики производительности, поддержка нескольких (в настоящее время - 8) календарей, хорошее тестовое покрытие, полная документация, зрелость, открытый исходный код. Подробнее обо всём этом можно почитать прямо на главной странице проекта. Далее в этом посте - инфо, примеры использования joda-time и полезные ссылки.

пятница, 27 июля 2012 г.

The Joda umbrella

Joda (http://joda.sourceforge.net/) - это группа java-проектов с открытым исходным кодом для расширения базовой функциональности jdk. В настоящее время включается в себя joda-money, joda-beans, joda-primitives, joda-convert и joda-time. Все библиотеки характеризуются узкой специализацией, небольшим размером, хорошим описанием и javadoc'ом, простотой и интуитивностью применения, совместимостью и удачным взаимодействием с jdk. Что же включает в себя эта группа и какие из них стОит поместить в свою "копилку" полезных библиотек?

пятница, 6 июля 2012 г.

//noinspection в IntelliJ IDEA

Как я уже упоминал в предыдущем посте, в IDEA есть интересный плагин InspectionGadgets, который на текущее время предлагает более 500 дополнительных проверок для этой IDE и является мощным инструментом статического анализа кода.
Инспекции этого инструмента весьма удобны в использовании, т.к. сгруппированы по содержанию и назначению и могут настраиваться индивидуально. Более того, результаты настройки можно сохранить в отдельный файл xml формата и загрузить его в IDE в другом месте. Ну, да разговор немного о другом. InspectionGadgets отслеживает и формирует гораздо больше предупреждений, чем java компилятор. И если требуется подавить какое-то из предупреждений, то аннотация @SuppressWarnings отлично работает. Но как узнать название нужного предупреждения, чтобы указать его в параметрах аннотации?

вторник, 3 июля 2012 г.

@SuppressWarnings: пример

@SuppressWarnings в java (list of warnings) список предупреждений

1) Praemonitus praemunitus (предупреждён, значит, вооружён)
Практически все компиляторы в процессе компилирования исходного программного кода выполняют статический анализ этого кода, что позволяет идентифицировать и предупреждать о наличии некоторых общих ошибок программирования. Положительный эффект заключается в том, что каждое имеющееся предупреждение - потенциальная проблема, и чем раньше эта проблема выявляется (в данном случае - уже на этапе компиляции), тем дешевле её решение. В целом, многие опытные разработчики придерживаются мнения, что конечный код не должен вызывать предупреждений компилятора. Более того, в некоторых компаниях идут дальше и настраивают политики систем контроля версий таким образом, чтобы коммиты не вызывали подобных предупреждений.
Однако жизнь такова, что иногда исключения из строгих правил всё-таки возникают. И оказывается, что в каком-то конкретном случае выдаваемое компилятором предупреждение легально, и что было бы здорово указать  компилятору проигнорировать конкретное предупреждение. Как вообще можно управлять политикой предупреждений в java?

среда, 27 июня 2012 г.

Как запустить groovy-скрипт?

Помню, в первом семестре первого курса университета на занятиях по информатике от нас требовали знать X способов включения компьютера, Y способов запуска программы и Z способов завершения работы...
Наверное, разработчиков Groovy учили приблизительно тому же - иначе зачем они придумали столько способов запуска groovy-скрипта? Итак.

четверг, 21 июня 2012 г.

Groovy - знакомство

Groovy - объектно-ориентированный язык программирования для платформы Java. Соответственно, groovy использует java-подобный синтаксис с динамической компиляцией в JVM байт-код и напрямую работает с другим Java кодом и библиотеками (ru.wikipedia.org/wiki/Groovy).

пятница, 1 июня 2012 г.

Best practices

Лучшие практики: поиск неисправностей

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

В этой статье - сейчас и в будущем при апдэйтах - я планирую собирать практики, которые могут быть удобны при troubleshooting.
Каждая практика будет описываться буквально несколькими предложениями.
Практики будут собираться/проверяться конкретно для java-мира, хотя - на то они и "лучшие практики", чтобы не быть зависимыми от применяемых технологий.

четверг, 10 мая 2012 г.

java.lang.OutOfMemory: JDK build-in analysis tools

Недавно услышал от одного из менеджеров удивлённое восклицание - "java и утечка памяти?! Как такое может быть?! В java же ведь нет утечек памяти!!!". К сожалению, этот менеджер был не прав, и утечки памяти - memory leak - в java всё-таки встречаются.
(Понимание причин требует знания модели памяти и работы сборщика мусора, в этом посте они не рассматриваются; в качестве обзора можно посмотреть, какие бывают типы OutOfMemoryError или из каких частей состоит память java процесса)
Что же делать, если в один не очень прекрасный день в логе приложения обнаруживается строка "java.lang.OutOfMemoryError: Java heap space"?
Некоторую помощь - иногда достаточно полезную, а иногда единственно возможную - могут предоставить встроенные в JDK средства. Далее следует краткий обзор таких средств с полезными ссылками.

суббота, 28 апреля 2012 г.

DbUnit: чистый sql

Начало: DbUnit: общее описание, DbUnit: пример.

В некоторых случаях сформировать простой датасет не только не просто, но и невозможно; и потому появляется необходимость выполнять "чистые" SQL запросы напрямую к базе данных. Естественно, что при этом желательно бы использовать тот же самый datasource, а ещё лучше - тот же самый DbUnit.
Далее приводится пример такого запроса на основе PreparedStatement с поддержкой транзакционности.

пятница, 27 апреля 2012 г.

DbUnit: пример

Начало: DbUnit: общее описание

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

четверг, 26 апреля 2012 г.

DbUnit: общее описание

Тестирование приложений, взаимодействующих с базой данных, имеет свои особенности. Накопленный девелоперами и тестировщиками опыт можно сформулировать в виде database unit testing best practices.
    * Каждому разработчику по базе данных. При написании тестов очень важно, чтобы состояние схемы базы данных и самих данных не менялось во время написания теста. Поэтому в проектах с несколькими разработчиками каждый разработчик должен работать в персональной базе данных.
    * Тесты должны быть независимы от результатов других тестов. Проще всего достичь этого, возвращая базу данных перед каждым тестом в начальное состояние. Этого можно добиться, очищая содержимое базы данных или просто не сохраняя результаты тестов в базе данных (rollback после каждого теста).
    * Функция очистки всей базы данных. Часто необходимо или неизбежно сохранение промежуточных данных и результатов тестов в базе данных (например из-за DDL autocommit в Oracle). Необходимо разработать процедуру возвращения базы данных в инициальное состояние (как вариант, можно загружать dump базы данных или написать программу, очищающую содержимое всех таблиц в схеме).
    * Маленькие входные данных. Для большинства тестов нет необходимости в полноценном содержимом базы данных. Вместо этого надо стараться создавать небольшие входные данные, специфичные для каждого теста; это облегчит анализ ошибок и сократит время разработки.
    * Общие данные. Многие тесты базируются на подобных данных. Чтобы ускорить процесс разработки тестов, можно создать наборы примитивных данных, которые могут быть использованы различными тестами. Кроме того, можно сохранять эти данные в базе перед выполнением группы подобных тестов, чтобы ускорить тестирование системы.

В мире Java удобным инструментом, позволяющим упростить реализацию и применение перечисленных принципов, является DbUnit (http://www.dbunit.org) - java framework для тестирования баз данных. Фактически, это расширение JUnit с возможностями дополнения и интеграции с другими инструментами разработки (Maven, Spring, Eclipse, Ant). DbUnit позволяет описать желаемое или ожидаемое состояние базы данных в виде обыкновенных текстовых файлов, а затем легко и просто выполнить инициализацию этой БД перед запуском каждого теста или проверить её актуальное состояние после выполнения теста.

среда, 18 апреля 2012 г.

Log4jdbc

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

Простым, удобным и при этом информативным инструментом для решения задач такого рода являются специальные JDBC logging библиотеки. Подобные библиотеки встраиваются в программу, используя Proxy Design Pattern, перед DataSource или Connection, что легко можно сделать в java-коде или декларативно (Spring).

Существует несколько независимых библиотек, реализующих такую функциональность, например, Log4jdbc (http://code.google.com/p/log4jdbc/). На страничке этого проекта можно найти достаточно подробную информацию о свойствах и возможностях библиотеки. Если кратко, то Log4jdbc:
  • open-source под лицензией Apache 2.0;
  • работает с JDK 1.4 и выше;
  • работает с системой логирования SLF4J 1.x, соответственно, поддерживает log4j, logback, JCL, java.util logging in JDK 1.4;
  • просто настраивается;
  • имеет широкие возможности по объёму и глубине логируемой информации.


вторник, 17 апреля 2012 г.

Run!

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

Сфера деятельности: разработка и автоматизация тестирование программного обеспечения.
Основной язык - java.