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.

Javarsovia 2010

Podroż na Javarsovie rozpocząłem w piątek z Wrocławia. Jako ze najważniejszym priorytetem przy wyborze środku transportu była cena, zdecydowałem się na podroż pociągiem, a dokładniej Tanią Linią Kolejową. Na tymczasowym dworcu we Wrocławiu wybrałem kasę, która miała najmniejsza kolejkę. Okazało się to złym wyborem, gdyż osoba przede mną (pan w średnim wieku wraz z pewną kobietą) kupował bilety do Międzyzdrojów na połowę lipca. No i oczywiście zaczęły się problemy z rezerwacją miejsc siedzących, później państwo zdecydowało się kupić kuszetki dla dzieci, ale pojawiła się kwestia, ile dzieci może być w jednej kuszetce, itd... Gdybym był w innej kolejce dawno bym już kupił bilet. Morał na przyszłość - lepiej stanąć za kimś z dużym plecakiem, bo taka osoba na pewno jest zdecydowana gdzie i jak chce jechać. Co do TLK to miałem wcześniej doświadczenia z tą linią i spodziewałem się bezprzedziałowego wagonu z plastikowymi siedzeniami. Trafiłem jednak na klasyczny wagon drugiej klasy, z lepszymi siedzeniami (tj. takimi co nie maja przerwy miedzy oparciem a zagłówkiem).

Na miejsce dojechałem z 1.5h opóźnieniem z powodu zerwania linii wysokiego napięcia gdzieś za Opolem. Pociąg przez to musiał jechać objazdem. Na miejscu czekała na mnie ciocia, która miała mnie przenocować.

Na drugi dzień na miejsce konferencji dojechałem około 9.20. Szybka rejestracja, odebranie torby gadżetów i można było się przejść po dostępnych stanowiskach wystawiających się firm sponsorskich. Do stoiska Oracle'a była długa kolejka, ponieważ rozdawali koszulki, a trzeba było wypełnić formularz z danymi o sobie. Zamiast tracić czas w tej długiej kolejce, poszedłem do sali gdzie było rozpoczęcie. Nie bylem od początku, ale chyba dużo nie straciłem. Co ciekawe, to to że jeszcze kilka dni temu sale w których odbywały się prezentacje, były ponumerowane. Na konferencji były już one ponazywane double, integer, char i boolean, stosownie do swojej wielkości :)

Na pierwszą prelekcje udałem się do największej sali na prezentacje Jakuba Nabrdalika, pt. Jak zapobiegać biodegradacji kodu? Prezentacja zaczęła się trochę wcześniej - gdyż jak tłumaczył autor - zazwyczaj prezentacje się przedłużają. Jakub mówił o dobrych praktykach stosowanych w jego firmie. Namawiał mocno do tego, aby jakość naszego kodu rosła. Podkreślał stosowanie TDD, refaktorkingu naszego jak i czytanego (obcego) kodu itd. Ważna jest tez motywacja zespołu i wmówienie im, że są najlepsi (choć na rożne osobowości rożnie to działa). Nie pamiętam dokładnie wszystkiego, gdyż nie miałem żadnego notatnika ani pustej kartki aby coś zapisać. Pamiętam na pewno ze prezentacja była udana i bardzo śmieszna:-)

Po prezentacji poszedłem do stoiska Oracle'a w celu wypełnienia ankiety i zgarnięcia koszulki. XLek już nie było, więc wziąłem XXLkę. Swoją drogą mogłaby być trochę dłuższa niż szersza. Spóźniłem się przez to lekko na kolejną prezentacje dotyczącą Gradle - od zera do dużego builda, Tomasza Kaczanowskiego. Prelegent pokazywał nam, że Gradle właściwie jest opakowaniem nad Antem, które ma dodatkowo sporo możliwości. Gradle zanim zacznie budowanie aplikacji, tworzy sobie acykliczny graf zależności, po to, aby nie kompilować ponownie tego, co jest aktualne. Dla kodu jest jasne, kiedy jest on aktualny. Funkcjonalność taką zapewniał już make. W przypadku generowania np. dokumentacji, możemy zdefiniować od czego ona zależy, jakie wyjście ona generuje i w ten sposób Gradle będzie śledzić, czy musi generować dokumentacje, czy nie. Ja osobiście nie miałem styczności z bardzo dużymi buildami (w sensie wielu zależności) i nie odczułem bezpośrednio problemów długiego budowania aplikacji, ale jestem jak najbardziej świadom tego problemu. Niestety Gradle nie ma jeszcze wersji 1.0, ale jak się ona pojawi to postaram się jej przyjrzeć. A i jeszcze cenna uwaga: Gradle szybciej buduje duże projekty, nie jest szybki na krótkim dystansie.

Na kolejną prezentację udałem się do sali obok, na Refaktoryzacja kodu testowego Piotra Jagielskiego. Prezentacja przede wszystkim uświadomiła mi, że nie tylko należy dbać o kod produkcyjny, ale także o kod testowy. Będę musiał się dokładniej przyjrzeć mojemu kodu testowemu w moich projektach i zadbać o jego jakość. Na prezentacji było wiele przykładów, jak doprowadzić kod testowy do tego aby był bardziej czytelny. Było przedstawionych wiele dobrych praktyk, choć większość już znalem wcześniej z innych prezentacji. Ale prelekcja i tak udana.

Po prelekcji był czas na obiad. Było parę specjałów do wyboru. Mi bardzo smakowało, jedzenie było cieple (aż mi się gorąco podczas jedzenia robiło) i było go dużo. Po obiedzie był czas na prezentacje nowego produktu firmy Azul Systems Zing. Ja jednak nie bawię się w wirtualizacje rożnych systemów, wiec nie byłem do końca tym zainteresowany.

Udałem się wiec na Projekt Voldemort: gdy relacyjna baza danych to za mało (zbyt wiele?) Tomasza Nurkiewicza. Od pewnego czasu korzystam intensywnie z obiektowej bazy danych db4o i jestem zwolennikiem inicjatywy NoSQL. Relacyjne bazy danych są mocno zakorzenione w biznesie, ale jednocześnie troch już stare (Oracle ma juz ponad 30 lat). W NoSQL chodzi o zwrócenie uwagi na to jest coś więcej, niż tylko relacyjne bazy danych na tym swiecie.

Projekt Voldemort jest swoistą persystentną HashMapą. Dla klucza obiektu, który chcemy zachować w bazie, wyliczany jest hash code i na tej podstawie jest on umieszczany w odpowiednim miejscu. Co ważniejsze, projekt ten od samego początku zakłada duży podział bazy na niezależne węzły. Domyślnie węzeł przechowuje dane których <hash code> % <liczba węzłów> = <numer partycji>. Powoduje to, że aplikacja kliencka na podstawie hash kodu, wie w którym miejscu (partycji bazy) zostanie dany obiekt zapisany. Można też w łatwy sposób zwiększać liczbę węzłów i maszyn, które obsługują dana bazę. Daje to nam niemal liniową skalowalność. Projekt wydal mi się bardzo interesujący, ale okazało się, że pod baza tak właściwie leży jakaś inna baza, np. MySQL, Berkeley DB, czy jeszcze coś innego. Spodziewałem się, że poniżej będzie jakiś wewnętrzny mechanizm ukryty, a tu inna baza danych. Projekt ten wykorzystuje więc dobrodziejstwa bazy umieszczonej poniżej. Cóż dobre i to. Przynajmniej mamy świadomość ze można inaczej.

Projekt Voldemort umożliwia również zwiększenie niezawodności poprzez zapis danych na większej ilości węzłów. Ogółem bazę Voldemort konfiguruje się za pomocą 3 liczb:

• replication-factor - liczba węzłów na których obiekt ma być zapisywany
• required-writes - minimalna liczba wezłów, na których powiedzie się zapis bez zgłaszania wyjątku do aplikacji klienckiej
• required-reads - minimalna liczba węzłów, z których musi być odczytana wartość

Chodzi o to, że w danym czasie węzły mogą być różnie obciążone i nie zawsze przechowywana wartość na wszystkich węzłach jest aktualna. Projekt ten zapewnia jednak przezroczystą (niewidoczną dla klienta) synchronizację wersji, np. podczas pobierania wartości. Synchronizacja nie opiera się na zegarach systemowych (bo serwery mogą być w różnych strefach czasowych), tylko na jakiś innych nowoczesnych mechanizmach. Należy pamiętać, aby required-reads + required-writes > replication-factor (przeinaczyłem wzór, ale już poprawilem, dzięki komentarzowi Tomka Nurkiewicza). Dzięki temu zawsze otrzymamy spójne dane (o ile tego potrzebujemy).

Wszystko ładnie wygląda i na prezentacji było trochę przykładów działania tego produktu. Wiadomo, że nie jest to idealne rozwiązanie do wszystkich przypadków, ale są miejsca gdzie warto je zastosować. Przykładem wykorzystania projektu Voldemort jest strona LinkedIn. Wiadomo, nie cała strona korzysta z tego projektu tylko pewne specyficzne jej elementy.

Kolejna prezentacja na którą się udałem było "Clean Tests" by Uncle Paul, czyli jak pisać testy, żeby dobrze Ci służyły, Pawła Lipińskiego. Początkowo zapowiadało się na jakiś performance. Prelegent był ubrany w szlafrok, ręcznik i miał szczoteczkę do zębów w ustach. Po chwili pozbył się tych artefaktów, choć pod szlafrokiem nie było tego czego można się było spodziewać:) Na początku prezentacji było trochę śmiesznych slajdów, przez co prelegent zdobył sobie zainteresowanie publiki. W dalszej części wystąpienia prelegent opowiadał o najważniejszych praktykach w projekcie, posiłkując się rozdziałami książki "Clean Code" Uncle Paula. Paweł mówił, co robić aby projekt w którym pracujemy nie był nieprzyjemną praca szambonurka. Nie wiem czemu, ale po pewnym czasie się trochę wyłączyłem, ale to mogło wyniknąć z mojego zmęczenia. Na prezentacji (drugi raz w ciągu dnia) była promowana wspomniana już książka. Trzeba rozważyć możliwość zakupu tej książki.

Ostatnia prelekcja na jakiej bylem było wystąpienie Jarosława Pałki pt. Jeden rozmiar nie dla wszystkich, czyli NoSQL w środowisku Java. Prelegent na początku pytał kto nie lubi SQL'a. Zgłosiło się niewiele osób. Świadczy to o wielkim zakorzenieniu się relacyjnych baz danych w biznesie i tego że my programiści przyzwyczailiśmy się do używania SQL'a. Jarosław wspominał, że reprezentuje tą druga stronę mocy (jest managerem zespołu) przez co dużo czyta. Twierdzi on, że my programisci również powinniśmy dużo czytać (nie tylko kod) i poszerzać swoje horyzonty.

Po krótkim wstępie mieliśmy prawo wyboru o czym będzie dalej prezentacja. Można było wybrać o Neo4j, CouchDB i chyba Berkeley DB (de facto produkt kupiony przez Oracle'a). Wybrano tą pierwszą opcje. Neo4j jest przykładem bazy danych stworzonej do przechowywania grafów. Przechowuje ona wierzchołki krawędzie i inne zdefiniowane przez nas informacje skojarzone z tymi elementami. Ogólnie minimalna funkcjonalność jaką zapewnia ta baza danych to przechowywanie grafu i jego przegląd zupełny. Jak chcemy trochę więcej podziałać na tym grafie, to musimy dołączyć dodatkową paczkę, która np. realizuje algorytm Dijkstry. Jest kilka takich niewielkich opcjonalnych paczek dostępnych dla tego projektu i dzięki temu dołączamy tylko to co jest nam potrzebne. Chętnie bym jeszcze o innych tych wynalazkach posłuchał, ale ograniczenia czasowe na to nie pozwolily.

Po tej prezentacji było już tylko zakończenie konferencji, losowanie nagród i zaproszeń na imprezę organizacyjną. Nic, po za kuponami zniżkowymi od wydawnictwa Helion, mi nie przypadło:-(

Podsumowując konferencja i tak mi się podobała. Poruszane tematy były interesujące i godne poświęcenia słonecznej soboty na nie. Brakowało mi może kartki, na której mógłbym zrobić szczegółowe notatki, ale po za tym wszystko ok. Nie żałuje czasu poświęconego na konferencje i w przyszłym roku będę się bardziej starał aby przekonać kogoś znajomego aby jechał ze mną.

P.S. Moja notatka w całości (po za ostateczna korektą) poswstała na telefonie komórkowym. Nie chciało mi się ze sobą laptopa targać, gdzyż zbytnio nie był mi potrzebny. Wiedziałem jednak, że bedę miał trochę czasu wolnego po konferencji wracając do domu, wiec wcześniej przygotowałem sobie aplikacje j2me typu notatnik, który zapisywał mi tego posta na karcie zewnętrznej w moim telefonie. Dzięki temu mogłem to łatwo później na komputerze zgrać, a i pisało się całkiem przyjemnie z racji posiadania dotykowego telefonu z klawiatura qwerty:-) Niestety pisanie bez stosowana polskich znaków spowodowało, że musiałem dużo czasu na korektę poświęcić. Muszę trochę dopracować całość.