33rd Degree 4 Charity we Wrocławiu

Keep things in memory with Cache, Mateusz Herbut

Mateusz na początku przedstawił ciekawą historię, odnośnie tego, dlaczego się zainteresował cache’m i kiedy został zdefiniowany standard JSR-107 - JCache. Fajnie się całość zbiegła z datami z filmu "Powrót do przyszłości", co prelegent dobrze wykorzystał na slajdach.

Mateusz bardzo fajnie przedstawił na diagramach sekwencji różne techniki działa cache'a:

• Cache Aside
• Read Through
• Write Through
• Write Back
• Write Behind
• Refresh Adead

Pierwsze trzy techniki z pośród wymienionych są zdefiniowane przez standard JSR-107, a pozostałe są wspierane dodatkowo przez niektóre implementacje.

Cache Aside jest najprostszy. Klient (aplikacja) sprawdza najpierw, czy wartość jest dostępna w cache’u. Gdy nie, to aplikacja sama odczytuje wartość ze źródła prawdy (dysku, bazy danych, etc.) i jeśli chce, to ją wrzuca do cache’a.

W metodzie Read Through to cache, a nie aplikacja kliencka, jest odpowiedzialna za odczyt wartości ze źródła prawdy i jej zapamiętaniu u siebie na później.

W podejściu Write Through to cache zapisuje wartość do źródła prawdy (synchronicznie) i zapamiętuje u siebie.

Write back zapisuje dane do źródła prawdy, dopiero wtedy gdy dana wartość jest usuwana z cache’a. Podejście to jest często stosowane w procesorach (L1, L2 cache) i wartości te mogą być niespójne ze źródłem prawdy (pamięć RAM). O unieważnieniu cache’a decyduje cache provider.

Przy Write behind klient zapisuje do cache’a i cache asynchronicznie rozpoczyna zapisywanie do źródła prawdy. Gdy w międzyczasie, ktoś będzie chciał odczytać wartości, to dostanie je bezpośrednio z cache’a.

W ostatniej metodzie Refresh Ahead cache decyduje podczas odczytu, czy wartość trzeba odświeżyć, czy nie.

Dalej było jeszcze o 3ch rodzajach operacji jakie mogą być wywoływane na cache’u:

• Pessimistic locking
• Lock free
• Optimistic locking

ale tu już nie będę przedstawiał, które są które.

Bardzo fajna, mięsista prezentacja. Uwagi odnośnie sposobu prezentowania  przekazałem wieczorem bezpośrednio Mateuszowi.

-XX:+UseG1GC, Jakub Kubrynski

Następnie Jakub Kurbyński ładnie omówił Garbage collector G1, który na być domyślny w Javie 9. Prelegent fajnie przeszedł przez to w jaki sposób jest zorganizowana pamięć w Javie i jakie to ma konsekwencje dla algorytmów odśmiecania. Stopniowo powoli odkrywaliśmy nowe pomysły w sposobach organizacji pamięci i algorytmów odśmiecających.

W G1 mamy wiele faz, ale dokładniej były omawiane 4:

• Young GC
• Concurrent cycle
• Mixed GC
• Full GC

Young GC to odśmiecanie młodej generacji, odpalane po zapełnieniu wszystkich regionów typu Eden. Jest ono wykonywane równolegle i zatrzymuje naszą aplikację. Concurrent Cycle bazuje na wynikach poprzedniej fazy i stara się znaleźć regiony łatwe do odśmiecenia i je oznacza. Mixed GC uwalnia te obszary z poprzedniej fazy. Czyści on pamięć zarówno z młodej generacji, jaki i starej. Najgorzej, gdy dojdziemy do Full GC (jak go zobaczymy w logach), gdyż on odśmieca całą pamięć i zajmuje sporo czasu, bo wykonuje się jednowątkowo. Powinniśmy tego unikać.

Fajne było podsumowanie, jak tuningować G1. Najlepiej ustawić:

-XX:MaxGCPauseMillis=250

lub na inną empiryczną wartość. Wtedy G1 będzie starał się nie przekroczyć zadanego czasu na odśmiecanie. Oczywiście gdy wartość będzie zbyt mała to się to nie uda. Złą stroną tuningu jest natomiast ten slajd:

czyli flagi których należy się wystrzegać ;)

Jeszcze inne dobre praktyki to:

A do przeglądania logów warto skorzystać z GCViewer, JVisualVM i Mission Control.

Nagranie z Confitury, polecam sobie obejrzeć:

Później była przerwa obiadowa, po której na prezentację Tomka Dziurko "Brzydka Pani od HR radzi…” po raz N-ty nie chciało mi się iść (widziałem na YT), a konkurencyjny temat mnie nie zachęcił. Filmik z prezentacji Tomka poniżej:

Liquibase - zarządzanie zmianami w relacyjnych bazach danych, Marcin Stachniuk

W kolejnym slocie przyszedł czas na moją prezentację. Grono zainteresowanych było niewielkie, bo w drugiej sali w tym czasie mówili o mikroserwisach po raz 144. Slajdy (trochę zaktualizowane od ostatniego razu) poniżej.

Ze zmian (po za kolorkami dopasowanymi do konferencji) to istnieje łatwiejszy sposób na wprowadzenie Liquibase'a do istniejącego projektu, niż ten który przedstawiałem na WrocJUG'u. Można skorzystać z komendy changeLogSync, która to tworzy i wypełnia danymi z changelog'a tabele potrzebne do działania biblioteki (DATABASECHANGELOG i DATABASECHANGELOGLOCK), a same zmiany nie są wykonywane. Po więcej szczegółów zapraszam na stonę Liquibase'a: Adding Liquibase on an Existing project.

Drugą wartością dodaną do prezentacji jest moje subiektywne porównanie Flyway'a i Liquibase'a, ale kot nie był niech żałuje.

Java 9, Arkadiusz Sokołowski

Prelegent pokazał parę nowości które nas czeka w kolejnej wersji Javy. Było oczywiście o REPLu i modułach, czyli projekcie Jigsaw i jak to na nas wpłynie. Prezentacja była ok, ale gdzieś już coś o nowościach słyszałem...

Java developer meets AngularJS/JavaScript: real-world projects’ experiences, Marek Matczak

Prelegent pokazywał z początku popularność różnych języków programowania, gdzie górował JavaScript i Java. Marek proponował te dwa języki do obecnych projektów, a dokładniej Spring-Boot’a i AngularJS’a.

Prelegent przedstawił, jakie są możliwości połączenia tych dwóch światów, od strony budowania aplikacji. Jedno podejście, to łączenie części frontend'owej z buildem Maven’owym. Można do tego wykorzystać maven-assembly-plugin, który buduje zzipowaną aplikację kliencką, a później za pomocą exec-maven-plugin można uruchomić node.js’a. A całość do WAR’a można wrzucić za pomocą: maven-war-plugin’a.

Drugie podejście proponowane przez Marka to wykorzystanie exec-maven-plugin’a do budowania frontendu w trakcie fazy generate-sources. Zasoby te wrzucamy do src/main/resources/static, czyli tam gdzie standardowo Spring Boot się ich spodziewa.

Całość jest dostępna na GitHubie jako Open Application Standard Platform (OASP).

Z ciekawostek, które mi utkwiły, to warto się przyjrzeć Google JavaScript Style Guide i Idiomatic JavaScript, aby wiedzieć jak dobrze pisać kod w JavaScript’cie.

Warto też na przyszłość przyjrzeć się Isomorphic JavaScript. Dzięki temu, będziemy mogli wyrenderować stronę HTML po tronie backend'u, co pozwoli nam np. na szybsze ładowanie się strony głównej naszej aplikacji.

Muszę się również przyjrzeć Gulp’owi, gdyż on ma wbudowane reverse proxy.

Dzień 2
On-heap cache vs. Off-heap cache, Radek Grębski

Drugi dzień zaczął się bardzo mięsistą prezentacją na temat pamięci off-heap, czyli pamięci po za standardowym heap’em Javowym. Jest to pamięć, która nie jest zarządzana przez Garbage Collector, można w niej zapisywać tylko tablice bajtów (korzystająć ze standardowego API) i sami musimy zajmować się jej zwalnianiem.

Generalnie bardzo polecam tą prezentację, jest dostępne nagranie z Confitury 2015 jak i kod na GitHubie: https://github.com/rgrebski/confitura2015

Trochę podsumowując prezentację:
Aby zaalokować pamięć w Javie, można skorzystać z następujących klas: HeapByteBuffer (na stercie [heap], do 2 GB), DirectByteBuffer (po za stertą, do 2 GB), MappedByteBuffer (po za stertą, do 2 GB, pamięć perzystowana), Unsafe.allocateMemory() (więcej niż 2 GB).

Pierwsze 3 klasy mogą allokować do 2 GB ponieważ jako argument przyjmują int’a, który ich ogranicza. Bardzo ciekawą klasą jest MappedByteBuffer, która tworzy buffer w pamięci, który może być zapisywany do pliku na dysku. Ma on tą przewagę nad wszystkim innym, że w przypadku całkowitego crash’u maszyny wirtualnej zapis i tak się powiedzie. Operacja ta jest zapewniana przez system operacyjny.

Chcąc allokować pamięć większą niż 2 GB to już trzeba korzystać z Unsafe’a. Korzystanie z tej klasy nie jest łatwe i wygląda jakby sam Chuck Noris ją pisał. Właściwie ta klasa z definicji miała być dostępna tylko dla „zaufanego kodu”, czyli do wewnętrznego użytku przez Javę. Ale coś poszło nie tak i obecnie masa frameworków i bibliotek z niej korzysta. Co gorsza to klasa ma być niedostępna w Javie 9, więc będzie ciekawie. Sporo kodu trzeba będzie przepisać, albo znaleść haka, aby się dostać do odpowiedniego modułu.

Dalej było o Chronicle Map. Jest to mapa, która jest zapisywana po za stertą. Jest też perzystowalna, dzielona pomiędzy osobnymi procesami JVM (również po sieci). Jedynym minusem jest fixed size, tzn. musimy wiedzieć jak duże będą nasze obiekty. I tak dla String’ów i kolekcji musimy za pomocą @MaxSize zdefiniować jak maksymalnie długie będą nasze teksty i jak wielkie kolekcje w obiektach. Gdy przekroczymy granicę to dostaniemy błąd. Obiekty zapisujemy do bloków o stałej wielkości - trochę pamięci się marnuje, ale dostęp do niej jest łatwiejszy.

Dalej było sporo porównań szybkości działania Mapy i Chronicle Mapy. Następnie prelegent opowiedział jeszcze z grubsza o Hazelcas’cie i Redisie, które również porównał z Chronicle Map.

Purely functional data structures, Tomasz Kaczmarzyk

Na początku zaczęło się o tym jak w językach funkcyjnych są zaimplementowane Listy, że składają się z głowy i ogona, że ogon wykorzystuje dokładnie tą samą strukturę co pierwotna lista itd. Kto się uczył Skali, lub innego języka funkcyjnego, to na pewno kojarzy koncept.

Póżniej było już ciekawiej, o tym jak jest zbudowana kolejka w językach funkcyjnych, w której można dodawać elementy na końcu. W standardowej liście jest to bardzo kosztowna operacja. Kolejka wprowadza pewne ciekawe pomysły, jak może ona być wewnętrznie zorganizowana, aby efektywnie przeprowadzać operacje na niej, mi.in. dodawania elementu na końcu. Ten fragment prezentacji był bardzo fajny.

Następnie było o tym jak wewnętrznie jest zorganizowany Git i jaka to jest ładna struktura danych. Temat był mi już wcześniej znany, więc mnie aż tak nie zachwycił jak poprzednia część.

Prelegent miał bardzo fajne slajdy (pisane kredą po tablicy), z ładnymi animacjami przejścia.

Sane Sharding with Akka Cluster, Michał Płachta

Tutaj było mnóstwo programowania na żywo, które działało! Prelegent się dobrze do tego przygotował.

Na początek napisał pojedynczego aktora obsługującego jakieś zapytania i zrobił test wydajności. Następnie, razem z publicznością, udoskonalał rozwiazanie… Implementowaliśmy system rozdzielający paczki na taśmociągu w jakimś magazynie.

Jako drugi krok, prelegent dorzucił drugiego aktora, który tylko podejmował decyzję o przeznaczeniu paczki. Następnie pojawili się kolejni aktorzy i to już bardzo przyspieszyło obsługę zapytań. Na koniec był jeszcze przedstawiony Akka cluster, aby można było to łatwo skalować na więcej maszyn.

Kod z prezentacji jest dostępny tutaj: https://github.com/miciek/akka-sharding-example. Warto przejść sobie po commit'ach i zobaczyć jak się aplikacja rozwijała.

Recepta na retrospekcję z finezją, Wòjcech Makùrôt

Retrospekcje są wpisane w Agile Manifesto jako dwunasty punkt:

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

czyli:

W regularnych odstępach czasu zespół analizuje możliwości poprawy swojej wydajności, a następnie dostraja i dostosowuje swoje działania do wyciągniętych wniosków.

Prelegent podał i opowiedział na przykładach swoje 10 punktów, które trzeba spełnić, aby mieć dobrą retrospektywę. Postaram się streścić, jak ja to zrozumiałem.

• Trzeba się dobrze przygotować. Spisać sobie plan spotkania, załatwić wszystkie niezbędne pomoce materialne, poszukać inspiracji, aby nie było nudno.
• Wprowadzamy jakiegoś IceBreak’era, aby rozmawiało się na luzie. Można odwrócić krzesła w sali, aby ludzie musieli zrobić coś innego. Prowadzący spotkanie (facylitator) może być niemerytoryczny - do niego należy moderacja i czasem pacyfikacja spotkania. Najważniejsze jest zdanie innych.
• Sprawdzamy, czy z poprzedniej retrospekcji udało nam się zrealizować jakieś postanowienia. Jeśli nic się nie udało, to powinniśmy przerwać i zastanowić się dlaczego się nie udało.
• Możemy opowiedzieć historyjkę, odnośnie tego co działo się w ostatnim sprincie. Budujemy przez to naszą wspólną świadomość.
• Grupowanie i priorytetyzowanie problemów - powinniśmy zajmować się tylko tymi najważniejszymi problemami.
• Dziel i rządź, czyli z którymi problemami jesteśmy zdolni sobie poradzić, i które będą miały największy wpływ na poprawę naszej sytuacji.
• Analiza przyczyn, dlaczego coś nie działa. Tutaj możemy skorzystać z metody 5x dlaczego, ość Ishikawy
• Planowanie naprawy, czyli: co trzeba zrobić, jak, kto będzie za to odpowiedzialny i na kiedy. Nie warto brać więcej niż 4 tematy do naprawy, bo to może być niemożliwe do zrealizowania.
• Celebracja tego do czego udało się dojść, czyli warto podziękować za współpracę, nagrodzić jakoś uczestników, wyjść na piwo...
• Śledzenie postępów w kolejnej iteracji, czyli sprawdzanie wykonania zadań.

Jako źródło inspiracji, warto spojrzeć na retrospectivewiki.org i blog.accentient.com/upgrade-your-sprint-retrospective-meetings oraz do książki Agile Retrospectives.

Slajdy z wystąpienia:

Refactoring meets big money, Michal Gruca

Prelegent przedstawił 3 możliwe podejścia do refactoringu:

• Codzienny refactoring
• Pisanie całości od nowa
• Przepisywanie modułów i podmienianie

Tylko jak to wszystko wytłumaczyć i sprzedać biznesowi? Warto zdecydować się na mierzenie jakiś metryk kodu. Można wziąć jakieś Sonarowe metryki dobrych projektów open source, porównać z metrykami naszych projektów, przełożyć na kasę i strać się wytłumaczyć, że to jest ważne. Warto zrobić sobie sceeena tych metryk z naszego projektu, aby później, po serii refaktoringów, zobaczyć czy i ile się poprawiło.

Warto też, przed pójściem do biznesu, trochę się przygotować. Można stworzyć jakieś prototypowe rozwiazanie i pokazać, że ono przynosi nam jakąś wartość. Przykładowo przyspieszymy build’a albo release’a.

Prelegent polecał do przeczytania fane case study, jak to Soundcloud przechodził na mikroserwisy.

Common fallacies of micro services, Marcin Matuszak

Prelegent w ciekawy sposób podszedł do tego, w jaki sposób obecnie są wynoszone pod niebiosa mikroserwisy, kontrargumentując potencjalne zalety jakie nam daje to podejście. I tak możliwość pisania każdego mikroserwisu w innym języku jest kiepski, bo jak ktoś napisze coś w bardzo egzotycznym języku (którego mało kto zna) i później się zwolni z pracy, to trzeba będzie nauczyć się tego języka, aby utrzymywać kod.

Monolityczne aplikacje wcale nie są takie złe. Są łatwe do pisania testów, w deploymencie i utrzymaniu. Jak rozmawiamy o mikroserwisach, to się skupiamy na tym, że mają być serwisy i że mają być małe. A zapominamy że mają sie komunikować po sieci, co przysparza masę dodatkowych problemów. Jeśli zepsuliśmy aplikację monolitową, to również i zepsujemy mikroserwisy.

Podsumowując całość, była to bardzo fajna konferencja, w końcu coś ciekawego i większego zawitało do Wrocławia. Nie miałem wysokich oczekiwań co do prelekcji, a okazały się one na dobrym poziomie. Byłem więc pozytywnie zaskoczony tą konferencją. Jednocześnie sam miałem okazję wystąpić i wyświetlać swoje slajdy po raz pierwszy na kinowym ekranie.

Relacja z 33 Degree 2014

Tegoroczną konferencję 33Degree rozpocząłem od wykładu Tomka Bujoka pt. 33 things you want to do better. Pierwszy poprzedzający go keynote był nudny, a drugi gdzieś już chyba widziałem lub słyszałem.

Tomek przedstawił sporo narzędzi ze swojego toolboxa, z którymi warto się zaznajomić i w razie konieczności używać. I tak było o bibliotekach: Guava, Lombok, SLF4J, Unitils (testy jednostkowe na plikach), JUnitParams, Awaitility (do testowania wielowątkowego), Byteman (ciekawy projekt do zmiany zachowania kodu produkcyjnego w locie), Spock, grape (do skryptów shelowych w Groovy’m), Git, bash i inne. Na koniec Tomek zareklamował swój projekt: babun. Jest to skonfigurowana powłoka z preinstalowanym gitem i paroma narzędziami do przyjemniejszej pracy z shellem pod Windowsem.

Z powyższych warto sobie odświeżyć Lomboka. Kiedyś już przyglądałem się tej bibliotece, ale był wtedy problem ze wsparciem dla IntellJ Idea. Teraz wygląda na to, że jest już lepiej i doszła możliwość tworzenia builderów za pomocą adnotacji.

O kolejnej prezentacji: RESTing away from hell Jakuba Janczaka nic nie napiszę, bo było nudno i nawet nic nie zanotowałem.

Kolejna prezentacja Get Back in Control of Your SQL Lukasa Edera bardzo mi się podobała. Początkowo prelegent przedstawił wady na przykładowym kodzie takich rozwiązań jak: JDBC, EJB 2 / 3 i Hibernate. Rozwiązaniem na wszystko ma być JOOQ. Narzędzie to generuje na podstawie schematu bazy danych stałe zawierające nazwy tabel, kolumn itp. Później możemy z tego korzystać za pomocą fluent API, które jest bardzo zbliżone do SQL. Właściwie jedno i drugie czyta się tak samo, tyle że w Javie dochodzi kilka kropek i nawiasów. Jeszcze przyjemniej wygląda to w Scali. A całość jest Type Safe. Jest nawet jakiś prosty mapping na obiekty POJO. Niestety JOOQ, jest rozwiązaniem komercyjnym, dla komercyjnych baz danych.

Narzędzie spodobało mi się i chętnie bym z niego kiedyś skorzystał w projekcie. Jakby ktoś chciał obejrzeć wystąpienie (ale z GeeCON'a), jest już dostępne:

A w tak zwanym międzyczasie rozwinął się gorący wątek na Wrocław JUG (wielkie brawa za reaktywację) i padło tam jeszcze parę innych narzędzi tego typu: LIQUidFORM (ale to już trochę martwy projekt) Prevayler i Querydsl.

Kolejny wykład był dosłownie sprintem po nowościach w JEE 7. Prelegent (Arun Gupta) przeleciał w 50 min po 50 nowinkach, dotykając każdego aspektu tej technologii. Dla mnie były to jedynie zmiany kosmetyczne, żadnej nowej wielkiej rewolucji.

Następnie słuchałem prezentacji Josh Longa pt. Microservices and REST with Spring Boot. Było kodowanie na żywo, ale bardzo fajnie. Prelegent zaczął od start.spring.io i pokazał jak niewiele należy samemu dopisać, aby mieć już coś działającego. Było sporo o Richardson Maturity Model i trochę o bezpieczeństwie. W międzyczasie prelegent korzystał z ciekawej wtyczki do Chrome’a do generowania zapytań RESTowych: Advanced REST client.

Dzień drugi zaczął się znów od keynotów. Pierwszy był wypełniony tabelkami z Excela i kolorowymi Clipart’ami z Worda bez konkretnego przesłania. Typowy przykład jak nie robić prezentacji... Szybko opuściłem salę.

Drugi keynote był już lepszy. Prelegent wziął na studium przypadku pisanie latarki na iOS. Najważniejsze jest, aby przy różnych przedsięwzięciach nie tylko programistycznych, odpowiedzieć sobie na pytanie „What, Whoam and Why?”

Prelegent opowiadał dalej o aplikacjach i ich interakcji z użytkownikiem. Nasza aplikacja powinna mówić do pojedynczej osoby (używać odpowiednich form gramatycznych), bo interakcja jest między użytkownikiem a sprzętem. W ten sposób uda nam się przemówić do tłumów. Nie zmienimy w ten sposób całego świata (bo nie możemy), ale zmienimy świat dla jednej osoby, a to już jest sukces. A zmieniając rzeczywistość pojedynczych osób zmieniamy świat wielu osób.

Było jeszcze o reklamach Apple które nie mówią o tym jak świetny jest ich produkt, ale uderzają w ludzkie życie, uczucia i inne wartości. Na koniec było jeszcze o córce prelegenta, która mu zmarła, przez co wykład bardzo oddziaływał na emocje prelegenta, jak i słuchaczy.

Następnie byłem na wystąpieniu Tomka Nurkiewicza na temat OLAPowej bazy danych Saiku. Bardzo fajne narzędzie do generowania raportów, trendów, wykresów itd. Wykład był fajny, było wiele przykładów użycia… Jakbym kiedyś potrzebował, to chętnie spróbuję.

Później byłem na wykładzie Jarosława Pałki na temat Patterns for Organic Architecture. Spodziewałem się, że będzie to prezentacja bardziej techniczna, z przedstawieniem konkretnych wzorców, ale było bardzo miękko, więc się zawiodłem.

Następnie byłem na prezentacji Venkat’a Subramaniam’a, który przedstawiał Projekt Nashorn. Jest to narzędzie, które kompiluje kod JavaScript’a do bytecodeu JVM. Czyli możemy sobie po stronie serwera pisać w JavaScript. Prelegent pokazywał na żywo, jak można wywoływać JS z Javy i na odwrót.

Kolejnym slotem byłem mocno zawiedziony. Najpierw byłem na prezentacji Abdelmonaim Remani dotyczącej debuggingu. Wykład był tragiczny, jak dla studentów pierwszego roku. „Aby znaleźć bug’a trzeba najpierw zlokalizować komponent w którym on jest”. Musiałem opuścić prezentację. W innych salach również nie było lepiej, gdyż sporo ludzi wędrowało wte i wewte.

W końcu wylądowałem na prezentacji dotyczącej github’a i gerrit’a Luca Milanesio. Prelegent porównywał oba systemy i przedstawił workflow, aby push’ować do innego brancha, który po przeglądnięciu się merguje z masterem. Było również wspomniane o Git review plugin, który po wypushowaniu zmian podaje linka do review. Było również o jakimś pluginie do Jenkinsa, który wspiera Gerrita. Całość można przetestować na gerrithub.io, które się integruje z naszymi repozytoriami z GitHuba.

Następnie byłem na prezentacji JavaScript Design Patterns Pratika Patela. Było o wzorcach z JS, za pomocą których możemy osiągnąć pewne elementy, które mamy w Javie. I tak przykładowo za pomocą namespace możemy utworzyć globalny obiekt, w ramach którego możemy trzymać sporo rzeczy. Należy jednak uważać, aby nam ten twór nie urósł za bardzo, bo nie będzie on odśmiecany. Było jeszcze o Mixin module (coś na kształt Dependency Injection), publish subscribre w ramach jednego kontekstu, Command (jako Aspect) i Factory (np. w backbone).

Na koniec została jeszcze zaprezentowana ciekawa stronka: TodoMVC.com na której jest napisana jedna i ta sama aplikacja z wykorzystaniem różnych bibliotek JavaScriptowych.

Trzeciego dnia keynote’y były przesunięte na koniec dnia, więc na szczęście można było je bezboleśnie pominąć. A dzień rozpocząłem od wystąpienia Jarka Ratajskiego Doing WEB development clean way, gdyż miało być duże show i ciekawy sposób prowadzenia prezentacji. I rzeczywiście było trochę strzelania do zombie i wywoływania osób z publiczności do odpowiedzi. Było również poprawianie kodu JS na żywo, ale nie do końca ono działało, ze względu na przeskalowanie ekranu.

Co do konkretów, to Jarek pokazał, że należy korzystać ze statycznej analizy kodu, zwłaszcza w dynamicznych, słabo typowanych językach jak JS, gdzie można bardzo łatwo zrobić sobie krzywdę. Takową analizę można przeprowadzić za pomocą np. jshint. Prelegent również namawiał do korzystania z frameworków JS, takich jak angularjs i do używania pluginów w przeglądarkach wspierających development.

Było również o trendach, jak kiedyś, a jak obecnie tworzy się strony internetowe. I tak na dzień dzisiejszy królują single page applications. Z narzędzi było jeszcze o Lesscss które pomaga nam generować CSS. Wartością dodaną jest możliwość tworzenia zmiennych funkcji itp. do lepszego zarządzania tymi stylami.

Prezentacja fajna w formie, ale jak na konferencję pokroju 33 Degree, to było za dużo show, a za mało konkretów. A wiem, że Jarka na pewno stać na więcej.

Później byłem na prezentacji Jakuba Kubryńskiego na temat Spring Boot. Już wcześniej o tym na konferencji słyszałem, ale postanowiłem jeszcze raz zobaczyć. Generalnie framework (a właściwie zbiór frameworków) został pomyślany dla, ostatnio dość popularnych, microserwisów. Jest również świetną baza, dla nowych projektów, gdyż trzeba bardzo mało napisać aby wystartować z aplikacją. Dodatkowo aplikacja zawiera wbudowanego tomcata lub jetty, więc można bardzo szybko ją wystartować.

Jakub pokazał możliwości frameworka i ostatnie 15 minut był live coding. Poprzez lokalne Wi-Fi można było się połączyć ze stworzoną na szybko stroną i dzięki temu prelegent mógł pokazać satystyki jakie daje nam spring boot. Prezentacja bardzo udana.

Następnie byłem na reaktywnej Javie Tomasza Kowalczewskiego. Było o bibliotece RxJava, ale jakoś mnie nie poniosło. Sposób przemawiania do mnie nie dotarł.

Na koniec konferencji byłem chyba na najmniejszym wykładzie podczas całej imprezy. Była to prelekcja Dariusza Lukszy pt. Your own full blown Gerrit plugin. Na sali było jakieś 10 osób, i wszyscy zgromadzili się bliżej prelegenta. Ale trudno się dziwić, skoro w sali obok było show Venkata.

Darek opowiadał, jak łatwo można napisać plugin do Gerrita, który wykonuje ponowny build naszego kodu na Jenkinsie. Kod można znaleźć tutaj: gerrit-retriggerme. Darek bardzo zwinnie przełączał się pomiędzy otagowanymi wersjami swojego kodu, opowiadając przy tym co się w nim zmieniło. Temat ciekawy, jakby ktoś potrzebował.

Podsumowując konferencję było bardzo gorąco, zwłaszcza w namiocie ze stoiskami sponsorskimi. Dmuchawy i otwieranie kolejnych ścian trochę pomagało, ale to i tak lepiej niż gnieździć się w wąskich korytarzach kina. Na szczęście stanowiska sponsorskie szybko reagowały na upał i załatwiały zimne napoje w kolejnych dniach konferencji.

Fajnie też, że przygotowano aplikację na telefon z rozkładem jazdy, ale brakowało mi w niej informacji o tym, kiedy, gdzie, jaki konkurs jest rozstrzygany. Pomogłoby to jeszcze bardziej promować się sponsorom konferencji. W tym roku chyba najbardziej zaszalał Luxoft, dając (prawie) każdemu uczestnikowi tableta. Wiadomo, że nie był to jakiś super sprzęt, ale zasponsorowanie tak sporej ilości urządzeń to na pewno było nie lada wyzwanie i koszt. Choć pewnie spora większość uczestników już takie zabawki dawno posiada w swoich zasobach.

Co do poziomu wykładów, to było bardzo nierówno. Nie było chyba żadnego, który by wywrócił, lub choćby zachwiał mój dotychczasowy światopogląd. Brakowało mi również bardziej praktycznych warsztatów.

Sporo czasu zajęło mi sporządzenie tej notki, ale niełatwo jest streścić 3 dni konferencji w jeden wpis. A już na dniach zbliża się Confitura. Mam nadzieję, że relacja z tej imprezy powstanie szybciej.

33 degree 2012 warsztat z Wujkiem Bobem

W ramach konferencji 33 Degree 2012, po za główną częścią konferencji (opisanej w 3 częsciach: cześć 1, część 2, część 3) wybrałem się jeszcze na warsztat Clean Code z Wujkiem Bobem. Było jakieś 27 osób na tym szkoleniu, stoły poukładane jak w szkole, czułem się jak na lekcjach. Ale przynajmniej lekcja była z nie byle kim. Szkolenie miało formę otwartego, tzn. sami mogliśmy zadawać pytania i proponować tematy, o których będziemy mówić. Niestety jakoś nikt się do tego specjalnie nie kwapił.

Na początku każdy miał się przedstawić i powiedzieć cos o sobie. Wujek Bob notował, kto ile czasu już programuje. Wynik poniżej:

Na początku była znana historyjka na temat symbolu \r\n. Jak wiadomo, w naszej dziedzinie ważne są detale. Następnie Wujek polecał książkę Kent’a Beck’a Implementation Pattern, a następnie znów mówił znaną historyjkę o odwróceniu jednego bitu w swojej głowie.

Następnie było o tym, ze minimalizacja połączeń pomiędzy modułami, ułatwia zrozumienie otoczenia klasy, którą musimy zmodyfikować. I to kod uczy nowych pracowników w projekcie, jak należy pisać. Jeżeli kod jest brzydko utrzymany, to nie ma się co spodziewać, że nowi to poprawią. Dalej będą pisać brzydko.

Później znów było o tym jak w jednej firmie robili redesign całego systemu przez 10 lat. Ledwo wczoraj to słyszałem.

Po przerwie Wujek zaczął w swoim stylu, czyli od wykładu nie na temat. Tym razem było o tym, w jaki sposób policzono odległość Ziemi do Słońca. Dalej było na temat używania słowa spróbuję (ang. try). Nie powinniśmy z niego korzystać, ponieważ dla nas oznacza ono nie, a dla naszego managera znaczy tak. Później była kolejna znana już „przypowieść” o lekarzach, którzy nie myją rąk.

W końcu pojawił się jakiś kod na ekranie. Był to kod klasy org.free.date.SerialDate. Dokładnie ten sam, który był opisywany w książce Czysty Kod. Bob bardzo dogłębnie analizował komentarz do tej klasy i sukcesywnie wywalał z niego elementy, które był tam zbędne. Prelegent używa w swoim IDE czerwonego koloru do wyświetlania komentarzy. Dzięki temu wie, gdzie ktoś miał problem z napisaniem czytelnego kodu i musiał się wspomóc komentarzem.

Później uczestnicy kursu mieli podopisywać trochę testów do tej klasy na swoich komputerach. W tym czasie prelegent chyba nagrywał fragmenty do swoich nowych filmików.

Po kolejnej przerwie Bob opowiadał kolejną znaną swoją historyjkę o artykule z gazety, że powinien on mieć nagłówek (który przekazuje główną informację), a potem są detale dla zainteresowanych. W przypadku Javy jest całkiem podobnie, jedynie zmienne definiujemy na górze klasy. Dla prelegenta jest to głupa konwencja, ale wszyscy się jej trzymają, więc trzeba programować w taki sposób.

Następnie było o długaśnej metodzie z FitNesse’a, która operowała na kilku poziomach abstrakcji i była stworzona przez kopiuj – wklej. Dalej była kolejna opowiastka, tym razem o mamie, która kazała mu sprzątać w pokoju. Analogia dla nas jest taka, że póki jesteśmy w jednoosobowym pokoju, to możemy mieć dowolnie wielkie bagno, byle byśmy się w nim odnajdowali. W przypadku gdy pracujemy zespołowo, to niestety musimy zadbać o porządek. Jeśli nie możesz wyekstrahować metody, to powinieneś ją wyekstrahować (prawdopodobniej jest nieczytelna i robi więcej niż jedną rzecz).

Dalej była wzmianka o programowaniu funkcyjnym, które jest pozbawione efektów ubocznych. Następnie było o rozróżnieniu programowania obiektowego i strukturalnego. Programowanie obiektowe ułatwia dodawanie nowych typów, ale utrudnia dodawanie nowych funkcji.  Programowaniu strukturalnym jest odwrotnie. Nie oznacza to jednak, że nie da się tego łączyć. Da się, ale może to być ciężkie w utrzymaniu. Ciekawe dla mnie było jeszcze stwierdzenie, że w C można programować w sposób obiektowy, poprzez przekazywanie funkcjom innych wskaźników na funkcje.

Dalej było o metodach wieloargumentowych. Tak naprawdę problemem z metodami wieloargumentowymi jest pozycja tych argumentów. Ciężko spamiętać co na której pozycji jest, gdy metoda ma więcej argumentów. Przez to możemy zatracić swój flow w czytaniu kodu, gdyż będziemy musieli wejść na niższy poziom abstrakcji (czyli do wnętrza metody), aby sprawdzić który argument jest czym.

Dalej było o złych zależnościach czasowych w naszych aplikacjach. Przykładowo najpierw musimy wywołać metodę open(), a dopiero później możemy wywołać close(). Jedynym rozwiązaniem jakie widzi object mentor jest przekazywanie do metody otwierającej procedury, która ma się wykonać pomiędzy rzeczywistym open() a close(). Trochę gorzej jest, gdy musimy np. pracować na 2ch plikach równocześnie, bo to powoduje brzydotę kodu.

To tyle jeśli chodzi o pierwszy dzień. Wieczorem miałem to szczęście, że mogłem zjeść razem kolację (i wypić piwko) z Sebastianem i Wujkiem Bobem. Pomęczyłem go jeszcze trochę trudnymi pytaniami i oglądaliśmy razem Kraków nocą. Było to wyjątkowe przeżycie dla mnie. Dzięki Sebastian za organizację tego spotkania!

Dowiedziałem się między innymi, po co Wujek Bob na początku swoich wystąpień robi takie wstępniaki z innych dziedzin. Mianowicie chodzi o poprawę pracy umysłu ludzkiego, poprawę koncentracji i wyostrzenie abstrakcyjnego myślenia. Bob stosuje tą technikę od kilkunastu już lat.

Drugi dzień „treningu” zaczął się od różnych definicji czystego kodu. Były przedstawione te same osoby, które są opisane w książce Wujka Bob’a i ich odpowiedzi na pytanie, czym jest dla nich czysty kod.

Po pierwszej przerwie były zabawy Boba niebieskim laserem. Bardzo ciężko go otrzymać. Istnieje jednak tańsza wersja z domieszką fioletowego, ale nie jest ona taka fajna jak czysty niebieski laser. A ten zostawia ślady na tabliczkach fluorescencyjnych, a świecąc na zwykłe okulary, można zrobić sobie na chwilę okulary przeciwsłoneczne ;)

Dalej było o funkcjach. Te które często wywołujemy, powinny mieć krótkie nazwy i zazwyczaj dużo robią. Później nawiązała się dyskusja na temat używania różnych języków w kodzie, przykładowo polskiego i angielskiego. Czasem jest to wymuszone pewnymi typami projektów, gdzie jest narzucone, że kod musi być pisany po polsku. Niestety Wujek Bob nie miał zbytnio zdania na ten temat, gdyż jego ten problem nie dotyczy.

Później były jeszcze opowieści o wynalazcy notacji węgierskiej (że zarobił fortunę) i o ludzkim kodzie genetycznym.

Następnie Wujek Bob pokazywał przykład refaktoryzacji. Niestety przykład był z książki Martin’a Fowler’a Refaktoryzacja.... Prelegent refaktorował na żywo kod wypożyczalni filmowej. Prelegent zaszedł troszkę dalej niż zrobił to Fowler. To co mnie zaskoczyło, to fakt, ze na samym końcu, klasa która początkowo nazywała się Customer tak de facto powinna się nazywać Statement. Refaktoryzacja pokazała nam prawdziwe przeznaczenie klasy. Był to dla mnie jedyny szok jaki przeżyłem podczas tej prezentacji. Filmik który pokazuje to przekształcenie kodu (ale troszkę inne), został później udostępniony uczestnikom warsztatu. Morał z tego taki, że mając testy można łatwo zmienić design kodu.

Co do zasad Wujka Boba, które stosuje w swoich testach, to czasem rezygnuje on z zasady step down (aby czytać kod od góry do dołu, jak artykuł w gazecie). W testach jest dobrze umieszczać na początku własne assercje. Dzieki temu będzie wiadome, co tak naprawdę testujemy w danej klasie.

Następnie Wujek Bob opowiadał o Katach, a następnie zaprezentował Prime Factors Katę. Można sobie poszukać filmik na necie i samemu obejrzeć.

Później jeszcze robiliśmy „na sucho” problem, jak byśmy napisali algorytm sortowania? Za pomocą małych kroczków i TDD doszlibyśmy do najprostszego algorytmu bąbelkowego. Następnie Bob pokazał ze swojej strony artykuł: The Transformation Priority Premise gdzie przedstawił różne przekształcenia kodu. Twierdził on, że za pomocą tych przekształceń, można dojść z algorytmu bąbelkowego do quicksorta. Trzeba to kiedyś sprawdzić w praktyce.

Na sam koniec szkolenia był jeszcze czas na pytania publiki. Bob mówił o architekturze. Dla niego architektura to nie Tomcat, Spring, JSF i baza danych. Architektura to rozdzielenie tego co system robi (wymagania użytkownika) od technicznych „plug-in’ów” (jak Spring, UI, baza danych). I de facto to co powinniśmy testować, to architektura systemu, czyli wymagania użytkownika, a nie GUI i baza danych.

Było jeszcze pytanie co do programowania defensywnego (zabezpieczanie się w każdej metodzie na błędne parametry)? Według Wujka Boba, należy mieć zaufanie wewnątrz teamu i nie powinno się za każdym razem sprawdzać, czy jakaś wartość nie jest null’em. Natomiast pisząc zewnętrzną bibliotekę, którą będzie używał ktoś inny, należy się już oto zatroszczyć. Mówiąc kolokwialnie, musi ona być idiotoodporna.

Podsumowując dwudniowy warsztat z Robertem C. Martinem jestem trochę zawiedziony. Spodziewałem się usłyszeć więcej, niż jest napisane w książkach Clean Code i The Clean Coder. Żeby chociaż przykłady były z poza tych książek, aby były nowe opowiastki, a nie te już znane przez kogoś, kto przeczytał choć jedną ze wspomnianych książek. No i brakowało mi więcej praktyki na tym szkoleniu. Dla kogoś kto był świeży w temacie przedstawianym przez prelegenta, warsztat na pewno wydal się ciekawy i pouczający. Ja jednak spodziewałem się czegoś więcej.

Jedynie wielki autorytet, szacunek, wspólna kolacja, zdjęcie, autograf na książce i możliwość zadania wielu pytań, ratuje obraz całej sytuacji. Gdyby nie to, byłbym mocno rozgoryczony, a tak jestem nie do końca usatysfakcjonowany. Mimo wszystko cieszę się że wziąłem udział w tym szkoleniu, będę je miło wspominał. Zdjęcie z Wujkiem Bobem trzeba teraz wywołać, w ramkę i na biurku w pracy postawić, aby już nigdy nie pisać brzydkiego kodu ;)

33 degree 2012 dzień 3

Dzień 1
Dzień 2
Warsztat z Wujkiem Bobem

Na początku 3ciego dnia konferencji miałem wielki dylemat na co pójść. Stwierdziłem, że z kolejnej prezentacji Venkat’a dużo nie wyniosę, a Jacka Laskowskiego pewnie jeszcze uda mi się zobaczyć w tym roku podczas innej konferencji. Ostatecznie poszedłem więc na prezentację Andreas'a Krogh'a pod tytułem: Lift from a JEE perspective. O tym framework’u słyszałem wiele dobrego (jest odporny na większość popularnych ataków) i spodziewałem się usłyszeć jak to widzi ktoś, kto go używał a siedział wcześniej w JEE (po prostu tytuł na to wskazywał).

Niestety była to moja najbardziej stracona godzina podczas całej konferencji. Prezentacja była kiepsko przygotowana (dużo tekstu, slajdy które były pomijane, XML’e z konkretną konfiguracją większości bibliotek użytych w projekcie prezentera), ale jeszcze gorzej było z samym prowadzącym, który mówił cicho monotonnie i chciało się tylko spać.

Co do treści prezentacji, to prelegent wymieniał początkowo co mu się w Javie nie podobało. Było o problemach w refaktoryzają (nie pamiętam w którym miejscu), z niedziałającymi testami GUI (przy zmianach w GUI wszystko im się sypało), z internacjonalizacją (m.in. chciano mieć w rzucanych wyjątkach komunikaty w języku natywnym prelegenta). Andreas narzekał, że nie ma w JPA standardu obsługi dla Lazy associations i że trzeba dużo kodu wygenerować na potrzeby DAO. Ponadto JSF jest pewnym standardem, ale mało kto go do końca rozumie, a alternatywne rozwiązania też mają sporo wad.

Później były przedstawiane już wcześniej wspomniane konfiguracje XMLowe i masa dziwnych rozwiązań (np. klasa JpaTextField która z JPA nie miała nic wspólnego). Generalnie prelegent brał udział w projekcie gdzie było jedno wielkie wymieszanie Javy i Scali z dodatkiem dziwnych pomysłów. Na koniec było krótkie demo i można było jedyne tam zobaczyć działanie push’a / pull'a oferowanego przez Comet. Dziękujemy temu panu, więcej nie zamierzam iść na jego prezentację.

Następnie byłem na wystapieniu Ken'a Sipe'a o MongoDB, czyli na temat bazy dokumentowej. Baza ta zawiera, dokładniej rzecz ujmując, kolekcje, które zawierają dokumenty. Prelegent pokazywał tworzenie nowej bazy i póki coś w niej nie wyląduje, to nie jest ona zapisywana na dysku.

Z MongoDB mamy możliwość zobaczenia planu wykonania zapytania. Możemy zakładać indeksy na właściwościach rozróżniających typy składowanych dokumentów i przez to poprawić wydajność. Ogółem chcąc coś wydajnie przechowywać w tej bazie, należy najpierw zrobić denormalizację.

Baza ta nie ma transakcji, przez co można bardzo łatwo ją skalować na wiele maszyn. Czyli zgodnie z CAP Theorem, tracimy na jednym, za zyskujemy na innym miejscu.

Następnie było wystąpienie Roberta C. Martina znanego bardziej jako Wujek Bob. Prezentacja była na temat 3 praw TDD. Początkowo wykład zaczął się od omówienia zasady działania lasera. Później było już powtórzenie tego co wujek pisze w swoich książkach. Było o zielonej opasce - symbolu, którego nie może zdjąć gdyż ma obsesję na temat testów i uważa siebie za profesjonalistę. Profesjonalista to ktoś taki, kto bierze na siebie odpowiedzialność za wykonywaną pracę, a managerowie potrzebują profesjonalistów w swoich zespołach.

Później było o krzywej Produktywności vs. Czas, o bagnie (w kodzie) i historia o redesign’ie systemu, czyli rozpoczęciu projektu od nowa, aby uzyskać lepszy design. Jednak zazwyczaj w takim przypadku stary zespól dalej rozwija poprzedni projekt, a ten nowy nigdy nie może dogonić starego. Sytuacja taka może trwać nawet 10 lat. Rozwiązaniem na to jest zasada skałtów, czyli poprzez niewielkie zmiany w kodzie, możemy pozbyć się tego całego bagna.

Dalej było o tym, że TDD zmusza nas do decoupling'u. Powinniśmy ufać swoim testom, analogicznie jak przy skokach spadochronowych, gdzie samemu musimy sobie odpowiednio spakować spadochron. TDD to gra z samym sobą – piszemy niedziałający test, który po chwili działa – i tak w kółko.

Co do tytułowych 3 praw TDD to nie było to: Red, Green, Refactor, a cos takiego:

• Write no production code unless you have a failing unit test.
• Do not write more of a unit test than is sufficient to fail. (And not compiling is failing.)
• Do not write more production code than is sufficient to pass.

Później było trochę pytań od publiczności, m.in. jak wprowadzać zmiany w projekcie. Bob mówił, aby zacząć od siebie i wtedy inni zobaczą, że jest to fajne i również będą tak postępować. A jak nie to iść za radą Martina Fowlera: "Change your organization or change your organization".

Co do testów akceptacyjnych to należy zrobić wszystko, aby były one szybkie. Przede wszystkim jak jeden test sprawdza logowanie, a drugi składanie zamówienia, to ten drugi powinien się obejść bez logowania. Oznacza to, że trzeba czasem podmienić pewne zachowanie system i przez to testy powinny śmigać szybciej.

Następnie była prezentacja Code Craft prowadzona w przedziwnym stylu. Mianowicie Nathaniel Schutta miał 267 slajdów na godzinne wystąpienie, co daje ponad 4 slajdy na minutę. Fakt faktem, na slajdach były pojedyncze hasła, ale były one bardzo zgrane z prelegentem.

Prelegent wymienił kilka ciekawych narzędzi, których nie znałem, jak crap4j, Crucible (do robienia review kodu), Clover (do prezentowania statystyk buildów – wykresów, pokrycia, można dużo konfigurować), Jester (do testów mutacyjnych, ciekawe jak on ma się do PIT’a) i Simian (detektor kodu pisanego metodą Copiego-Pastea).

Co do prowadzania zmian w projekcie (np. wprowadzenie FindBug’a), to prelegent przedstawił ciekawe podejście jak to robić. Nie można włączyć od razu wszystkich możliwych dobrych reguł jakie są, bo to spowoduje wyświetlanie brzydkich wykresów jakości kodu i nikt z tym nic nie będzie robił, a kod będzie dalej gnił. Trzeba na początek włączyć tylko kilka reguł, poprawić kod i sukcesywnie dołączać dalsze reguły.

Inną ciekawą rzeczą jest aktualizowane przez świeżaków Developrs handbooks, czyli dokumentów tłumaczących jak skonfigurować środowisko, jakie są standardy w projekcie itd.

Kolejnym ciekawym pomysłem, jest nagrywanie filmików, ze spotkań na których są podejmowane ważne decyzje projektowe. Jak się po jakimś czasie okazuje, że została podjęta jakaś zła decyzja w projekcie, to można zawsze wrócić do nagrania i przypomnieć sobie dlaczego tak to się stało a nie inaczej.

Następnie był wykład Jurgen Appelo pt. How to Change the World. Prelegent jest autorem książki Management 3.0 i podczas prezentacji opowiadał, jak można przekonywać innych ludzi do czegoś. Bazował na kilku książkach m.in. Influencer, Leading Changes, Fearless Change. Jedna z ciekawych metod wpływania na innych współpracowników, jest przedstawianie nowych pomyslów, podczas wspólnego jedzenia. Pewnie to wynika z tego, że rozmówca może na wtedy poświęcić więcej uwagi, niż gdy siedzi przy biurku i właśnie go wyrwaliśmy z flow.

Był jeszcze przedstawiony wykres innowacyjności, The Feedback Door (czyli karteczki przylepiane na drzwiach, aby dawać feedback) i jeszcze parę abstrakcyjnych przykładów, jak wprowadzać zmiany. Generalnie książkę autora można ściągnąć z ze strony management30.com.

Na koniec 3ciego dnia został wykład Wujka Boba. Standardowo na początku było trochę o fizyce/biologii, że ludzie mają 3 receptory koloru, a składowe RGB również są trzy.

Tym razem wykład był prowadzony kompletnie bez użycia rzutnika (kto by się tego spodziewał w tych czasach). Jedynie prelegent miał małe karteczki z notatkami do pomocy (których i tak prawie nie używał).

Bob tłumaczył nam, jak pracują obecni inżynierowie. Owocem ich pracy jest zazwyczaj jakiś dokument, który później się przekazuje dalej i ktoś go realizuje. Przykładowo architekci tworzą plan budynku, wraz z tym jak ma być urządzone wnętrze. Przekazują dokument ekipie budowlanej i ta już działa. Elektronicy przykładowo projektują płytkę / układ scalony, przekazują do fabryki i ta wytwarza gotowy produkt.

A jak to jest w naszej profesji? Co jest tym dokumentem, który generujemy i który dajemy fabryce do realizacji produktu? Okazuje się, że jedynym słusznym dokumentem wytwarzanym przez inżynierów oprogramowania jest kod źródłowy. Nie stosy dokumentacji fachowej, technicznej, analitycznej i jeszcze nie wiadomo jakiej, a kod. Kod jest zawsze aktualny i prawdziwy. Kod prawdę Ci powie. Fabryką w tym przypadku jest kompilator, który generuje zbiór bitów, czyli działającą aplikację.

Zasadniczą różnicą, pomiędzy naszą a innymi działkami szeroko pojętej inżynierii, jest to, że w naszym przypadku koszt przekazania kodu kompilatorowi, czyli wygenerowania gotowego produktu, jest zerowy. Tak więc wprowadzanie zmian jest tańsze niż w innych dziedzinach inżynierii. Przykladowo, gdyby koszt powiększenia kuchni w wybudowanym już domu (ale nie kosztem innych pomieszczeń) wynosiłby 1000 dolarów, to nikt by jakoś szczególnie nie projektował domów, a jedynie iteracyjnie je rozbudowywał.

Było jeszcze o kryzysie oprogramowania w 1968 i o dokumencie opisującym czym jest model kaskadowy. Podobno jest on na tyle fascynujący, ze każdy powinien go przeczytać.

Dalej była już znana opowiastka, że nasze obecne komputery (jeśli liczyć razem prędkość procesorów, dysków, pamięci i ich ilości) są ileś tam (10^26 jak dobrze pamiętam) razy szybsze od tych z lat 60tych. A dalej programiści piszą te same instrukcje if, for, while...

Pod koniec wykładu był jeszcze czas na pytania. Co do testowania bazy danych, to Wujek Bob ma ciekawe podejście. On generalnie uważa, że nie powinno się jej testować, albo testować w niewielkim stopniu. Generalnie na bazę danych powinno się patrzyć jak na pewną abstrakcję, gdzie są zachowywane dane. Nie powinno nas interesować jak są one składowane, a jedynie powinniśmy, na potrzeby testów, podmieniać klasy dające nam dostęp do tych danych. I tak dla przykładu: w FitNesse, który jest pisany prze Wujka Boba, bazą danych jest płaski plik.

Analogicznie powinniśmy postępować z testowaniem timeout’ów. Jest to też pewne „wejście” do systemu i powinniśmy podmienić je tak, aby testy szybciej chodziły.

I to by było na tyle jeśli chodzi o konferencję. Na koniec były podziękowania od Grześka Dudy i dla Grześka Dudy - organizatora. Ja również dziękuję, bo konferencja była super zorganizowana. Było ponad 630 uczestników, a jakiś wpadek (którym mógłby zapobiec organizator) nie było. Tablica, na której można było przyklejać karteczki, co idzie dobrze a co źle, bardzo mi się spodobała. No i fajnie były przerwy dobrane, tzn. czasem krótkie (aby zmienić tylko sale), a czasem dłuższe (aby pogadać na korytarzu).

Zostało mi jeszcze do opisania, jak wyglądał warsztat z Wujkiem Bobem w którym brałem udział. Ale to w kolejnym wpie.

Na stronie konferencji znajdziecie jeszcze relacje innych osób z 33 Degree 2012.

33 degree 2012 dzień 2

Dzień 1
Dzień 3
Warsztat z Wujkiem Bobem

Pierwszą prezentacją drugiego dnia 33 degree 2012 na którą się wybrałem, było wystąpienie Joonas'a Lehtinen'a na temat Vaadin’a. Jest to framework do tworzenia Interfejsu użytkownika dla „bogatych” aplikacji. Rozpowszechniany jest on na zasadach Apache License. Vaadin bazuje na GWT, jednak nie ma w nim RPC, serwisów dla UI, a kod renderowania widoku znajduje się po stronie serwera. Po stronie serwera przechowywany jest również stan interfejsu użytkownika, co powoduje brak trybu offline.

Po krótkim wprowadzeniu teoretycznym przyszedł czas na kodowanie na żywo. Do stworzenia projektu wymagany jest jedynie web.xml i jeden JAR. Prelegent pokazywał jak stworzyć prostą przeglądarkę / edytor stron HTML. Podobało mi się rozwiązanie Lazy Loadingu, np. gdy w rozwijanej liście, przewijając suwakiem w dół, ściągały się na życzenie potrzebne elementy. Na pewno generuje to sporo requestów do serwera, ale funkcjonalność ta mi się spodobała.

Kolejna rzecz która mi przypadła do gustu to spor ilość kontrolek, które mogą być od razu powiązane z różnymi źródłami danych. Gdy modyfikujemy jednocześnie te same źródła danych w jednym komponencie, to zmiany te są od razu widoczne w innych / różnych komponentach, które mają podpięte to samo źródło zasilania danych.

Co do dalszych zalet Vaadina, to jest fajny edytor Drag&Drop do Eclipsa / IDEI. Framework działa również na urządzeniach mobilnych i mamy od razu zdefiniowane kilka tematów kolorystycznych do wszystkich komponentów. Można pisać własne nowe komponenty (trzeba trochę grzebać w GWT) i mamy stronę skupiająca te komponenty. Można je ściągać i bezproblemowo integrować z edytorem.

Aplikacje Vaadinowe można podobno pisać w dowolnym języku działającym na JVM. Wspiera on IE6, nie trzeba instalować żadnych dodatków do przeglądarki, a samą aplikację można umieścić na dowolnym serwerze wspierającym Servlety. Na stronie framework’a jest dostępna darmowa książka do nauki, jak i tabela porównująca konkurencyjne rozwiązania. Prowadzący polecał przy okazji REFcardz DZone do nauki nowych technologii.

Co do prezentacji to była ona bardzo fajnie prowadzona, były przykłady, kodowanie, animacje pomiędzy slajdami, ale nie za dużo – dobrane z odpowiednim wyczuciem. Po prostu dobrze przygotowana prezentacja.

Następnie poszedłem na wykład Vogel’a na temat nowych funkcjonalności w Androidzie 4.0. Słychać było mocno niemiecki akcent prelegenta. Na prezentacji było trochę przykładów i kodu. Ogółem dobra prezentacja.

W nowym Androidzie dodano m.in. nową kompozycję kolorów, GridLayout, możliwość zmieniani rozmiarów widget’ów, obsługę Drag&Drop. Doszło jeszcze TextureView, Calendar API, ViewPager (do przesuwania (slidowania) ekranów), Fragments (dzięki czemu ułożenie telefonu zmienia layout) i Properties for Animation API. Jeszcze by się trochę poznajdywało, więcej na prezentacji Vogel'a.

Ciekawym rozwiązaniem jest biblioteka napisana na starsze wersje Androida, emulująca nowe gadżety. Ciekawie jak z jej używaniem.

Następnie wybrałem się ponownie na wykład Venkat’a. Tłumy szalały, miejsca pod ścianami i w drzwiach były obsadzone. Ty razem najlepszy prelegent konferencji opowiadał o programowaniu wielowątkowym. Było sporo kodowania na żywo i w dodatku jemu to wychodziło! Świadczy to o wysokim profesjonalizmie Venkat’a.

Zapamiętałem bardzo fajny trik, który może oszczędzić nam na prezentacji ewentualnych wpadek podczas kodowania na żywo. Mianowicie można tuż przez prezentacją naklepać dokładnie to do czego mamy dojść, a następnie stopniowo usuwać napisane linijki w odwrotnej kolejności, w jakiej chcemy je przedstawić. A na samej prezentacji wystarczy już wciskać kombinację Ctrl + Z i kod będzie się przyrostowo pojawiał przed oczami.

Prezentację zaczęliśmy od standardowego książkowego przykładu z klasą Account, na której można wykonać operacje deposit() i withdraw(), czyli przelać kasę z jednego konta [bankowego] na drugie. Czyli mamy prostą logikę: jeżeli na koncie jest wystarczająco kasy, to ją pobieramy i deponujemy kwotę na innym koncie. Wiadomo nikt nie chce aby znikły mu pieniądze z konta, więc trzeba dobrze to oprogramować. No i zaczęło się.

Prelegent implementował na żywo sugestie proponowane przez publiczność. Jak po chwili dotarliśmy do synchronizacji dwóch obiektów, to się okazywało, że przez to może powstać dead lock. Później rozwiązanie zaczęło ewoluować do monitora, aby ostatecznie prelegent ujawnił preferowane eleganckie rozwiązanie. Mianowicie można dodać do naszego projektu bibliotekę z Clojure’a i już możemy się cieszyć ładnymi transakcjami. Jeśli będziemy chcieli wykonać jakąś „wrażliwą” operację poza transakcją, to biblioteka rzuci nam odpowiednim wyjątkiem i trzeba będzie poprawić kod.

Rozwiązanie bardzo eleganckie i trzeba koniecznie przyjrzeć mu się z bliska. Prelegent twierdził jeszcze, że Clojure jest jedynym bezpiecznym językiem programowania dla JVM’a. Mi ta prezentacja uświadomiła, że obecnie w czasach serwerów aplikacyjnych i super framework’ów mało kiedy piszemy coś na wątkach. A wiedza ucieka. Ja z tego powodu zajrzałem do książki Core Java 2 Techniki zaawansowane (Rozdział Wielowątkowość -> Synchronizacja), aby przypomnieć sobie jak to się powinno robić w czystej Javie.

Następnie, po przerwie obiadowej udałem się na prezentację Sławomira Sobótki na temat technik w inżynierii oprogramowania. Początkowo zaczęło się od charakterystycznych terminów, które można poczytać na blogu prelegenta: 8tysiecznik, osobliwość, boska klasa, ofiary muszą być. Ale na szczęście nie było o tym :)

Sławek przedstawił kilka technik, których stosowanie ma sens w większych projektach. Część z nich w jakiś tam sposób łączy się z DDD (o którym Sławek prowadził później warsztaty), ale można je również stosować po za światem DDD. I tak baza danych nie jest modelem. Model to coś co można pokazać (np. model samochodu, domu), a nie właściwości zapisywane na temat danego modelu. Baza danych może być jedynie strukturą danych, która służy do modelowania.

Kolejną pomocną techniką, o której często zapominamy, to zastosowanie Value Object’ów. Czyli tworzymy sobie abstrakcję, przykładowo klasę Money, aby nie przekazywać wszędzie double (wiadomo dlaczego, było to na 3ch prelekcjach wałkowane). Value Object pełni w tym momencie rolę Adaptera pomiędzy typem technicznym, a domenowym.

Kolejną techniką jest stosowanie Agregatów, aby opakowywać anemiczne encje. Można dodatkowo tworzyć transformacje tego samego obiektu domenowego, zależnie w jakim kontekście jest on używany. Przykładowo pracownik magazynu i pani księgowa inaczej patrzą na ten sam byt, jakim jest faktura. Interesują ich inne dane z tej faktury, jak i mogą wykonywać odmienne operacje na niej.

Następnie było o zasadzie OCP w praktyce. Czyli powinniśmy tworzyć polityki w odpowiednich miejscach, w których mogą później przyjść zmiany. Dzięki temu nasz kod będzie łatwiej rozszerzalny, jak kiedyś przyjdzie konieczność innego sposobu wyliczania podatku, rabatu, czy wypłaty. Dobry kod powinien dać nam w tedy możliwość napisania nowej klasy, implementującej zdefiniowany interfejs, w celu spełnienia wymagania. Zyskujemy również dzięki temu na testowaniu i czytelności kodu (zamiast dopisywać kolejne if’y).

Było jeszcze m.in. zalecenie, aby umieszczać cały zły coupling w fabrykach – smutnych miejscach systemu, czyli w „czarnych dziurach”. Było jeszcze o zastosowaniu wzorców Wizytator i Kompozyt.

Podsumowując wystąpienie Sławka, stosując się do zaproponowanych prze niego technik można uzyskać logikę aplikacji z dużą liczbą zależności, ale za to z prostymi metodami. Więcej można poczytać na blogu Sławka.

Następnie chciałem iść na prezentację Jarosława Pałki, aby posłuchać o architekturze. Niestety wykład został odwołany a w jego miejsce wskoczyło cos innego. Ciężko również było się dostać inne wykłady (z powodu tłoku), więc sobie zrobiłem przerwę.

Następnie znów poszedłem na prezentację Venkat’a, tym razem na temat Scali. Prelegent pokazywał jak w Scali łatwiejsze jest używanie XML’a (nie trzeba jak w Javie całości zamykać cudzysłowami). Język ten jest zorientowany na używanie finalnych obiektów. Można kodować w stylu imperatywnym jak i funkcjonalnym. Można bez przeszkód mieszać te style.

Dalej było o różnicach pomiędzy var a val i że jest to lepsze niż final w Javie. Również nie trzeba na każdym miejscu pisać co jakim typem jest, jedynie tam gdzie jest to niezbędne. Słowo return jest opcjonalne, podobnie jak i średnik. Scala daje nam za darmo konstruktor gettery i settery. Mnie ucieszył fakt, ze nie ma metod statycznych (na pewno poprawia to testowalność kodu). Mamy za to coś takiego jak  wbudowany wzorzec Singeleton w język (object). Również w Scali mamy strategię (za pomocą słwa kluczowego trait).

Na koniec dnia poszedłem jeszcze na sesję BoF m.in. Jakuba Nabrdalika na temat porażek. Cieszę się, że prelegenci nie bali się mówić o swoich niepowodzeniach. Przykładowo u nich w projekcie okazało się, że samoorganizujące się teamy nie działały najlepiej. Potrzebna była osoba decyzyjna, bo demokracja nie zawsze jest najlepsza. Było jeszcze trochę o innych porażkach. Dobrze czasem posłuchać, że nie tylko nam się coś nie udaje.

33 degree 2012 dzień 1

Dzień 2
Dzień 3
Warsztat z Wujkiem Bobem

Konferencja 33 Degree 2012 zaczęła się od szybkiego 10minutowego przywitania o godzinie 9:10 przez organizatora Grześka Dudę. Potem było chwilę o platynowym sponsorze Luxoftcie i o 9:25 zaczęła się pierwsza prezentacja Raffi’ego Krikorian’a z Twittera. Opowiadał on o powodach migracji z Ruby on Rails do JVM’a.

Twitter posiada 100 Milionów użytkowników, którzy tworzą 250 Milionów twittów na dzień, co daje prawie 3000 tweetów na sekundę. Serwis ten cechuje ogromna liczba równoległych połączeń, wiele operacji I/O i nie wielka liczba obiektów trwałych. Twitter potrzebował więc wydajnego języka, do obsługi takiego obciążenia.

Początkowo serwis ten był pisany w Rubym. Sam język nie jest zły, pisze się w nim przyjemnie, szybko, jest bardzo ekspresywny. Słabym punktem są w nim garbage collector i wielowątkowość. Nie wiem jak działa zrównoleglanie w Ruby’im, ale według Raffiego nie dawało to rady, nawet na 60 rdzeniach.

Postanowiono wiec zmigrować kluczowe części systemu na wirtualna maszynę Javy. Początkowo wybór padł na Scalę. Jest ona funkcyjna, ekspresyjna, elastyczna, statycznie typowana i z dobrą współbieżnością. No i do tego jest piękna. Po za Scalą Twitter jeszcze używa Clojure’a. Było jeszcze coś wspomniane o bibliotece Finagle powstałej w Twitterze, ale nie pamiętam w jakim kontekście.

Ogółem prelegent fajnie gadał, chwilowo mikrofon nie dawał rady. Mi trochę brakowało więcej konkretów, jakie rozwiązania zostały zastosowane i co się gdzie sprawdziło. Z chęcią również bym zobaczył model bazodanowy. Było jedynie wspomniane, że dzieli się on na 4 części (Timeline storage, twitts, social graph i user storage).

Następny był wykład Ken’a Sipe pod tytułem Complexity of Complexity. Zdania na temat tego wykładu są podzielone, jednym się podobał, ale mi nie do końca. Generalnie głównym przesłaniem wykładu było to, że nie ma jednego rozwiązania dobrego do wszystkiego i należy poszukiwać najlepszej drogi.

Jak dla mnie to Ken za bardzo skakał po różnych tematach. Było o modelu dreyfus’a, CAP Theorem i jeszcze paru sprawach. Prelegent wspominał, że SOAP nie zawsze jest dobrym rozwiązaniem, gdy w danej infrastrukturze występują spore zależności pomiędzy komunikującymi się systemami. SOAP ładnie to na schemacie przedstawia, ludziom biznesu się to podoba, ale de facto te zależności dalej pozostają.

Był przykład z liczeniem: 2.0 – 1.1 (o tym więcej za chwilę), o adnotacji @Immutable z Groovi’ego i książce: Hackers & Painters. Oraz że eBay nie stosuje rozproszonych transakcji.

Podsumowując, to najważniejszy jest dobry zespół, język (z odpowiednim poziomem abstrakcji) i design aplikacji. Co do stosowanych języków, to powinny one być wygodne, łatwe, znane i proste do nauczenia przez świeże osoby w projekcie.

Następne było wystąpienie Venkat’a Subramaniam’a. Już jakiś czas temu byłem nakręcony na jego wystąpienia, gdyż były mocno wychwalane przez innych polskich blogerów (niestety nie pamiętam gdzie to czytałem). I rzeczywiście sposób prowadzenia prezentacji jest pierwszorzędny, istny majstersztyk. Prelegent zaprosił jedną osobę na scenę i czasem prowadził z nią dialog. Pytał, jak się czuje jako programista, czy odczuwa przyjemność z tego co robi.

Venkat mówił o „Pointy haired bosses” i pragmatycznych programistach. Czyli o zderzeniu dwóch światów: bezmyślnych szefów i programistów. Zastanawiałem się o co chodzi z tym pierwszym terminem, ale wystarczy spojrzeć na pewną postać z komiksów Dilberta: Pointy-haired Boss i już jest wszystko jasne.

Venkat opowiadał dalej o pewnych uniwersalnych prawdach. Porównywał managerów, do rekinów, z którymi musimy walczyć (niczym Janek Lisewski ostatnimi czasy). Ponadto najważniejsi w projekcie są... ludzie. Nie metodyki, technologie, a ludzie. Projekt nie wygrywa ze względu na proces a na ludzi. Aby wygrać ludzie muszą mieć pasję, kompetencję i odpowiedzialność.

Dwoma słowami jakich nienawidzi Venkat to „Best Practice”, jeżeli są one wypowiadane bez kontekstu. Jeśli jest inaczej to trzeba uciekać.

Następnie prelegent prezentował zabawne filmiki, o tym jak ludzie mogą wpływać na innych. Tłumaczył wpływ praktyk (przykład z szerokością silników rakietowych) i że zawsze powinniśmy pytać dlaczego. A do szefa to zamiast mówić, że „mamy problem”, to należy mówić, że „mamy wyzwanie”.

Venkat odwoływał się również do książek: Dreaming in Code i do The Paradox of Choice: Why More Is Less.

Prelegent mówił również, że standaryzacja rozwiązań przed innowacją, to zła droga. Najpierw należy coś wynaleźć, znaleźć kilka następnych, możliwych, ponownych zastosowań, dopiero ustandaryzować i na koniec sprzedawać. Niestety sporo rzeczy w świecie Javy nie idzie tym torem, gdyż często do danej specyfikacji (która powstawała latami), dopiero jest dopisywana implementacja. Jako przykład framework’ów, które szły tą lepszą ścieżką Venkant podał Rails’y i Spring’a.

Następnie zostały wytłumaczone różnice w językach programowania na podstawie wykresu podobnego jak poniżej.

Źródło: http://blogs.agilefaqs.com/2011/07/11/dynamic-typing-is-not-weak-typing/

Następnie było trochę praktyki, czyli ponownie lekcja liczenia. Proponuję każdemu odpalić i sprawdzić co się stanie (jeśli jeszcze ktoś nie wie).

System.out.println(2.0 - 1.1);
System.out.println(new BigDecimal(2.0).subtract(new BigDecimal(1.1)));
System.out.println(new BigDecimal("2.0").subtract(new BigDecimal("1.1")));

Przykładowo w Groovy’m mamy to za darmo.

W kolejnym przykładzie Venkant przedstawił bardziej interesujący kod:

ArrayList<Integer> numbers = new ArrayList<Integer>();
numbers.add(1);
numbers.add(2);
numbers.add(3);
numbers.remove(0);
System.out.println(numbers.size());

Podczas prezentacji dałem się nabrać i dziwiłem się z wyświetlanego wyniku. Dopiero pisząc tego posta zrozumiałem co się dzieje.

To  że Java jako język jest silnie typowany i ze statyczną kontrolą typów sprawia, że musimy się dostosowywać do kompilatora, np. poprzez deklarowanie w sygnaturze metody Checked Exceptions. Podsumowaniem całego wykładu była sentencja: „A Professional who doesn't learn to fail, fails to learn”. Let’s be a champions.

Po wykładzie był obiad, bardzo smaczny. Nieporównywalny z innymi konferencjami w których brałem udział.

Następna prezentacja na którą się udałem była o Dart’cie a przedstawiał ją pracownik Google’a, a dokładniej z Chrome’a: Mike West. Dart to nowopowstający opensource’owy język do budowania web aplikacji, kompilowany do JavaScript’u. Jest to dopiero technology preview, więc nie ma jeszcze nawet wersji alfa tego wynalazku.

Najciekawszy jest sposób powstawania języka. Mianowicie tęgie głowy wymyślają, co by tutaj dodać do języka, a społeczność dyskutuje na grupie o danej funkcjonalności i od tego zależy, czy pojawi się w języku czy nie.

Przeznaczeniem języka mają być małe i średnie aplikacje, niezależne od platformy, szeroko dystrybuowane i bez instalacji. Dart bazuje na HTML’u 5 i modelu DOM, ma być wsparcie dla testów jednostkowych. Przy języku pracuje sporo ludzi od GWT i język ma być bardziej popularny od CoffeeScript’a.

Na prezentacji było trochę kodu, ale ja osobiście jakoś się nie przekonałem i coś nie czuję aby to wypaliło. Jednakże model powstawania języka jest bardzo ciekawy. Co do samej prezentacji, to troszkę dziwna akustyka była w sali a i prelegent jakoś mało ciekawie przedstawiał temat.

Następna prezentacja była bardzo ciekawa. Andrey Breslav pracownik JetBrains’a przedstawił język Kotlin  (nazwa dokładnie taka jak polskie miasto i firma produkująca keczup). Prelegent obecnie pracuje przy tym wynalazku. Jakiś czas temu widziałem informacje o tym języku, ale się nie przyglądałem bliżej.

Język jest statycznie typowany, ogólnego przeznaczenia, open source’owy i do zastosowań przemysłowych. Kompilowany jest on do bytekodu JVM’a lub do JavaScriptu, tyle że wówczas nie można używać wszystkich bibliotek.

Ciekawa jest motywacja firmy do tworzenia kolejnego języka. JetBrains tworzy aktualnie środowiska programistyczne (IDE) dla 7 języków. Wiodącym jest to dla Javy, ale Java rozwija się bardzo powoli w stosunku do IDEI. Jako że inne języki wspierają produkty tej firmy, to postanowiono wesprzeć samego siebie. I tak oto powstaje język eliminujący niedoskonałości Javy, mający od razu wsparcie IDE do tworzenia kodu. Ponadto można bezproblemowo mieszać kod Kotlina i Javy w projekcie i nawet debugować w jednym IDE. To sprawia, że integracja i ewentualna migracja może być bezbolesna. I jest również dostępne wsparcie dla podpowiadania składni, refaktoringu itd.

Kotlin nie jest research’owym projektem, ani nie jest pod specyficzną domenę, czy może raczej pod specyficzne zastosowanie. Zanim kolejna wersja języka wyjdzie, to jest ona używana na produkcji w JetBrains. Są już nawet jakieś zewnętrzne firmy, które wykorzystują ten język.

Co do samego języka: Nie ma słowa kluczowego new, argumenty przekazywane do konstruktora są od razu zapisywane jako pola klasy, są extension functions, przeciążanie operatorów matematycznych i nie tylko, wyjątki tylko unchecked, operacje bezpieczne na występowanie null’a, inne rzutowanie pozwalające pozbyć się javowego rzutowania i switch’a, Trait’y czyli interfejsy z domyślną implementacją, a adnotacjom można nadać coś jakby alias i później używać w kodzie, co eliminuje znak ‘@’. Mają być również zaimplementowane Run-time generics.

Z ciekawostek, to kod jest kompilowany do modułów, a nie do pojedynczych plików jak w Javie, przez co można lepszą optymalizację kodu wykonać. Kto chce to może się dołączyć do Community i trochę porozwijać język.

Prezentacja była bardzo ciekawie prowadzona. Były filmiki pokazujące jak kodować (opatrzone w razie potrzeby odpowiednim komentarzem prowadzącego). I jak całość działa. Był po raz drugi przykład a odejmowaniem (2.0 – 1.1) z którym Kotlin radzi sobie podobnie jak Groovy (czyli lepiej niż Java). Prezentacja bardzo mi się podobała i uważam, że język może być ciekawą alternatywą w niedalekiej przyszłości dla Javy. Nie wiem dokładniej jak się to ma do innych obecnie coraz popularniejszych języków jak Scala, Groovy, Ruby, ale przyjrzę się jemu bliżej niedługo. Na stronie JetBrains’a można sobie przeczytać porównanie do Javy lub Scali. Widać, że język sporo czerpie inspiracji ze Scali i Grooviego. Można się jeszcze „na żywo” pobawić językiem nie instalując żadnych aplikacji wchodząc na stronę kotlin-demo.

Następnie wybrałem się na prezentację o testach którą prowadził Wojciech Seliga. Opowiadał on o swoich 10 latach testowania przy tworzeniu oprogramowania JIRA. W początkowej części prezentacji było sporo danych statystycznych, wykresów itp. I tak projekt ma: około 500 zależności, 1.5 miliona LOC, 13 tysięcy testów jednostkowych, 1000 testów z Selenium, 4000 funkcjonalnych i integracyjnych, pokrycie kodu testami na poziomie 60-80% do ~92% dla krytycznych funkcjonalności…

Wszystko to jest kompilowane i odpalane na ponad 70 maszynach w chmurze Amazona. Jednak i tak trwa to bardzo długo, a poprawa testów jeszcze dłużej, przez co zaczął się pojawiać u nich w projekcie syndrom wybitego okna. Po pewnym czasie, aby developerom wróciło zaufanie do testów, zaczęto komentować (a z czasem usuwać gdy nie szło naprawić) te testy, które za długo były czerwone – ale nie profesjonalne zachowanie.

Co do ciekawych praktyk, to dowiedziałem się o Page Object Pattern co mocno ułatwia testowanie i jest niezależne od zmian w GUI. A jeżeli już chcemy testować po GUI, to lepiej skorzystać z JQuery Selectors niż z XPatch i/lub używać ID’ków zamiast CSS’a. Dobre jest również podzielenie kodu testowego na moduły, które znajdują się w miarę blisko kodu źródłowego. Pozwala to developerom odpalać testy dotyczące danego modułu, zamiast testów dla całego systemu. Przydatne również może być mockowanie zewnętrznych systemów.

I to by było tyle jeśli chodzi o tą prezentację. Ja spodziewałem się dowiedzieć czegoś więcej, tzn. oczekiwałem przykładów, dobrych rozwiązań, stosowanych wzorców, technik, ciekawych wniosków. Jak na kogoś kto ma dziesięcioletni kontakt z testami, to wypadło bardzo słabo.

Po wykładzie chciałem iść jeszcze na sesję BOF, ale skończyło się na tym, że zacząłem rozmawiać z ludźmi na korytarzu i dołączyłem do imprezy piwnej sponsorowanej przez ZeroTurnaround wydawcę JRebel’a Bardzo mi się spodobała taka forma integracji i możliwości nawiązania kontaktów.

Podsumowanie kolejnych dni w kolejnych wpisach.