Długo się zbierałem do napisania tego postu, ale w końcu się udało, skoro to czytacie. Kurs
podstaw programowania funkcyjnego w Scali dobiegł końca, zaliczony na 96.5 %, certyfikat ściągnięty, spadł śnieg, motywacja wzrosła, więc można się zająć blogiem.
Co do samej konferencji
Java Developers Day, to się
do niej zraziłem w 2010 roku. Tym razem jednak wygrałem darmową wejściówkę, więc głupio by było nie skorzystać. Pojechałem więc do Krakowa.
Pierwsza prezentacja na jakiej byłem:
The dark art of performance tuning or how to become a performance hero without spending a penny on tools, Leonida Igolnika. Facet pracuje w Oracle jako “Vice President of Product Development” I gadał ponad 5 minut o sobie. Jak to mówią, ten co dużo mówi o sobie, ma mało do powiedzenia na temat prezentacji, więc miałem małe obawy co do wykładu. Jednak szybko się pozytywnie rozkręciło. Leonid przekonywał nas, że w przypadku problemów z wydajnością naszych aplikacji, nie powinniśmy patrzeć do kodu, a na narzędzia.
I tak na początek musimy poznać nasze środowisko (system operacyjny) jaki i Runtime Environment. Prelegent pokazał jak można to zrobić na Unixie. Chcąc sprawdzić parametry JVM na Windowsie, można odpalić (oczywiście z konsoli)
jps, aby poznać PID naszej aplikacji / serwera aplikacji. Następnie za pomocą
jinfo można sprawdzić, co tak naprawdę jest uruchomione (np. na produkcji) i z jakimi parametrami VM.
Następnie za pomocą
jmap -heap PID można sprawdzić używaną implementację GC i statystyki pamięci. Narzędzie to posiada jeszcze kilka ciekawych opcji: zrzuty pamięci, histogram obiektów heap’u i inne statystyki. To na co należy szczególnie zwrócić uwagę, to ile zajmują Stringi w naszej pamięci, gdyż one siedzą w przestrzeni PermGen (permanent generation). Problem ten nie występuje w Javie 7, gdyż teksty nie są dłużej alokowane w tym obszarze pamięci, a na heap’ie. Rozwiązuje to kilka problemów. Więcej na ten temat można przeczytać na
Java SE 7 Features and Enhancements.
Coś było jeszcze wspomniane o
Kirku Pepperdine ekspercie od tuning’owania Javy i autorze słów: „dominating consumer of the CPU”. Prelegent polecał również to video:
Everything I Ever Learned about JVM Performance Tuning @twitter. Można się z niego dowiedzieć, ile zajmują w pamięci instancje prostych obiektów, jak jest reprezentowana wartość
null w polach klas i jak często się uruchamia full GC na serwerach Twittera.
Następnie było przedstawiane chyba najlepsze darmowe narzędzie do profilowania, czyli
jVisualVM. Łączy ono przedstawione wcześniej aplikacje konsolowe i jest rozszerzalne przez pluginy. Prelegent pokazał, że jak mamy duże zużycie CPU i jest to głównie System Time, to może to być problem z przełączaniem kontekstu.
Później Leonid przedstawił plugin do jVisualVM o nazwie
TDA - Thread Dump Analyzer. Pomaga on nam analizować stacktrace’y. Był też przykład błędnego użycia
WeakHashMap i synchronized. W końcu niemal każde użycie tego słowa kluczowego, jest informacją, że tu gdzieś się czai błąd. Było jeszcze o narzędziu
GCViewer, do analizowania tego co Garbage Collector wypluwa, o opcji
-XX:-HeapDumpOnOutOfMemoryError i o
Memory Analyzer - plugin’ie do Eclipse, który pozwala przeanalizować referencje pomiędzy obiektami.
Po takim wykładzie aż chce się mieć problemy w projekcie i możliwość dostania tego często jakże niewdzięcznego zadania, tylko po to aby pobawić się tymi zabawkami, jakie przedstawiał prelegent. Jak dla mnie najlepsza prezentacja podczas całej konferencji, mimo że gościu jest z Oracle’a.
Następnie byłem na prezentacji
Jarosława Pałki: The deconstruction of architecture in times of crisis. Prelegent mówił, że ostatnio za bardzo się skupiamy na frameworkach (technology masturbation), że one rozwiązują jedynie problemy ich twórców, zamiast bardziej skupić się na tym jak dostarczyć funkcjonalność naszemu klientowi. Była wyjaśniona zasada działania
Tragedii wspólnego pastwiska i jak to może prowadzić do upadku projektu.
Z ważnych tematów, jakie wyniosłem z tej prezentacji, to gdy pewien zasób jest współdzielony przez wiele procesów, to procesy powinny mieć wyłączność do danego zasobu. Przykładowo procesy batch’owe, robiące coś na bazie danych, powinny mieć w czasie swojego działania współdzieloną bazę tylko na wyłączność. Rozwiązuje to wiele problemów. Ważne jest również monitorowanie metryk systemu. Ogółem prezentacja fajna sporo przykładów z życia, ale trochę mało konkretów.
Następnie byłem na prezentacji
Rebecci Wirfs-Brock Why We Need Architects (and Architecture) on Agile Projects. Prelegentka mówiła, że małe, niekrytyczne projekty nie potrzebują wiele zajmowania się architekturą. Według niej, architekt powinien być odpowiedzialny za:
- redukcję technicznego długu
- integrację nowej wiedzy z kodem (czyli refactoring, redesign, sprzątanie kodu)
- testy jednostkowe
- standardy kodowania
- zwięzłość (użycie API, logowanie, obsługa błędów)
Generalnie kiedy zespół jest większy niż 9 osób, to należało by się w jakiś sposób podzielić i skoordynować działania pomiędzy grupami. Przy dużych projektach, powinno się dodatkowo poświęcić iterację zerową na eksperymenty i prototypy, aby można było dobrać odpowiednią architekturę. Powinna również w projekcie znajdować się osobna tablica dla architektonicznych tematów.
Następnie udałem się na wykład
Sławka Sobótki pt. Ewolucyjna Destylacja Architektury – myślenie wizualne na przykładzie Ports&Adapters. Dla tego prelegenta, architektura to segregacja kodu na kawałki. Bardzo ciekawe stwierdzenie, które przypadło mi do gustu. Sławek pytał uczestników, jak wyobrażamy sobie kod. W końcu piszemy go codziennie, więc jakąś postać w naszej pamięci powinien on mieć. Ja sam do dzisiaj nie mam jednoznacznej odpowiedzi na to pytanie. Z jednej strony widzę interakcję pomiędzy obiektami, a z drugiej myślę wymaganiu które aktualnie implementuję i formalizuję je do postaci zrozumiałej dla kompilatora. Kod wyobrażam sobie w tym przypadku jako transformację żądanej odpowiedzialności w tekst. Nie mam na pewno w głowie diagramów klas w stylu UMLa, gdyż raczej na co dzień uprawiam TDD. Będę musiał sobie w pracy przypomnieć tą kwestię, to może odpowiem sobie wtedy na to pytanie.
To o czym było mówione, można znaleźć na prezentacji:
http://prezi.com/p0psif9qixgz/ports-adapters/ Z ważniejszych aspektów, to należy wymienić różne, możliwe architektury aplikacji:
- Micro Kernel
- Pipes & Filters
- Layers
- CQRS
- oraz tytułowe Ports & Adapters.
Odnośnie ostatniej architektury była poświęcona prezentacja, wraz z wyjaśnieniami na przykładowym kodzie. Było również trochę o
Sadze, oraz o możliwych problemach, jakie mogą wystąpić podczas stosowania Ports & Adapters.
Prezentacja była pełna żartów, ciekawa i trzymała wysoki poziom. Część rzeczy już widziałem na innych prezentacjach, ale prelegent wyjaśnij to na swoim blogu we wpisie:
Materiały z konferencji Java Developers Day. Generalnie zbierając wiedzę rozsianą po różnych prezentacjach Sławka, kształtuje mi się coraz bardziej wyraźnie, rozwiązanie znane pod nazwą DDD, którym namiętnie od jakiegoś czasu zajmuje się prelegent. Pytanie tylko, czy ludzie będą chcieli zmienić swoje podejście i wyjść po za ramę modelu trójwarstwowego? I czy to podejście wejdzie do kanonu nauczania na studiach informatycznych?
Następnie udałem się na prezentację
Pawła Badeńskiego The Catcher in the Code. Na tej prezentacji siadłem trochę za blisko i nie za bardzo widziałem slajdy (mównica zasłaniała). Wykład był bardzo ogólny, a jego przesłaniem było, że powinniśmy pisać czysty kod. Było o 4ch ważnych regułach:
- pisaniu takiego kodu ze świadomością, jakby osoba która musi później z nim pracować, była seryjnym mordercą i wiedziała gdzie mieszkasz
- nazwy metod i zmiennych należy tak samo dokładnie dobierać jak się wybiera imię dla swojego dziecka
- write your code with your brain in mind
- stop codding, start telling the stories (cieżko było mi to jakoś sensownie przetłumaczyć)
Ogółem nie lubię jak na konferencjach są takie luźne, niewiele uczące prezentacje. Temat czystego kodu przewija się już od kilku lat i myślę, że na konferencję przychodzą osoby, które już wiedzą o tym.
Następnie byłem na prezentacji
Piotra Buckiego o XSS. Generalnie ataki Cross-site scripting dzieli się na persistent (czyli zapisany na serwerze) i non-persistent, czyli najczęściej zmodyfikowany URL. Jak się bronić przed tego typu atakami? Przede wszystkim filtrowanie danych wejściowych nazywane po angielsku Sanitization. Dzięki temu widzimy później w naszej bazie danych typowo HTMLowe krzaczki. Technika te jest ważna, ale zazwyczaj nie wystarczająca. Zalecanym rozwiązaniem jest konwersja HTML’a do DOM’a i stosowanie białej listy dozwolonych tagów.
Inną możliwością jest escape’owanie danych wyjściowych. Czyli jak komuś uda się zapisać złośliwy skrypt w bazie danych, to lepiej go już wyświetlić w postaci tekstowej na stronie zamiast pozwolić się wykonać. Należy jednak pamiętać, aby escape’ować do odpowiedniego kontekstu.
Było jeszcze przejście po frameworkach Javowych, z wyszczególnieniem jakich konstrukcji używać, a jakich nie i kilka ogólnych przykładów podatności. Ogółem wykład średni, jakoś nie porwał ani mnie, ani publiki (żadne pytanie nie padło). Czegoś mi ewidentnie w tej prelekcji brakowało. Może jakiś konkretny przykład, że XSS jest poważnym zagrożeniem by lepiej podziałał na wyobraźnię uczestników?
Następnie udałem się na wykład
Hardy Ferentschik’ na temat Hibernate Search. Prelegent jest developerem tegoż mapera obiektowo relacyjnego. Hardy pokazał, jak można korzystać z
Hibernate Search. Jest to projekt, który bazuje na
Lucynce, zintegrowany oczywiście z Hibernatem. Wadą projektu Apache jest konieczność dobudowania indeksu, gdy nastąpiły jakieś zmiany w bazie. Hibernate Search wprowadził więc przyrostowe aktualizowanie indeksu. Czyli jak coś aktualizujemy / zapisujemy w bazie, to równocześnie jest aktualizowany indeks Lucene. Wszystko jest oczywiście konfigurowalne za pomocą adnotacji, czyli definiujemy, po których polach klasy będzie możliwe wyszukiwanie.
Chcąc wyszukać już cos konkretnego z naszego zbioru danych, można skorzystać z API dostarczonego przez Lucene, lub z Hibernate’owego Query DSL’a. Było jeszcze o wydajności projektu, projekcjach i paru innych możliwościach projektu.
Drugiego dnia konferencji udałem się na prelekcję
Henri Kerola na temat Vaadina. Pamiętam, że na
33 Degree byłem zachwycony prezentacją tegoż frameworka. Tutaj jednak już po minucie, wiedziałem, że długo na wykładzie tego pana nie wysiedzę. Niestety ten pan się kompletnie nie nadaje do występów publicznych. Początkowo było trochę o frameworku, aż w pewnym momencie zaczęło się kodowanie na żywo. Henri pokazał, jak łatwo można spiąć bazę danych z tym co jest w warstwie widoku i dostają za darmo Lazy Loading, podczas przewijania listy użytkowników w dół. Jednak wklejenie SQL’a bezpośrednio w kodzie UI bardzo mi się nie spodobało. Jak już uczyć, to bez antypatternów. W porównaniu z tym co pokazał Joonas Lehtinen na 33 Degree było to smutne.
Następnie chciałem iść na
BDD Rafała Jamróza, ale zagadałem się na korytarzu, a sala była wypełniona po brzegi, a nie chciało mi się stać. Udałem się więc na prelekcję Adama Biena pt.
Java EE–Future Is Now, But It Is Not Evenly Distributed Yet. Adam pokazał projekt mavenowy, z którego usuwał zależności, które są zbędne przy korzystaniu z Javy EE 6. Tworząc projekt w korporacyjnej szóstce nie potrzeba nam już
web.xml’a, ani innych biblotek, które standardowo wrzucamy do nowych projektów.
Prelegent wyśmiał kilka konwencji, które są namiętnie bez zrozumienia stosowane na co dzień w projektach. Przykładowo postfix w nazwach klasy
Impl. Co się wtedy stanie, gdy przyjdzie nam napisać kolejną implementację tego samego interface’u? Nazwiemy ją
Impl2,
Impl3, itd. No i po co nam interface’y, skoro mamy jedną implementację? Bo pewnego dnia trzeba będzie napisać inną implementację... Później było o tym co można w Javie EE 6 robić. Co ciekawe, prelegent używał na prezentacji NetBeans’a. Było to wielkie zaskoczenie dla mnie, gdyż dawno nie widziałem tego środowiska w akcji.
Później byłem n a wykładzie
Patrycji Węgrzynowicz na temat bezpieczeństwa open source’owych bibliotek Javowych, których używamy na co dzień. Na początku było omówione, jak można oceniać podatności w aplikacjach, jak są przyznawane za to punkty i jak można scharakteryzować owe luki w oprogramowaniu. Później było sporo wykresów, bazujących na
NVD. Patrycja początkowo skupiła się na serwerach aplikacji i co ciekawe to najbardziej dziurawe są te komercyjne. Było również trochę o framework’ach tj. Struts 2, Seam, GWT i szkoda że tylko o tych. Brakowało mi czegoś w tym wykładzie, jakoś mnie nie zaciekawił zbytnio.
Na koniec byłem jeszcze na wykładzie
Martina Gunnarssona i
Pär Sikö o JavieFX. Trochę dziwnie się patrzy na wykład prowadzony przez 2 osoby. Bo gdy jeden mówi to drugi nie zawsze wie co ze sobą zrobić. Panowie mówili fajnym angielskim, kompletnie bez akcentu, jednak jeden mówił zdecydowanie za cicho. Prelegenci pokazywali ciekawe dema i stworzyli pewną kabaretową atmosferę. Mam na myśli śmieszne dialogi, jakie pomiędzy sobą prowadzili. Niestety na zawartości merytorycznej już się nie skupiłem.
Po obiedzie pokręciłem się jeszcze trochę po konferencji, porozmawiałem z ludźmi i udałem się w stronę Wrocławia.
Z konferencji nie jestem zadowolony, nie za wiele z niej wyniosłem pod względem merytorycznym. Od strony organizacyjnej nie było się do czego przyczepić: dobre obiady (choć był problem z miejscem do jedzenia), impreza, miejsce konferencji... Tylko coś organizatorzy nie trafiają z doborem wykładów. Jak dla mnie JDD ma szansę być dobrą konferencją, ale chyba zawsze będzie tylko miała tą szansę.
