Java *

Весь поисковый индекс Google размещается в RAM памяти уже как минимум 5 лет. Почему бы не попробовать сделать то же самое и с поисковым индексом для Lucene?

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

Очевидный вопрос – не попробовать ли нам загрузить весь индекс, в предоставляемый Lucene класс RAMDirectory?

Если вы уже знаете, что такое Maven и хотите собрать простое модульное веб приложение (если нет- можно прочитать топик о нем и основы). Тема данного топика- как сконфигурировать pom.xml, добавить отдельный модуль к проекту, подключить плагины, развернуть приложение на сервере Apache Tomcat.

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

1. Darcula

Главная и очень хорошая новость: в JetBrains работают (в частности stalk) над стандартной темной схемой. Она будет подключаться через look and feel и будет называться Darcula. Она уже включена в исходники для Comunity Edition и попадет в новые EAPы.

• На данный момент она выглядит вот так:
  
• А вот тут можно посмотреть видео: www.screenr.com/asl8

Это узкоспециализированная короткая заметка про то, как я запинывал write once, run everywhere тесты для библиотеки, портированной с C# на Java, при помощи Python.

Смысл в следующем: есть большая, толстая и красивая библиотека, которая была по коммерческим соображениям портирована с C# на Java. API осталось почти одинаковым, naming conventions естественно сменились при переходе на другой язык. Нам нужно было написать толстую пачку тестов, проверяющих, что клон библиотеки работает идентично оригиналу (тесты на регрессии, иными словами). Для этого сравнивались результаты работы кода библиотек (некие бинарники и xml-метаданные). Тесты были нетривиальные, их было много, и что самое неприятное — они постоянно дописывались с одного конца командой из четырех человек. Некоторое время я старательно портировал их на Java, затем плюнул и предложил команде писать тесты на языке, который сразу можно было бы выполнять на CLR (со старой библиотекой) и на JVM (с клоном). Оказалось, они и сами уже некоторое время думали про Python,

Предисловие

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

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

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

Когда-то поставили передо мной задачу начать разработку Web-сервисов и дали мне сорцы простейшего проекта без каких-либо объяснений. Проект, конечно же, не запускался. Что такое Spring и как он работает, я тоже представления не имел. Адекватных статей по разработке Web-сервисов средствами Spring ни русскоязычных, ни англоязычных я тоже не смог найти. Пришлось разбираться во всем самому, оказалось все не так страшно.
И вот недавно я решил посмотреть, какие новые возможности добавились в Spring с тех пор, и обновить старые сервисы, что в результате и сподвигло меня на написание данной статьи.

Данная статья является руководством по разработке простейшего Web-сервиса, использующего SOAP-протокол, средствами Spring-WS.

Споры о том, что лучше: ручное управление или автоматическое ведутся во многих областях науки и техники. Положиться на человека или отдаться на откуп бесстрастным механизмам и алгоритмам? Похоже, что в мире создания Enterprise решений чаша весов склонилась все-таки в сторону автоматического управления памятью, большей частью из-за того, что возиться с указателями, ручным управлением памятью и закрашивать седину после каждого бага, появившегося из-за «неправильного» компилятора С/C++ не хочется сейчас уже никому. Но до сих пор возникают на форумах топики, где не сдающиеся суровые приверженцы ручного управления памятью яростно и непримиримо отстаивают свои ретроградные взгляды в борьбе с прогрессивной частью человечества. Пусть их, оставим их в покое.

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

В прошлом месяце Red Hat объявила о покупке компании Fusesource, разрабатывающей несколько продуктов категории «middleware». В интервью InternetNews, Red Hat CEO, Джеймс Уайтхерст (Jim Whitehurst) рассказал, почему в Red Hat решили купить FuseSource, а не развивать собственные конкурирующие решения.

Когда нужно купить конкурента, а когда разрабатывать собственные продукты? Это сложный вопрос для любой компании, но ещё сложнее он становится, если дело касается открытого ПО.

Проводя уже около 6 лет собеседования с Java-разработчиками заметил, что из приходивших кандидатов вообще никто не знает, что можно штатными средствами JDK удалённо мониторить состояние JVM с контейнерами сервлетов.
Поэтому далее пошаговый рецепт, как настроить и использовать эту замечательную возможность

Кажется, что Js — это «просто скриптовый язык» на котором я по-быстрому добавлю нужные фичи на странице, не сильно заботясь о качестве кода. Когда-то это было верным. Даже текущие стандарты Js и Html в целом располагают к этой философии.
Но времена изменились! Теперь на Js создают сложные и запутанные веб-приложения, которые просто не могут не столкнуться с проблемами своих «старших братьев» (серверных приложениях написанных на Java, C# и т.д.). А значит, чтобы не погрязнуть в тысячах строк «спагетти-кода», требуется отказаться от философии «просто скрипт». Нужно воспринимать Js как инструмент, с которым требуется создать сложную, модульную и масштабируемую систему.

В рамках новой философии «серьезного языка, для серьезных задач» я хочу начать цикл небольших статей о мире Js со стороны Java разработчика. Начнем с инструментов и различных шаблонов разработки.

На прошлой неделе состоялся успешный эксперимент по запуску нового решения для download-сервиса. Один достаточно скромный сервер (2 x Intel Xeon E5620, 64 GB RAM) под управлением Java-приложения собственной разработки принял на себя нагрузку восьми Tomcat'ов, обслуживая более 70 тысяч HTTP-запросов в секунду общей пропускной способностью 3000 Mb/s. Таким образом, весь трафик Одноклассников, связанный с пользовательскими смайликами, обрабатывался одним сервером.

Вполне естественно, что высокие нагрузки требовали нестандартных решений. В цикле статей о разработке высоконагруженного сервера на Java я расскажу о проблемах, с которыми нам пришлось столкнуться, и о том, как мы их преодолели. Сегодня речь пойдет о кешировании изображений вне Java Heap и об использовании Shared Memory в Java.

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

Уже догадались, о чем будет статья?

Третий год занимаюсь разработкой крупной системы на Java с использованием СУБД PostgreSQL. Система десктопная, клиент-серверная. Опытного Senior-Java-Developer-а у нас нет, поэтому приходится думать самим. Думать, строить, ломать, строить заново, опять ломать…
За время работы накопился некоторый опыт как по организации непосредственно работы с БД, так и по взаимоувязыванию этих платформ, о котором и хочу рассказать в этой статье.

Опишу выборочно некоторые вопросы, с которыми мы столкнулись при разработке и которые решили.

Однажды, в студеную зимнюю пору, в одно старое приложение на С++, успешно работавшее до этого годами, пришлось вставить новый Java runtime 7 вместо отлично работавшего Java 6. Ничто не предвещало, и вдруг.

Код в общем-то очевиден и прост — немного JNI, и вот он — больной зуб. Приведу код только для Windows, т.к. чудеса эквилибристики под маком не потребовались.

Данный материал изначально был подготовлен в качестве раздела статьи “Первые шаги в Robocode”, но я решил вынести его, т.к. он значительно увеличивал размер и без того большой первоначальной статьи и не является базовым и необходимым для осуществления первого шага. Если вы сразу заинтересовались вторым шагом или постепенно доросли до него, то прошу под кат.

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

• http://www.youtube.com/watch?v=dqHmp_kMz-U — Дуэль
• http://www.youtube.com/watch?v=eqlPbtO3rQY — Дуэль
• http://www.youtube.com/watch?v=zx7xFJiBGZQ — Схватка, >2 роботов, каждый за себя
• http://www.youtube.com/watch?v=EJPskFGvGi8 — Схватка, стоит обратить внимание на робота Portia (бирюзовый) — это один из лучших бойцов в этой категории

disclaimer Так получилось, что последний месяц я разбираюсь с ZooKeeper, и у меня возникло желание систематизировать то, что я узнал, собственно пост об этом, а не о сервисе блокировок, как можно было подумать исходя из названия. Поехали!

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

От распределенного сервиса блокировок разумно требовать:

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

Создать подобный сервис нам поможет ZooKeeper

В википедии написано, что ZooKeeper — распределенный сервис конфигурирования и синхронизации, не знаю как вам, но мне данное определение мало что раскрывает. Оглядываясь на свой опыт, могу дать альтернативное определение ZooKeeper, это распределенное key/value хранилище со следующими свойствами:

• пространство ключей образует дерево (иерархию подобную файловой системе)
• значения могут содержаться в любом узле иерархии, а не только в листьях (как если бы файлы одновременно были бы и каталогами), узел иерархии называется znode
• между клиентом и сервером двунаправленная связь, следовательно, клиент может подписываться как изменение конкретного значения или части иерархии
• возможно создать временную пару ключ/значение, которая существует, пока клиент её создавший подключен к кластеру
• все данные должны помещаться в память
• устойчивость к смерти некритического кол-ва узлов кластера

Я — Jdev, автор Robocode-бота Tomcat, который в ноябре/декабре 2011 года был Королём Премьер Лиги общего зачёта Robocode (пруф) без единого поражения, сейчас занимает 3-е место из 911 в процентном зачёте и является героем моего повествования. В этой статье я рассказываю о своём шестилетнем пути к победе.

Совсем недавно, перейдя на новый проект, я решил для разнообразия также перейти с Eclipse на Idea. С идеей у меня уже был опыт еще с 6-й версии, она мне нравилась, но проблем у нее было достаточно много. Тогда я отказался от нее в виду периодических глюков при долгой работе. Увидев, что уже на дворе 11-я версия я обрадовался и решил опять попытать счастья, так как по интерфейсу идея для меня гораздо приятней…

Около месяца назад заметил, что при активной разработке, когда выделенные под кучу 768мб памяти заполнены под 80%, любое действие, вроде движения мышкой, переключения фокуса, просто прокрутка колесом мышки или непосредственно скроллом в окне вызывает большое потребление памяти и оставшиеся 20% памяти съедаются за несколько секунд работы. После чего, естественно, про комфортную работу можно забыть и приходится перегружать среду в виду постоянного срабатывания сборщика. Сегодня эта ситуация меня окончательно достала и я решил узнать — в чем же собственно проблема?

Интуитивно я понимал, что вероятней всего каждое движение мышки и любое действие вроде прокрутки генерирует определенные события, которые потом обрабатываются, но ТАК МНОГО этих событий я не ожидал. Для затравки — 2 скриншота потребления памяти при движении мыши в окне редактора и скроллинге внутри открытого класса на 1000 строк:

Движение:
Скроллинг:

Обычная прокрутка в окне редактирования кода в пике съедает почти 100мб памяти за несколько секунд… Любое движение мыши генерирует объектов на десятки мегабайт… Единственный позитивный момент во всем этом, что все эти объекты потом собираются.

17 Июля город Киев. Speakers' Corner: «OSGI in banking environment»


Приглашаем неравнодушных Java разработчиков обсудить возможности OSGi (Open Services Gateway Initiative) — спецификация динамической плагинной (модульной) шины для создания многофункциональных Java десктоп-приложений и энтерпрайзных систем.

Наш гость из Женевы, Java специалист с 15-летним опытом Fulco Houkes расскажет об использовании OSGi для банковской инфраструктуры. Внимание! Доклад и обсуждение будут проходить на английском языке без перевода!

Темы к обсуждению:
• Banking challenges
• An elegant solution: OSGI
• What is OSGI?
• OSGI best practices & pitfalls