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

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

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

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

lifeline vs. deadline

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

Также это выражение закрепилось и в сфере управления временем/задачами/жизнью. Используете to do list - и для перечисленных дел указываете крайний срок, когда дело должно быть сделано? Вот он, крайний срок, к которому задача должна быть решена и вычеркнута. Вычёркивание задач из списка дел в конечном итоге завершится вычёркиванием всей вашей жизни - самым крайним и неоспоримым дэдлайном.

Может, стоит мыслить по-другому - "не deadline и не конец, а lifeline и начало"? Мыслить в терминах нового дня, новой недели и нового старта.

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

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

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

Работа с liquibase

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

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

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

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

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

Joda time

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

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

The Joda umbrella

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

//noinspection в IntelliJ IDEA

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

@SuppressWarnings: пример

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

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

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

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

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

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

Best practices

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

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

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

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

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

DbUnit: чистый sql

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

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

DbUnit: пример

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

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

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 позволяет описать желаемое или ожидаемое состояние базы данных в виде обыкновенных текстовых файлов, а затем легко и просто выполнить инициализацию этой БД перед запуском каждого теста или проверить её актуальное состояние после выполнения теста.

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;
• просто настраивается;
• имеет широкие возможности по объёму и глубине логируемой информации.

Run!

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

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