В предыдущих статьях на примерах JUnit и TestNG я упоминал о test-driven development(TDD) и data-driven testing(DDT). Но есть еще один активно набирающий популярность подход, behaviour-driven development(BDD). Это такое развитие TDD техники, при котором на тест смотрят не как на тестирование каких-то компонентов системы, а как на требования к функционалу. Если TDD оперирует такими понятиями, как тест или метод, то для BDD это спецификация и требования. Про эту технику уже говорили на хабре ранее:

• Эволюция юнит-теста,
• Экстремальное программирование, знакомство с Behavior Driven Development и RSpec

Этот подход применим используя и JUnit, и TestNG. Но есть и другие инструменты заточенные именно под BDD. В этой статье я расскажу про такой фреймворк. Называется он Spock Framework и сочетает в себе не только принципы BDD, но и достоинства Groovy. Да-да, именно Groovy. И хотя используется Groovy, используется он и для тестирования Java кода. Примерами использования могут служить Spring, Grails, Tapestry5. Интересно? Тогда читаем дальше.

За последнее время появилось несколько статей, рассказывающих о протоколе SOAP, а также описывающих процесс создания сервера на различных языках и платформах. Продолжим тему. В этой статье будет описываться создание сервера на языке Java с использование Apache CXF и Spring Framework. Предполагается, что читатель уже имеет общее представление об упомянутом протоколе, а также о работе с ant и maven. Для того, чтобы сделать задачу немного интереснее, добавим начальное условие: дана WSDL-схема, описывающая веб-сервис. Итак…
(Картинка из статьи на Wikipedia.)

Как известно, при разработке высоконагруженных серверов часто применяется событийная модель работы с сокетами. Ключевым компонентом системы при этом является epoll (во FreeBSD и Windows есть свои решения, но остановимся на Линуксе). Функция epoll_wait, будучи единственным блокирующим вызовом, возвращает нам информацию обо всех сетевых событиях, которые нас интересуют. Подобным образом, конечно, работает и всем известный сервер NGINX.

Событийная модель программирования делает код весьма своеобразным, как будто выворачивает его наизнанку. Но эта проблема не так страшна. Есть другая проблема — использование в событийно-ориентированном коде существующих библиотек, изначально не предназначенных для него. Если подобная библиотека делает блокирующие вызовы (например, connect, recv и т.д.), вся событийная модель может потерять смысл т.к. окончания одного такого вызова будут ждать все остальные клиенты, что совершенно неприемлемо, если вы пишете серьезный продукт.

Нашел как-то на stack overflow вопрос (link).
Need to create java CLI programm that searchs for specific files matched some pattern. Need to use multi-threading approach without using util.concurrent package and to provide good performance on parallel controllers.
Перевод
Нужно написать консольную программу, которая ищет файлы по какому-то паттерну. Программа должна быть многопоточная, но нельзя использовать пакет util.concurrent. Требуется добиться максимальной производительности.


В общем идея в принципе была не сложная. Т.к. по условию нельзя использовать util.concurrent, то надо реализовать свой пул потоков, плюс написать какие-то таски, которые в этом пуле потоков будут крутиться.
Так же я не был уверен в том, что при многопоточном использовании IO будет увеличение производительности.

Достался мне проект по адаптации флеш-курса электронного обучения под iPad.
Хотел поделиться некоторыми моментами.

Медиа
Проект должен был позволять играть видео/аудио файлы, причем без лишний движений со стороны пользователя.
Видео на iPad можно проиграть только путем нажатия пользователем на что-нибудь, т.е. автоматически проиграть медиа файл, например, при загрузке страницы не получится, или получится, но далеко не во всех версиях iOS.
Так что первый раз проиграть видео/аудио приходится по клику пользователя. Дальше, если тому же тегу менять атрибут src, отлавливая событие onended, проигрывание можно делать автоматически.

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

Прежде всего Hibernate cache — это 3 уровня кеширования:

• Кеш первого уровня (First-level cache);
• Кеш второго уровня (Second-level cache);
• Кеш запросов (Query cache);

Кеш первого уровня

Кеш первого уровня всегда привязан к объекту сессии. Hibernate всегда по умолчанию использует этот кеш и его нельзя отключить. Давайте сразу рассмотрим следующий код:

SharedDoc persistedDoc = (SharedDoc) session.load(SharedDoc.class, docId);
System.out.println(persistedDoc.getName());
user1.setDoc(persistedDoc);

persistedDoc = (SharedDoc) session.load(SharedDoc.class, docId);
System.out.println(persistedDoc.getName());
user2.setDoc(persistedDoc);

Возможно, Вы ожидаете, что будет выполнено 2 запроса в БД? Это не так. В этом примере будет выполнен 1 запрос в базу, несмотря на то, что делается 2 вызова load(), так как эти вызовы происходят в контексте одной сессии. Во время второй попытки загрузить план с тем же идентификатором будет использован кеш сессии.
Один важный момент — при использовании метода load() Hibernate не выгружает из БД данные до тех пор пока они не потребуются. Иными словами — в момент, когда осуществляется первый вызов load, мы получаем прокси объект или сами данные в случае, если данные уже были в кеше сессии. Поэтому в коде присутствует getName() чтобы 100% вытянуть данные из БД. Тут также открывается прекрасная возможность для потенциальной оптимизации. В случае прокси объекта мы можем связать два объекта не делая запрос в базу, в отличии от метода get(). При использовании методов save(), update(), saveOrUpdate(), load(), get(), list(), iterate(), scroll() всегда будет задействован кеш первого уровня. Собственно, тут нечего больше добавить.

Преамбула

Здравствуйте. Я являюсь главным разработчиком крупнейшего в СНГ сервера Minecraft (не буду рекламировать, кому надо, те знают). Уже почти год мы пишем свою реализацию сервера, рассчитанную на больше чем 40 человек (мы хотим видеть цифру в 500 хотя бы). Пока всё было удачно, но последнее время система начала упираться в то, что из-за не самой удачной реализации сети (1 поток на ввод, 1 на вывод + 1 на обработку), при 300 игроках онлайн работает более 980 потоков (+ системные), что в сочетании с производительностью дефолтного io Явы даёт огромное падение производительности, и уже при 100 игроках сервер в основном занимается тем, что пишет/читает в/из сети.

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

Здесь я постараюсь расписать серверную часть работы с сетью через Netty, может быть это кому-то будет полезно.

После настройки MySQL репликации master-master, следующий логический шаг это настройка проверки этой системы. Читая туториалы по интернету стало ясно, что подобная репликация — дело популярное, а слетает оно на раз два три. Поэтому решил вставить проверку — а работает ли репликация до сих пор, или что-нибудь произошло и все слетело.
Первые же несколько гугл запросов показали, что верить «SHOW SLAVE STATUS\G» нельзя: Штука хорошая, но врет часто и помногу. Немного подумав, я пришел к следующему решению:

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

Миграционные скрипты

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

1. Рестарт сервера — самый простой и, обычно, самый не приемлемый способ;
2. Очистка кеша через определенные механизмы — пожалуй самый оптимальный по простоте и надежности метод. Этот метод можно вынести, например в JMX, на веб страничку или другой интерфейс и вызывать при необходимости. Гибкость метода в том, что пишется это один раз, а используется сколько угодно и где угодно. В случае, если Ваш провайдер кеша — EHCache и класс провайдер — SingletonEhCacheProvider, то Ваш код может выглядеть так:
   

   public String dumpKeys() {
       String regions[] = CacheManager.getInstance().getCacheNames();
       StringBuilder allkeys = new StringBuilder();
       String newLine = System.getProperty("line.separator");
       for (String region : regions) {
           Ehcache cache = CacheManager.getInstance().getEhcache(region);
           allkeys.append(toSomeReadableString(cache.getKeys()));
           allkeys.append(newLine);
       }
       return allkeys.toString();
   }
   

   
   Естественно что этот код должен выполняться в том же процессе что и хибернейт, статистику которого Вы хотите отследить. Подробней можно прочитать тут. Того же можно добиться используя фабрику сессий.
   
3. Запуск миграционных скриптов, используя фабрику сессий работающего сервера. Это похоже на второй метод, с той лишь разницей, что мы не очищаем кеш, а пропускаем все миграционные скрипты через существующую фабрику. Таким образом все необходимые кеши обновляться сами. Этот метод рационально использовать в случае если кеш большой и дешевле его обновлять нежели создавать по новой;

Приветствую всех хаброжителей!

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

Думаю вполне резонным будет предположение, что данная тема уже набила оскомину, но все же я рискну поделиться своим опытом. На суд читателя будет представлена клиент-серверная реализация схемы резервного копирования. В качестве инструмента я выбрал open source проект Bacula. По более чем полугодовому опыту его использования остаюсь доволен своим выбором.

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

Под хабракатом я опишу все демоны подробно


В моем случае резервному копированию подлежат:

1. Конфигурационные файлы различных демонов со всех серверов.
2. MySQL базы данных.
3. Документооборот с файлового сервера Windows.
4. Различные важные данные с nix серверов(движки сайтов/форумов, etc..)

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

В свете нынешней эпохи определения всего и вся аннотациями предлагаю вам статью о Spring Framework и возможностях аннотирования проектов. Прим. перев.
В начале был EJB 2.1, с его огромным количеством XML-файлов везде где только можно. Не будет особым преувеличением, если сказать, что на одну строку кода для бизнес-логики нужно было написать по крайней мере 10 строк кода от фреймворка и две страницы XML. Локальные и удалённые интерфейсы, ручной JNDI-lookup, многоуровневые try-catch, проверки на RemoteException… enterprise, в-общем. Даже инструменты соответствующие были для автоматической генерации всей этой «кухни».

Spring Remoting

Spring framework предоставляет обширные возможности по созданию распределенных приложений. Он не только помогает создавать удаленные службы, но и упрощает доступ к ним. На данный момент в с помощью фреймворка можно организовывать удаленный доступ с помощью большого количества технологий — Caucho’s Hessian и Burlap, собственная реализация удаленного доступа через HTTP, RMI и т.д. Под катом краткий обзор возможностей фреймворка Spring для создания распределенных приложений с помощью RMI.

Этот пост является продолжением предыдущего. Мониторинг прогнозированием – не стандартный метод мониторинга. Поэтому и оповещения необходимо использовать не совсем стандартные. Рассмотрим, как это делается и почему именно так.

Это первая статья из серии «Сети для самых маленьких». Мы с товарищем thegluck долго думали с чего начать: маршрутизация, VLAN'ы, настройка оборудования.
В итоге решили начать с вещи фундаментальной и, можно сказать, самой важной: планирование. Поскольку цикл рассчитан на совсем новичков, то и пройдём весь путь от начала до конца.

Предполагается, что вы, как минимум читали о эталонной модели OSI (то же на англ.), о стеке протоколов TCP/IP (англ.), знаете о типах существующих VLAN’ов (эту статью я настоятельно рекомендую к прочтению), о наиболее популярном сейчас port-based VLAN и о IP адресах (более подробно). Мы понимаем, что для новичков «OSI» и «TCP/IP» — это страшные слова. Но не переживайте, не для того, чтобы запугать вас, мы их используем. Это то, с чем вам придётся встречаться каждый день, поэтому в течение этого цикла мы постараемся раскрыть их смысл и отношение к реальности.



Начнём с постановки задачи. Есть некая фирма, занимающаяся, допустим, производством лифтов, идущих только вверх, и потому называется ООО «Лифт ми ап». Расположены они в старом здании на Арбате, и сгнившие провода, воткнутые в пожжёные и прожжёные коммутаторы времён 10Base-T не ожидают подключения новых серверов по гигабитным карточкам. Итак у них катастрофическая потребность в сетевой инфраструктуре и денег куры не клюют, что даёт вам возможность безграничного выбора. Это чудесный сон любого инженера. А вы вчера выдержали собеседование и в сложной борьбе по праву получили должность сетевого администратора. И теперь вы в ней первый и единственный в своём роде. Поздравляем! Что дальше?

День добрый всем. Решил написать заметку о небольших средствах автоматизации, которые возникли в процессе моей работы со связкой Ant+Tomcat. Работаю java-разработчиком, с недавних пор пришлось окунуться в web-разработку на Java (надо сказать не без удовольствия). Никогда с серьезными проектами для web на java не сталкивался, игрался пару раз с примерами в рамках книжек по java из серии «обо всем по немного», но ничего серьезного. А здесь проект из полноценного портала с backend`ом для отвественных за контент, большими объемами данных в БД. Ну что же столкнулся да и столкнулся. Работа пошла, новая область знаний — интересно, мелочи не достают. Но со временем процесс сборки и развертывания приложения стал очень сильно доставать, так как в самые «жаркие» дни приходилось выполнять эту операцию раз по 40, чтобы посмотреть результат работы и прощелкать его. Вот тут и возник вопрос, нельзя ли это как то автоматизировать.

Введение

[1]
Фракталом (лат.«fractus» – дроблёный, сломанный, разбитый) называют сложную геометрическую фигуру, обладающую свойством самоподобия, т.е. составленной из нескольких частей, каждая из которых подобна целой фигуре. В более широком смысле под фракталами понимают множества точек в евклидовом пространстве, имеющие промежуточную (дробную) метрическую размерность (размерность Хаусдорфа).
Размерность Хаусдорфа – естественный способ определить размерность множества в метрическом пространстве. Размерность Хаусдорфа согласуется с нашими обычными представлениями о размерности в тех случаях, когда эти обычные представления есть. Например, в трёхмерном евклидовом пространстве хаусдорфова размерность конечного множества равна нулю, размерность гладкой кривой – единице, размерность гладкой поверхности – двум и размерность множества ненулевого объёма – трём.

В этой статье я расскажу как можно кэшировать в memcache значения, возвращаемые методами bean'ов. Для этого не потребуется писать код, достаточно добавить конфигурации в xml файлы Spring'а и разметить код с помощью аннотаций.

Итак поредставим что у нас есть DAO с тремя методами — двумя для поиска сущностей и одним для сохранения сущностей. Для правильного функционирования нам нужен интерфейс и реализующий его класс (чтобы можно было добавить dynamic proxy на реализацию)

Вот уже почти год как усиленно занимаюсь коддингом на Java. Столкнулся с довольно серьезной на мой взгляд проблемой, связанных с многопоточностью, как мне кажется, неразрешимой в рамках текущей реализации JVM от Oracle (сказанное относится к JDK 1.5 и выше). Дело в том, что на данный момент в Java нет возможности гарантированно безопасно остановить выполнение какого-либо потока. Данный пост разъясняет почему это именно так и предлагает начать дискуссию о способах решения этой проблемы.

Описание задачи:

Вы делаете проект на java под Tomcat. И решили организовать разделы своего сайта в виде поддоменов.
К примеру, на сайте www.domen.xx сделать разделы: mail.domen.xx, user.domen.xx и т.п. В какой-то момент разработки вы с удивлением обанружите, что пользовательская сессия вопреки ожиданиям существует строго в рамках одного домена. То есть юзер авторизовавшись на главной странице (www.domen.xx), переходя почту (mail.domen.xx), теряет авторизацию.

Дело в том, что сессия привязывается к клиенту через cookie с именем JSESSIONID и с пустым доменом. А когда домен не указан, браузер использует полный текущий домен. То есть сессия привязывается не к «domen.xx», а к «www.domen.xx». По неизвестной мне причине в Томкэте нет настроек позволяющих управлять этим поведением.