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

Суть её очень проста: если хранить перечисления как сущности (@Entity), то с ними получается крайне неудобно работать, база данных нагружается лишними запросами даже несмотря на кэширование, а сами запросы к БД усложняются лишними JOIN'ами. Если же перечисление определять как enum, то с ними становится удобно работать, но возникает проблема синхронизации с базой данных и отслеживания ошибок таковой синхронизации.

Особенно актуально это в том случае, когда поле, содержащее перечисление, аннотировано как @Enumerated(EnumType.ORDINAL) — всё мгновенно ломается при смене порядка объявления значений. Если же мы храним значения в строковом виде — как @Enumerated(EnumType.STRING) — возникает проблема скорости доступа, так как индексы по строковым полям менее эффективны и занимают больше места. Более того, вне зависимости от способа хранения значения поля при отсутствии в базе данных таблицы со списком допустимых значений мы никак не защищены от некорректных или устаревших данных и, как следствие, проблем.

Однако сама идея хранения в базе данных заманчива простотой построения запросов вручную, очень ценной при отладке ПО или решении сложных ситуаций. Когда можно написать не просто SELECT id, title FROM product WHERE status = 5, а, скажем, SELECT id, title FROM product JOIN status ON status.id = product.status_id WHERE status.code = 'NEW' — это очень ценно. В том числе и тем, что мы всегда можем быть уверены в том, что status_id содержит корректное значение, если поставим FOREIGN KEY.

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

К написанию сей заметки меня сподвигло то, что я устал делать развёрнутые замечания на эту тему в комментариях к статьям, где в качестве части инструкции по сборке и настройке чего-либо для конкретного дистра предлагают выполнить make install.

Суть сводится к тому, что эту команду в виде «make install» или «sudo make install» использовать в современных дистрибутивах нельзя.

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

Тут приспичило мне периодически запускать некоторый код в небольшом проектике написанном на Spring Framework. Я уж было приготовился по старой памяти (еще со спринга 2.x) к долгому прикручиванию quartz-а и написании кучи конфигов на xml, как оказалось все значительно проще

На JavaOne 2011 было объявлено о выпуске финальной версии JavaFX 2.0. Рассмотрим из чего оно состояит и какие средства предлагает.

Интернет пестрит руководствами по настройке виртуальных хостов в Apache. Но, в большинстве случаев, создание такого поддомена представляется хлопотным делом.
По «стандартной» инструкции предлагается сделать следующее:

1. Создать папку для сайта
2. Создать конфигурационный файл с именем будущего домена
3. Включить сайт специальной опцией
4. Перезагрузить Apache
5. Прописать наш домен в файле hosts

Некоторые пытаются оптимизировать данный процесс различными скриптами, но проблемы это, по сути, не решает.
Итак, попробуем добиться, чтобы процесс создания поддомена сводился лишь к созданию папки для сайта. Возможно ли это? Проверим…

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

Уверен, каждый из читателей, знает что такое шаблон проектирования “Singleton”, но не каждый знает как его программировать эффективно и правильно. Данная статья является попыткой агрегирования существующих знаний по этому вопросу.

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

Расскажу вам как я использую интерактивную консоль Jython для ускорения разработки Bean'ов в поддерживаемом мной приложении.

Суть вопроса

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

По долгу службы пришлось поддерживаю очень древнее приложение с громадной кодовой базой. Хуже всего то, что оно собирается оно от минуты до семи и ещё минуты три стартует. Опять же каждому программисту не сложно представить себе какой ад написать энное количество кода, а затем ловить NullPointerException'ы от внешних сервисов с таким длинным циклом Implement->Compile->Start Deploy->Wait->Smoke->Wait->Test.

Возможен также другой вариант. Есть энное количество кода в классе, который нужно адаптировать под выполнение задачи, близкой уже им выполняемой. А теперь представьте, что этот класс реализован в рамках Java 1.4. Он не работает с Generic'ами, потому что они были добавлены только в Java 1.5. Кроме того программисты, ранее занимавшиеся поддержкой системы, этим активно пользуются и суют в коллекции возвращаемые методами других классов, что не попадя вплоть до анонимных реализаций java.lang.Object.

Поев кактус пару дней я почувствовал, что начинаю сходить с ума от того, что пишу пять-двадцать строк работающего кода в день.

Итак, кроме обычных топиков есть еще и топики из песочницы, при этом их можно публиковать с какой угодно кармой, так что можно опубликовать топик с кармой меньше нуля, для этого (далее на примере хрома): лезем в Developer Tools -> Element -> Search topic-type, меняем значение поля на sandbox и вуаля, топик якобы из песочницы, как подтверждение теории я публикую этот топик с кармой -4.

P.S. т.к. мне терять нечего то если меня забанят то пусть так и будет.

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

Добрый день, Хабражители!

Сегодня я опять постараюсь привлечь Ваше внимание к некоторым сторонам и тонкостям работы с графикой в Java. Я уже кратко описал в предыдущей статье некоторые доступные средства и способы создания компонентов и UI, но это лишь вершина айсберга. Именно поэтому я хочу уделить отдельное внимание (и статью) именно работе с графикой. Естественно имеется в виду Graphics2D – Java 3D это большая отдельная тема (возможно о ней еще пойдет речь в дальнейшем, но не сегодня).

Итак, из предыдущей статьи Вам уже должны быть известны некоторые основы построения компонентов — постараемся расширить эти знания.

Начнем с того, что если рассматривать любой компонент с точки зрения MVC – он состоит из 3ех частей:
Model – модель, которая хранит в себе данные о состоянии компонента и на основе которой строится внешний вид
View – непосредственно визуальное отображения компонента
Controller – отвечает за управление компонентом (события от клавиатуры, мыши и прочих устройств ввода)

Фактически, все стандартные компоненты Swing построены по паттерну MVC. К примеру в JButton — ButtonModel отвечает за поведение и состояние кнопки (Controller и Model), а ButtonUI в свою очередь за внешнее её представление (View). В итоге на долю самого класс JButton практически ничего не остаётся. Речь пойдет по большей части о реализации внешнего представления компонентов (View), и если уточнять — о Graphics2D, на основе которого, фактически, рисуется весь интерфейс.

Не буду спорить, что на данную тему есть множество различного материала, но он настолько раздроблен и раскидан по просторам сети, что мне кажется не лишним собрать всё в одном месте и последовательно изложить.

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

Сейчас уже никто не создает программы в консоли. Используя любимую IDE, разработчик чувствует себя неуютно за чужим компьютером, где её нет.
Решив разобраться в работе Ant и Maven, я поймал себя на том, что не смогу собрать приложение без них в консоли.
В данной статье я постарался уместить все этапы проектирования демонстрационного приложения, чтобы не искать справку по каждой команде на просторах Интернета.

Здравствуйте, в этой статье я расскажу вам как регистрировать глобальные нажатия клавиш из Java под Windows, Linux, BSD и Mac OSX с использованием отличной библиотеки JNA.

Для чего нужен JNA

Java с десктопом дружит сложно, для некоторых вещей нужно писать мосты для взаимодействия с операционной системой. Одной из таких функциональностей являются глобальные хоткеи, весьма популярные в аудио плеерах, когда даже в скрытом состоянии программой можно управлять с помощью определенных сочетаний клавиш или медиа-кнопок. На помощь приходит JNA — надстройка над jni и libffi для вызова нативных библиотек, она поддерживает почти все популярные платформы, разрабатывается уже долгое время и весьма стабильна.

Для джавы уже есть несколько достаточно стабильных библиотек для всех платформ: JIntelliType для Windows, которая даже поддерживает медиа-кнопки, JXGrabKey для систем Linux, и ossuport-connector для Mac OSX. Однако, все они используют jni, имеют разный интерфейс, и с библиотеками на jni не всегда удобно работать, потому что нужно прописывать пути к нативным библиотекам, разбираться с разрядностью системы и пр. Плюс это будет интересным упражнением по использованию JNA, потому что эту задачу можно сделать полностью на java достаточно малыми усилиями и получить легко поддерживаемый кроссплатформенный код.

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

Многим может не нравится, что мавен в самом деле отбирает у разработчика свободу выбора структуры проекта и прямо таки диктует ее, но в самом ли деле эта свобода настолько важна, чтобы делать изза нее жирный аргумент против? Не думаю. Есть другие, более серьезные, на мой взгляд, недостатки, в первую очередь — трудность диагностики проблем при сборке и недостаточная документированность мавена и плагинов.

Жизнь — дерьмовая штука. По крайней мере, так считают многие «взрослые» люди, с которыми мне довелось общаться. Они постоянно жалуются на свою работу, неудовлетворительные отношения и раздолбаев-детей, которые никак не хотят становиться такими, какими хотят их видеть родители. Жизнь для этих людей — это бесконечная карусель разочарований, неприятностей и несбывшихся надежд. Они встают рано утром с больной головой, заливают в рот пару литров кофе и едут на работу в состоянии, которому позавидовали бы самые отъявленные зомби. Они ненавидят свою работу и считают, что их занятия бессмысленны и никому не нужны. Но, не смотря на это, они с упорством леммингов продолжают делать эту работу, день за днём, год за годом. Они продираются сквозь собственную жизнь, надеясь, что всласть поживут потом, когда отработают 10-20-30 лет. Так вот, это всё херня. Когда вам будет пятьдесят, вы настолько устанете от такой жизни, что единственным вашим желанием будет лечь и сдохнуть. Да и здоровье будет уже не то, потому что вы слили его, занимаясь всякой ерундой, до которой вам даже не было дела. Так что, когда вы выйдете на пенсию, вы не поедете в Африку охотиться на львов, потому что солнце плохо сказывается на вашем давлении. Вы также не поедете на Северный полюс, потому что у вас артрит и холод — не лучшее для него лекарство. Южный полюс отпадает ещё и потому, что вы недолюбливаете пингвинов, что неудивительно, учитывая ваш 30-летний стаж работы сисадмином. Так что же вам остаётся? Поездки на дачу и вечера в уютной компании телевизора, вот что. Прожив 30 лет в постоянной борьбе с самим собой, у вас просто не останется сил на то, чтобы оторвать задницу от дивана.

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

Однако, в зависимости от вида, каждые 7, 11, 13 или 17 лет периодические цикады одновременно массово вылезают на свет и превращаются в шумных летающих тварей, спариваются и вскоре умирают.

Хотя наши странные цикады весело уходят в иной мир, возникает очевидный вопрос: это просто случайность, или числа 7, 11, 13 и 17 какие-то особенные?

Иногда полезно представить граф в графической форме, так чтобы была видна структура. Можно привести десятки примеров, где это может пригодиться: визуализация иерархии классов и пакетов исходного кода какой-нибудь программы, визуализация социального графа (тот же Twitter или Facebook) или графа цитирования (какие публикации на кого ссылаются) и т.д. Но вот незадача: количество ребер в графе зачастую настолько велико, что нарисованный граф просто невозможно разобрать. Взгляните на эту картинку:



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

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

Часто довольно трудно найти в базе нетипичную фамилию, например:

— Леха, поищи в нашей базе Адольфа Швардсенеггера,
— Шворцинегира? Нет такого!

В этом случае использование фонетических алгоритмов (особенно в сочетании с алгоритмами нечеткого сопоставления) может значительно упростить задачу.

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

В этой статье я рассмотрю наиболее известные алгоритмы, такие как Soundex, Daitch-Mokotoff Soundex, NYSIIS, Metaphone, Double Metaphone, русский Metaphone, Caverphone.

Жизнь была прекрасна и все было в этом мире хорошо, пока почта с моего сайта не стала активно посылаться в спам практически всеми крупными почтовыми серверами. Особенно усердствовал в этом Gmail. Частенько меня принимали за спамера в Yandex, реже в mail.ru и rambler.

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

Xpath — это язык запросов к элементам xml или xhtml документа. Также как SQL, xpath является декларативным языком запросов. Чтобы получить интересующие данные, необходимо всего лишь создать запрос, описывающий эти данные. Всю «черную» работу за вас выполнит интерпретатор языка xpath.
Очень удобно, не правда ли? Давайте посмотри какие возможности предлагает xpath для доступа к узлам веб-страниц.