poniedziałek, 10 grudnia 2012

Java Developers Day 2012


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ę.

2 komentarze:

  1. Marcin, nie bądź taki malkontent, ja choć na konferencji nie byłem, widzę kilku światowej sławy prelegentów (np. Adam Bien) i top polish speakers (np. Sławek S.), więc chyba tak źle nie było. Ale jak się jeździ na 5 konferencji w roku...
    :)
    Peace,
    Andrzej

    OdpowiedzUsuń
  2. @AndrzejB :) Samo nazwisko nie wystarcza, ważny jest jeszcze przedstawiany temat. Sławek S. miał bardzo dobrą prezentację, ale u Adama Bienia było już gorzej. Nie jest to jak dla mnie najwyższa światowa półka, a dla dwóch wystąpień jechać taki kawał - nie widzę sensu.
    Thx za komentarz, a Twój blog zasubskrybowany:)

    OdpowiedzUsuń