JDD 2015 – podsumowanie (dzień 2/2)

Kontynuacja relacji z JDD (pierwsza część znajduje się tutaj). Drugiego dnia miałem znacznie więcej szczęścia przy wyborze wykładów, bo wszystkie były interesujące, chociaż każdy trochę inaczej :-).

DDD w praktyce, czyli jak wdrażamy i uczymy się DDD w Allegro (Krzysztof Muchewicz)

Fajny prowadzący, bardzo ciekawie opowiadał o własnych doświadczeniach. Rozpoczął historię od opisu sytuacji sprzed 2 lat, gdy Allegro opierało się na monolitycznym kodzie w PHP i 40 zespołach programistycznych. Gdy Allegro zdecydowało się na migracje na Javę i wprowadzanie zmian zgodnie z DDD, zaprosiło do siebie na warsztaty Erica Evansa, autora znanej książki Domain-Driven Design. Wyszli z założenia że Polacy lubią autorytety i to ułatwi im przekonanie zespołów do zmiany myślenia. Moim zdaniem świetny pomysł, jednak pewnie niewiele firm na taki krok stać finansowo :-(.

Potem usłyszeliśmy o sposobie wyboru od której strony system przepisywać: od dołu, czyli frameworku, narzędzi i kończąc na core biznesu, czy na odwrót. Uzasadnienie zamrożenia wszystkich zmian na pół roku żeby zacząć od frameworku nie brzmiało wtedy najlepiej, więc zdecydowanoe na przepisywanie od core, co wydało się przekonujące. Dzięki temu kolejne części już działały w nowym modelu i można było je rozwijać. Do tego zadania zostali skierowani najlepsi ludzie, a po przekroczeniu pewnego momentu uznali że przestają rozwijać stary system (określenie „kości zostały rzucone”). Ilość zespołów została zwiększona do 60 (!).

Następnie usłyszeliśmy trochę o podstawach DDD, o Entity (unikalne własne wartości), ValueObject (obiekt wartości, np. adres pod którym może mieszkać wiele osób) i AggregateRoot. Wprowadzając nowy model kierowali się zasadą „(Prawie) wszystko powinno by obiektem wartościowym” poznaną w książce Vaughna Vernona „Effctive Aggregate Design” (dostępna na 3-częściowy 33-stronicowy darmowy e-book).

Ostatnia część wykładu była poświęcona kulturze organizacyjnej. Zgodnie z prawem Conway’a kultura organizacyjna wpływa na tworzone rozwiązania techniczne. Więc Allegro rozpoczęło wprowadzanie zmian właśnie od zmiany kultury organizacji, a ich celami stały się: płaska hierarchia i bezpośrednia, jasna odpowiedzialność.

Infinispan – Data Grid do zadań specjalnych (Sebastian Łaskawiec)

Sebastian Łaskawiec

Sebastian Łaskawiec

Ciekawy wykład o Infinispan, czyli dużym rozproszonym cache. Jest to rozwiązanie rozwijane przez firmę RedHat i, podobnie jak jej inne produkty, ma dwie bliźniacze wersje: darmową dla społeczności i płatną ze wsparciem dla firm. Usłyszeliśmy wprowadzenie do teorii CAP z 1999 roku mówiącej o tym że dla systemów rozproszonych niemożliwe jest spełnienie jednocześnie wszystkich trzech zasad spośród:

  1. spójności (ang. consistency) – wszystkie węzły mają te same dane w tym samym momencie,
  2. dostępności (and. availability) – gwarancji że każde żądanie zakończy się sukcesem albo porażką,
  3. tolerancji na podział (ang. partition tolerance) – możliwości działania nawet po przerwaniu połączeń pomiędzy grupami klastra.

Fajnie zostało to zilustrowane schematem wyboru rozwiązania NoSQL’owego które spełni dwa wybrane zasady spośród trzech (obrazek z artykułu z serwisu digbigdata.com):

Visual Guide to NoSQL Systems

Visual Guide to NoSQL Systems

Instalacja Infinispan odbywa się poprzez pobranie binarek lub przez Dockera. Standardowo działa tylko w pamięci ale można go skonfigurować do wielu sposobów utrwalania danych. Działa zgodnie z JCache JSR-107, w części głównej złożony jest z JGroups, serwera WildFly, Hibernate. Dalej: Lucene, RHQ (konsola do zarządzania), REST, Camel, OSGi Alliance, Spring, MemCached.

Rekomendowane jest konfigurowanie go programowo w Javie, a nie przez pliki XML. Posiada dwa tryby: synchroniczny (bezpieczny, oczekujący na potwierdzenie) i asynchroniczny (szybki ale bez gwarancji).

Kubernetes – Beyond the basics (Paul Bakker)

Paul Bakker

Paul Bakker

Prowadzący znany mi był już z zeszłorocznego JDD, więc szedłem „na pewniaka”. Tym razem opowiadał o Kubernetes – systemie do zarządzania kontenerami Dockera.

Usłyszeliśmy ogólny opis projektu oraz przykłady zastosowania. Interesujące były przykłady tworzenia węzłów, które robi się tylko jednym poleceniem na podstawie konfiguracji w JSON:

kubectl create -f nazwaPliku.json

Narzędzie zawiera także mechanizm do agregacji logów z wielu węzłów z użyciem innego ciekawe narzędzia Graylog, które po pobieżnym przejrzeniu wygląda na prostszy odpowiednik kombajnu Logstash + Kibana i także opiera się na ElasticSearch.

Ciekawe było także rozwiązanie organizacyjne prezentacji, ponieważ prowadzący wiedząc że ma tylko 40 minut na całość, część demonstracyjną zaprezentował jako film, na którym oglądaliśmy wyklikiwanie konfiguracji w aplikacji WWW oraz wywoływanie poleceń konsolowych – szybko i bezpiecznie.

Refactoring meets big money (Michał Gruca)

Michał Gruca

Michał Gruca

Fajny wykład z elementami miękkimi, czyli jak komunikować i sprzedawać konieczność wykonywania refaktoringu we własnym projekcie – coś, z czym spotykamy się niemal codziennie ;-).

Wymienione zostały powody, kiedy refaktoring musi zostać wykonany: kod staje się ciężko utrzymwalny i nie można go rozwijać, przychodzą kolejne duże zmiany, nie ma testów, development nowych rzeczy idzie za wolno, system za wolno działa albo nikt z programistów nie chce już przychodzić do pracy…

Zagrożenia jakie wprowadza refaktoring to: nie dajemy nic przez wiele sprintów, nie wprowadzamy nowych funkcjonalności, więc biznes jest nieszczęśliwy. Ze swojego doświadczenia dodałbym jeszcze zagrożenie błędami regresji ;-).

Jako rekomendowane rozwiązanie poleca Sprouting (z książki „Working Effectively with Legacy Code”, Michael Feathers), czyli dodawanie nowego kodu obok używanego i sukcesywne zaprzestawanie używania tego ostatniego.

W kwestii komunikacji z biznesem prowadzący sugerował położenia nacisku na zysk w postaci liczbowej (bo biznes kocha liczby), to znaczy jakie współczynniki kodu lub zespołu możemy poprawić po wykonaniu refaktoringu:

  • ilość commitów / sprint
  • ilość commitów / plik
  • współczynnik złożoności cyklicznej
  • pokrycie testami
  • ilość linii kodu / sprint
  • ilość issuesów w Findbugs / Sonar
  • itd.

Jako bardzo ciekawe narzędzia prowadzący polecał:

  • JArchitekt – do mierzenia złożoności kodu (300 EURO/licencje, 14-dniowa darmowa wersja próbna),
  • Dynatrace – do mierzenia wydajności (cena tylko na zapytanie, 30-dniowa darmowa wersja próbna)
  • Liquibase – do refaktoringu modelu bazy danych (opensource).

Przy wyborze obszaru refaktoringu prowadzący sugerował posiłkowanie się widzą działu supportu i QA, żeby dowiedzieć się do który obszarów jest najwięcej zgłoszeń błędów i najtrudniej lub najdłużej są poprawianie.

Kolejne porady to:

  • założenie wyraźnych i osiągalnych celów,
  • dostarczanie do biznesu poprawiających się wskaźników,
  • robienie tego w ramach SCRUm i dzielenie się wynikami na daily scrumach,
  • robienie tego przez wszystkie zespoły po równo, bez wyznaczania „ofiar”
  • używanie formuły hackathonów,
  • dzielenie się wiedzą i szkolenie zespołów w tym obszarze,
  • tworzenie na bieżąco standardów i egzekwowanie ich.

Końcowy efekt należy przełożyć na konkretne zyski finansowe: ile można zaoszczędzić.

Java Everywhere Again—with DukeScript (Jaroslav Tulach)

Jaroslav Tulach

Jaroslav Tulach

Jaroslav Tulach – autor książki Practical API Design, współautora NetBeans IDE, aktualnie pracujący dla Oracle.

Fajna prezentacja, prowadzący z zaangażowaniem opowiadał o swoim projekcie i próbował uczestników wciągnąć w dyskusję. Głupio wyszło, bo nie było jasno napisane że to mają być warsztaty na które uczestnicy powinni być przygotowani z NetBeans. Prowadzący pokazywał wiele przykładów (z których tylko jeden nie zadziałał…).

Tytułowy DukeScript to framework do tworzenia aplikacji na urządzania mobilne w języku Java i HTML, a następnie konwertowanie ich do JavaScript, a następnie do natywnych aplikacji Android i iOS. Framework ma wsparcie dla NetBeans IDE, gdzie po zainstalowaniu plugina można sobie wizardem ładnie stworzyć nowy pusty projekt, skompilować, uruchomić, debugować i modyfikować w czasie działania (!).

Nie korzystając z IDE można to także zrobić z maven kilkoma poleceniami:

mvn archetype:generate \
  -DarchetypeGroupId=com.dukescript.archetype \
  -DarchetypeArtifactId=knockout4j-archetype \
  -DarchetypeVersion=0.10 \
  -DgroupId=com.dukescript.test \
  -DartifactId=no-redeploys \
  -Dversion=1.0-SNAPSHOT
cd no-redeploys
mvn install
cd client
mvn exec:exec

Prowadzący dowodził że JavaScript i HTML5/CSS jest aktualnie najbardziej przenośną technologią, ponieważ poprawnie interpretują go wszystkie urządzania, nie blokując z powodu bezpieczeństwa tak jak apletów Java. Jednak nie powinno się w ogóle pisać kodu javaScript bo jest nieutrzymywalny – określając go ładnym skrótem „WONTA” – write once and never touch again” 🙂 Więc opisywany przez niego framework ładnie rozwiązuje ten problem.

Na końcu pokazał ładny przykład z komunikacją z back-end’em i z podwójną walidacją: JS i SS. Ten sam kod jest walidacji jest używany w obydwu przypadkach :-). Niezależnie jest wyzwalana komunikacja z B/E i niezależnie obsługa wyników jak wrócą.

Ciekawy pomysł, w szczególności do prototypowania – być może jeżeli będziemy zaczynali jakiś nowy projekt, to rozważymy jego użycie.

O autorze

Marek Berkan

Marek Berkan: programista, motocyklista, żeglarz, eks-wspinacz, zamiłowany turysta. Witryny: , , .

Share Button

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *