Enterprise

Нещодавно усвідомив, що переклад і осмислення слова "Enterprise" допомагають позбавитися "ментального лоску", "тремтіння" перед таким поняттям, як "Java Enterprise Edition".

Моя проблема була в тому, що до цього часу я асоціював це слово більше із корпорацією, ніж із "банальним" підприємством.

Корпорація - це монстр, якого не соромно боятися.
А підприємство - воно ж може бути і скромним державним.
Чого його боятися?

Java (по мотивам собеседований)

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

1. Множестенное наследие, но для интерфейсов


В голову вбил, что в java нет множестенного наследования, и для объектов это действительно так.
Но вот для интерфейса вполне правомерно написать:

Для тестирования простой класс:


2. Одинаковые названия метода и конструктора

Сигнатуры-то разные

Примеры компилируются, и выполняются без ошибок.

очень упрощенный конспект книги о Spring Data

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

1. Причины появления NoSQL: увеличение количества данных, соотношение структуры домена со структурой базы данных (графы как графы, key-value как key-value)
2. Виды NoSQL баз: key-value (похоже на hashtable), column family (как key-value но value это column), document (структурированные данные, например XML или JSON) и graph (графы, модель данных содержит узлы-nodes и ребра-edges)
3. Atomicity Consistency Isolation Durability (ACID) в RDBMS заменяется Basically Available Scalable Eventually consistent (BASE) для NoSQL
4. JPA не подходит как основа общего интерфейса для NoSQL - его спецификация завязана на Object Relational Mapping.
5. Каждое из хранилищ Spring Data содержит не только одинаковую структурную модель, но и отличия в свойствах и возможностях
6. Spring Data работает на основе декларативного маркерного обозначения имен элементов архитектуры (классов, интерфейсов, полей данных, методов). Выбор конкретного хранилища определяется в конфигурации приложения (например, @EnableJpaRepositories или jpa:repositories base-package="..." если используется XML-конфиг).
7. Методы интерфейса для работы с определенным доменным класом (например, Client) определяются или полностью пользователем (через запрос @Query для выполнения), или путем расширения интерфейсов Spring Data.
   Repository - простой маркерный интерфейс для пометки для Spring Data определяемого пользователем репозитория.
   CrudRepository расширяет Repository основными методами объектно-реляционной модели - поиском, сохранением и удалением сущностей.
   PagingAndSortingRepository расшираяет CrudRepository методами распределения по страницам и сортировкой.
8. Пользователь может сам определять новые интерфейсы для репозиториев согласно своему представлению архитектуры приложения. Для этого интерфейс необходимо пометить как @NoRepositoryBean если интерфейс будет наследоваться от существующего интерфейса репозиториев, или создать свой собственный интерфейс и его реализацию согласно соглашения по именованию (например, ClientRepositoryCustomization и ClientRepositoryCustomizationImpl)
9. Имена методов интерфейсов репозитория должны соответствовать верблюжемуРегистру и основываться на запроектированных шаблонах чтобы Spring Data их распознал, или полагаться на прилагаемое Query.
   Например,
   Client findByFirstname(String firstname) - найти клиента Client по его полю данных firstname,
   List findByAddress_ZipCode(ZipCode zipCode) - найти список клиентов по почтовому коду, который содержит его поле данных - адрес address,
   List findByEmailAndLastname(EmailAddress email, String lastname) - найти список клиентов по почтовому адресу и фамилии.
   Если держаться за конвенцию именования, то Spring Data генерирует нужный запрос Query.
10. Spring Data поддерживает интеграцию с Querydsl. который позволяет обобщенно составлять запросы к JPA, Hibernate, JDO, native JDBC, Lucene, Hibernate Search, и MongoDB. Похоже на попытку сделать нечто подобное LINQ, но для java. Не понравилось - Eclipse не подхватил даже с танцами, Intellij Idea разобралась, но осадочек остался. По-моему, шаг с отдельной автогенерацией запросов не удобный. Вот разве что если запросов в проекте много, и их все надо поддерживать в удобочитаемом виде?
11. MongoDB - хранилище документов в формате BSON - бинарного расширения JSON.
12. Neo4J - база данных графов, состоит из вершин и их отношений.
13. Redis - key-value база данных.
14. Spring Roo - проект SpringSource для управления кодом и его созданием.
15. Spring REST Exporter - проект SpringSource для доступа к основанным на JPA репозиториям через REST-интерфейс.

Это приятное чувство "а я ведь говорил"

Вспомнилось.

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

SELECT DISTINCT [smthng1] FROM (множество_1) WHERE [smthng2] NOT NULL AND EXISTS (множество_2)

Не буду углубляться в сложности выборки обоих указанных множеств - это не существенно. Сложные. Поля из нескольких таблиц.

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

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

Разбор полетов показал, что эффективнее разбить запрос на две части, и с помощью java перебрать совпадения множеств, чем ждать пока MySQL обработает EXISTS.
Что ж, решение было внедрено и отправлено клиенту.

Но внезапно оказалось, что у клиента MS SQL и его проблему патч не решил.
Ощущение собственной правоты подогрело душу.
Клиент своим отказом отсрочил полноценное решение проблеммы.

Но это не было концом истории.

Дамп базы MS SQL для препарирования мы все-таки получили.
Но потом оказалось, что никаких проблем с EXISTS у запроса нет.
Недоразумения для MS SQL связаны с DISTINCT.

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

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

Выводы, они же советы.

1. Добивайтесь максимального совпадения рабочей среды и среды разработки.
2. Осторожно с  EXISTS в MySQL.
3. Осторожно с DISTINCT в MS SQL.

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

Сбой кодировки где-то между Spring MVC и MySQL

Во время написания одного небольшого задания столкнулся с возмутительным недоразумением между Spring MVC и MySQL базой: внесенные данные никак не хотели быть в одной кодировке на всех страницах приложения и базы.
Я наблюдал нечитаемые символы в базе и на страницах броузера.
Проверка, перепроверка базы\классов (кодировка базы была нужная) ничего не дала.

Помог поиск в гугле.
Не помню как я нашел END TO END UTF-8 ENCODING USAGE WITH MYSQL AND SPRING
Но там было указание на причину проблеммы: класс, ответственный за соединение с базой (в моему случае bean на основе org.apache.commons.dbcp.BasicDataSource) не получил двух важных свойств - useUnicode и characterEncoding.
Расширение класса вместе с добавлением метода init() вида :


public class UTF8DataSource extends BasicDataSource {

public void init() {
addConnectionProperty("useUnicode", "true");
addConnectionProperty("characterEncoding", "UTF-8");
}

}

Конечно, bean должен быть чуть другой:

 bean id="..." class="...UTF8DataSource" ... 

Надеюсь, кому-то сбережет время.

Странно, что в http://www.springframework.org/schema/p нету нужного свойства (p:initialSize и p:maxActive для Connection Pool есть...).

Не уверен, что так было с самого начала, когда я начал тесты на BlackBeltFactory.com, но факты на лицо. Последний экзамен не забрал очки активности на сайте (contribution points), а наоборот их добавил. Дело в том, что если выполнять экзмамены в предложенной последовательности, то они будут как-бы бесплатны:

Java SE - Basic (Passed!)
OO for Java - Basic (Passed!)
Java SE Core - Intermed (Passed!)
Java SE Collections : Take this exam for free!
Java SE Base API - Basic (Take previous exam first to get it for free)
OO - Intermed (Take previous exam first to get it for free)
Java SE Base API - Intermed (Take previous exam first to get it for free)
Java 5 New Language Features (Take previous exam first to get it for free)
XML Core - Basic (Take previous exam first to get it for free)

Я немного надеюсь, что это не все бесплатные.

Я тут (медленно, слишком медленно!) читаю книгу для подготовки к Oracle Certified Professional Java Programmer, и сравниваю темы и разделы - текущий приоритетный для меня Java SE Collections более строгий. У меня такое ощущение, что без проработки всего поведения и возможных состояний (через API классов) я не смогу рассчитывать на успешную сдачу экзамена.

(+ Java SE Core - Intermed )

Небольшой конфликт между gwt-dev-2.2.0.jar и servlet api 3.0

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

Ошибка была связана с работой третьей редакции сервлетов.

А конкретно - в коде никак не хотели вызываться методы javax.servlet.http.HttpServletRequest.startAsync() и javax.servlet.http.HttpServletRequest.startAsync( javax.servlet.http.HttpServletRequest req, javax.servlet.http.HttpServletResponse res).

Постоянно eclipse ругался, что нет такого метода.

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

"Ручная" компиляция в консоли единстенно нужного класса с указанием библиотеки сервлетов третьей редакции проходила успешно.

Оказалось: библиотека gwt-dev-2.2.0 содержит Servlet API 2.4, и если в списке загружаемых библиотек она стоит выше (раньше) библиотеки нужных сервлетов, то та уже и не подгружается, видимо.

Решение проблеммы простое: поднять библиотеку третьих сервлетов раньше библиотеки gwt.

Актуально и для Intellij Idea, и для eclipse.

Спасибо ulizko.com