2011-12-01

Разное про Java, Web и Vaadin

1. Для качественного ускорения web разработки на Java можно использовать замечательный продукт JRebel zeroturnaround.com/jrebel (кратко, что это). Он позволяет практически полностью отказаться от длительного re-deploy процесса.
Внес исправление в код, перекомпилировал - web приложение уже обновилось (вроде PHP,Python,Ruby). Продукт платный, но есть интересный способ использовать бесплатно: social.jrebel.com.

Кроме того они сделали вкусную zip java lib: новость repo.


2. Если не использовать JRebel и разрабатывать используя Vaadin, то можно обнаружить, что при первом запуске vaadin приложения после старта Tomcat, оно висит несколько секунд (примерно 10 на моём ПК). Исследование показало, что "висит" не сам Vaadin, а вызванный в com.vaadin.terminal.gwt.server.AbstractApplicationServlet#serveStaticResourcesInVAADIN Tomcat.
vaadin.jar довольно большой и чтение ресурсов из него длительная операция.
Чтобы избавится от этой задержки достаточно скопировать папку VAADIN из vaadin.jar в web app root (там где WEB-INF, META-INF, etc).
Если Вам помог этот совет проголосуйте за мой совет на stackoverflow.com/questions/3904735.


3. JavaScript is assembly language for the web ИЛИ кто ещё не написал свой веб-Си?
GWT (Google Web Toolkit) - золотой стандарт компиляции в JS, все знают, многим хочется повторить.

Ладно Google начал страдать NIH синдромом и решил изобрести JavaScript (его придумали/сделали не они) dartlang.org

Но так, чтобы ВСЕ бросились компилировать в JS (включая больных и убогих)...
На 20ом языке начинает пробивать смех:
github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS

Даже QBASIC не забыт!


4. Унифицированный способ запускать различные контейнеры e.g. Tomcat из своего кода
cargo.codehaus.org


5. Для копирования DTO между разными уровнями в web приложении пригодится
dozer.sf.net

2011-07-07

Интересное про память и Java

javaspecialists.eu/archive/Issue193.html

Вообще имеет смысл прочитать все его выпуски.

В частности же:

на 64-bit серверах с 64-bit java полезно попробовать опцию
-XX:+UseCompressedOops
64bit архитектура == 64bit указатели (vs 32bit = в 2 раза больше).
С этой опцией JVM указатели (не все) оптимизирует ==
- жрет меньше памяти
- меньше байт прокачивать по шинам.

В Java7 будет сексуально выглядящий Javadoc

http://download.java.net/jdk7/docs/api/


Хотя лично мне нравится chm версия: упакованная, быстрая, со сквозным индексом и поиском.

Работа территориально распределенных коллективов

Для удаленной работы одного GMail/GTalk бывает недостаточно.
Skype ~ GTalk только без архива на сервере и более распространненый.

JIRA (и другие аналогичные продукты), Wiki, Jing - уже почти всё что нужно.

Недавно наткнулся на интересный продукт:
Team Viewer
совместная работа, презентации, удаленное управление, тех поддержка и тд
Изучаю...

fun

Стараюсь всякий нетехнический бред писать в ЖЖ.
Но убогость ЖЖ просто доканывает.
Картинку по простому нельзя разместить. Обязательно ритуал вида "найдите три китайских девственницы, поститесь с ними три года, на четверый в самую большую луну пойдите на..."

В blogger просто зашел и разместил!
В блог добавляется preview, при клике на картинке открывается полная версия.


Манул IKEA по сборке Стоунхенджа и говнотвиттер:





PS: ну и немного о технике...
Эта гребля с ЖЖ напомнила мне о книге, которую я рекомендую прочитать всем.
Жизнь внутри пузыря.
Она как бы историческая и про интернет, но работая в большой "реальной" корпорации "я плакалъ".

2011-07-04

Сравнение схем БД

Я работаю с MSSQL и MySQL и часто приходится сравнивать изменения в БД.

* Делаю так: скриптую БД с разбивкой всех объектов на индивидуальные файлы, после чего сравниваю, используя diff tool с возможностью сравнения директорий.
Очень просто и удобно.
Сама папка находится под DVCS Mercurial/HG т.е. можно смотреть историю изменений.


* Знаю про другой способ (работает в т.ч. между серверами разных версий т.к., например, скрипты MSSQL 2008 и 2000 довольно сильно отличаются).
Для MySQL: devart.com/ru/dbforge/mysql/studio
Для MSSQL: devart.com/ru/dbforge/sql/datacompare
Сам активно не пользовал, но один знакомый активно использует и очень хвалит.

* Есть что-то ещё?...

2011-05-15

Скриншоты и скринкасты - просто и удобно

Потребовалось отправить в Jetbrains screen-cast бага (что он существует ;-).

Провел небольшое исследование: чем быстро и просто записать короткий screen-cast (изображение части экрана, курсор, звук с микрофона).
Нашел несколько вариантов, в итоге выбрал jing

Просто (ничего не надо настраивать), удобно.
Делает помимо видео, фотки куска экрана (PrtScn и последующее вырезание в редакторе достало).

Думаю о дальнейшем использовании.

PS: для скриншотов есть OpenSource sf.net/projects/greenshot - сегодня рассылка SF-ная принесла

UPD2: http://camstudio.org/ OpenSource утилита для записи скринкастов

2011-04-05

2011: Сменил default кодировку консоли cmd.exe на cp1251

Как известно default  кодировка/codepage windows консоли cmd.exe DOS 866.
На дворе 2011 и я решился сменить её на кодировку остальной системы cp1251.
Узнать какая кодировка выставлена, можно набрав в cmd.exe команду chcp.
Сменить "на лету" можно chcp 1251.
С UTF-8 chcp 65001, как мы уже выяснили не работает.

Чтобы сменить на постоянной основе требуется:

Start->Run->regedit
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage
сменить кодировку в OEMCP с 866 на 1251

После чего потребуется перезапуск.

Найдено здесь.


Пора избавляться от старого барахла.
Если очень захочется запустить что-то старое DOS-овское "chcp 866" в помощь.

Замеченые минусы:
давно надо было у архиваторов выставить кодировку файлов UTF-8, пришлось некоторые архивы пережать.

2011-03-22

Mercurial - Hg

Начал читать http://hginit.com
Читая раздел для SVNщиков утер слезу - до чего верно пишет.

После этого полезно mercurial.selenic.com/guide


В UTF-8 не работает (глюк windows). Поэтому не chcp 65001 (меняет кодировку консоли на UTF-8), а chcp 1251 - ваш друг.
Для работы удобнее всего оказался cmd.exe /X /K chcp 1251 && cd "путь"

Отличная утилита HgWin, вызывается из командной строки (hgwin cmd) и открывает GUI окошко. Если сразу в GUI, то TortoiseHG вполне.

Отличная короткая статья об организации процесса подходящего и для моих проектов: http://stevelosh.com/blog/2010/05/mercurial-workflows-stable-default/

Относительно коммитов решил, что буду коммитить часто. Как ограничение "вечером не должно оставаться незакоммиченной работы".
Чтобы не зафлудить репозитарий сырым кодом буду применять следующее соглашение:

1. закомичиваемый код должен компилироваться (этого можно достичь даже вечером, пустые методы с todo написать и тд)
2. если тесты не прошли или нет времени на все тесты, то commit message должен начинаться с "?": ?Обзвон нескольких телефонов в списке
3. если тесты проходят и по ощущениям код хороший, то commit message не начинается с ? и ! т.е. любые другие символы
4. если код отлично прошел тесты на DEV SERVER и его можно пытаться выкладывать на PRODUCTION, то commit message начинается с !
5. на бой выкладываются только ревизии с commit message начинающиеся на !
6. после выкладки на бой (вроде полетело, чуток поглядели - летит) тегируем версию "YYYY-MM-DD major.minor примечания"
7. после некого интервала (ничего не вылезло, клиенты не звонят с воплями) мержим default в stable

x. если вдруг потом обнаружен баг, переключаемся на "YYYY-MM-DD
major.minor примечания" в stable, правим / build, test, func/sys test, deploy / tag "ymd major.minor примечания"2, merge это исправление в default

y. если хочется надолго всё сломать - локальный feature clone. Из которого потом pull, merge в local#default и rm -rf feature clone


PS1:
Мучился вопросом: как бранчи случайно названные одинаково разными программистами не пересекаются?
Ответ: пересекаются! Рекомендуют именовать приватные бранчи "программист-название бранча".
http://nubyonrails.com/articles/five-features-from-mercurial-that-would-make-git-suck-less

Про бранчи vs клоны общий совет такой:
для собственных нужно лучше делать локально клоны.
Именованые бранчи для длительных линий разработки, типа есть три версии программы 1.0, 2.0, 3.0. Переход на новую версию стоит денег и не все пользователи переходят, сидят на 1.0 и 2.0, однако баги, возможно какие-то вкусняшки им давать необходимо (они купили). Дескать это хорошее применение для бранчей.


PS2:
Разумеется все теоретики запада против хранения генерируемых файлов в репозитарии - их можно моментально создать, любой версии, когда понадобятся (class, jar, war, ear, javadoc).
Сгенерированные исходники (Google Protobuf, из WSDL) - нельзя менять, но хранить в VCS можно. Для анализа, что менялось или "почему всё сломалось". Но менять нельзя!
Если в сгенерированные исходники надо внести изменения - советуют от них наследоваться, либо использовать композицию, тогда сгенерированный код может следовать за обновлениями, а не  останется на века в той версии где подправили.