Разгоняем ThreadLocal

Всем серьезным и не очень программистам из мира Java известен данные класс. Он привязывать объект к конкретному потоку. Достаточно часто используется в многопоточных приложениях, наш сервер также не стал исключением. А раз у нас самый многопоточный из многопоточных серверов – то используется данный класс достаточно часто – на одну входящую команду с клиента раз 20 точно. Сегодня я провел тестирование скорости работы данного класса, оказалось всего лишь 7 000 операций get() за одну миллисекунду. Пришлось ускорять и вот каким методом – у каждого Thread есть метод long getId() который возвращает уникальный идентификатор потока, но также не следует забывать, что если поток умирает – то данный идентификатор может реиспользоваться.
Читать далее Разгоняем ThreadLocal

NoSQL Redis – первые шаги

Решение отказаться от PostgreSQL и перейти на Redis было принято еще полтора месяца назад. Но только сегодня практически полностью завершена интеграция базы в платформу. Изначально для доступа к базе данных я использовал JRedis. Чуток позже выяснилось, что он поддерживается не все команды, в том числе он не поддерживал работу с hash. А это для нас критично. Пришлось править код и добавлять поддержку данных команд, поддержку то я сделал, но разбираясь в чужом коде понял, что это совершенно не Realtime решение. А сборке мусора автор даже не подумал, куча объектов, структур и классов. Сам проект – 200 классов самого разнообразного назначения. И поэтому пришлось самому писать API для доступа. В итоге – 5 классов и 10 JUNIT тестов, поддержка всех существующий команд. Работа с сокетами на уровне ByteBuffer и NIO. Пул коннектов, шардинг и многое другое. И все это работает в OSGi. Исходный код дать не могу, но кому интересно – пишите, по крайней мере на вопросы отвечу. По скорости процентов на 30% быстрее чем JRedis, по памяти раза в три и главное не создает объектов в процессе работы.

Redis меня в последнее время радует, недавно сделали поддержку виртуальной памяти, в итоге можно хранить достаточно большое количество данных, нам вполне хватит. А поддержка сортированный SET вообще сказка, именно на нем мы будем делать TOP рейтинг игроков (пример можно посмотреть на http://tankionline.com).

Scrum vs Ваша компания

Периодически в небольших компаниях по разработке ПО случаются революции. Например главные по направлениям пытаются поменять методологию разработки. Я тоже честно пытался. Но все не выходит и не выходит, хотя частично мы уже работаем по данной методике, но нам еще очень далеко до идеала. Одна из причин – высокая загруженность, нет времени на плановое внедрение новых методов и методолгий. Сегодня прочитал еще одну статью по этому поводу, и что самое интересно – практически наша ситуация, может быть у нас чуток лучше, но все же. (далее цитирование)
Читать далее Scrum vs Ваша компания

Альтернативная навигация по исходникам в Eclipse

Каталоги и файлы являются в настоящий момент самым распространным способом навигации по коду. Но на мой взгляд не очень удобным. Например, у меня открыто 10 проектов и я хочу быстро перейти к классам, которые используют рейтинг игрока. Навигация по каталогам такого удобства мне не предоставляет, прийдется вспоминать в каких именно классах я использоваль рейтинг, потом открывать пару каталогов и сам класс. И повторить эту операцию N раз.
В ходе дебатов родилась такая идея – к стандартной навигации добавить навигацию по тегам. Программист в комментах для класса описывает теги – @tags rating user battle. А плагин для Eclipse отображает данные теги в виде облака и позволяет быстро открывать нужные классы и файлы.
Вот такая идея. Реализовать бы 🙂

XSLT, SVN и Пермские WEB Студии

В далеком 2003 году делал я сайт Западно-Уральского Сбербанка. И врядли я бы его вспомнил сегодня если бы не два обстоятельства:
1) в качестве языка шаблонов использовался XSLT
2) сегодня я набрел на презентацию – http://veged.ru/works/WhyXSLT_CS.pdf

В не менее далеком 2002 году у нас было много спорос с одним из товарищей – стоит ли применять эту технологию или нет. Основной аргумент против с его стороны – сложность и неудобность. И в этом он прав – как ни крути XSLT это практически ФУНКЦИОНАЛЬНЫЙ язык программирования. Кто же его будет то изучать. Вот так и сидит у нас в Пермь куча PHP программистов, которые пишут хорошии сайты небольшой величины и крупные сайты с отвратной архитектурой и большим количеством ошибок. Не хотят учится и не будут.

А такие слова как SVN, JIRA, SCRUM для них как индийский язык. Вот поэтому ни одна из веб фирм в перми ничего не достигла. Пока нет ни одного положительного примера в разработки сложных веб сайтов.

Занятная ошибка при реализации интерфейса Comparator

Два варианта кода – первый работает почти всегда корректно, второй всегда:

  RATING {
	Comparator comparator = new Comparator() {
	    public int compare(UserInfo o1, UserInfo o2) {
		return (int)(o2.rating-o1.rating);
	    }
	};

	@Override
	public Comparator comparator() {
	    return comparator;
	}
    },
  RATING {
	Comparator comparator = new Comparator() {
	    public int compare(UserInfo o1, UserInfo o2) {
		return new Float(o2.rating).compareTo(o1.rating);
	    }
	};

	@Override
	public Comparator comparator() {
	    return comparator;
	}
    },

Разница проявляется только на значениях близких к нулю – (int)(0-0.4) всегда дает 0 в результате, а для компаратора это означает равенство значений.

Pcollections. Persistent Java Collections Library

Занятная штука – НЕИЗМЕНЯЕМЫЕ аналоги Java коллекций. Зачем оно надо ? Для некоторых алгоритмов и многопоточных программ самое то. Один из примеров

import pcollections.*;
public class Example {
  public static void main(String... args) {
    PSet set = HashTreePSet.empty();
    set = set.plus("something");
    System.out.println(set);
    System.out.println(set.plus("something else"));
    System.out.println(set);
  }
}

Результат:
[something]
[something else, something]
[something]

http://code.google.com/p/pcollections/

Облако Google теперь поддерживает Java

http://www.youtube.com/watch?v=c7LzQbEEY5o
Отличная может получится штучка например для онлайн игр.
Аналога наших танков конечно не написать, но war.ru например запросто можно было сделать. 100% масштабируемость, легкость программирования, нет проблем с дата центром – и это только начало.

Офф страница: http://code.google.com/intl/ru/appengine/docs/java/overview.html
Плагин для Eclipse: http://code.google.com/intl/ru/appengine/docs/java/tools/eclipse.html

Этапы разработки ПО

* есть общая идея – пишем прототип, пока писали, поняли что хотим;
* превращаем прототип в сложный набор кода, так как ТЗ все время меняется и уточняется, переписываем участки кода по нескольку раз – самый длительный этап – 60% времени;
* УРА – мы утрясли ТЗ и поняли в чем ошибались;
* переписываем все за два дня и на ПОРЯДОК снижаем размер и сложность программного кода;

Такой подход требует в два раза больше времени, зато позволяет не писать сразу полностью все ТЗ. Я в Перми вообще не знаю людей кто бы смог сразу и все описать в ТЗ. Если кто знает – скажите. Но чтобы он сразу бы сел и за две недели выдал подробный документ.