суббота, 26 февраля 2011 г.

Java в Ubuntu

В Ubuntu по умолчанию стоит OpenJDK, что для разработчика 'как то не привычно'. Xочется видить и пользовать Sun JDK.

1. Разрешаем использовать пакеты из зеркал партнеров. Для этого:
- открываем /etc/apt/sources.list и раскоментриуем вхождения для restricted и pertner зеркал.
- обновляем список пакетов sudo apt-get update

2. Устанавливаем желаемую JDK:
sudo apt-get install sun-java6-bin sun-java6-jdk sun-java6-jre

3. Добиваемся использования Sun JDK вместо OpenJDK. Тут есть варианты:
3.1. Прописать в настройках приложений (например Eclipse) пути именно к /usr/lib/jvm/java-6-sun и на этом успокоится.
3.2. Изменить 'JDK по умолчанию': sudo update-alternatives --config java. Логика подсказывает, что это наиболее безопастный способ, но другая логика подсказывает, что держать на винчестере 2 экземпляра джавы как то не правильно (расточительно). Поэтому....
3.3. Полное удалени неиспользуемых пакетов. Лучше делать через Sinaptic: грохнуть все пакеты, которые начинаются с openjdk. В результате освобождаем 100-200 МБ

четверг, 3 февраля 2011 г.

Знакомство с Hudson

Пришлось познакомится с CI системой Hudson.
Первое впечатление очень даже ничего:
  • при своей бесплатности, выглядит на редкость представительно и имеет кучу возможностей;
  • довольно просто устанавливается и конфигурируется;
  • для тех кому мало существующего функционала, есть возможность дописывать свои плагины. Кстати API выглядит довольно многообещающе;
  • ну и естественно, кросплатформенное приложение.
На первый взгляд, система довольно легко может заменить такие продукты как TeamCity и Bamboo. А мрачное убожество СС здесь и рядом не стояло:)

Из минусов:
  • для разработчика плагинов ну очень мало информации. Возможно я еще чего то еще не знаю, но пару обзорных статей и устаревших/не работающих туториалов как то не внушаю оптимизма;
  • последние пол года проект как то колбасит. Видно что недавно они перехали на новый домен java.net + совсем недавно проект решил сменить свое название на Jenkins (тут и тут). И это, тоже, вносит свою долю неразберихи.

пятница, 31 декабря 2010 г.

31 декабря - Работаем!

Человек, который надеется что 31 программист будет эффективно работать, либо садист, либо имбицил.

понедельник, 13 декабря 2010 г.

Немножко о холиварах

Предыстория

Решил попробовать Google Chrome (GC) на работе . Основной причиной было:
  • более удобная строка ввода адреса (совмещенная с поисковиком)
  • бОльшее пространство под страницы. У FF это Заголовок окна + строка ввода + верхняя панель + закладки + нижняя панель, у GC Закладки + верхняя панель
  • ну и конечноже 'восторженные вопли очевидцев': да он супер!, да он реактивный!, да он кульный/гламурный и т.д.

Проблемы с памятью

После запуска насторожил объем использованного ОЗУ. Решил провести 'следственный эксперимент':
  • Открыто порядка 20 закладок. Немного JS, и очень чуть-чуть Flash (несколько банеров)
  • Google Chrome 8.0.552.215, FireFox 3.6.12. Оба портабельные версии, установлены все необходимые плагины/дополнения
  • Оба браузера стартуют с USB-HDD (дабы ограничит скорость чтения + протестировать работу в боевых условиях)

По очереди запускаем браузеры и смотрим на использование ОЗУ (Windows Task Manager).
Результат меня поразил: FF: 260MB, GC: 1210MB.
В принципе на этом этапе уже все стало ясно: это абсолютно не допустимо тратить 1,5ГБ памяти на 20 страниц (тем более в свете того, что для программистов память это довольно ценный ресурс).
Но, решил проверить "скорость работы".

Оценка быстродействия

Этап 1. От "Клик на иконку" до "Видим готовое к использованию окно (страницы еще не недогруженные)" FF: 6 сек., GC: 1-3 сек.
Этап 2. От "Видим окно" до "Полное восстановление сессии (все страницы загрузились)". FF: 20 сек., GC: 58 сек!!! (30 сек на определении proxy и 28сек. на загрузку всех страниц)
Этап 3. Открытие новой страницы и повторное открытие той же страницы. FF: 5сек/2сек, GC: 5сек./4сек. В качестве примера взята демка icefaces: удивило более быстрое повторное открытие в FF (кеширование или работа JS интерпретатора??).

Выводы

  1. Если вы думайте, что ваш FireFox кушает много памяти, запустите Chrome. Для меня 1200МБ для 20 страниц это непозволительная роскошь!
  2. Похоже, что хваленный быстрый старт Chrome это очередной лохотрон от великого и ужасного. Вспомнился 'более быстрый' старт WinXP по сравнению с Win2000
  3. В работе оба браузера примерно одинаковы. Какой-то супер скорости одного перед вторым замечено не было
  4. В хроме ужасно неудобно работать с закладками
  5. В хроме не нашел некоторых очень полезных плагинов, например WebDeveloper, ScrapBook и FlashGot
Похоже что Chrome пока 'не катит' на роль рабочего инструмент программиста.

среда, 8 декабря 2010 г.

Знакомство Runtime.exec()

Недавно захотелось запустить 'нечто' из Java приложения. В роли 'нечто' был 7Zip, в роли приложение было обычный SE класс с методом main().
Так вот, наткнулся на несколько интересный моментов.

Консольный ввод/вывод нового процесса

Итак, у java.lang.Process есть методы позволяющие работать с stdin, stdout и stderr потоками. Но выяснилось, что не все, что выводится на консоль, попадает в потоки stdout/stderr. Для примера можно запустить 7z.exe b. Есть предположение, что подобным образом ведут себя почти все Java приложения. Также есть предположение, что виной этому работа с буфером консоли 'напрямую' (насколько я понял из объяснений, например это вывод символа в заданную позицию консоли).

Скользкие моменты java.lang.Process

Очень понравилась статья When Runtime.exec() won't

среда, 1 декабря 2010 г.

Знакомство с принципами SOLID проектирования

Знакомство начал вот с этого:
- Хороший дизайн должен быть SOLID: TOP-5 архитектурных принципов - коротко и ясно (на русском и с картинками :) )
- вот где то здесь - серия очерков по каждому из принципов. Но на данный момент, сайт автора 'спит' и на внешние раздражители не реагирует