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.
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ść.
