Wrażenia po konferencji GeeCON: Conference Day I

Dzięki uprzejmości mojego aktualnego pracodawcy, firmy Capgemini  mogłem wziąć udział w konferencji GeeCON. Co prawda musiałem przez część czasu stać na stanowisku sponsorskim, ale i tak sporo skorzystałem z wykładów. Zacznijmy od początku.

Do Krakowa przyjechałem razem z kolegą z pracy w środę wieczorem. Po zameldowaniu się w hotelu i chwili odpoczynku, poszliśmy zobaczyć kino, w którym miała się odbywać konferencja. Część stanowisk sponsorskich była już rozłożona, a że było już późno, postanowiliśmy się rozłożyć następnego dnia z samego rana. Pojechałem jeszcze się spotkać z ziomkiem z rodzinnego miasta i do hotelu wróciłem około północy. Poprosiłem jeszcze w hotelu o żelazko i deskę do prasowania, ale się nie doczekałem :/

W czwartek wstałem około 5.40, aby móc pójść jak najwcześniej na miejsce konferencji i rozłożyć stanowisko sponsorskie. Na miejscu byliśmy chwilę po 6 i dobrą godzinkę zajęło nam składanie całości. Później jeszcze powrót do Hotelu na śniadanko i z powrotem na konferencję.

Chwilę po 8.00 zaczęli się schodzić pierwsi uczestnicy. Dla każdego uczestnika był zestaw: duża ekologiczna torba, koszulka i kubek. Bardzo podobała mi się ulotka IntelliJ IDEA, na której były wypisane skróty klawiaturowe. Fajna pomoc na początek nauki nowego środowiska. Trzeba powiesić w widocznym miejscu i często zerkać. Ponadto był jeszcze program z opisem konferencyjnych wykładów, gazetka Open Source Journal i trochę spamu.

Z początku konferencji stałem na stoisku sponsorskim, a pierwszy wykład na który dotarłem to była prelekcja: Dra Heinz’a Kabutz’a pt. Reflection Madness. Autor jest jednym z redaktorów serwisu javaspecialists.eu. Było to szczególnie widać po formatce prezentacji i sporej liczbie odwołań do artykułów w tym serwisie. Generalnie sporo prelegentów nie trzymało sie standardowej formatki, co mi się nie podobało.

Co do samej prezentacji to było dużo o mechanizmie refleksji w Javie. Początkowe możliwości które autor pokazywał były mi znane, gdyż używałem je intensywnie w pracy magisterskiej. Późniejsze przykłady były jednak bardziej zaawansowane i dzięki temu mechanizmowi można wszystko zrobić, na co domyślnie kompilator Javy nam nie pozwala. Nie jest to mechanizm, który się wykorzystuje w codziennej pracy, ale znajomość tego się przydaje. Końcowa konkluzja jest taka, że warto stosować SecurityManager w miejscach narażonych na hakowanie naszego kodu. No i w wolnym czasie trzeba będzie przejrzeć posty publikowane na javaspecialists.eu.

Po wykładzie był obiad. Nie był on rewelacyjny: ryż z kawałkami mięsa i sos. Do tego nie było gdzie usiąść, no ale trudno. Kino nie było w całości wynajęte (jedynie 3 sale i hol), więc nawet organizacyjnie było by to trudne. Organizatorzy poszli trochę po kosztach, ale miejsce konferencji rekompensuje to niedociągnięcie. Możliwość oglądania prezentacji na ekranie kinowym, z porządnym nagłośnieniem i wygodnymi fotelami sprawia, że nawet w ostatnim rzędzie można w pełni skorzystać z konferencji.

Po obiedzie udałem się na prezentację Michaël’a Figuière’a i Cyrille’a Le Clerc’a pt. NoSQL & DataGrid from a Developer Perspective. Panowie byli przedstawicielami firmy Xebia i pochodzili z Francji. Gdybym wcześniej zwrócił na to uwagę, to bym się zastanowił, czy iść na ten wykład. Słuchanie francuskiego angielskiego nie jest łatwe, ani przyjemne. Prelegenci pokazywali dużo obrazków i wiedzy, ale bez konkretów, reklamując na końcu swoją firmę. Fajnie, że pokazali podejście do transakcji w rozwiązaniach NoSQL. Mianowicie można dodać obiektom metody typu DO i UNDO. Przykładowo jeśli mamy koszyk internetowy na sprzedawane produkty i ograniczoną ilość produktów, to jedna metoda wkłada do koszyka towar, zmniejszając liczbę dostępnych produktów w bazie danych, a druga cofa tą operację. Gdy dojdzie do realizacji zamówienia i się okaże, że któryś z produktów jest niedostępny i gdy użytkownik wycofa się z zakupów, to dla dostępnych produktów wywołujemy metodę typu UNDO. A wszystko odbywa się bez transakcji. Dodatkowo mieli fajny styl rysunków, z taką kreską, jakby malowaną grubym ołówkiem lub kredką świecową.

Podczas całej konferencji brakowało mi pani z dzwoneczkiem, informującej o rozpoczęciu wykładów. Widziałem takie rozwiązanie na którejś z poprzednich konferencji i było ono bardzo praktyczne. Brak „naganiacza / przypominacza” powodował, że się prelekcje ciągle opóźniały i przeciągały. Przerwy jednak miały sporo zapasu czasowego i pozwalały / dopuszczały takie sytuacje.

Kolejną prezentacją, którą odwiedziłem, było drugie wystąpienie dra Heinz'a Kabutz'a pt.
Productive Coder. Szkoda, że prelegent nie wyświetlał na ekranie skrótów klawiaturowych z których korzysta. Używał on środowiska IntelliJ IDEA. Co mi się spodobało, to równoczesne dodawanie kilku polom w klasie tego samego zakresu, wyświetlanie linii w IDE oddzielających kolejne metody, hotkey do przejścia w tryb pełnego okna… Musze poszukać, jakie to są skróty. Prezenter twierdził, ze powinniśmy poświęcić 10 godzin na poznawanie hotkey’ów w naszym środowisku programistycznym. Całkowicie się zgadzam. Uważam, że warto tu zastosować programowanie w parach i oglądanie screencast'ów lub pracy innych programistów.

Później Heinz pytał się publiczności o to, czy obiekt typu String jest mutable czy immutable. My programiści de facto z niego korzystamy jako immutable, ale w rzeczywiśtości jest mutable, czyli modyfikowalny. Ilustruje to poniższy kod:

String myText = "My Example String";
Set<String> mySet = new HashSet<String>();
mySet.add(myText);
System.out.println(myText);

Gdy ustawimy breakpointa na trzeciej linii to zobaczymy, że wewnętrzne pole hash w obiekcie myText ma wartość 0. Po wykonaniu 3ciej linii zmieni się ono na inną wartość. Obiekt zmienia więc swój stan. Skąd sie to bierze? Mianowicie podczas dodawania tekstu do zbioru, wywoływana jest metoda hashCode() na obiekcie myText i obliczana jest wartość hash’a. Żeby nie obliczać jej wielokrotnie, to jest ona zapamiętywana do późniejszego użycia. Jako, że obiekty typu String są używane zazwyczaj w kontekście, gdzie wartość ta nie ma znaczenia, to nie jest ona obliczana w trakcie tworzenia obiektu – wiadomo wydajność.

Doktor zachęcał również do wykorzystywania inspekcji kodu dostępnych w IntelliJ IDEA (menu Analyze -> Inspect Code...). Narzędzie potrafi między innymi wyszukać pola, które mogą mieć mniejszy zakres widoczności, pola które można zmienić na finalne, lub są niezainicjowane itd. Generalnie to potężne narzędzie do statycznej analizy kodu, które od razu potrafi wprowadzić poprawki do projektu. Szczególnie warto je wykorzystać, przy otrzymaniu odziedziczonego kodu po kimś. Dzięki niemu można znacząco pozbyć się nieużywanego kodu, który zaśmieca cały projekt.

Prelegent pokazywał jeszcze ciekawe komentarze w kodzie SDK, które nic nie wnoszą i jak się zmieniają w kolejnych wersjach SDK. Proponował on wyłączyć wszelkie automatyczne generowanie komentarzy, gdyż to nic nie daje. Nawiązała się dyskusja ze słuchaczami, czy warto stosować komentarze czy nie. Publiczność twierdziła, że należy pisać kod tak, aby był zrozumiały sam przez siebie. Heinz twierdził jednak, że kod mówi jak, a komentarz dlaczego tak a nie inaczej. Pokrywa się to z informacjami, które ostatnio przeczytałem w książce: Kod doskonały Steve’a McConnell’a. Ponadto jak nie jesteśmy w stanie napisać dobrego komentarza, to oznacza to, że sami nie wiemy jak nasz kod funkcjonuje i powinniśmy go poprawić.

Później miałem iść na prezentację Hamlet’a D'Arcy’ego  pt. New Ideas for Old Code, ale jakoś długo się zbierałem i w końcu nie doszedłem, czego później żałowałem.

Następnie chciałem iść na Aslak’ena Knutsen’a na prezentację Arquillian: Real Java enterprise testing, ale gdy się dowiedziałem, że chodzi o testowanie EJB z całym kontekstem kontenera, to sobie dałem spokój. Staram się trzymać od takich ciężkich rzeczy z daleka. Ostatecznie poszedłem więc na Nicolas’a Leroux’a, Morten’a Kjetland’a: Play! framework: a revolution in the Java world. I znów Francuzi. Co prawda jeden miał dobry angielski, ale mało mówił, gdyż stał obok, lub kodował na żywo, a drugi opowiadał, co ten pierwszy pisze. Szkoda tylko, że nie korzystał ze skrótów klawiaturowych, tylko właściwie wszystko pisał ręcznie, prawie jak w notatniku. Generalnie fajny pomysł na prezentację – jeden koduje, a drugi mówi o co chodzi.

Prelegenci to autorzy przedstawianego framework’a. Fajnie, że nie trzeba kompilować całego kodu po wprowadzeniu małej zmiany, tylko wystarczy odświeżyć stronę w przeglądarce. Ciekawe jak to we wnętrzu jest zorganizowane? I jak coś się sypnie, to bezpośrednio w przeglądarce widzimy w której linii kodu i co w niej jest! Prelegenci napisali na szybko czat przez przeglądarkę i pozwolili publiczności się połączyć i popisać. Po kilku testowych wpisach zaczęły się zgodnie z moimi przewidywaniami „ciekawsze” wpisy, typu: „Euro 2012 w Łodzi”. Na koniec ktoś jeszcze napisał Cross-site scripting i wyświetlił komunikat na ekranie, ukazując słabość framework’a. Podobno w Lift’cie jest to wbudowane we framework.

I to był ostatni wykład pierwszego dnia konferencji. Wieczorem jeszcze byłem na imprezie konferencyjnej w klubie Pauza na Florianskiej. Można było tam pogadać z innymi uczestnikami, wypić piwko i powymieniać się spostrzeżeniami. Wiadomo, że nie można było poszaleć, gdyż jeszcze czekał nas drugi dzień konferencji, o którym w kolejnym wpisie.