GeeCON – podsumowanie

W FP bardzo cenimy sobie rozwój, jednym z dobrych sposobów zdobywania wiedzy jest uczestniczenie we wszelkiego rodzaju konferencjach i eventach. Jak co roku, kilka osób wybrało się na kolejną edycję konferencji GeeCon, tym razem do Krakowa, w celu poszerzania horyzontów w Javovym świecie. Zapraszam na relację z konferencji opracowaną przez Zespół w składzie: Marcin Kania, Grzegorz Masłowski, Paweł Rychlik.

Tegoroczna konferencja GeeCON miała miejsce w krakowskim Multikinie i była rozplanowana na trzy dni, czyli – biorąc pod uwagę jedynie „Conference Days” – dłużej niż poprzednie edycje.
Tak jak zazwyczaj, nie było ścieżek dydaktycznych dotyczących konkretnych dziedzin. Cztery ścieżki każdego dnia, na każdej średnio sześć slotów. Prezentacje poruszały szeroki zakres tematów:

• techniczne, związane z narzędziami – np. niskopoziomowe optymalizacje JVM, nowości w JDK 8, kompilowane DSL-e w Scali, czy możliwości Graphite i Riemann,
• z dziedziny automatyzacji procesów – np. Gradle do zarządzania procesem budowania modułów, Jenkins (serwer Continuous Integration) i kilkaset pluginów do niego,
• dotyczące programowania – np. DDD, CQRS, refactoring, programowanie funkcyjne,
• związane z dev-ops, deploymentem i chmurą – np. Chef, Puppet, Vagrant, Amdatu, OSGi,
• NoSQL i BigData – HBase, MongoDb, elasticsearch,
• miękkie – budowanie teamów, XP, metodyki lekkie.

Pomimo tak wielu możliwości, czasem trudno było zdecydować, na który wykład pójść. Niekiedy kilka świetnych prezentacji wypadało równolegle – np. Wojtka Seligi „Software Developer Career Unplugged” i Szczepana Fabera „Automation dogfood” lub Piotra Gabryanczyka „Typeclasses, Monads – Functional and simple!”, Oliviera Gierke’a „REST assured – Hypermedia APIs with Spring MVC”, Sama Newmana „From Macro to Micro: How big your services should be?”. Z drugiej strony – niestety zdarzało się, że akurat żadna z dostępnej czwórki prezentacji nie zapowiadała się szczególnie interesująco.

Jeśli chodzi o tegorocznych prelegentów – można było spotkać m.in. Joela „z Polski” Spoolsky’ego (współtwórcę stackoverflow), Kohsuke Kawaguchi (twórcę jenkinsa), Leonida Igolnika (VP Product Development @ Oracle), Oliviera Gierke’a (project leadera Spring Data JPA), Antona Arhipova (project leadera JRebel), Sama Newmana (thoughtworks), Erika Onnena (VP of architecture @ Urban Airship), Svena Petersa (ambasador Atlassiana), Kena Sipe’a (top ranked speaker). Dopisały również gwiazdy polskiego podwórka: Paweł Brodziński, Paweł Lipiński, Sławek Sobótka, Szczepan Faber, Wojtek Seliga.

Miernikiem dobrej prezentacji jest poziom inspiracji na wyjściu (dosłownie) lub wykrzesanej motywacji np. do wprowadzenia tego usprawnienia w naszym projekcie, wypróbowania tego frameworka w wolnym czasie, zapięcia takiego narzędzia „na produkcję”. Wybierzmy zatem najciekawsze czy najbardziej inspirujące prezentacje.

Wojtek Seliga – „Software Developer Career Unplugged”

Slajdy: http://www.slideshare.net/wseliga/software-developercareerunpluggedgee-con2013

Jedna z najlepszych prezentacji na tegorocznym Geeconie. Zmotywowała do refleksji nad własną karierą i wywołała burzę dyskusji w naszym gronie. Wojtek zaczął od zobrazowania kariery developera jako szczególnego przypadku krzywej sigmoidalnej (http://vannevar.blogspot.com/2009/01/riding-sigmoid-curve.html). Motywował słuchaczy do zastanowienia się nad ich aktualnym położeniem w odniesieniu do wspomnianej krzywej. W życiu programisty bywa różnie: czasem trzeba zrobić parę kroków w tył, z senior developera stać się znów mediumem bądź juniorem w innym projekcie, z innymi ludźmi, być może w innej firmie. Z czasem inwestycja zwraca się i wychodzimy na plus, dokładnie tak, jak wskazuje bieg krzywej. Prelegent następnie poruszył temat ludzi, konkretnie specjalistów. Mówił o tym, co ich motywuje, co kieruje nimi przy wyborze ścieżki kariery. Okazuje się, że czasy się zmieniają. Coraz częściej dla pracowników kultura organizacji jest ważniejsza od zarobków. Bardzo ważna jest dla nich również możliwość rozwoju.

Kohsuke Kawaguchi  – „Large Scale Automation with Jenkins”

Slajdy: http://s3-eu-west-1.amazonaws.com/presentations2013/50_presentation.pdf

Prezentacja nieco rozczarowała, zwłaszcza, że prelegentem był sam twórca Jenkinsa i CloudBees. Styl prezentacji niestety nie powalał. Niemniej przy odrobinie skupienia dało się wynieść parę cennych informacji. Największą zaletą Jenkinsa jest jego rozszerzalność o dodatkowe pluginy, zapewne dlatego Kohsuke poświęcił większą część prelekcji na przegląd wtyczek jego zdaniem niezastąpionych:

• pokazał między innymi, jak można parametryzować zadania:
  (http://wiki.jenkins-ci.org/display/JENKINS/Parameterized+Trigger+Plugin),
• wspomniał o Join Plugin (http://wiki.jenkins-ci.org/display/JENKINS/Join+Plugin), który przypomina framework fork/join, tyle, że do zarządzania jobami,
• zasugerował, że Copy Artifact Plugin (http://wiki.jenkins-ci.org/display/JENKINS/Copy+Artifact+Plugin) mógłby się przydać do przekazywania artefaktów pomiędzy poszczególnymi jobami (np. jeżeli wynik jednego joba mógłby posłużyć jako baza innego, zależnego joba – każdorazowe budowanie w takiej sytuacji to strata czasu),
• polecił Promoted Builds Plugin: (http://wiki.jenkins-ci.org/display/JENKINS/Promoted+Builds+Plugin) w celu konstruowania bardziej złożonych struktur jobów, np. do automatyzacji wielopoziomowych testów, testów cross-platform, release’ów, itp.

Istotną kwestią w użytecznym środowisku Continuous Integration, jest przejrzystość zależności pomiędzy poszczególnymi jobami
i ich wynikami. Dependency Graph Plugin (http://wiki.jenkins-ci.org/display/JENKINS/Dependency+Graph+View+Plugin) i Build Pipeline Plugin (http://wiki.jenkins-ci.org/display/JENKINS/Build+Pipeline+Plugin) świetnie sprawdzą się w wizualizacji tych powiązań i ułatwią monitorowanie całego potoku uruchamianych jobów.

Stefan Tilkov – „Web development you are doing it wrong”

Slajdy: http://s3-eu-west-1.amazonaws.com/presentations2013/31_presentation.pdf

Kolejna prezentacja z serii dających do myślenia. Stefan Tilkov zaczął od wytycznych, jak nie robić web developmentu. Podał kilka popularnych sposobów wprowadzenia w irytację odwiedzającego stronę internetową. Może się wydawać, że w czasach, kiedy wszyscy robimy RIA, SPA i inne cuda, nie musimy przejmować się takimi szczegółami, jak niemożność użycia przycisku „wstecz” czy wyłączona możliwość skopiowania linku do konkretnego zasobu. Nic bardziej mylnego. Wszyscy próbujemy obchodzić jedną z głównych cech protokołu HTTP – bezstanowość – tak, jakby to był bug.Tymczasem bezstanowość to jak najbardziej pożądana cecha, dzięki której sieć web jest skalowalna i dostępna na każdym zakątku globu. Pierwsze przykłady „naprawiania” HTTP można było zauwazyć we frameworkach takich jak Struts. Cały stan na serwerze, wszędobylska sesja. Życie nauczyło nas, że to strzał w stopę. Kolejny przykład to omijanie javascriptu, w końcu to nie jest prawdziwy język programowania, a przecież my jesteśmy prawdziwymi programistami (przykład: GWT). Podobnie z CSS, kto by się w to bawił, skoro nikt nie rozumie, jak on działa? Dziś można zaobserwować kolejny przykład „naprawiania” HTTP: tak zwane “single page applications”. Oczywiście istnieje pewna klasa aplikacji, dla których taka architektura sama się narzuca (na przyklad gry online), jednak w większości przypadków taki model tylko denerwuje użytkowników. Stefan nie nawoływał bynajmniej do porzucenia tej ścieżki rozwoju aplikacji internetowych, wręcz przeciwnie, uznał ją za bardzo ciekawą. Ostatnio powstało wiele obiecujących frameworków, które być może się sprawdzą i wyznaczą kierunek rozwoju stron www na kolejne dziesięciolecia (przykład: AngularJS). Zobaczymy, co przyniesie przyszłość, jednak dzisiaj ciągle najlepszym pomysłem jest trzymanie się ogólnie przyjetych standardów i dobrych praktyk sieci web. ROCA Style for the win (http://roca-style.org/)!

Szczepan Faber – „Automation dogfooding”

Slajdy: http://s3-eu-west-1.amazonaws.com/presentations2013/11_presentation.pdf

Rzeczywiście tytuł adekwatny do treści. Szczepan (współtwórca Gradle’a) zaczął od krótkiego wstępu o firmie, w której pracuje. Zauważył, że przy pracy z rozproszonym sześcioosobowym zespołem (każda z osób w innym kraju), w rytmie wydań co 6 tygodni, nad projektem rozmiarów ~500 KLoC i 40 modułów bardzo ważne jest, żeby jak najwięcej procesów było zautomatyzowanych.
Od importu projektu do IDE i postawienia całego wymaganego środowiska, poprzez testy jednostkowe, testy integracyjne (w kilku dostępnych trybach uruchamiania), testy cross-platform i backwards compatibility i testy wydajnościowe, aż po testy dokumentacji. To nie pomyłka – panowie z Gradleware testują automatycznie nawet poprawność wycinków kodu zamieszczanych w dokumentacji. Nie trzeba już chyba wspominać o tym, że dystrybucja tej dokumentacji (User Guide, DSL reference, API reference i Release Notes) również wykonuje się w sposób zautomatyzowany. Co ciekawe, @szczepiq napomknął tak na marginesie, że gdyby w jego slajdach do prezentacji pojawiły się fragmenty kodu – one również byłyby automatycznie przetestowane (!).

Na koniec mieliśmy wgląd w pipeline budowania projektu, który składa się z wielu mniejszych kroków, tj. statycznej analizy, względnie szybkich testów na kilku platformach, dystrybucji artefaktów, serii długich i ciężkich testów. Dopiero na końcu całego cyklu artefakt jest uznawany za godny promocji do wydania następnej wersji narzędzia. W sumie trudno się dziwić, że firma, która specjalizuje się w dostarczaniu narzędzia do automatyzacji, ma tak umiejętnie zorganizowany proces jego budowania i dystrybucji.

Wracając do tytułu – dogfooding – inaczej  – eating your own food – w całym opisanym pipelinie podstawową rolę odgrywa sam Gradle –  to przecież na nim opiera się większość kroków procesu.

Prezentację można było sklasyfikować jako „inspirującą” – jej treścią było głównie to, jak wiele można osiągnąć. Szkoda tylko, że tak mało było powiedziane o tym, jak to zrobić.

Podsumowując – Szczepan Faber wcale się nie pomylił, umieszczając stwierdzenia “inspires” i “impresses (hopefully ;))” w sekcji “about this talk” :).

Baruch Sadogursky – „Developing for multi-component environment”

Slajdy: http://s3-eu-west-1.amazonaws.com/presentations2013/48_presentation.pdf

Baruch Sadogursky pracuje w JFrog (http://www.jfrog.com/), obecnie nad Bintray’em (http://bintray.com/). Swoją prelekcje rozpoczął od szybkiego przedstawienia projektu i używanych w nim narzędzi (m. in. mongoDB, nginx, elasticsearch). Cała prezentacja była prostą receptą na poradzenie sobie z zarządzaniem używanymi w projekcie narzędziami, zarówno „na produkcji”, jak i w środowisku developerskim. Rozwiązaniem tego problemu według Barucha jest kombinacja Vagrant + ChefSolo (dla środowiska deweloperskiego) oraz ChefServer + chmura (dla środowisk produkcyjnych). Baruch opisał zalety stosowania wirtualizacji oraz provisioningu: umożliwienie pracy developerowi na dowolnym systemie operacyjnym, łatwość zmiany wersji używanych komponentów, łatwość postawienia środowiska, w przypadku gdy nasz kod powali na ziemię bazę danych. Sama konfiguracja pisana jest w kodzie (Ruby), który potrafimy zrozumieć my – programiści, i można jej używać ponownie dla środowisk produkcyjnych. Tutaj Baruch posłużył się wymownym zdaniem: „I don’t know Ruby, but it looks like code to me”.

W czasie prezentacji pokazane zostało demo wykorzystania ChefSolo i Vagranta. Jedna z lepszych prezentacji, po której po prostu ma się ochotę usiąść i zmienić całe środowisko developerskie!

Sven Peters – „How To Do Kick-Ass Software Development”

Slajdy: http://s3-eu-west-1.amazonaws.com/presentations2013/17_presentation.pdf

W czasie wykładu Sven Petters (ambasador Atlassiana) pokazał w jaki sposób Atlassian „uprawia” kick-ass development w swoich projektach. Wymienił kilka technik, które zapewniają wysoką jakość wytwarzanego oprogramowania – branch per task, code review dla pull request, skrócenie cyklu wydawniczego, szybki feedback, chat zamiast emaili, continuous integration, wallboards. To nie wszystko! – ważne jest ciągłe usprawnianie stosowanego procesu (np. skracanie czasu wykonywanych testów automatycznych). Jednak to, co tak naprawdę wywarło na mnie największe wrażenie, to współpraca pomiędzy QA i Devami. W Atlassianie każdy developer jest (do pewniego stopnia) testerem. Dodatkowo każdy developer odpowiedzialny staje się za design, a każdy designer może odciążać developera. Sven omówił, jak duży nacisk Atlassian kładzie na współpracę wszystkich jednostek, tak aby wszyscy tworzyli jeden zespół, który czuje potrzebę i chce ciągle się rozwijać i doskonalić!

Całość prezentowana była z należnym entuzjazmem, humorem i naszpikowana była cennymi wskazówkami. Kolejna z prezentacji, która wywołała falę zadowolenia i obudziła w nas wewnętrzną chęć do działania, doskonalenia procesów i uprawiania kick-ass developmentu!