Niecały miesiąc temu odbył się, piąty już z kolei, JavaCamp w Krakowie. JavaCamp to seria „większych” spotkań organizowany przez Polish Java User Group. Naszym pomysłem na spotkania JUGowe jest jak widać „rzadziej, a więcej”, trochę inaczej niż pozostałe JUGi które zazwyczaj spotykają się regularnie, za to na jedną prelekcję. W związku z tym, że obecnie pracuję w XSolve wpadliśmy (piszę „my” jako członek PJUGa jak i zespołu XSolve) na pomysł zasponsornowania tego wydania JC, a teraz nareszcie możemy pochwalić się umieszczonymi nagraniami z spotkania na parleys.com (kto nie zna – niech wejdzie i pozna).

Na pierwszy ogień poszedł Łukasz Lenart, który opowiedział troszkę o byciu lepszym programistą, miękkich umiejętnościach oraz na przykład Zen To Done lub znanym Pomodoro. Prezentacja bardzo przyjemna i omawiająca rzeczy „wydawałoby się że oczywiste”. Problem leży w tym że czasami (hah! A może nawet „często”?!) o tych rzeczach najprostszych się zapomina wpadając w wir ślepego klepania kodu… ;-)

Drugą prezentację prowadziłem ja, a temat był oczywiście jednym z dla mnie obecnie bardzo (bardzo) istosnych: rozproszone systemy kontroli wersji, a konkretniej: git. Była to moja pierwsza prezentacja przed „większą” publicznością i mimo drobnych komplikacji („demo syndrome”… ;-)) przekazałem uczestnikom dość dobrą dawkę użytecznych informacji na temat git’a, co może potwierdzić wzmożone zainteresowanie i migracje wśród znajomych od czasu tej prezentacji…

Po przerwie na pizzę ufundowaną przez XSolve, do prezentowania przystąpił Łukasz Żmudziński. Proszanym tematem był projekt Lombok – który swoją drogą niedługo później autorzy bardzo wesoło prezentowali na niemieckim Devoxx :-). Lombok za cel stawia sobie zdjęcie z programistów Java smętnego klepania tak zwanego boilerplate („ten szum który musimy naklepać w każdym POJO etc etc”).

Ostatnia prezentacja tego dnia poruszyła tematykę również mi bardzo bliską i ciekawą: TDD, na przykładach. Łukasz Czerpak pokazał na licznych przykładach jak powinny wyglądać dobre testy. Jego przykładowe testy (których było mnóstwo) były dla mnie dość ciekawe jako, że z EJB większej styczności dotychczas jeszcze nie miałem.

To by było na tyle nagrań z piątej edycji JavaCamp’u. Zapraszamy na przyszłe (już niebawem) oraz oczywiście na nadchodzący wielkimi krokami GeeCON. :-) W razie zainteresowania innymi nagraniami i przyszłymi spotkaniami Polskiego JUGa, zapraszamy na java.pl oraz nasz kanał na parleys.com… :-)

W związku z tym, że mój zespół korzysta z troszkę dziwnego formatowania źródeł (przez eclipse, z którego nie korzystam) a inne IDE nie do końca idealnie potrafią odtworzyć zachowanie tego formattera, czasami zdarzało mi się wcommitować kilka(naście) linii gdzie jedyną zmianą była na przykład różnica o jedną spację. Korzystałem przez pewien czas z pluginu external-formatter do IntellJ IDEA jednak przy moim dość częstym wykorzystywaniu automatycznego formatowania kodu okazało się to „trochę” nie wydajne i irytujące…

Na szczęście od pewnego czasu przerzuciłem się na git-svn i mogę sobie obecnie lokalnie pozwolić na wykorzystywanie jego pełnego potencjału. Jedną z sztuczek którą podsuwa nam pod nos git są tak zwane „client-side-hooks” oraz komenda „git alias„, o wiadomym wydaje mi się przeznaczeniu :-) Hooki, w dwóch słowach, to podobnie jak w innych SCMach, „skrypty wołane w pewnych momentach flow takiego systemu kontroli wersji”. W git możemy je również instalować również po stronie klienta – w dodatku, jest to bardzo proste: umieszczamy odpowiednio nazwany plik wykonywalny (skrypt) w folderze .git/hooks/ i gotowe.

Ponieważ nie dałem za wygraną z korzystaniem z tego samego formattera co reszta zespołu, pierwszym pomysłem był właśnie hook, który by to przed każdym commitem formatował wszystkie moje źródła eclipsowym narzędziem. Nie wołałbym go aż tak często jak w przypadku formatowania wewnątrz IDE podczas pisania, a mimo wszystko od repo trafiałby jedynie legalnie sformatowany kod. Kilka linijek niżej został umieszczony wspomniany skrypcik. Aby został „zobaczony” przez git’a wystarcza go odpowiednio nazwać i umieścić w folderze .git/hooks/ a konkretniej: „.git/hooks/pre-commit” i tyle, git zajmie się resztą.

Aby rozwiać wątpliwości co do pliczku org.eclipse.jdt.core.prefs – pochodzi on z projektu eclipse’owego w którym przy formaterze zaznaczymy aby „korzystał z osobnych ustawień formattera dla tego projektu. Ten pliczek zostanie wówczas wygenerowany do folderu .settings. Wracając do meritum posta, zobaczmy jak ten skrypt się sprawdza:

Mimo braku wspominanych przezemnie dziwnych elementów tego formatowania w tej przykładowej klasie – wyraźnie widać iż nasz hook zadziałał jakbyśmy się tego spodziewali. Niestety to również okazało się troszkę za wolne jak na mój typowy flow, gdzie bardzo często commituję, a do svn wypycham jedynie „większe spójne całości”, kolejnym krokiem było przepisanie tego hook’a na własne polecenie git’a. Konfiguracja tego jest jeszcze prostsza niż ustawienie hooka:

git config --global alias.eclipse-formatter '!~/git-hook-eclipse-formatter'

Warto zauważyć składnię !command którą git alias wspiera od wersji 1.5.0. Działa, jak zapewne już się domyśliliście po prostu pozwalając na wykonanie dowolnego programu (zanim wprowadzono obsługę składni !command możliwe było jedynie wołanie innych komend git’a). Zobaczmy czy działa to tak jakbyśmy się tego spodziewali:

I rzeczywiście, nie dość, że uzyskałem teraz wygodny dostęp do formattera kodu mojego zespołu to dostęp ten jest „globalny”, w sensie „w każdym repozytorium git mogę wykonać tą komendę”. Sama operacja aliasowania nie musi być wcale wykonywana przez git, jak widać polega ona przecież tylko na dopisaniu odpowiedniej linijki w pliku ~/.gitconfig albo, gdybyśmy chcieli uzyskać to samo na poziomie projektu (a nie „globalnie”) do .git/config. Wisienką na torcie jest iż bash poprawnie będzie podpowiadał naszą komendę… :-)

To by było na tyle… Happy hacking!

SVN jest jednym z najpopularniejszych i najpowszechniej używanych systemów kontroli wersji w dzisiejszych czasach. Nie oznacza to jednak, że jest rozwiązaniem najlepszym. Coraz większą popularność zyskują rozproszone systemy kontroli wersji, takie jak Git, Mercurial czy Bazaar. W tym artykule skupimy się na Gicie, który został stworzony przez Linusa Torvaldsa, w celu wersjonowania kernela Linuksa (zastąpił BitKeepera). Nie sposób wymienić wszystkich zalet, ale można wymienić kilka projektów, które go używają, co pokaże jego pozycję na rynku: Andorid, Arch Linux, Fedora, Gimp, Gnome, jQuery, OpenSuSE, Perl, Ruby On Rails, Wine, X.Org.

Poniżej pokażę rozwiązanie następującego problemu: „jestem programistą, znam i lubię Gita, ale w mojej firmie używa się SVNa”. (więcej…)

Od zeszłego tygodnia mam niewątpliwą przyjemność uczestniczenia w praktykach organizowanych przez XSolve. W tym czasie zastanawiałem się troszkę nad systemami kontroli wersji – a konkretniej porównaniem (lubianego i używanego przeze mnie) Gita z SVNem. Są to narzędzia na pierwszy rzut oka podobne – „jakieś SCMy”, jednak różnice w podejściach obu projektów do problemu są naprawdę ogromne.
(więcej…)