Confitura 2015

"Otwórz swój projekt albo daj mu umrzeć", Krzysztof Debski.
Był to keynote, w którym prelegent z Allegro opowiadał o tym, że warto otwierać swój kod, tj. wypuszczać go w open source. Krzysztof najpierw opisał jak to było, gdy nie dzielili się swoimi dokonaniami ze światem zewnętrznym. Tworzyli więc pewne rozwiązania, a po jakimś czasie okazywało się, że ktoś robił coś podobnego i lepszego. A jeszcze później trzeba było się zmigrować do innego rozwiązania.

Natomiast, gdy jakiś projekt wychodził do open source’a, to nie dość, że inni zaczynają go używać, to i też rozwijać. A to strasznie przyspieszyło development danego rozwiązania. Nie trzeba oczywiście udostępniać wszystkiego (główny core biznesu można sobie zostawić), ale pewne rzeczy czasem warto upublicznić.

"Jak prezentować swoje pomysły przed ludźmi technicznymi i biznesem - rady od zwykłego programisty dla programisty", Sławomir Sobótka.
Nie widziałem w tym slocie nic lepszego dla siebie, więc poszedłem na „pewniaka”, czyli wystąpienie Sławka. Prezentację przejrzałem sobie wcześniej, wiedziałem czego się spodziewać, ale i tak było warto posłuchać i poznać parę wskazówek dla prelegentów.

Ludzie nie chcą słuchać o innych ludziach, tylko o sobie. Powinniśmy podkreślać, że prezentacja jest dla nich i przykładowo nie mówić „ja zrobiłem to i to…”, tylko raczej powinniśmy pytać się publiki, jak ona by się zachowała, gdyby miała taki problem u siebie. Taka sztuczka sprawia, że słuchacze zaczynają myśleć o tym problemie i się z nim utożsamiać. Zyskujemy sobie wtedy zainteresowanie słuchaczy.

Innym błędem, często popełnianym przez początkujących prezenterów, jest mówienie na początku wystąpienia, że są raczkujący w danym zagadnieniu, albo, że się nie przygotowali itd. Jest to spory błąd, bo od samego początku nastawia słuchaczy negatywnie do prelegenta. Można jedynie powiedzieć, że się przykładowo sepleni, ale nie powinno to wpłynąć na jakość prezentacji. Trzeba trochę z tego zażartować, aby rozluźnić atmosferę.

Jest sporo poradników, jak robić prezentację, jak się przygotowywać, ale tak naprawdę to każdy musi wypracować sobie swój sposób. No i wiadomo, że prezentacje robione na kolanie dzień wcześniej nie mogą się udać.

Przygotowania przygotowaniami, ale co z stresem przed widownią? Warto na pewno przyjść wcześniej, poczuć klimat sali, na spokojnie się rozłożyć i przyzwyczaić do otoczenia. A gdy pojawia się stres? Emocje są przez nas rozpoznawane w ciągu 0.3 s i mamy tylko 0.2 s na to, aby nazwać nasze uczucie i zlokalizować, z jaką częścią ciała jest to powiązane. Dzięki temu cukier będzie dopływał do kory przedczołowej, a nie do układu limbicznego.

Sławka osobiście denerwuje, gdy prelegent zadaje pytanie publiczności i sam podnosi rękę do góry sugerując odpowiedź. Ja na to dotychczas nie zwróciłem uwagi i osobiście nie przeszkadza mi to. Dla mnie jest to sygnał, że pytanie nie jest retoryczne, że prelegent oczekuje odpowiedzi, a także sam korzysta z rzeczy, o które pyta. Dodatkowo może to trochę obudzić publiczność i zachęcić do interakcji.

Na koniec Sławek zachęcał do nakręcenia video ze swojej prezentacji. Można to uczynić na większości polskich JUG’ów. Następnie należy je obejrzeć kilkakrotnie. Raz ogólnie, raz zwrócić uwagę na głos, kolejnym na reakcję ludzi, następnym na mowę ciała itd. Na koniec trzeba wyciągnąć wnioski i się poprawić.

Slajdy z prezentacji można przejrzeć tutaj: https://prezi.com/lwiqdtc1oe9u/jak-prezentowac-swoje-pomysy-przed-ludzmi-technicznymi-i-biznesem/

"Are you aware of /bin of your JDK?" Andrzej Grzesik
Na prezentację się chwilę spóźniłem, ale Andrzej ogólnie pokazywał narzędzia, jakie każdy ma w swoim JDK. Było o javac, javap, jps, jar, jmap, jhat, jstack (wypisuje stacktrace’y), jstat, jstatd (monitoring zdalnej maszyny).

Większość tych narzędzi już widziałem w akcji. Nowy był dla mnie jhat. Potrafi on wystawić serwer http i można za jego pomocą analizować to, co znajduje się na starcie naszego procesu javovego. Ponadto udostępnia on OQL - Object Query Language do wyszukiwania naszych obiektów na owej stercie.

W nowym JDK 9 ma wejść nowe narzędzie jcmd, które ma zastąpić wszystkie te pozostałe narzędzia. Sensowne posunięcie, zwłaszcza, że część tych funkcjonalności powiela się między narzędziami. Na koniec było jeszcze o Jvisualvm i plugine visualgc.

"Need for async: In pursuit of scalable internet-scale applications", Konrad `ktoso` Malawski
Konrad opowiadał o wielu kwestiach związanych z przetwarzaniem wielowątkowym. Było o Unfair scheduling’u, czyli gdy jakiś proces jest głodzony przez scheduler’a i jakie są sposoby radzenia sobie z tym, czyli o algorytmach nieblokujących. I tak Lock-free (inaczej Lock-freedom), jak mu się nie uda uzyskać lock’a to się cofa i próbuje jeszcze raz. Wait-free (albo Wait-freedom) dodatkowo wprowadza maksymalną liczbę prób, jakie może podjąć algorytm, aby uzyskać locka na potrzebnym zasobie.

Było jeszcze java nio, czyli o nowym sposobie dostępu do plików. Na poziomie systemu operacyjnego operacje wejścia / wyjścia są bardzo czasochłonne, ponieważ system musi się przełączyć pomiędzy user mode a kernel mode. I to się dzieje wielokrotnie podczas typowej pracy z plikami, a jak wiadomo to kosztuje czas i zasoby. Rozwiązaniem tej kwestii jest korzystanie z Zero-copy.

Było jeszcze parę pobocznych tematów, ale podsumowując prelekcję, to powinniśmy wybierać narzędzia pod nasze problemy, a nie ze względu, że są na hype.

"Vert.x - wydajna i skalowalna platforma", Bartek Zdanowski
Bartek bardzo pobieżnie i marketingowo przedstawił narzędzie Vert.x Posiada ono swoją szynę zdarzeń, za pomocą której przesyłamy zdarzenia, które następnie są wykonywane przez inną cześć aplikacji. Czyli możemy tworzyć aplikacje wielowątkowe. Dla mnie najciekawszy jest fakt, że z Vert.x’a można korzystać z Javy, Grooviego, Ruby jak i JavaScript’a. Jeszcze do końca tego nie pojmuję, jak to jest zbudowane, ale z prezentacji wynikało, że część serverowa, pisana np. w Groovym, może rzucić event’a, który zostanie obsłużony po stronie przeglądarki w JavaScripcie.

Generalnie zabrakło mi trochę konkretnych przykładów, zamiast przymiotników, jaka to nie jest wspaniała technologia. Cała prezentacja chyba zrodziła więcej pytań i wątpliwości niż wyjaśnień, co było widać po ogromnej ilości pytań na koniec.

"Elasticsearch at Scale of Billions of Documents," Igor Kupczyński
Na tej prezentacji spodziewałem się doświadczeń i wniosków z napotkanych problemów z użyciem Elastic’a. Sam z niego ostatnio sporo korzystałem w projekcie, więc byłem w temacie.

Igor sugerował, aby definiować minimum_master_nodes=(n+1)/2, gdzie n to [chyba] liczba wszystkich nodów w klastrze.

discovery:
  zen:
    minimum_master_nodes: 2

Nie powinniśmy również wykorzystywać Elastic’a jako nasze główne źródło prawdy, tylko powinniśmy przechowywać dane w innej bazie / bazach i je replikować do Elastica.

Nie powinniśmy również pozwalać, na ponowne tworzenie utraconych shardów. Pozwoli to nam uniknąć niekonzystencji. Przykładowa konfiguracja dla 4ch nodów w klastrze:

gateway:
  expected_data_nodes: 4
  recover_after_time: 48h

Było też o tym jak przeprowadzać update’y oprogramowania lub sprzętu, aby klaster dalej działał. Cała procedura jest opisana na stronie Elastic’a pod hasłem: Rolling Restarts.

Dalej było o ustawieniach pamięci, której 50% powinniśmy ustawić dla JVM heap’a, a drugie tyle dla Lucynki. Powinniśmy jednak mieć mniej niż 32 GB pamięci operacyjnej ze względu na compressed object pointers. Powinniśmy również tą pamięć zaalokować od razu na starcie:

bootstrap:
  mlockall: true

i sprawdzić, czy JVM nam na to rzeczywiście pozwala:

curl -s $URL/_nodes/process?pretty | grep mlockall

Było jeszcze o Fielddata, garbage collector’ze i paru innych tematach. Powinniśmy raczej obserwować nasz klaster, a nie go stroić, co radzą również twórcy tego rozwiązania. Do monitoringu Igor polecał m.in. Kopf, Elastic HQ, Bigdesk i pluginy do Nagios’a. Spis tego typu narzędzi możemy znaleźć na oficjalnej stronie: Health and Performance Monitoring.

Wykład fajny, ale wolałbym go usłyszeć po polsku. Slajdy są dostępne tutaj: ELASTICSEARCH IN PRODUCTION.

"Czego Javowiec nauczy się od Haskella?", Tomasz Nurkiewicz
Najlepszy, wg mnie, wykład został na koniec. Nie dotyczył on co prawda jakiejś konkretnej przełomowej technologii, ale zmieniał trochę światopogląd na nasz sposób programowania i wywracał myślenie do góry nogami. O dziwo na prezentacji nie było kodu Haskell’a, a chodziło o pewne koncepty z tego języka, a właściwie to, czego tam nie ma: null, zmienne, wyjątki, void, Object, pętle, przeciążanie metod, efekty uboczne. Tylko jak bez tego wszystkiego żyć? A no da się.

W Haskelu już na podstawie definicji funkcji, można wywnioskować, jaka jest jej implementacja. Bardzo często mamy jedną możliwość implementacji takiej funkcji. Dlatego powstało Hoogle, czyli takie Google dla Haskella do wyszukiwania funkcji na podstawie sygnatury. W IntelliJ’u jest to zdefiniowane jako Structural Search Ctrl + Shift + S.

I tak, jak Java w tym roku obchodziła 20-lecie, tak null obchodził 50-lecie. Ile to katastrof z tego faktu wynikło… W Javie i Scali mamy niby teraz Optional, ale i tak może ono być null’em:

Optional<String> name = null;

albo jeszcze lepiej:

Optional<String> name = Optional.of(null);

więc to tak naprawdę niczego nie rozwiązuje. A w Haskellu tak się (podobno) nie da. Tomek pokazywał przykład w Kotlin’ie, jak on nam uniemożliwia wykonanie kodu, który jest niebezpieczny pod względem null pointerów. A propo de facto, czy my w ogóle mamy w Javie wskaźniki?

Dalej Tomek podawał przykłady aplikacji, które nie zmieniają stanu, a jedynie tworzą nowe, z ewentualnymi referencjami do poprzednich stanów. I tak przykładowo działa Git, gdzie każdy commit to nowe pliki + wskazanie ma poprzedni commit. Baza danych Datomic została napisana w Clojure i posiada ona tylko jedną zmienną. Nie można w niej edytować danych - baza trzyma całą historię zmian.

I ostatnia rzecz, która wywarła na mnie ogromne wrażenie, to eksperyment John'a Carmack'a, twórcy Wolfenstein'a 3D, Doom'a i Quake'a, który przepisał pierwszy tytuł do Haskella, czyniąc go czysto funkcyjnym. Pomysł ten mnie zniszczył w pierwszej chwili i dał sporo do myślenia. Myślę, że to świetna metoda nauki. Pozatym kod tych produkcji jest w całości dostępny na githubie: github.com/id-Software.

Podsumowując, Confitura w tym roku była na pewno lepiej zorganizowana (mniejsze kolejki do rejestracji), była walka o wejściówki (ale się udało), a napoi chłodzących było pod dostatkiem w ten upalny dzień. Co do agendy, to mam wrażenie, jakby poza ścisłą, oczywistą, polską czołówką prelegentów, dostało się sporo prezentacji z przypadku. Albo takich, co już były. No ale cóż, taka była wola ludu.

Konfitura, marmolada, dżem, powidło i spiżarnia, czyli wrażenia po confiturze 2014

Rapid dev environments, Marcin Brański i Przemek Hejman
Prelegenci opowiadali o tym w jaki sposób tworzyć środowiska developerskie, a właściwie ich konfiguracje i obrazy, aby później można było je szybko odtworzyć np. na nowej maszynie. Chłopaki bardzo sprawnie i płynnie mówili, widać, że przećwiczyli to wystąpienie wcześniej. Ale niestety używali w swoich wypowiedziach sporo skrótów, które nie koniecznie musieli wszyscy znać. Pokazywali również sporo detalów, a zabrakło mi jakiegoś big picture, co do czego jest, oraz czym różnią się opisywane rozwiązania.

I tak oto było o następujących narzędziach: Packer.io, Puppet, Vagrant, Ansible, Chef, Salt, Fabric, Docker i Fig (nakładka na dockera). Niestety z powodu znikomej znajomości tematu nie jestem w stanie nic więcej tutaj napisać.

Git nie dla początkujących, Tomasz Borek
Tomek na początku przedstawił różnicę, pomiędzy surowym repozytorium (utworzonym z flagą --bare), a zwykłym repozytorium. Dalej już było ciekawiej. Prelegent pokazywał, co tak naprawdę jest potrzebne w katalogu .git, aby istniało repozytorium. I tak są to katalogi: objects i refs/heads oraz plik HEAD z zawartością (np.: „ref: refs/heads/master”). Ciekawa sztuczka, ale trwała trochę za długo i prelegent miał problemy z koordynacją, tj. czy klepać w klawiaturę, trzymać mikrofon, stać, siedzieć, czy mówić do mikrofonu stojącego na biurku (o którym później prelegent kompletnie zapomniał).

To było trochę jako ciekawostka, ale Tomek omówił również, po co są pozostałe katalogi i pliki. I tak w description jest opis projektu, który nie jest nigdzie pushowany i prawie nigdzie nie używany. W info/exclude można zignorować pewne pliki, których nie chcemy wersjonować. Przydaje się to w momencie, gdy mamy jakiś plik z ustawieniami lub hasłami, który tylko lokalnie powinien być dostępny, a z jakiś powodów nie chcemy go ignorować za pomocą .gitignore.

Jeszcze było o  wewnętrznej budowie commit’a. Ogółem git’a można potraktować jak acykliczny graf skierowany. Pojedyńczy commit może wskazywać na drzewo lub inne commity, drzewo wskazuje na BLOBy lub drzewa, a w BLOBach zapisywana jest zawartość plików. Co ciekawe, to nazwy plików nie są zapisywane w BLOBie, a w drzewie. Dlatego łatwo jest wykrywać zmiany położenia plików, nawet jak częściowo zmieni się zawartość.

Było jeszcze o root-commit’cie, który jest praojcem wszystkich commit’ów. Jak jakiś inny commit nie jest w stanie osiągnąć tegoż praojca, to znaczy, że jest wiszącym commit’em i można go usunąć. Swoją drogą ciekawi mnie, skąd się biorą takie wisielce? Chyba jak nie usuwamy niezmerge'owanych branchy z flagą -D, lub jakiś pojedynczych commit'ów, to nie powinno dochodzić do takich sytuacji.

Dalej było wspomniane, że nie warto wrzucać duże pliki do repozytorium. Nawet jak te pliki tam umieścimy, a następnie usuniemy, to i tak strasznie nam to spowolni pracę z git’em. A ciężko takie coś usunąć z historii tak, aby jej nie popsuć.

Oczywiście ta prezentacja nie mogłaby się odbyć z pominięciem tematu funkcji skrótu SHA1. Organizacja NIST(National Institute of Standards and Technology), która to ogłosiła ten algorytm, obecnie wycofuje się z niego i zaleca zastąpienie go SHA3. Ale w Gitcie ta funkcja skrótu nie jest wykorzystywana w celach kryptograficznych a identyfikacyjnych, więc zagrożenie jest naprawdę niewielkie. Co prawda można wygenerować plik, który będzie nam kolidował z czymś w repozytorium, ale na to pewnie też się znajdzie obejście. Po za tym zmiana funkcji hashującej wymusiłaby zmianę protokołów git’a, a ta jest dodatkowo tak zoptymalizowana, że trafia z chache CPU.

SHA1 jest wykorzystywana w Gitcie do identyfikowania commitu i innych obiektów. Dla commitów wystarczają nam zazwyczaj pierwsze 6, lub 8 znaków tegoż skrótu. Największy otwarty znany projekt hostowany na Gicie, czyli linux kernel, potrzebuje 12 znaków do identyfikacji commit’a. Wartości te są widoczne w .git/objects i są one pogrupowane w podkatalogi, aby nie osiągnąć maksymalnego limitu ilości plików w jednym katalogu i aby można było je szybko odszukać.

Było jeszcze o różnicy w sposobie przechowywania zmian w gitcie, a w SVNie. I tak SVN przechowuje różnice w plikach. Natomiast Git przechowuje całe pliki i gdy się nic w nich nie zmienia, to aktualizuje tylko wskaźnik na aktualną wersję pliku. Nie jest to do końca prawdą, gdyż gdy repozytorium nam rośnie, to git przechowuje stare rewizje również jako różnice w pliku i dodatkowo je kompresuje. Najnowsza wersja jest zawsze przechowywana jako pełen plik, gdyż najczęściej jej potrzebujemy. Dodatkowo Git został zoptymalizowany pod względem ilości zajmowanego miejsca na dysku.

Tomek wspomniał również o komendzie add w trybie interaktywnym, gdzie można wybrać, które zmiany w danym pliku wejdą do commita. Było również o takich poleceniach jak squash (pozwala złączyć commity w jeden), rebase (modyfikuje historię) i instaweb. Ta ostatnia komenda git’a pozwala przeglądać historię repozytorium przez przeglądarkę. Niestety funkcjonalność ta, póki co, nie działa w mysysgit na Windowsie(#11).

Z rzeczy poza Gitem z prezentacji dowiedziałem się o fajnej powłoce ZSH i o nakładce na nią ze zbiorem fajnych rozszerzeń: Oh My ZSH.

Prezentacja bardzo fajna. Spodziewałem się trochę więcej o komendach typu plumbing i tego co się pod spodem dzieje, gdy wywołujemy komendy typu porcelain. Ale o tym można sobie doczytać (nawet po polsku) w książce Pro Git 9. Mechanizmy wewnętrzne w Git, a prezentacja Tomka była dobrym wstępem do tego.

Po tej prelekcji niestety zmarnowałem trochę czasu na chodzeniu po stanowiskach sponsorskich, ale mówi się trudno. Ominięte wykłady oglądnę, gdy już zostaną opublikowane.

Clean architecture - jak uporządkować architekturę Twojej aplikacji. Wnioski z projektu. Andrzej Bednarz
Prelegent opowiadał, o swoim greenfield projekcie, w którym wraz z zespołem postanowili poszukać dobrej architektury. W tym celu przejrzeli to, co wielkie autorytety tego świata mówią i piszą w tym temacie i zaczęli podążać ścieżką promowaną przez Wujka Boba, a mianowicie Clean architecture.

Podejście nie jest jakoś szczególnie nowe. Mówi o odseparowaniu GUI i baz danych od naszej logiki. Każda sensowna architektura o tym mówi. Kluczowe w czystej architekturze jest odwrócenie zależności, tj. aby nasz core aplikacji NIE był zależny od bazy danych, frameworka GUI i innych komponentów. Czyli w naszych encjach powinniśmy przechowywać przykładowo datę w formacie typowym dla daty, a nie zdeterminowanym przez bazę danych, czy ORM. Innymi słowy, musimy mieć zależności DO naszej aplikacji. Więcej powinien wyjaśnić ten rysunek ze strony Wujka Boba:

Podejście takie powoduje, że nie jesteśmy uzależnieni od używanych framework'ów i możemy je łatwo wymienić. Zyskujemy również na łatwości testowania naszej logiki biznesowej. Architektura ta wymusza jednak pewien narzut na tworzenie warstw abstrakcji, wielu DTO i konwersji między różnymi obiektami.

Prezentacja była ogółem fajna. Andrzej pokazał na przykładzie kodu, jak to wygląda u niego w projekcie. Osobiście zabrakło mi trochę porównania w kodzie, z typową architekturą 3warstwową, aby móc uświadczyć różnice. Wadą wystąpienia było patrzenie prelegenta przez plecy, na kod wyświetlany na ścianie, aby pokazywać gdzie coś jest. Jak by nie można było włączyć odpowiedniego trybu pracy z rzutnikiem.

JVM and Application Bottlenecks Troubleshooting with Simple Tools Daniel Witkowski
W tym roku było sporo wykładów na Confiturze dotyczących szybkości działania tworzonych przez nas aplikacji. Prelegent pokazał kilka prostych sztuczek, jak wyłapywać problemy w naszych aplikacjach.

Na początku trzeba ustalić nasze wymagania jakościowe, czyli SLA, czas odpowiedzi, ile requestów na sekundę musimy wytrzymać itd. Następnie prelegent odpalił przygotowaną aplikację, „klikający” w nią JMeter i obserwowaliśmy, co nam pokazuje nam JVisualVM. I gdzieś tam chyba z Thread Dump’a wyczytaliśmy, że gdzieś jest ręcznie wywoływany Garbage Collector. Oczywiście wiadomo, że to jest zła praktyka, ale można zawsze ją wyłączyć, za pomocą flagi -XX:+DisableExplicitGC.

Będąc już przy temacie GC, to warto zawsze zapisywać logi z jego działania i przeglądać za pomocą GCViewer.

Inną pożyteczną wiadomością, jaką ze sobą niesie JVisualVM, jest podgląd wątków. Można tam przykładowo sprawdzić, czy liczba wątków http (przyjmujących żądania) jest taka jak się spodziewamy. Gdy będzie tylko jeden, to nie dobrze, bo requesty będą obsługiwane sekwencyjnie.

Wykres aktywności wątków, może również pokazać nam problemy z synchronizacją i blokowaniem się. Może to świadczyć o niewłaściwym użyciu słówka synchronized (np. na metodzie doGet()) lub innych mutex’ów. Jeśli widzimy, że wiele wątków nam się blokuje, to musimy znów w Thread dumpie szukać miejsc, gdzie coś może być nie tak.

Warto też spojrzeć, czy nie mamy problemów z odczytem / zapisem na dysku. W Linuxach można to sprawdzić za pomocą top’a, a na Windowsie poprzez Process Explorer. I tak jeśli dyski nie wyrabiają, może to oznaczać, ze mamy włączony za wysoki poziom logowania. Przy tej okazji w końcu zrozumiałem zasadność takich zapisów:

if(log.isDebugEnabled()) {
     log.debug(createLogMessage());
}

Jeśli ktoś napisze jakieś długotrwające operacje w metodzie createLogMessage(), to powyższy if, spowoduje, że nie będą ona wykonywane, gdy są i tak niepotrzebne. I tu bardzo fajnie widać wyższość Scali, gdzie taki argument mógłby być wyliczany w razie potrzeby.

Ponadto jakie nie wiemy w jaki sposób jest zaimplementowane isDebugEnabled(), to lepiej odczytać tą wartość raz i trzymać gdzieś w systemie.

Na koniec była jeszcze (na szczęście krótka) reklama narzędzia Zing Vision, jako że prelegent jest przedstawicielem Azul Systems. Firma ta jest również producentem maszyny wirtualnej Zing, która wg. producenta jest lepsza od implementacji Oracla.

Working with database - still shooting yourself in the foot? Piotr Turski
Prezentacja Piotrka bardzo mi się podobała, gdyż w moim projekcie doszliśmy do prawie tych samych wniosków co prelegent, a o drobnych różnicach mogliśmy sobie porozmawiać na Spoinie.

Piotrek korzysta w swoim projekcie z dwóch baz: H2 i Oracle. Jednak H2 nie do końca sprawdzała się w testach, gdyż czasem pojawiały się błędu specyficzne dla Oracla. Przykładowo w klauzurze in nie może być więcej niż 1000 elementów. Jest to dość znany problem, ale u Piotrka wyszło to dopiero na produkcji. Innym problemem było wykorzystywanie specyficznych możliwości „wyroczni” w zakresie wyszukiwania po umlautach (üöä). H2 tego nie obsługiwało, więc nie dało się testować. Innym problemem był typ Date, który na Oracle, inaczej jak na H2, po za datą zawiera również dokładną godzinę.

Z tych powodów w projekcie prelegenta testy integracyjne puszczano na Oracle, i każdy developer miał pod ręką dla siebie takową bazę. H2 nie zostało jednak wyrzucone z projektu (mimo 3 rund rozmów na ten temat), gdyż jest lżejsze, szybsze, i tylko kilka funkcjonalności na nim nie działa.

W takim wypadku, warto mieć mechanizm czyszczenia bazy na potrzeby testów. Można to załatwić DbUnit’em, ale utrzymywanie plików z danymi jest kosztowne. Po za tym narzędzie to nie zresetuje sekwencji. Można próbować również próbować przywracać dane z backup’a, ale to również może prowadzić do innego stanu bazy. Problematyczne jest tutaj usuwanie constraint’ów i powiązanych z nim index’ów. Dlatego warto wygooglać, jak można resetować bazę na Oraclu i dopasować rozwiązanie do własnych potrzeb.

Przy takich akrobacjach, warto zadbać o proces wprowadzania zmian na bazie danych. Piotrek używał w tym celu flyway, a ja u siebie korzystałem z liquibase. Nie można wtedy niestety ręcznie robić hotfix’ów. Zaletą jest to, że do testów można wtedy budować bazę tak samo jak na produkcji.

Warto również wprowadzić mechanizm testu „produkcyjnego deploymentu”. Chodzi o to, aby zgrywać stan z produkcyjnej bazy danych (schemat i dane) i wykonać deployment aplikacji (co wymusza wykonanie migracji). Zyskujemy wtedy pewność, że nic nie powinno się posypać przy roll out’cie.

Było jeszcze trochę o testowaniu integracyjnym z bazą danych, np., gdy chcemy sprawdzić HQL’a. Można do tego zaprząc wspomnianego już DbUnit’a, ale analizowanie później czemu test się wywalił, jest czasochłonne. Lepiej przygotować dane do testów w teście. Przecież i tak mamy zapewne możliwość zapisywania naszych encji w bazie, więc możemy to wykorzystywać w setupie naszych testów. Warto również przy tej okazji skorzystać z Builder’ów.

Programowanie JEE'ish bez stresu Jakub Marchwicki
Prelegent opowiadał na początku o tym, że warto czasem zbudować jakąś aplikację, wykorzystując inne technologie, niż standardowy Spring, Hibernate i JSF. Pozwala nam to przypomnieć, co te technologie załatwiają za nas, oraz jak działają pewne rzeczy na niższym poziomie. Do tego są lekkie, a przecież nie zawsze potrzebujemy tych wszystkich kombajnów, aby skosić 2m² trawnika.

I tak Jakub pokazał kilka alternatywnych rozwiązań:

• Jetty + sql2o
• Jetty + RESTEasy + MyBatis
• Spark + jOOQ
• Webbit + jdbi
• Dropwizard

Opisywane przykłady, można sobie tutaj przejrzeć: github.com/kubamarchwicki/micro-java

Zakończenie konferencji.
Na zakończenie konferencji było jeszcze losowanie nagród, wręczanie statuetek, podziękowania dla wolontariuszy itd. Szkoda, że część konkursów była wcześniej rozwiązywana, tj. w przerwach międzywykładowych. Niszczyło to szansę potencjalnych zwycięzców. Oganizatorzy od razu zapowiedzieli, że rejestracja w przyszłym roku będzie poprawiona i nie będzie tak długiej kolejki. Trzymam za słowo.

Na koniec była jeszcze impreza: Spoina, gdzie można było jeszcze trochę pogadać, zjeść pizzę, napić się piwka i pograć w kręgle. Bardzo fajne zwieńczenie tej konferencji, na którą 1400 wejściówek rozeszło się w 2 godziny od rozpoczęcia rejestracji.

Organizatorzy namawiali jeszcze do udziału w siostrzanej konferencji tj: w Warsjawie. A ja ze swojej strony dziękuję za super konferencję i zachęcam do nowej inicjatywy dBConf.

Konfitura, marmolada, dżem mydło i powidło ‘12

W ostatnią sobotę odbyła się największa (pod względem ilości uczestników ~850) polska, jednodniowa, konferencja javowa, czyli Confitura 2012. Tym razem odbywała się ona w budynkach Uniwersytetu Warszawskiego na Krakowskim Przedmieściu.

Pierwszy wykład był sponsorowany przez Akamai, tytuł miał po angielsku, więc spodziewając się zła koniecznego (czyli typowej reklamy jakiegoś produktu, za którą ktoś sporo zapłacił) odpuściłem sobie ten wykład. Pozwiedzałem wówczas stanowiska sponsorskie, zgarniając co się dało. Miałem również możliwość porozmawiania z pracownikami firmy e-point, którzy ostatnio wypuścili OneWebSQL. Jest to framework, tworzący na podstawie modelu danych, klasy encji, DAOsy i tak dalej. Taki ORM, tylko że dostajemy wygenerowany kod, którego ręcznie nie modyfikujemy, a jedynie wywołujemy to co nam jest potrzebne. Widziałem wcześniej filmik prezentujący to rozwiązanie, na którym wykorzystywano PowerDesigner’a do przygotowania modelu danych. Dowiedziałem się, że wsparcie dla kolejnych narzędzi jest w drodze, w tym generowanie kodu na podstawie istniejącego schematu bazy. Czy odniesie to sukces komercyjny - zobaczymy.

Po godzinie 10 była prezentacja Grześka Dudy na temat produktywności. Okazuje się, że najbardziej produktywni jesteśmy do kilku godzin po przebudzeniu i powinniśmy ten czas jak najlepiej spożytkować. Powinniśmy wtedy kodować, analizować problemy i wszystko to, co wymaga od nas dużego wysiłku intelektualnego. Nie powinniśmy wtedy czytać e-maili, oglądać YT ani grać w gry.

Kolejna sprawą jest podział zadań do wykonania na:
1) ważne i pilne
2) ważne i niepilne
3) nieważne i pilne
4) nieważne i niepilne.
O podziale tym można chyba przeczytać w każdej książce dla menagierów i na temat zarządzania sobą w czasie.

Kolejna sprawa to automatyzacja wszystkiego co się da. I Grzesiek nie miał tutaj na myśli automatycznych testów (bo to jest jasne ze to trzeba robić) ale optymalizację powtarzających się co jakiś czas czynności. Przykładem jest test Selenium, który może coś tam aktualizować w Eclipse.

Powinniśmy również unikać robienia 2ch rzeczy równocześnie, chyba że angażujemy do tego 2 półkule mózgowe. Inaczej nie wpływa to dobrze na wydajność. Część małych rzeczy możemy zrobić, czekając na przystanku na autobus, jak np. zadzwonić do mamy.

Następnie Grzesiek krytykował Pomodoro Technique. Uważa on, że 25 min. to za mało. W tym czasie dopiero się rozkręcamy i nie zdążymy zrobić nic konkretnego. Jedyny sens robienia pomidora, to notowanie co nam przeszkadza i jak często. Przydatne tutaj mogą być również narzędzia do analizy, która aplikacja jak długo jest otwarta, np. RescueTime. Inna ciekawa aplikacja to Pocket (Formerly Read It Later), do zapamiętywania tego, co chcemy przeczytać (aby zminimalizować liczbę otwartych zakładek w przeglądarce). Zacząłem ją od teraz stosować. Przydaje się zwłaszcza, gdy w pracy są niektóre strony poblokowane.

Gdy już przeanalizujemy, co nam przeszkadza w pracy, to najczęściej okazuje się, że są to e-maile. Dobrze jest więc wyłączyć wszelkie powiadomienia o nowych wiadomościach, aby nie wychodzić z flow. Potwierdzam z doświadczenia, że to pomaga. Kolejna powiązana kwestia to moment odpisywania na e-maile. Zasada three.sentenc.es mówi, że jeśli jesteśmy w stanie odpisać w 3ch zdaniach, to można zrobić to zaraz po przeczytaniu wiadomości. Jeśli mamy więcej do napisania, to lepiej pogadać. No i oczywiście pisząc bezwzrokowo jesteśmy w stanie zyskać 30% na produktywności (w dłuższym okresie czasu).

Jeśli chodzi o oprawę organizacują, to całkiem fajnie się oglądało prezentację z góry, tj. z balkonu. Niestety nie wiedziałbym o tej możliwości, gdyby Tomek Dziurko (jeden z organizatorów) mi o tym nie powiedział. Ogółem brakowało mi trochę oznaczeń gdzie co jest. Przykładowo dopiero ze zdjęć się dowiedziałem że gdzieś były stare konsole (a może to i lepiej że nie wiedziałem). Następnym razem proszę o więcej oznaczeń, lub schematyczny rzut z góry z zaznaczonymi ciekawymi miejscami.

Następnie byłem na Kędzierzawych testach z kontraktami Cezarego Bartoszuka. Prelegent prezentował bibliotekę CoFoJa. Pomysł kontraktów nie jest nowy, ale pomimo czasu nie przyjął się. Dla mnie te kontrakty to bardziej ciekawostka, niżeli coś co chciałbym stosować. Przypominają mi one słówko kluczowe assert, gdyż tak jak asserta kontrakty można wyłączyć, a korzystać z nich powinniśmy jedynie w trakcie testów. No i nie mamy wsparcia dla refaktoryzacji, a długość definicji pojedynczego pola w klasie mocno rośnie. Jak dla mnie lepiej wykorzystać TDD i BeanValidation jak już coś musimy walidować.

Jeśli chodzi o kędzierzawość, to prelegent przedstawił jeszcze testy z Yeti Test. I to narzędzie już bardziej mi podeszło. Potrafi ono generować sporo losowych testów jednostkowych dla naszego kodu, z uczuleniem na błędne i skrajne wartości. Yeti dobrze współpracuje z kontraktami, ale można go oczywiście stosować oddzielnie.

Co do wad prezentacji można zaliczyć przepełnienie sali. Wiem że była wcześniej ankieta, na co kto chce iść i na tej podstawie były przydzielane sale, ale to przepełnienie świadczy o trochę za dużej liczbie uczestników całej konferencji.

Następnie udałem się na zwinne szacowanie Piotra Burdyło. Było o szacowaniu całości projektu, a nie pojedynczych zadań. Prelegent opowiadał o prawie Parkinsona i syndromie studenta.

Co do szacowania Piotrek zdefiniował kilka zasad, których się trzyma:

• Szacuj po ludzku
• Mierz rzeczy które są mierzalne
• Różne szacunki wymagają różnych metryk
• Bliska przyszłość - dużo szczegółów, daleka przyszłość - mało szczegółów

Prelegent czerpie też sporo z Agile Manifesto i twierdzi że weryfikacja jakości oszacowania jest bez sensu. Wynika to z częstego wypełniania zestawienia czasu pracy pod koniec miesiąca, a także z niedokładności tego wypełnienia. Bo co np. zrobić, gdy kolega z zespołu przyjdzie do nas po pomoc? Zatrzymać aktualny stoper i włączyć inny? No i gdzie de facto upychać wszelkie przeszkadzajki (e-maile, wypełnianie czasu pracy, inne korporacyjne pierdoły, piłkarzyki...)? Nie chce nam się tego aż tak dokładnie notować, gdyż nie jest to warte swego zachodu.

Na koniec była jeszcze ciekawa metoda szacowania całego projektu. Mianowicie piszemy na karteczkach nasze historyjki i je kolejno przyklejamy na tablicy. Kolejną karteczkę umieszczamy w miejscu, które będzie wskazywało, na ile nowa historyjka jest trudniejsza od poprzednich. Na koniec dzielimy tablicę na kilka części i przyporządkujemy historyjkom odpowiednie punkty. Te które są na granicy ponownie analizujemy czy raczej są większe czy mniejsze. Na koniec jeszcze sporo pytań, aż prelegent nie dotarł do końca prezentacji.

Następnie ponownie udałem się na prezentację miękką, tym razem odnośnie Retrospekcji autorstwa Michała Bartyzela. W sali tej był mały problem ze światłem, mianowicie było go za dużo, a przez to slajdy niewidoczne. Na szczęście prelegent więcej gadał niż pokazywał. Widać że Michał ma bardzo dobrze opanowaną sztukę publicznych wystąpień, swobodnie stoi na scenie i bardzo szybko dostosowuje się do aktualnych wydarzeń na sali. Przykładowo raz zaczął się witać ze spóźnialskimi, a gdy mówił o nowych postanowieniach, to jako przykład podał, aby się więcej nie spóźniać na prezentacje (oczywiście ktoś akurat wchodził na salę).

Prelegent zachęcał do robienia małych, osobistych retrospekcji codziennie. Ma to na celu wytworzenia w nas wyrzutów sumienia, które później powinny nas zmotywować do poprawy naszych małych grzeszków. No i odpowiedni powinniśmy definiować swoją pokutę, czyli nie "poprawię swoje szacowania", a "będę szacował za pomocą przedziałów".

Było jeszcze o tym czym jak nie powinny wyglądać retrospekcje. Nie jest to terapia grupowa, gdzie wylewamy swoje żale i idziemy zadowoleni do domu. Po retrospekcji powinny pójść konkretne ustalenia i zmiany.

Na koniec było jeszcze o pytaniach C5:
1. Co zacząć robić?
2. Co przestać robić?
3. Czego robić więcej?
4. Czego robić mniej?
5. Co robić inaczej?

Kolejny wykład na który się udałem był o tym jak uwolnić się od "if" Tomka Nurkiewicza. Są dwa powody dla którego powinniśmy się ich pozbywać. Poprzez duże zagęszczenie instrukcji warunkowych tracimy na czytelności i na szybkości (na poziomie CPU, ale to temat na osobny wpis).

Było sporo przykładów z kodem i refaktoringu na żywo. Bardzo często sprawdzamy za pomocą if'ow, czy pewne wartości nie są null'em. Zamiast tego lepiej stosować Null Object. Dodatkowo chcąc pozbyć się obsługi opcjonalnych argumentów warto stworzyć metody z mniejszą liczbą argumentów, które później wywołują docelową metodę, przekazując właśnie Null Object.

Fajnym ułatwieniem, jakie pokazał Tomek, było Simplify. Przykładowo poniższy kod:

Zostanie przekształcony do:

System.out.println("bbb");

Ważne by kursor przed naciśnięciem Alt + Enter, w jedynym słusznym środowisku, znajdował się na if'ie.

Kolejnym przykładem był refkatoring kodu wywołujący pewne zadanie (Task) w wątku i bloku synchronizowanym lub nie. Prelegent ładnie przerefaktorował kod pełen if'ów na synchronizowany dekorator Taska, kod Taska i klasę tworzącą odpowiednie wątki. czyli dostaliśmy ładne rozdzielenie odpowiedzialności.

Później było o tym gdzie używać if'ów. Było na temat tego pytania: Get rid of ugly if statements i sensowności różnych implementacji. Polecam przejrzeć wątek, zwłaszcza odnośnie wielomianu 45 stopnia.

Kolejnym przykładem było porównywanie dat i jeśli daty się nie zmieniają w wymaganych, to czasem dla czytelności lepiej je zahardkodować. Jeśli musimy te daty wczytać skądś, to lepiej skorzystać z Chain of responsibility.

Na koniec było jeszcze trochę na temat wizytatora (odwiedzającego). Wzorzec ten pomaga nam się pozbyć instanceof i rzutowania w dół. Gdy przyjdzie nam dodać nowy typ to jednak trzeba wszystkie dotychczasowe klasy o jedną metodę rozszerzyć.

Co do samej organizacji, to lampa w środkowym rzutniku była mocno wypalona, przez co obraz był nieostry. Na szczęście były jeszcze dwa po bokach i po ściemnieniu światła można było wygodnie się gapić, na to prelegent robił.

Co do samej prezentacji, to bardzo mi się podobała - dużo wiedzy, szybkie tępo, brak nudy, praktyczna wiedza.

Następnie było wystąpienie Pawła Cesara Sanjuana Szklarza na temat złożonych architektur bez podziału na warstwy. Prelegent przedstawiał swoje rozwiązanie dotyczące wstrzykiwania zdalnych wywołań w ramach innych maszyn wirtualnych Javy. Ma to na celu unikniecie kudu, który tylko deleguje zdania dalej. Nie będę się tutaj więcej rozpisywał, kod do przejrzenia jest tutaj: github.com/paweld2/Service-Architecture-Model.

Na koniec był jeszcze wykład "How to be awesome at a Java developer job interview" Wojciecha Seligi Opowiadał on, jakie cechy powinien mieć kandydat na stanowisko w jego firmie (lub ogółem w firmie która chce mieć tylko najlepszych w swoim fachu). Wykład sponsorowany, ale wzbudził wiele kontrowersji.

Pierwsza sprawa to języki (ale nie programowania). Powinniśmy znać język klienta, dla którego będziemy pracować, język firmy w której będziemy pracować i oczywiście angielski.

Później prelegent przedstawiał dwa typy kandydatów, których nie lubi. Pierwszy z nich to certyfikowani analfabeci, którzy mają górę certyfikatów, ale niewielką wiedzę. Brakuje im znajomości pakietu java.util.concurrent, Garbage Collectora, zarządzania zasobami w JVM, programowania sieciowego, wielowątkowego i stosu IP.

Swoją opinię na ten temat przedstawił już Koziołek we wpisie Rozbrajamy minę.... Ja od siebie dorzucę, że rzeczywiście wg. mnie nie każdy musi znać java.util.concurrent. Znajomość wątków i podstawowych metod synchronizacji jest jednak konieczna, a nieznajomość nowego kodowania wielowątkowego zazwyczaj wynika z używania starej wersji Javy w projekcie, jak i przerzucenia sporej odpowiedzialności na serwer aplikacji, w przypadku typowego programowania webowego. I w typowych obecnych projektach rzadko się wątki wykorzystuje. A w pracy są przecież potrzebni przedewszystkim typowi rzemieślnicy, którzy wyrzeźbią wymagania funkcjonalne klienta, które bardzo często kończą się na wczytaj, pokarz, zmodyfikuj, sprawdź, zapisz…

Analogicznie ma się sprawa do znajomości GC i zarządzania zasobami. Jak już w projekcie się zdarzy, że coś tam trzeba pogrzebać, to robi to część zespołu i nie każdy ma okazję wtedy poeksperymentować. Nawet jak już się będzie tym szczęśliwcem, to po kilku miesiącach już się nic nie pamięta. Co do stosu IP to pamiętam, że model OSI ma 7 warstw a TCP/IP 4, które jakoś tam odpowiadają jedne drugim. Ale na rozmowie kwalifikacyjnej na stanowisko kodera javy nie przypomniałbym sobie za nic nazw tych warstw i nawet nie przyszło by mi do głowy, aby sobie o tym przypominać.

Z drugiej strony powinniśmy równać w górę a nie w dół, więc trzeba będzie kiedyś wrócić do tych tematów i je ogarnąć.

Kolejny typ kandydata do pracy, którego Wojciech nie lubi to Astronauci którzy mają o sobie nie wiadomo jakie mniemanie.

Dalej było o umiejętnościach typowo technicznych, jakie powinien posiadać dobry kandydat. Nie będę ich tutaj wymieniał a jedynie odeślę do prezentacji. Jak kolejnym razem przyjdzie mi się zmierzyć z jakimś rekruterem, to na pewno przypomnę sobie tą prezentację przed rozmową. Warto też przeczytać komentarz autora pod prezentacją, czyli odpowiedź na stawiane zarzuty. Rzeczywiście prezentacja wywołała sporo emocji - bardzo mnie to cieszy, cel prelegenta osiągnięty - brawo!

Prelegent polecał jeszcze książkę Java Concurency in practice. A z dalszą częścią prezentacji już ciężko się nie zgodzić. Feedback po rozmowie powinien być telefoniczny (choć e-mailowy też mi się podoba), na rozmowie powinno być prawdziwe kodowanie, a rekrutacje powinni przeprowadzać najlepsze osoby z firmy, choćby się paliło i waliło w projekcie. Ponadto najlepsi chcą pracować tylko z innymi najlepszymi, lub jeszcze lepszymi.

Było jeszcze o trudnych pytaniach od kandydatów, czyli o ścieżkę rozwoju, możliwości awansu i gwarancję stabilności. Pytania te nauczyły nas stawiać korporacje, które na dzień dobry mydlą oczy takim lukrem (ścieżki kariery, awansu, rozwoju, szkolenia, wyjazdy i inne benefity).

Co do różnicy zdań jeszcze, to Wojtek szuka profesjonalistów, ale sam nie jest bez skazy. Już podczas pisania relacji z tegorocznej konferencji 33 degree, zwracałem uwagę na usuwanie testów, jeśli są przez dłuższy czas czerwone. Raczej nie po to ktoś się wysila aby napisać test, aby go potem usunąć, gdy nie działa. A druga sprawa (o której wtedy zapomniałem napisać) to niby 10 lat doświadczenia w tworzeniu testow, a na prezentacji (tej z 33 degree) był kod testu, gdzie na zmianę były wywoływane testowane metody, assercje, metody, assercje itd. I nazywane było to testem jednostkowym...

Na sam koniec było trochę reklamy, ale skoro to wykład sponsorowany to nich będzie. Mimo że się w kilku punktach nie zgadam z prezenterem, to prezentację uważam za bardzo udaną i wartościową, gdyż bylem ciekaw spojrzenia z punktu widzenia osoby rekrutującej.

Po ostatnim wykładzie było losowanie nagród, podziękowania itd.

Wieczorem jeszcze udałem się na imprezę integracyjną. Była wynajęta kręgielnia wraz ze sponsorowanymi grami piwem i pizzą. Czyli nikt nam nie przeszkadzał i można było się spokojnie zrelaksować.

Wielkie brawa dla organizatorów, wolontariuszy i innych zaangażowanych w konferencję. Dobra robota. Co do minusów to już Koziołek pisał o braku foyer, przez co z powodu natłoku ludzi ciężko było się przemieszczać w trakcie dziesięciominutowych przerw. Ale i tak fajnie że mój postulat z poprzedniego roku na temat wydłużenia przerw został spełniony, więc więcej nie narzekam. Brakowało mi jeszcze oznakowań (albo ich nie widziałem) / planu sal, klimy. Lekkie przepełnienie uczestników utrudniało przemieszczanie się pomiędzy wykładami, a w powidle było za dużo światła (brak zasłoniętych żaluzji). Widać było, że organizatorzy się bardzo starali, ciągle biegali i mieli kupę roboty. Jeszcze trochę i nie będzie czego poprawiać.

Podobne wypisy można znaleźć na stronie konferencji.

Confitura pełna wiedzy – wrażenia po konferencji

W sobotę 11 czerwca odbyła się w Warszawie największa darmowa konferencja javowa w Polsce: Confitura, zwana wcześniej Javarsovią. Na początku wielkie podziękowania dla organizatorów, wolontariuszy i sponsorów, za chęć organizacji i wsparcia tejże inicjatywy. Ale od początku.

Do Warszawy przybyłem w piątek wieczorem, aby być wypoczętym na konferencji. W sobotę byłem na miejscu o 8.30, szybka rejestracja, obchód po stanowiskach sponsorskich, spotkanie znajomych…

O 9.15 członkowie kapituły oficjalnie rozpoczęli Javarsovie Confiturę. Pierwszy wykładzik był sponsorski na temat KeyNote. Prowadzący mówił bardzo cicho i monotonnym głosem, no ale płaci to niech ma :P Był to dobry czas na rozwiązanie konkursów, przygotowanych przez sponsorów. Pod koniec już wyszedłem i chciałem się napić czegoś. Niestety obsługa cateringowa stała, ale napoje czekały dopiero na przerwę kawową co mnie się niezbyt spodobało.

W tym roku zestaw uczestnika był troszkę uboższy niż rok wcześniej. Zamiast materiałowej i ekologicznej torby (używam do dziś) była papierowa i brakowało mi notesika (na szczęście się przed tym zabezpieczyłem). Nie ma jednak na co narzekać, gdyż konferencja jest w pełni bezpłatna i nie można wymagać nie wiadomo jakich gadżetów. Nie to jest najważniejsze, gdyż nie po gratisy przyjechałem.

O 10.35 zaczęły się pierwsze wykłady. Ja się udałem na Aspekt bezpieczeństwa w tworzeniu aplikacji internetowych Jakuba Koperwasa. Prelegent zaprezentował popularne ataki na aplikacje webowe (jak SQL Injection) jak i mniej popularne (jak CSRF). Wspomniał on również o inicjatywie OSWAP, dzięki której można się pobawić w hakowanie.

Było też o sposobach, jak można się bronić przed różnymi atakami. Przede wszystkim należy nie przestawać myśleć i nie ufać ślepo framework’om. Powinniśmy walidować dane, a nie formularz, gdyż dane do naszej aplikacji mogą spływać różnymi drogami – nie tylko poprzez żądanie http, ale także z innych serwisów, aplikacji, z telefonów... W celu walidacji danych może nam pomóc BeanValidation JSR-303, za pomocą którego można zdefiniować, jakie ograniczenia powinny mieć nasze dane.

Warto również znać różnice pomiędzy używanymi framework’ami i bibliotekami, Przykładowo GWT traktuje tekst jako zwykły tekst, natomiast ExtGWT, jako html. Dzięki temu tworząc przycisk z tekstem <b> text </b> w tym pierwszym dokładnie taki napis zobaczymy na ekranie, a w przypadku ExtGWT dostaniemy przycisk z pogrubionym tekstem.

Kolejnym rodzajem omawianego ataku była kradzież sesji. Można się przed tym bronić, dodając do każdej akcji jednorazowy RequestId, który jest później unieważniany. Można z palca to naklepać, lub jeśli korzystamy z Seam’a, wykorzystać znacznik <s:token>. Można również monitorować czy na pewno uprawniony użytkownik korzysta z danego klucza sesji. Można dodatkowo monitorować MAC i IP, a także używaną przeglądarkę. O ile IP może się czasem zmienić (zależy jakiego mamy dostawcę Internetu), to już zmiana przeglądarki może być podejrzana. Wszystko również zależy od krytyczności naszej aplikacji. Jak by się trzeba było co kilka minut logować na facebook’a, to by ludzie przestali się z niego korzystać. Również warto przesyłać ciasteczka po https. Prelegent na koniec polecał przeczytanie 12 rules for developing more secure Java Code.

Prelegent opowiadał jeszcze o kilku ciekawych rzeczach. Przekazał w ten sposób sporo wiedzy słuchaczom. Może trochę mi brakowało przykładów, ale przy takim czasie prezentacji ciężko je zaprezentować. No i nie było czasu na dogłębne analizowanie omawianych problemów. Prelegent mówił szybko, ale zrozumiale i nie dało się spać. Wykład mi się podobał.

Później była przerwa kawowa. Następnie chciałem iść na Tomasza Skutnika i prezentację: Gdzie jest moja tabela? Czyli jak sobie radzić w Javie i SQL gdy zmienia się schemat bazy danych. Kolega Szymon mnie jednak odwiódł od tego zamiaru i wylądowaliśmy na prezentacji Patrycji Węgrzynowicz, pt. Patterns and Anti-Patterns in Hibernate. Patrycja już kilka krotnie występowała z tą prezentacją na innych konferencjach, w tym na 33deegre i GeeCon’ie. Nawet slajdy zawierały na końcu informacje o pierwszej z wymienionych konferencji.

Prelegentka wzięła na warsztat przykładowa aplikację CaveatEmptor z książki Java Persistence with Hibernate – biblii do Hibernate’a napisanej przez jej twórców. Pokazując kawałek kodu, Patrycja pytała publiczność, czy wiedzą, gdzie jest błąd. Znalazł się ktoś z sali, kto dobrze trafił, co się nie zdarzało na poprzednich wystąpieniach. Jak się okazało, nawet twórcy Hibernate’a mogą się czasem pomylić w pracy ze swoim narzędziem. Z ciekawszych rzeczy, co zapamiętałem, to użycie metody Collections.unmodifableList(), która zwraca jedynie wrappera na oryginalną kolekcję. I w zależności od implementacji getterów i setterów, możemy sobie coś zepsuć. Wykład całkiem, całkiem, tylko te częste eeee… i yyyyyy… Patrycji powodowały, że już się go tak przyjemnie nie słuchało.

Kolejnym wykładem na jaki się udałem, to Jak wycisnąć maksimum z testów? Bartka Majsaka. Było trochę o testach integracyjnych i akceptacyjnych. Prelegent wspominał o takich rozwiązaniach jak Tumbler (wspomaga pisanie w stylu BDD) Cargo (wspomaga konfiguracją i deploy'em w różnych kontenerach) i Arquillian (do testowania kodu osadzonego w kontenerze). Praktyczny przykład z tym ostatnim nie zadziałał, prawdopodobnie z powodu problemów z netem.

Dalej było o Selenium / WebDriver. Bartek testował za jego pomocą funkcjonalność na github'ie. Mianowicie po wciśnięciu T, można wyszukiwać pliki z danego projektu. Istnieje również możliwość eksportu z Selenium do JUnit’a 4, ale to się i tak nie kompiluje i w ogóle nie działa. Można to jednak poprawić (tudzież ręcznie napisać) i wtedy można uruchamiać testy bezpośrednio z ulubionego IDE.

Było jeszcze trochę o BDD i jak można ładnie DSL’e w Groovy’m wykorzystać. Warto również w trakcie build'ów z maszyn wirtualnych korzystać, jeśli musimy przeprowadzać testy w zróżnicowanych środowiskach uruchomieniowych. Prelegent próbował jeszcze coś tam pokazać, za znów nie zadziałało z winy sieci. Spodobała mi się idea nagrywania screencast'ów z testów akceptacyjnych, które to później można wykorzystać, do zbudowania prezentacji pokazującej funkcjonalność produktu.

Następnie był obiad. Tym razem trzeba było sobie za niego zapłacić (nie było tak fajnie jak rok temu) a i tak jakiś wypaśny nie był: zupka, sałatka, kanapka i jabłko. Później był wykład sponsorski, czyli jak zwykle…

Następnie udałem się na Re-fuck-toryzacja czyli sprowadzanie sp****go kodu na właściwe tory Pawła Lipińskiego. Chciał on swoim wystąpieniem udowodnić, że jeszcze potrafi programować… W trakcie prezentacji było krótkie ogłoszenie od organizatorów, że właśnie odholowują źle zaparkowane samochody. Ktoś wybiegł z sali...

Paweł wziął pod lupę open source’owy projekt e-commerce OFBiz Pokazywał w jaki sposób przeprowadzać bezpieczne refaktoryzacje. Da się, nawet bez posiadania testów. Nie odpalał jednak na końcu aplikacji, więc nie wiadomo czy wyszło:P

Trochę czasu zabrakło na pokazanie wszystkiego, a im dalej, tym ciężej było śledzić co się dzieje w kodzie. Na koniec był jeszcze zabawna piosenka o refaktoryzacji przygotowana przez autora.

Kolejną prezentacją, na której byłem, było Zastosowanie przetwarzania asynchronicznego w aplikacjach Tomka Łabuza. Testował on obciążenie aplikacji i pokazywał, jak się ona zachowuje przy przetwarzaniu synchronicznym jaki i asynchronicznym. Prelegent mówił również, kiedy warto zastosować takie rozwiązanie w naszej aplikacji.

Następnie była przerwa kawowa i losowanie nagród od sponsorów. Ja wygrałem otwieracz do piwa z funkcją pendrive’a i 2 bilety do kina. Tak więc można powiedzieć, że losowanie nie było ustawione, ale i tak wolałbym Xbox’a :P

Ostatnią prezentacją w której miałem możliwość uczestnictwa było: Pisz po pijaku, przeglądaj na trzeźwo Piotra Przybylaka. Tu również były nagrody dla aktywnych uczestników, tylko że w postaci piwa lub gorzkiej żołądkowej. W końcu tytuł prezentacji zobowiązuje :)

Prezentacja była o sposobie, w jaki działa nasz mózg i czy da się to jakoś wykorzystać. Można się przełączać pomiędzy rożnymi trybami jego pracy, np. za pomocą alkoholu, spaceru, pisaniu czegoś na kartce zaraz po przebudzeniu… Chcąc wykorzystać dwa tryby pracy mózgu, można stosować pair programing, gdyż wtedy kierowca skupia się na pisaniu linijek kodu, a pilot o tym nie myśli, ale ma za to obraz całości.

Dobre może być również odwrócenie problemu. Chcesz się nauczyć pisać dobry kod? Napisz jak najbardziej brzydki, zagmatwany i niezrozumiały kod. Prelegent wspominał jeszcze o modelu kompetencji braci Dreyfus, Shu Ha Ri, kryzysie pielęgniarek w stanach i o powstawaniu nowych neuronów w mózgu. Podobno szczurom w warunkach laboratoryjnych nowe neurony się nie rodzą (no bo i po co?), ale kto wie jak to w rzeczywistości jest...

Generalnie na wykładzie było sporo śmiechu i sporo braw. Było lekko i przyjemnie. Idealny wykład na końcówkę konferencji. Brawo.

Później było tylko zakończenie konferencji. Podziękowania dla organizatorów, wolontariuszy i sponsorów. Było jeszcze losowanie przygotowanych nagród, ale już na nic się nie załapałem. Liczba osób, które potwierdziły rejestracje to 742, ale wiadomo – ktoś jeszcze nie dojechał, ktoś jeszcze doszedł, wiec trochę ciężko przybliżyć rzeczywistą liczbę uczestników.

Po confiturze udałem się jeszcze pod PKiN na piwko z Szymonem. Ja jeszcze zostałem na niedziele w Warszawie. Wracając pociągiem rozwiązywałem jeszcze jedno zadanie konkursowe firmy OutBox. Musze przyznać, ze bardzo ciekawy konkurs (tzn. treść tego co trzeba zrobić, a właściwie gdzie ją znaleźć). We wtorek było ogłoszenie wyników, ale niestety nic nie wygrałem.

Podsumowując konferencję, to wypadła ona trochę słabiej od zeszłorocznej edycji. Wydaje mi się, że wcześniej wykłady były na trochę wyższym poziomie (albo to ja się czegoś w ciągu roku nauczyłem). Było ciężko się przemieszczać pomiędzy salami (co nie jest dziwne przy tej liczbie uczestników), co skutkowało spóźnieniami na prelekcje. Przerwy mogły by być trochę dłuższe, a napoje dostępne non stop. Więcej niedociągnięć się nie dopatrzyłem i za rok będę starał się znów wziąć udział w tej konferencji.