пятница, 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 архитектурных принципов - коротко и ясно (на русском и с картинками :) )
- вот где то здесь - серия очерков по каждому из принципов. Но на данный момент, сайт автора 'спит' и на внешние раздражители не реагирует

О декомпозиции методов

Часто приходится встречаться с длинными методами. Реакция на 'это' может сильно зависеть от сложности и времени суток: от "ничего сложного, щас разберемся!" (утром), до "дайте я кого нибудь пристрелю!" (под вечер, когда натыкаешься на 'это' под конец рабочего дня).
Попытки разбить длинный метод на 'много маленьких' не всегда заканчиваются успешно... и регулярно возникают вопросы: 'почему так?' и 'что с этим делать?'