Dev Crowd 2015 – wrażenia

Osiemnastego kwietnia odbyła się siódma już edycja szczecińskiego DevCrowdu. Siedemnaście wystąpień, po raz pierwszy w trzech ścieżkach i ponad dwustu słuchaczy – DevCrowd z roku na rok ma się coraz lepiej. W tym poście chciałbym się podzielić moimi wrażeniami z tej imprezy.

DevCrowd 2015 - przed rozpoczęciem
Przed rozpoczęciem

Na początek trochę o prezentacjach na których byłem.

Sebastian Łaciak: Clean JavaScript code – only dream or reality

DevCrowd 2015 - Clean JavaScript code
Pierwsza prezentacja na której byłem tego dnia

Pierwsza prezentacja tego dnia dotyczyła nie tylko, jak sugeruje tytuł, czystego kodu. Mogliśmy posłuchać również o “kulturze” pracy z językiem zapewnianej przez dostępne nam narzędzia.

Sebastian zaczął od szybkiego przeglądu zasad pisania czystego kodu, znanych z książki Clean Code. Jak widać Wujek Bob jest wiecznie żywy – niezależnie od języka programowania ;)

W dalszej części Sebastian wspomniał o Node.js a później opowiedział o narzędziach, dzięki którym developer JavaScriptu staje się szczęśliwszą osobą:

  • Chrome z jego dev toolsami (debuger, profiler).
  • Github Atom w roli edytora tekstu.
  • Wtyczka JsHint do Atoma, która sprawdza poprawność kodu.

Mówiąc o czystym kodzie, nie sposób pominąć kwestii pisania testów. Sebastian pokazał, że testowanie w JavaScripcie może być przyjemne. Jako przykłady bibliotek zobaczyliśmy QUnit i Jasmine. Napisanie testów to jedno – uruchamianie to co innego. Możemy skorzystać z zapewniającego podstawową funkcjonalność runnera QUnit, ale możemy użyć fajniejszych zabawek takich jak Karma, czy PhantomJS. Dzięki Karmie będziemy mogli uruchomić nasze testy na “prawdziwej” instancji przeglądarki (a nawet kilku przeglądarkach na raz). PhantomJS jest natomiast samodzielnym silnikiem JavaScript, dzięki czemu odpalimy na nim testy bez konieczności podnoszenia całej przeglądarki.

Prezentacja została poprowadzona fajnie – Sebastian nieźle dawał sobie radę jak na osobę, która spędziła pół nocy w samochodzie jadąc do Szczecina.

Zastanawiam się trochę nad samą tematyką prezentacji. Mamy 2015 – Ekosystem JavaScriptu rozwija się bardzo szybko już od dawna. Wydaje mi się, że też już od dawna traktuje się ten język jako poważne narzędzie. Ale jednak Sebastian zdecydował się przygotować prezentację o tym, że w JS można pisać czysto i istnieją wygodne narzędzia wspomagające programistę. Czyżby nadal pokutował stereotyp JavaScriptu jako “tego dziwnego języka, do pisania efektu padającego śniegu na stronie”? Żeby nie było niedomówień – to nie jest w żaden sposób zarzut w kierunku Sebastiana (prezentacja jak najbardziej mi się podobała) – po prostu taka lużna myśl mi się nasunęła po Jego wystąpieniu.

Dominik Przybysz: Spock, czyli przyjemne testowanie

DevCrowd 2015 - Spock
Spock, czyli przyjemne testowanie

Jakiś czas temu na spotkaniu szczecińskiego JUGa, Magda Stożek opowiadała o Spocku. Niestety nie mogłem posłuchać jej wystąpienia, więc ucieszyło mnie, że temat ten zostanie poruszony na DevCrowdzie.
Nie miałem wcześniej okazji pobawić się Spockiem – po tej prezentacji już wiem, że napewno spróbuję.

Spock jest biblioteką do testowania napisaną w języku Groovy. Mimo, że aplikacje napisane w tym języku uruchamiają się na JVM, to jednak nie każdy programista Javy zna jego składnie. Na szczęście Dominik rozpoczął swoją prezentację od ekspresowego przeglądu składni Grooviego.

Następnie zostaliśmy zapoznani z ogólną strukturą testów – Spock wymusza na nas podział na sekcje:

  • given: – gdzie przygotowujemy środowisko testowe,
  • when: – gdzie wykonujemy testowaną akcję,
  • then: – gdzie sprawdzamy poprawność rezultatów naszych akcji.

To, oraz fakt, że w Groovy’m możemy nadawać metodzie nazwę ze spacjami, sprawia, że kod testów jest przejrzysty i łatwo go się czyta.

Później Dominik pokazał nam mocne strony Spocka:

  • Łatwe parametryzowanie testów, np. po przez “narysowanie” ascii-tabelki z zestawieniem parametrów.
  • Wygodna obsługa wyjątków. Nie musimy pakować całego testu w drabinkę try-catchy.
  • Wygodne mockowanie. Mocki są wbudowane w Spocka więc nie musimy korzystać z innych bibliotek. Wewnątrz “labelki” expect: definiujemy jak mock ma się zachowywać. Weryfikacja wywołań oparta jest o bardzo przejrzystą składnie, np. zapis 2 * foo.bar() oznacza, że chcemy sprawdzić czy metoda bar z naszego mocka foo była wywołana dwa razy.

Dominika mówiącego o Spocku w ramach JInkubatora można obejrzeć tutaj

Łukasz Lenart: Dlaczego Cię nie zatrudnimy czyli jak w SoftwareMill szukamy dobrych programistów

DevCrowd 2015 - Dlaczego cię nie zatrudnimy
Porzućcie wszelką nadzieje, wy którzy tu składacie CVki ;)

Łukasz opisał dokładnie wszystkie kroki procesu rekrutacji w SoftwareMill. Dzielił się swoimi spostrzeżeniami i podawał przykłady najczęściej popełnianych błędów. W czasie prezentacji najbardziej uderzyło mnie to, że dużo ludzi popełnia bardzo podstawowe błedy:

  • Wysyłają nieaktualne CV, lub wcale go nie wysyłają.
  • Nie umieszczają klauzuli o wyrażeniu zgody na przetwarzanie danych (!).
  • Wysyłają dokumenty w dziwnych formatach.
  • Linkują do kont na githubie które mają np. tylko jeden commit.
  • Nie robią zadań testowych.

Ogólnie rzecz biorąc wystąpienie Łukasza podsumowałbym w ten sposób:

  • Rekruter też człowiek – nie utrudniajmy mu życia.
  • W dobie LinkedIna, Githuba, Twittera i innych tego typu narzędzi nadal największą siłę mają najbardziej podstawowe narzędzia rekrutacyjne: CV i list motywacyjny (co akurat mówiąc szczerze mnie trochę smuci).

Nie udało mi się znaleźć nigdzie wideo z innej konferencji, gdzie Łukasz opowiadałby na ten sam temat. W zamian za to mam jednak wystąpienie Eweliny Malarowskiej z zeszłorocznej Confitury. Ewelina opowiadała o tym jak różne elemnty CV są postrzegane przez rekruterów (i dlaczego tak a nie inaczej). Myślę, że ta prezentacja i wystąpienie Łukasza nieźle się uzupełniają.

Marcin Matuszczak: Łagodne wprowadzenie do tworzenia nieblokujących aplikacji w Javie

DevCrowd 2015 - NonBlocking & Rx
Na prezentacji o nieblokujących aplikacjach było dość tłoczno

Marcin trafił na chyba najtrudniejszą porę do poprowadzenia prezentacji – czyli termin zaraz przed obiadem ;)

Marcin miał opowiedzieć o aplikacjach nieblokujących zarówno z punktu widzenia Javy 8 jak i Rx, jednak ze względu na dużą ilość contentu Marcin musiał przyciąć prezentację o część Rx’ową (co mnie bardzo zasmuciło).

Prezentacja rozpoczęła się od przedstawienia historii wielowątkowości w Javie. Zaczynając od wypełnionych smutkiem czasów ręcznego tworzenia i zarządzania wątkami, przez executory a następnie wprowadzenie Future. Ukoronowaniem ewolucji obługi wątków stał się CompletableFuture w Javie 8.

Sam fakt wykorzystania CompletableFuture nie sprawi automatycznie, że nasze aplikacje staną się nieblokujące. Marcin pokazał wiele przykładów na to, że wykorzystanie tego interfejsu może prowadzić do stworzenia blokującej aplikacji. Marcin pokazał nam jednak również w jaki sposób poprawnie używać CompletableFuture w kontekście tworzenia aplikacji nieblokujących. Zobaczyliśmy w jaki sposób łączyć ze sobą poszczególne zdania – czy to “szeregowo” czy “równolegle” i co nam to daje a czym może grozić.

Bartek Kuczyński: Od architektury do Infrastruktury

DevCrowd 2015 - od architektury do infrastruktury
Koziołek wierny minimalizmowi w swoich slajdach

Po obiedzie wybrałem się na dwie “use case’owe” prezentacje – na pierwszy ogień poszedł Koziołek.

Bartek na początku opowiadał o roli architektury w procesie tworzenia aplikacji. Wg. niego najbardziej ogólna architektura powinna wynikać z najważniejszych potrzeb klienta. Znając główne potrzeby klienta będziemy mieli możliwość zorientowania się czy budujemy raczej lepiankę, czy też drapacz chmur. Pozwoli nam to na przygotowanie odpowiedniej architektury. Będzie ona stanowić dla programisty drogowskaz, dzięki któremu “nie popłynie w nieznanym kierunku” podczas implementacji.

Po tym wstępie Bartek przystąpił do opisania konkretnej aplikacji przy której pracował – zdecydowano się w niej na podejście typu microservices. Każdy mikroserwis został napisany w zgodzie z Clean Architecture Wujka Boba.

Następnie poznaliśmy szczegóły infrastruktury które uzupełniały i wspierały wybrane podejście architektoniczne. Infrastruktura poszła w kierunku wirtualizacji, która daje powtarzalność.

Architektura i infrastruktura były do siebie dopasowane – wspierały się nawzajem. Połączenie mikroserwisów z wirtualizacją pozwoliło na uzyskanie rozwiązania które łączyło ze sobą zalety obu dych podejść:

  • poszczególne moduły były lekkie, mogły działać niezależnie od siebie, mogły być lokowane na niezależnych maszynach.
  • postawienie nowego środowiska z pracującym modułem wymagało minimalnego nakładu pracy.

Jacek Kunicki Michał Matłoka: From spaghetti with no src/test to green CI, good coverage and well-sleeping developers

DevCrowd 2015 - spaghetti
Jacek i Michał o refaktoryzacji

Przez cały dzień zastanawiałem się czy pójść na tą prezentację, czy na prowadzoną równolegle do niej prezentację na temat Akka Persistence. Koniec końców wylądowałem tutaj i naprawdę tego nie żałuję – jeżeli musiałbym wybierać to byłaby to najfajniejsza prezentacja ze wszystkich na których byłem.

Prezentacja opowiadała o refaktoryzacji super smutnego legacy systemu w coś zjadliwego dla developerów pracujących nad nim. Zastany system był ciężką spaghetti-driven aplikacją. Kod był pisany wg. konepcji copy-paste. Klasy były ze sobą mocno powiązane – nie było używane Dependency Injection. Nie istniał mechanizm walidowania parametrów, podobnie jak nie istniały żadne testy jednostkowe.

Chłopaki postawli sobie ambitny cel przeprowadzenia procesu ewolucji systemu w taki sposób aby zwiększyć jakość kodu, dodać obsługę błędów, śledzenie poszczególnych requestów, lepsze logowanie i wersjonowanie wszystkiego co się da.

Przede wszystkim usystematyzowano obsługę błędów – każdy response posiadał informację o wyniku operacji i ew. błędach – taka sama informacja była dołączana do wyrzucanych wyjątków. Logi były agregowane za pomocą logstasha a błędy za pomocą bugsnaga. Wszystkie requesty miały swoje correlation id więc niezależnie od tego gdzie trafiały – można było łatwo je odnaleźć.

Logowano całe requesty/response’y (po wycięciu wrażliwych danych takich jak hasła). Bardzo ułatwiało to obsługę zgłoszeń o błędach – developer mógł samodzielnie odtworzyć problematyczny scenariusz bez proszenia o reprodukcję. Pozwoliło to również na szybkie usunięcie wielu drobnych błędów w stylu – logika aplikacji działa dobrze, ale formularz na stronie przepuszczał głupoty. Dodatkowo wszędzie umieszczana była informacja o wersji (na podstawie hasha z gita) – dzięki temu bardzo szybko można było określić jaka wersja kodu powoduje problemy.

W ciekawy sposób rozwiązano problem braku testów jednostkowych. Okazało się, że w systemie tego typu przygotowywanie mocków do testów jednostkowych jest bardzo pracochłonne – dlatego też chłopaki postawili na testy integracyjne wykorzystujące Spring Boota (przy testach automatycznych) i Swaggera (do ew. ręcznego testowania).

Zarządzanie kodem oparte było o gita i gitflow oraz wersjonowanie w stylu semantic versioning. Najnowszy changeset uznawany za “działający” był oznaczony specjalnym tagiem gita – z tego taga był wykonywany deployowalny build. Dzięki temu, gdyby okazało się, że aplikacja się sypie, to bardzo łatwo można było wrócić do ostatniej znanej działającej wersji po przez “przesunięcie” taga.

Podczas prezentacji chłopaki dzielili się mnóstwem mniejszych i większych trików, które stosowali. Opisywali wiele ciekawych narzędzi. Dzięki temu nie była to sto pierwsza prezentacja o tym “jak refaktorowaliśmy legacy system”, ale raczej zbiór fajnych pomysłów, technik i narzędzi do wykorzystania we własnym zakresie.

Adam Bien: Java EE 7 / Java 8 in 2015

Podobnie jak w zeszłym roku tak i teraz Adam Bien poprowadził zdalną prezentację. Adam swoim zwyczajem przeprowadził swoje wystąpienie w formie live codingu – pisząc na żywo aplikację korzystającą z JaxRs, EJB, CDI i Javy 8.

Adam, podobnie jak rok temu – bardzo szybko wrzucił zapis wideo swojej prezentacji, więc zamiast opisywać co mówił, proponuję po prostu obejrzeć całe wystąpienie:

Podczas tej prezentacji pojawił się chyba jedyny zgrzyt podczas całej konferencji – prezentacja była streamowana na żywo i niestety momentami strasznie się cieła – całe szczęscie, że Adam Bien ma w zwyczaju publikowanie wideo ze swoich wystąpień.

Po konferencji odbyło się after party w Starym Browarze. Niestety mogłem być tam tylko chwilę.

Podsumowanie

Ogólnie konferencja po raz kolejny się udała. Organizacyjnie wszystko stało na wysokim poziomie – i gdyby nie problemy ze streamem prezentacji Adama Biena to właściwie nie przypominam sobie nic do czego można by było się przyczepić. W zeszłym roku pewne prezentacje wybijały się znacząco ponad średnią (np. wystąpienie Jacka Laskowskiego), ale były też takie które mi się nie podobały – w tym roku natomiast wszystkie prezentacje na których byłem trzymały równy, dobry, poziom – nie było takiej która by się bardzo mocno wyróżniała na plus bądź na minus.

DevCrowd 2015 - koszulka
Koszulka tegorocznej edycji

Można sobie tylko życzyć, aby za rok konferencja wypadła równie udanie – ale biorąc pod uwagę poziom wszystkich poprzednich edycji na których byłem, myślę, że można założyć w ciemno, że tak będzie. Kto wie, może nawet wystąpienia zaczną być nagrywane… ;)