Pierwszy Legacy Code Retreat

W sobotę miało miejsce niezwykle wydarzenie, mianowicie drugi Global Day of Code Retereat. Jako że niedawno było organizowane w Wolfsburgu to wydarzenie, postanowiono tym razem zrobić Legacy Code Retreat dla odmiany. Całość odbyła się z inicjatywy tych samych osób i w tym samym miejscu i sponsoringu.

Podczas Legacy Code Retreat pracuje się z już gotowym kodem, który można znaleźć na githubie: Trivia Game. Kod jest przygotowany w kilku językach i jest właściwie nie testowany. Osiągnięto to za pomocą metod zwracających void, wymieszaniu wyświetlania wyników z logiką, niejasne przeznaczenie zmiennych i boską klasę. Zadaniem uczestników jest ogarnięcie tego chaosu programując w parach.

Miałem dobre przeczucie podczas pierwszej sesji, aby początkowo stworzyć test testujący integracyjnie to co jest. Z założenia aktualny stan jest fachowo poprawny, więc nawet jak się widzi coś w kodzie co wydaje się nie prawdą, należy to zaakceptować. Taki całościowy test nazywa się Golden Master. Najlepiej stworzyć ich kilka i nie mogą one nigdy być czerwone, gdy będziemy modyfikować kod.

Jak już mamy kilka testów, możemy zacząć refaktoring. Najlepiej taki, do którego wsparcie daje nam IDE, gdyż wtedy nie powinniśmy nic zniszczyć. I tak powoli można pisać bardziej szczegółowe testy, konkretnych metod.

Podczas Legacy Code Retreat można ćwiczyć m.in. następujące rzeczy:

• tworzenie Golden Master
• pisanie testów dla nietestowanego kodu
• testowanie poprzez partial mocking (nazywane również Subclass To Test)
• refaktoring do kodu obiektów
• refkatoring do kodu czysto funkcyjnego
• refaktoring do ValueObjects

Miałem podczas warsztatów okazję przez dwie sesje pracować z kodem Scalowym. Jednak słabe wsparcie środowiska i mała przerwa w eksplorowaniu tegoż języka, sprawiły, że było bardzo ciężko przemieścić się do przodu. Inna sprawa to standardowe ułomności Eclipse’a, ale to już zasługuje na osobny post. Podczas kilku sesji korzystałem też z IntelliJ IDEA i tam już było trochę lepiej. Więcej nie opisuję, aby nie psuć wam ewentualnej zabawy z Legacy kodem, podczas warsztatów, które sami u siebie zorganizujecie.

Co do jakości i organizacji eventu nie ma się do czego przyczepić. Nie było problemów ze stołami, przedłużaczami, rzutnikami. Były naklejki z imionami, odliczanie czasu podczas każdej sesji, kanapki na śniadanie, kawa, herbata, soki, Club Mate i inne napoje. Obiad również był dobry, ciepły, wystarczył dla wszystkich i jednocześnie nie wiele się zmarnowało. Zabrakło mi jedynie videokonferencji z innymi miastami, jak to było rok temu. A to ja w sumie mogłem podsunąć pomysł organizatorom. Niestety jakoś mi to uciekło.

Osobiście wolę tworzyć nowy kod, niż grzebać w starym, tym bardziej w Legacy. Z tego powodu impreza podobała mi się trochę mniej niż typowy Code Retreat. Z drugiej strony, w naszej profesji umiejętność pracy z nieswoim kodem jest właściwie niezbędna i trzeba ją wykorzystywać od czasu do czasu. Oby taki sytuacji było jak najmniej, więc dbajmy o to, aby nie tworzyć Legacy Kodu.

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

Kolejny Code Retreat

Dzisiaj wziąłem po raz kolejny udział w imprezie spod znaku Code Retreat. Tym razem odbył się on w Wolfsburgu – czyli mieście największego europejskiego koncernu samochodowego. Zorganizowany został on przez znajomych z pracy, a sponsorem była firma T-Systems on site.

Podczas początkowych sesji mogłem podzielić się swoją wiedzą z zakresu programowania w parach, TDD, baby steps, pisania dobrych testów i znajomości IDE. Nie ma się tu co rozpisywać, bo ciekawsze działo się później.

Postanowiłem wykorzystać obecność fanatyków Scali i trochę się poduczyć tegoż języka. Zdobyta wiedza przyda się przy realizacji kursu: Functional Programming Principles in Scala. Kto się jeszcze nie zapisał, ma jeszcze szansę. Więcej o kursie można poczytać na scala.net.pl. Podczas mojej pierwszej scalowej sesji, udało mi się sporo samemu napisać i odświeżyć jakieś stare wiadomości na temat tego języka. Część wymagań nawet działała. Szkoda jednak, że Eclipse dalej kuleje w tym temacie. Mam nadzieję, że z Ideą będzie lepiej.

Podczas mojej drugiej sesji skalowej programowałem razem z jeszcze większym wyjadaczem (fanatykiem) tego języka. Było więc co chłonąć. Podczas tej sesji (w ogólności) ćwiczyliśmy pisanie bez pętli, co w Scali nie jest jakimś utrudnieniem. Udało nam się całą logikę zakodować wraz z testami i bez pętli, w czasie krótszym niż 45 minut i z wyjaśnieniem mi, jak działa ta cała magia! Co chwilę wlepiałem swoje ślepia w ekran, dziwiąc się, co ‘to’ lub ‘tamto’ robi, oraz próbując zrozumieć, czy to aby na pewno pokrywa wszystkie wymagania. Jestem pod bardzo dużym wrażeniem tej sesji. Teraz trzeba na spokojnie (albo pod wpływem ;) ) poznać wykorzystane mechanizmy tegoż języka, aby móc je później efektywnie stosować.

Wyniesione doświadczenie z tej sesji, pozwoliło mi jeszcze podczas ostatniego sparowania, ponownie zakodować wszystkie reguły gry. Czasem lubię się droczyć, z moimi partnerami podczas Code Retreat. Zwłaszcza przy ping pongu staram się tak odbić piłeczkę, aby się później dużo nie narobić, a jedynie obserwować, jak ktoś się męczy. Tym razem coś poszło nie tak, gdyż sam musiałem się napocić. O dziwo udało się po raz drugi dojść do końca, bez większych problemów, że coś nie działa i nie wiadomo dlaczego. Dodatkowo nie można było rozmawiać podczas tej sesji, co stanowiło dodatkowe utrudnienie. Spotkałem się z nim po raz pierwszy i przekonałem się, ile rzeczy można przekazać niewerbalnie.

Podsumowując wypadło super. Był to mój 6ty CodeRetreat (licząc te oficjalne jak i te zamknięte). Obiad był na wypasie, ciepły z dużymi możliwościami wyboru dania i z deserem. Również było sporo owoców (zamiast ciasteczek) i możliwość zjedzenia śniadania (jak ktoś nie zdążył rano). Ważnym punktem (który był strzałem w dziesiątkę) była Club Mate. Pomogła ona zebrać siły na ten jakże wyczerpujący wysiłek intelektualny, jakim jest Code Retreat. Nieźle się naYerbałem, a w ogólnym rozrachunku, to cała skrzynka poszła. Uważam, że napój ten, powinien wejść do formuły Code Retreat ;)

Teraz pozostaje już tylko czekać, na drugi Global Day of Coderetreat, który w tym roku przypada 8 grudnia. Rok temu 94 miasta wzięły w tym udział, a cel na ten rok to 200 miast. Zobaczymy czy się uda i jak spędzę ten dzień.

Konfitura, marmolada, dżem mydło i powidło ‘12

W ostatnią sobotę odbyła się największa (pod względem ilości uczestników ~850) polska, jednodniowa, konferencja javowa, czyli Confitura 2012. Tym razem odbywała się ona w budynkach Uniwersytetu Warszawskiego na Krakowskim Przedmieściu.

Pierwszy wykład był sponsorowany przez Akamai, tytuł miał po angielsku, więc spodziewając się zła koniecznego (czyli typowej reklamy jakiegoś produktu, za którą ktoś sporo zapłacił) odpuściłem sobie ten wykład. Pozwiedzałem wówczas stanowiska sponsorskie, zgarniając co się dało. Miałem również możliwość porozmawiania z pracownikami firmy e-point, którzy ostatnio wypuścili OneWebSQL. Jest to framework, tworzący na podstawie modelu danych, klasy encji, DAOsy i tak dalej. Taki ORM, tylko że dostajemy wygenerowany kod, którego ręcznie nie modyfikujemy, a jedynie wywołujemy to co nam jest potrzebne. Widziałem wcześniej filmik prezentujący to rozwiązanie, na którym wykorzystywano PowerDesigner’a do przygotowania modelu danych. Dowiedziałem się, że wsparcie dla kolejnych narzędzi jest w drodze, w tym generowanie kodu na podstawie istniejącego schematu bazy. Czy odniesie to sukces komercyjny - zobaczymy.

Po godzinie 10 była prezentacja Grześka Dudy na temat produktywności. Okazuje się, że najbardziej produktywni jesteśmy do kilku godzin po przebudzeniu i powinniśmy ten czas jak najlepiej spożytkować. Powinniśmy wtedy kodować, analizować problemy i wszystko to, co wymaga od nas dużego wysiłku intelektualnego. Nie powinniśmy wtedy czytać e-maili, oglądać YT ani grać w gry.

Kolejna sprawą jest podział zadań do wykonania na:
1) ważne i pilne
2) ważne i niepilne
3) nieważne i pilne
4) nieważne i niepilne.
O podziale tym można chyba przeczytać w każdej książce dla menagierów i na temat zarządzania sobą w czasie.

Kolejna sprawa to automatyzacja wszystkiego co się da. I Grzesiek nie miał tutaj na myśli automatycznych testów (bo to jest jasne ze to trzeba robić) ale optymalizację powtarzających się co jakiś czas czynności. Przykładem jest test Selenium, który może coś tam aktualizować w Eclipse.

Powinniśmy również unikać robienia 2ch rzeczy równocześnie, chyba że angażujemy do tego 2 półkule mózgowe. Inaczej nie wpływa to dobrze na wydajność. Część małych rzeczy możemy zrobić, czekając na przystanku na autobus, jak np. zadzwonić do mamy.

Następnie Grzesiek krytykował Pomodoro Technique. Uważa on, że 25 min. to za mało. W tym czasie dopiero się rozkręcamy i nie zdążymy zrobić nic konkretnego. Jedyny sens robienia pomidora, to notowanie co nam przeszkadza i jak często. Przydatne tutaj mogą być również narzędzia do analizy, która aplikacja jak długo jest otwarta, np. RescueTime. Inna ciekawa aplikacja to Pocket (Formerly Read It Later), do zapamiętywania tego, co chcemy przeczytać (aby zminimalizować liczbę otwartych zakładek w przeglądarce). Zacząłem ją od teraz stosować. Przydaje się zwłaszcza, gdy w pracy są niektóre strony poblokowane.

Gdy już przeanalizujemy, co nam przeszkadza w pracy, to najczęściej okazuje się, że są to e-maile. Dobrze jest więc wyłączyć wszelkie powiadomienia o nowych wiadomościach, aby nie wychodzić z flow. Potwierdzam z doświadczenia, że to pomaga. Kolejna powiązana kwestia to moment odpisywania na e-maile. Zasada three.sentenc.es mówi, że jeśli jesteśmy w stanie odpisać w 3ch zdaniach, to można zrobić to zaraz po przeczytaniu wiadomości. Jeśli mamy więcej do napisania, to lepiej pogadać. No i oczywiście pisząc bezwzrokowo jesteśmy w stanie zyskać 30% na produktywności (w dłuższym okresie czasu).

Jeśli chodzi o oprawę organizacują, to całkiem fajnie się oglądało prezentację z góry, tj. z balkonu. Niestety nie wiedziałbym o tej możliwości, gdyby Tomek Dziurko (jeden z organizatorów) mi o tym nie powiedział. Ogółem brakowało mi trochę oznaczeń gdzie co jest. Przykładowo dopiero ze zdjęć się dowiedziałem że gdzieś były stare konsole (a może to i lepiej że nie wiedziałem). Następnym razem proszę o więcej oznaczeń, lub schematyczny rzut z góry z zaznaczonymi ciekawymi miejscami.

Następnie byłem na Kędzierzawych testach z kontraktami Cezarego Bartoszuka. Prelegent prezentował bibliotekę CoFoJa. Pomysł kontraktów nie jest nowy, ale pomimo czasu nie przyjął się. Dla mnie te kontrakty to bardziej ciekawostka, niżeli coś co chciałbym stosować. Przypominają mi one słówko kluczowe assert, gdyż tak jak asserta kontrakty można wyłączyć, a korzystać z nich powinniśmy jedynie w trakcie testów. No i nie mamy wsparcia dla refaktoryzacji, a długość definicji pojedynczego pola w klasie mocno rośnie. Jak dla mnie lepiej wykorzystać TDD i BeanValidation jak już coś musimy walidować.

Jeśli chodzi o kędzierzawość, to prelegent przedstawił jeszcze testy z Yeti Test. I to narzędzie już bardziej mi podeszło. Potrafi ono generować sporo losowych testów jednostkowych dla naszego kodu, z uczuleniem na błędne i skrajne wartości. Yeti dobrze współpracuje z kontraktami, ale można go oczywiście stosować oddzielnie.

Co do wad prezentacji można zaliczyć przepełnienie sali. Wiem że była wcześniej ankieta, na co kto chce iść i na tej podstawie były przydzielane sale, ale to przepełnienie świadczy o trochę za dużej liczbie uczestników całej konferencji.

Następnie udałem się na zwinne szacowanie Piotra Burdyło. Było o szacowaniu całości projektu, a nie pojedynczych zadań. Prelegent opowiadał o prawie Parkinsona i syndromie studenta.

Co do szacowania Piotrek zdefiniował kilka zasad, których się trzyma:

• Szacuj po ludzku
• Mierz rzeczy które są mierzalne
• Różne szacunki wymagają różnych metryk
• Bliska przyszłość - dużo szczegółów, daleka przyszłość - mało szczegółów

Prelegent czerpie też sporo z Agile Manifesto i twierdzi że weryfikacja jakości oszacowania jest bez sensu. Wynika to z częstego wypełniania zestawienia czasu pracy pod koniec miesiąca, a także z niedokładności tego wypełnienia. Bo co np. zrobić, gdy kolega z zespołu przyjdzie do nas po pomoc? Zatrzymać aktualny stoper i włączyć inny? No i gdzie de facto upychać wszelkie przeszkadzajki (e-maile, wypełnianie czasu pracy, inne korporacyjne pierdoły, piłkarzyki...)? Nie chce nam się tego aż tak dokładnie notować, gdyż nie jest to warte swego zachodu.

Na koniec była jeszcze ciekawa metoda szacowania całego projektu. Mianowicie piszemy na karteczkach nasze historyjki i je kolejno przyklejamy na tablicy. Kolejną karteczkę umieszczamy w miejscu, które będzie wskazywało, na ile nowa historyjka jest trudniejsza od poprzednich. Na koniec dzielimy tablicę na kilka części i przyporządkujemy historyjkom odpowiednie punkty. Te które są na granicy ponownie analizujemy czy raczej są większe czy mniejsze. Na koniec jeszcze sporo pytań, aż prelegent nie dotarł do końca prezentacji.

Następnie ponownie udałem się na prezentację miękką, tym razem odnośnie Retrospekcji autorstwa Michała Bartyzela. W sali tej był mały problem ze światłem, mianowicie było go za dużo, a przez to slajdy niewidoczne. Na szczęście prelegent więcej gadał niż pokazywał. Widać że Michał ma bardzo dobrze opanowaną sztukę publicznych wystąpień, swobodnie stoi na scenie i bardzo szybko dostosowuje się do aktualnych wydarzeń na sali. Przykładowo raz zaczął się witać ze spóźnialskimi, a gdy mówił o nowych postanowieniach, to jako przykład podał, aby się więcej nie spóźniać na prezentacje (oczywiście ktoś akurat wchodził na salę).

Prelegent zachęcał do robienia małych, osobistych retrospekcji codziennie. Ma to na celu wytworzenia w nas wyrzutów sumienia, które później powinny nas zmotywować do poprawy naszych małych grzeszków. No i odpowiedni powinniśmy definiować swoją pokutę, czyli nie "poprawię swoje szacowania", a "będę szacował za pomocą przedziałów".

Było jeszcze o tym czym jak nie powinny wyglądać retrospekcje. Nie jest to terapia grupowa, gdzie wylewamy swoje żale i idziemy zadowoleni do domu. Po retrospekcji powinny pójść konkretne ustalenia i zmiany.

Na koniec było jeszcze o pytaniach C5:
1. Co zacząć robić?
2. Co przestać robić?
3. Czego robić więcej?
4. Czego robić mniej?
5. Co robić inaczej?

Kolejny wykład na który się udałem był o tym jak uwolnić się od "if" Tomka Nurkiewicza. Są dwa powody dla którego powinniśmy się ich pozbywać. Poprzez duże zagęszczenie instrukcji warunkowych tracimy na czytelności i na szybkości (na poziomie CPU, ale to temat na osobny wpis).

Było sporo przykładów z kodem i refaktoringu na żywo. Bardzo często sprawdzamy za pomocą if'ow, czy pewne wartości nie są null'em. Zamiast tego lepiej stosować Null Object. Dodatkowo chcąc pozbyć się obsługi opcjonalnych argumentów warto stworzyć metody z mniejszą liczbą argumentów, które później wywołują docelową metodę, przekazując właśnie Null Object.

Fajnym ułatwieniem, jakie pokazał Tomek, było Simplify. Przykładowo poniższy kod:

Zostanie przekształcony do:

System.out.println("bbb");

Ważne by kursor przed naciśnięciem Alt + Enter, w jedynym słusznym środowisku, znajdował się na if'ie.

Kolejnym przykładem był refkatoring kodu wywołujący pewne zadanie (Task) w wątku i bloku synchronizowanym lub nie. Prelegent ładnie przerefaktorował kod pełen if'ów na synchronizowany dekorator Taska, kod Taska i klasę tworzącą odpowiednie wątki. czyli dostaliśmy ładne rozdzielenie odpowiedzialności.

Później było o tym gdzie używać if'ów. Było na temat tego pytania: Get rid of ugly if statements i sensowności różnych implementacji. Polecam przejrzeć wątek, zwłaszcza odnośnie wielomianu 45 stopnia.

Kolejnym przykładem było porównywanie dat i jeśli daty się nie zmieniają w wymaganych, to czasem dla czytelności lepiej je zahardkodować. Jeśli musimy te daty wczytać skądś, to lepiej skorzystać z Chain of responsibility.

Na koniec było jeszcze trochę na temat wizytatora (odwiedzającego). Wzorzec ten pomaga nam się pozbyć instanceof i rzutowania w dół. Gdy przyjdzie nam dodać nowy typ to jednak trzeba wszystkie dotychczasowe klasy o jedną metodę rozszerzyć.

Co do samej organizacji, to lampa w środkowym rzutniku była mocno wypalona, przez co obraz był nieostry. Na szczęście były jeszcze dwa po bokach i po ściemnieniu światła można było wygodnie się gapić, na to prelegent robił.

Co do samej prezentacji, to bardzo mi się podobała - dużo wiedzy, szybkie tępo, brak nudy, praktyczna wiedza.

Następnie było wystąpienie Pawła Cesara Sanjuana Szklarza na temat złożonych architektur bez podziału na warstwy. Prelegent przedstawiał swoje rozwiązanie dotyczące wstrzykiwania zdalnych wywołań w ramach innych maszyn wirtualnych Javy. Ma to na celu unikniecie kudu, który tylko deleguje zdania dalej. Nie będę się tutaj więcej rozpisywał, kod do przejrzenia jest tutaj: github.com/paweld2/Service-Architecture-Model.

Na koniec był jeszcze wykład "How to be awesome at a Java developer job interview" Wojciecha Seligi Opowiadał on, jakie cechy powinien mieć kandydat na stanowisko w jego firmie (lub ogółem w firmie która chce mieć tylko najlepszych w swoim fachu). Wykład sponsorowany, ale wzbudził wiele kontrowersji.

Pierwsza sprawa to języki (ale nie programowania). Powinniśmy znać język klienta, dla którego będziemy pracować, język firmy w której będziemy pracować i oczywiście angielski.

Później prelegent przedstawiał dwa typy kandydatów, których nie lubi. Pierwszy z nich to certyfikowani analfabeci, którzy mają górę certyfikatów, ale niewielką wiedzę. Brakuje im znajomości pakietu java.util.concurrent, Garbage Collectora, zarządzania zasobami w JVM, programowania sieciowego, wielowątkowego i stosu IP.

Swoją opinię na ten temat przedstawił już Koziołek we wpisie Rozbrajamy minę.... Ja od siebie dorzucę, że rzeczywiście wg. mnie nie każdy musi znać java.util.concurrent. Znajomość wątków i podstawowych metod synchronizacji jest jednak konieczna, a nieznajomość nowego kodowania wielowątkowego zazwyczaj wynika z używania starej wersji Javy w projekcie, jak i przerzucenia sporej odpowiedzialności na serwer aplikacji, w przypadku typowego programowania webowego. I w typowych obecnych projektach rzadko się wątki wykorzystuje. A w pracy są przecież potrzebni przedewszystkim typowi rzemieślnicy, którzy wyrzeźbią wymagania funkcjonalne klienta, które bardzo często kończą się na wczytaj, pokarz, zmodyfikuj, sprawdź, zapisz…

Analogicznie ma się sprawa do znajomości GC i zarządzania zasobami. Jak już w projekcie się zdarzy, że coś tam trzeba pogrzebać, to robi to część zespołu i nie każdy ma okazję wtedy poeksperymentować. Nawet jak już się będzie tym szczęśliwcem, to po kilku miesiącach już się nic nie pamięta. Co do stosu IP to pamiętam, że model OSI ma 7 warstw a TCP/IP 4, które jakoś tam odpowiadają jedne drugim. Ale na rozmowie kwalifikacyjnej na stanowisko kodera javy nie przypomniałbym sobie za nic nazw tych warstw i nawet nie przyszło by mi do głowy, aby sobie o tym przypominać.

Z drugiej strony powinniśmy równać w górę a nie w dół, więc trzeba będzie kiedyś wrócić do tych tematów i je ogarnąć.

Kolejny typ kandydata do pracy, którego Wojciech nie lubi to Astronauci którzy mają o sobie nie wiadomo jakie mniemanie.

Dalej było o umiejętnościach typowo technicznych, jakie powinien posiadać dobry kandydat. Nie będę ich tutaj wymieniał a jedynie odeślę do prezentacji. Jak kolejnym razem przyjdzie mi się zmierzyć z jakimś rekruterem, to na pewno przypomnę sobie tą prezentację przed rozmową. Warto też przeczytać komentarz autora pod prezentacją, czyli odpowiedź na stawiane zarzuty. Rzeczywiście prezentacja wywołała sporo emocji - bardzo mnie to cieszy, cel prelegenta osiągnięty - brawo!

Prelegent polecał jeszcze książkę Java Concurency in practice. A z dalszą częścią prezentacji już ciężko się nie zgodzić. Feedback po rozmowie powinien być telefoniczny (choć e-mailowy też mi się podoba), na rozmowie powinno być prawdziwe kodowanie, a rekrutacje powinni przeprowadzać najlepsze osoby z firmy, choćby się paliło i waliło w projekcie. Ponadto najlepsi chcą pracować tylko z innymi najlepszymi, lub jeszcze lepszymi.

Było jeszcze o trudnych pytaniach od kandydatów, czyli o ścieżkę rozwoju, możliwości awansu i gwarancję stabilności. Pytania te nauczyły nas stawiać korporacje, które na dzień dobry mydlą oczy takim lukrem (ścieżki kariery, awansu, rozwoju, szkolenia, wyjazdy i inne benefity).

Co do różnicy zdań jeszcze, to Wojtek szuka profesjonalistów, ale sam nie jest bez skazy. Już podczas pisania relacji z tegorocznej konferencji 33 degree, zwracałem uwagę na usuwanie testów, jeśli są przez dłuższy czas czerwone. Raczej nie po to ktoś się wysila aby napisać test, aby go potem usunąć, gdy nie działa. A druga sprawa (o której wtedy zapomniałem napisać) to niby 10 lat doświadczenia w tworzeniu testow, a na prezentacji (tej z 33 degree) był kod testu, gdzie na zmianę były wywoływane testowane metody, assercje, metody, assercje itd. I nazywane było to testem jednostkowym...

Na sam koniec było trochę reklamy, ale skoro to wykład sponsorowany to nich będzie. Mimo że się w kilku punktach nie zgadam z prezenterem, to prezentację uważam za bardzo udaną i wartościową, gdyż bylem ciekaw spojrzenia z punktu widzenia osoby rekrutującej.

Po ostatnim wykładzie było losowanie nagród, podziękowania itd.

Wieczorem jeszcze udałem się na imprezę integracyjną. Była wynajęta kręgielnia wraz ze sponsorowanymi grami piwem i pizzą. Czyli nikt nam nie przeszkadzał i można było się spokojnie zrelaksować.

Wielkie brawa dla organizatorów, wolontariuszy i innych zaangażowanych w konferencję. Dobra robota. Co do minusów to już Koziołek pisał o braku foyer, przez co z powodu natłoku ludzi ciężko było się przemieszczać w trakcie dziesięciominutowych przerw. Ale i tak fajnie że mój postulat z poprzedniego roku na temat wydłużenia przerw został spełniony, więc więcej nie narzekam. Brakowało mi jeszcze oznakowań (albo ich nie widziałem) / planu sal, klimy. Lekkie przepełnienie uczestników utrudniało przemieszczanie się pomiędzy wykładami, a w powidle było za dużo światła (brak zasłoniętych żaluzji). Widać było, że organizatorzy się bardzo starali, ciągle biegali i mieli kupę roboty. Jeszcze trochę i nie będzie czego poprawiać.

Podobne wypisy można znaleźć na stronie konferencji.

Code Retreat w Berlinie

W Niedzielę 3ciego czerwca wziąłem udział w warsztatach Code Retreat w Berlinie. Był to mój nie pierwszy udział w tego typu „imprezie”, ale pierwszy raz było to za granicą i w otwartej formie jednoczenie (wcześniej zorganizowaliśmy sobie CR w pracy). Co mnie bardzo zaskoczyło to wielka różnorodność kulturowa. Spodziewałem się, że event będzie prowadzony w języku niemieckim, ale jak się okazało w Berlinie mieszka sporo ludzi, którzy nie mówią w tym języku. Z drugiej strony, jak się okazało, łatwiej jest mówić o typowo technicznych sprawach w języku angielskim.

Pierwszą sesję kodowałem z Carlosem z Portugali. Przykładowo on mimo prawie rocznego już tutaj pobytu nie używał Niemieckiego, a w pracy oficjalnym językiem jest angielski, ze względu na sporą różnorodność kulturowa. Kodowaliśmy w Rubym, tzn. miałem okazję zobaczyć jak to można robić i poznać podstawy podstaw, ale ogółem nic konkretnego. Generalnie w Portugalii jest podobna sytuacja jak w Polsce, tzn. projekty są, praca jest, ale lepiej być gdzieś indziej.

Druga sesję miałem okazję po kodować z Grzegorzem Dziemidowiczem. W końcu była możliwość się poznania i sprawdzenia się przy klawiaturze. Była to moja najbardziej produktywna sesja podczas tego dnia jak i chyba podczas wszystkich Code Retreat’ów w jakich brałem udział. Obaj dobrze się poruszaliśmy po IntelliJ IDEA, była super komunikacja, zbliżone pomysły na design (czyli nie wiele konfliktów) i szybka ewolucja designu (ekstrakcja osobnych klas dla żywych i umarłych komórek, przeniesienie do nowych klas odpowiednich implementacji).

Udało mi się sprzedać fajnego hotkey’a do Idei. Mianowicie zamiast pisać assercję, można napisać warunek, jaki chcemy sprawdzić (tak jak by to był zwykły if), zaznaczyć tekst, wcisnąć Alt + Enter i wybrać opcję „Create JUnit Assertion”, aby zamienić porównanie w wywołanie odpowiedniej metody. Screen poniżej.

Podczas kolejnej sesji (tym razem z Łukaszem Balamutem) jak drugi raz pokazywałem ten skrót, to odkryliśmy, że nie zawsze on działa. Teraz jak to sprawdzałem, to doszedłem do tego, że jak zaznaczymy tekst od lewej do prawej, to popup pokazuje się bez tej (i innych opcji). Na szczęście ktoś już zgłosił ten błąd: IDEA-86707.

Z Łukaszem ćwiczyliśmy pisanie w Javie, przy czym na napisanie testu mieliśmy tylko dwie minuty. Jak stoper dochodził do końca, a my nie zdążyliśmy skończyć testu, to trzeba było usunąć kod i zacząć od nowa. Później analogicznie robiliśmy z implementacją. Ćwiczenie to miało na celu tworzenie małych prostych testów i prostej implementacji. Mi się kilka razy nie udało skończyć testu, gdyż nie była to moja klawiatura i bardzo ciężko mi się tworzyło test „na szybko”. Dla mnie pisanie testu, to czas w którym intensywnie myślę, co chcę testować, jak, jaką nazwę dobrać i czy test jest poprawny. Dwie minuty to troszkę za mało, nawet jak test jest niewielki.

Później trochę się posprzeczaliśmy na temat używania słówka should na początku nazwy każdej metody testowej. Łukasz twierdzi, że kiedyś było test (bo musiało być), a teraz ten „noise” zamieniliśmy na should i jak czytamy nazwy niedziałających testów, to i tak pomijamy ten prefiks.

Później wyskoczyliśmy całą grupą na obiad. Poszliśmy na jakieś burgery w pobliskim bistro. Panie z za lady bardzo się zaskoczyły nagłym zmasowanym atakiem żądnych mięsa programistów w Niedzielę, gdyż wcześniej nikogo w tym barze nie było. Co prawda nie była to pizza, ale taki lepszy fast food, smaczny i sponsorowany przez Nokię. Była w tym czasie możliwość pogadania z innymi uczestnikami.

Po obiedzie miałem jeszcze okazję pokodować z Janem. Tym razem rozmawialiśmy po Niemiecku.

Ostanie dwie sesje były bardzo szalone. Postanowiliśmy zrobić coś, z czym spotkałem się pierwszy raz. Mianowicie 6 par postanowiło zacząć kodować w Javie i wykonywać rotację jednej osoby co 10 minut. Do tego nie skasowaliśmy kodu pomiędzy sesjami. Bardzo smutne było, gdy trafiałem co chwila na tą samą trefną implementację jednego z uczestników, jednak ciężko było mi przeforsować jemu inny sposób spojrzenia na problem i odpuściłem. Ciężko, zwłaszcza podczas drugiej sesji, przebiegało wdrożenie w to, co się dzieje w projekcie, gdyż przez 10 minut ktoś musiał wytłumaczyć / pokazać w którym miejscu jesteśmy, jak to implementujemy i coś dopisać. W momencie gdy udało się już dopchać do klawiatury, to przychodziła już nowa osoba na sąsiednie stanowisko i role się odwracały.

O dziwo prowadzący stwierdził, że pierwszy raz widział, że ludzie podczas ostatniej sesji są tak mocno ożywieni. I rzeczywiście tak było. Te częste rotacje powodowały, ze trzeba było dawać z siebie wszystko, a stres z tym związany na pewno powodował wydzielanie się motywująco – pobudzających substancji w naszym ciele.

Na koniec oczywiście retrospekcja z całego dnia, podziękowania, wymiana kontaktami i wypad na piwko. Tam to dopiero całość spływa z człowieka i można jeszcze pogadać w luźniejszej atmosferze. No i jeszcze było sporo dzielenia się wrażeniami z Marcinem Saneckim i Rafałem w drodze powrotnej.

Podziękowania dla sponsorów @nokia, @crealytics, @klosebrothers. Miejsce odbywania się imprezy było ciekawe, gdyż znajdowało się w niezbyt uroczej dzielnicy, a blok wyglądał jak była fabryka. Za to firma crealytics udostępniła małe przytulne biuro i Club Mate, które trzymało mnie cały dzień na nogach. Powinni wprowadzić ten napój w pracy obok / zamiast kawy. Ogółem organizacja była bardzo dobra, dojście oznaczone, a na ścianach wisiały ciągle reguły gry.

Podsumowując, poznałem ciekawą technikę wymiany rotacyjnej uczestników co 10 minut, z którą nie spotkałem się wcześniej. Podpatrzyłem kilka innych konwencji nazywania metod testowych i zorientowałem się jak wygląda praca w Berlinie (miasto start-up’ów), gdzie dominującym językiem jest angielski.

DevCrowd 2012

Ledwo 3 tygodnie temu zakończyło się 33 Degree, a tu już kolejna polska konferencja DevCrowd, tym razem w Szczecinie. Konferencja ta jest całkowicie jest przeciwieństwem tej Krakowskiej, jeśli chodzi o wielkość, prelegentów, atmosferę no i cenę. Nie wiedziałem, czy uda mi się wybrać na tą konferencję, ale rzuciłem temat wśród ziomków i z racji dobrego połączenia ze Szczecinem, uczestniczyliśmy w tym wydarzeniu. Przejdźmy od prezentacji.

Na początku udałem się na prezentację Sebastiana Pietrowskiego na temat programowania funkcyjnego w codziennym developmencie. Sebastian opowiadał, czym są języki funkcyjne, po co to i tak dalej. Było trochę przykładów kodu, co jak można w innych językach zrobić, wzmianka o bibliotece Guava, która kilka pomysłów funkcyjnych stara się zaadoptować w Javie.

Później była jeszcze historia na temat tego, co się stało ze słowem kluczowym GOTO i całego sporu na temat stosowalności tego wynalazku. Ciekawa jest ewolucja tej instrukcji, od assemblera, przez programowanie strukturalne (C), obiektowe i w końcu funkcyjne. W Javie słowo goto jest słowem kluczowym (nie możemy nazwać w ten sposób zmiennej), ale nie ma ono implementacji. Mamy za to break i continue, które pozwalają nam wyskoczyć z pętli. Prelegent się mocno zastanawiał, czy w językach funkcyjnych miało by to słowo kluczowe jakieś sensowne zastosowanie i jakie inne ewentualnie konstrukcje językowe mogą podobną funkcjonalność zaoferować.

Generalnie na prezentacji było trochę mało informacji przedstawionych, spodziewałem się trochę więcej. Może coś więcej bym napisał w tym wpisie, ale z racji wszczesnej godziny wyjazdu nie pomyślalem, aby spakować ze sobą notes. Co do samego prelegenta, to jeszcze musi on trochę poćwiczyć wystąpienia publiczne, gdyż było czuć jekkie zdenerwowanie i prezentacja jak dla mnie byla mało ciekawie prowadzona.

Następnie było wystąpienie Jacka Laskowskiego, którego nikomu chyba przedstawiać nie trzeba, na temat Clojure'a, Jest to temat którym Jacek się od dłuższego czasu zajmuje, opisuje na blogu i przedstawia na konferencjach. Wcześniej raczej z daleka omijałem ten wynalazek, chyba ze względu na składnię pełną nawiasów i moje słabe rozeznanie paradygmatu funkcyjnego. Ostatnio jednak się przekonuję, że trzeba się przyjrzeć temu językowi (a na pewno jakiemuś funkcyjnemu).

Co jest w Clojur'ze takiego wspaniałego? Mnie np. zachwyciła obsługa wielowątkowości, którą przedstawił Venkat na 33 degree (więcej we wpisie: 33 degree 2012 dzień 2). Jacek przedstawił jednak temat w inny sposób.

Jako że na sali byli programiści obiektowi, prelegent starał się porównać byty obecne w Javie do tych które występują w Clojure. I tak w Javie mamy klasy, które posiadają metody, a klasy są agregowane w pakiety. Innymi słowy pakiet to zbiór klas, a klasa to zbiór metod. W programowaniu funkcyjnym mamy funkcje (jako byt podstawowy), które są agregowane w pakietach. Nie wiem czy to poprawne określenie w ramach tego języka, ale to co musimy sobie uświadomić, to to, że odpowiednikiem klasy w programowaniu funkcyjnym jest pakiet. W dalszej części prezentacji Jacek udowodnił tą tezę w kodzie.

Aby dalej zrozumieć temat, prelegent kazał się zastanowić, co robimy w programowaniu obiektowym. Mianowicie tworzymy obiekty, przekazujemy je jako argumenty metod i możemy je również otrzymać jako wynik wywołania jakiejś metody. W programowaniu funkcyjnym możemy funkcję (analogicznie jak obiekt) przekazać jako argument funkcji, zwrócić jako wynik i przypisać do zmiennej (a właściwie do stałej). Porównanie to dało mi sporo do myślenia.

Dalej Jacek kodował na żywo. Pokazał, jak można wywoływać rzeczy napisane w Clojure z poziomu Javy. Można skompilować kod pisany w Clojure do bytekodu, w taki sposób, aby było to widoczne przez klasy Javowe. Do tego automatycznie się generował plik JAR, który już w sobie miał wszystkie potrzebne biblioteki wymagane przez Clojure. Dzięki temu wystarczy zaimportować plik do projektu i używać po jawowemu. Jacek przez to zachęcał do pisania po kryjomu w projekcie kodu w tym funkcyjnym języku, bo i tak będzie działało. Na pewno duże zdumienie by było podczas review takiego kodu...

Bardzo mi się jeszcze spodobało spostrzeżenie, że wszystkie języki kompilujące się do bytecodu JVM’a, to tak naprawdę dostarczają nam ten sam produkt (bytecode), ale w trochę inny sposób. Tak więc na poziomie bytekodu języki te są nie rozróżnialne! Czy Java jest w tej sytuacji jakoś uprzywilejowana? NIE! Po prostu była pierwszym językiem do generowania bytecodu.

Co do samego wystąpienia Jacka, to poziom jak zwykle wysoki, potrafił zaciekawić słuchaczy, nawiązać dialog z publiką i zmusić ją do myślenia. W tytule prezentacji było o zastosowaniach serwerowych i spodziewałem się prezentacji jakiegoś framework’a Webowego do Clojura, a był pokazany prosty serwerek, który odbierał żądania http. Więcej, co pokazał Jacek, możecie przeczytać na jego angielskojęzycznym blogu.

Następnie udałem się na warsztaty ze Scali z Łukaszem Kuczerą (@lkuczera). Były one zaplanowane na 3 godziny plus przerwa obiadowa. Początkowo Łukasz wprowadzał nas do języka, dużo o nim opowiadając. Ja kilka dni przed konferencja poczytałem trochę i coś tam napisałem sobie w Scali, aby nie być całkiem zielonym. Dzięki temu na części wprowadzającej w język wiedziałem już co nieco, przez co tematy które nie do końca rozumiałem stawały się jaśniejsze. Do tego dostałem w piątek licencję na IntelliJ IDEA, w zamian za opisanie wrażeń z 33 degree. Mogłem więc od razu zobaczyć jak nowa wersja IDEI radzi sobie ze Scalą.

Później był obiad (zapewniony przez organizatorów). Do wyboru były pierogi, lub kurczak, a całość była dostarczona w styropianach pewnie przez jakąś lokalną firmę cateringową. Dzięki temu można było z obiadem iść gdziekolwiek i wraz z Marcinem Saneckim poszliśmy na zewnątrz na słoneczko. Tam już siedział Jacek Laskowski z Sebastianem Pietrowskim na krawężniku (w pobliżu nie było ławek) i zaprosili nas do wspólnego jedzenia.

Jacek bardzo pochwalił moje wpisy na blogu i nakręcił mnie do dalszej aktywności w tym kierunku. Jeszcze inne bardzo ciekawe tematy się wywiązały, ale lepiej o nich tutaj nie wspominać ;)

Po smacznym obiadku wróciliśmy dalej poznawać zakamarki Scali. Nie będę tutaj opisywał cech języka, ani tego o czym Łukasz opowiadał, bo było tego sporo, a jako świeżak w temacie nie chciałbym nikogo wprowadzać w błąd.

Następnie uczestnicy podzielili się na 2 części i zaczęliśmy w końcu kodować. Generalnie był trochę problem z tym co chcemy napisać, ale w końcu postanowiliśmy napisać parsera wpisow na bash.org, który będzie je zapisywał w bazie danych. Tak więc jeden zespół pisał bazę, a drugi (w którym uczestniczyłem) pisał parsera dla podanej strony. Nie poszlo nam zbytnio, polegliśmy na wyrażeniach regularnych i parsowaniu html’a.

Podczas tego szkolenia zdałem sobie sprawę, jak trudno jest poprowadzić warsztat dla nowicjuszy z nowego języka programowania. Jak dobrze przygotować zadania, aby uczestnicy w ciągu kilku godzin mogli coś napisać i wyjść z warsztatów z przeświadczeniem, że się czegoś nauczyli? Odpowiedź na pytanie z pewnością nie jest łatwa. To, że się nie pamięta podstawowych konstrukcji  języka i nie zna jego API, sprawia, że jednak każdy musi w domu sam usiąść z książką / tutorialem i poprostu zacząć pisać. Czy da się zrobić to jakoś podzczas kilkugodzinnego warsztatu? Nie wiem.

Na zakończenie konferencji było jeszcze rozstrzygnięcie konkursów. Firma SoftwareMill zaproponowała konkurs w którym można było wygrać SonyPlayStation3 Vita. Należało podesłać kawałek kodu, który będzie grał w papier, kamień, nożyce. Bardzo fajna akcja, jednak odpadłem w pierwszej rozgrywce. Było jeszcze losowanie 3ch licencji IntelliJ IDEA, ale już mam, wiec nie brałem nawet udziału :P

Wieczorem była jeszcze impreza pokonferencyjna. Dzięki uprzejmości Andrzeja (który prowadził i zgodził się wracać później) uczestniczyliśmy w after party. I tu było mega pozytywne zaskoczenie, gdyż po wejściu do restauracji zobaczyliśmy białe nakrycia stołów i jedzenie. Przez chwile myśleliśmy, że to jakaś inna impreza, ale zobaczyliśmy innych uczestników konferencji (koszulki konferencyjne przydają się do czegoś), a pani kelnerka jeszcze nas w tym utwierdziła. Nie mogłem się nadziwić, gdyż konferencja była w pełni darmowa, a do tego obiad w trakcie i po (można było spokojnie biegac po dokładkę) i dodatkowo sponsorowane napoje (wiadomo jakie). Wielki szacun dla organizatorów, za taką wspaniałą organizację!

Na wspomnianej afterparty było już mniej osób niż na samej konferencji, przez co atmosfera zrobiła się bardziej kameralno - społecznosciowa. Podpowiedź na przyszły rok: trzeba od razu od samego początku złączyć stoły, aby szybciej zacząć integrację z innymi. Może jeszcze warto zastosowac jakieś techniki sprzyjajace integracji? Myślę, że jest to warte rozważenia.

Z udziału w konferencji jestem bardzo zadowolony, zwłaszcza z możliwosci dowiedzenia się jak IT funkcjonuje w innych miastach (Szczecin), podzielenia sie z innymi swoimi uwagami, jaki i z ogólnego uspołecznienia, oraz możliwości spotkania innych branżowych zapaleńców. Podziękowania dla organizatorów, bo jak na darmowy event, to całość stała bardzo wysoko. Do zobaczenia (mam nadzieję) za rok.

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.