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.