środa, 15 lipca 2015

Confitura 2015

"Otwórz swój projekt albo daj mu umrzeć", Krzysztof Debski.
Był to keynote, w którym prelegent z Allegro opowiadał o tym, że warto otwierać swój kod, tj. wypuszczać go w open source. Krzysztof najpierw opisał jak to było, gdy nie dzielili się swoimi dokonaniami ze światem zewnętrznym. Tworzyli więc pewne rozwiązania, a po jakimś czasie okazywało się, że ktoś robił coś podobnego i lepszego. A jeszcze później trzeba było się zmigrować do innego rozwiązania.

Natomiast, gdy jakiś projekt wychodził do open source’a, to nie dość, że inni zaczynają go używać, to i też rozwijać. A to strasznie przyspieszyło development danego rozwiązania. Nie trzeba oczywiście udostępniać wszystkiego (główny core biznesu można sobie zostawić), ale pewne rzeczy czasem warto upublicznić.

"Jak prezentować swoje pomysły przed ludźmi technicznymi i biznesem - rady od zwykłego programisty dla programisty", Sławomir Sobótka.
Nie widziałem w tym slocie nic lepszego dla siebie, więc poszedłem na „pewniaka”, czyli wystąpienie Sławka. Prezentację przejrzałem sobie wcześniej, wiedziałem czego się spodziewać, ale i tak było warto posłuchać i poznać parę wskazówek dla prelegentów.

Ludzie nie chcą słuchać o innych ludziach, tylko o sobie. Powinniśmy podkreślać, że prezentacja jest dla nich i przykładowo nie mówić „ja zrobiłem to i to…”, tylko raczej powinniśmy pytać się publiki, jak ona by się zachowała, gdyby miała taki problem u siebie. Taka sztuczka sprawia, że słuchacze zaczynają myśleć o tym problemie i się z nim utożsamiać. Zyskujemy sobie wtedy zainteresowanie słuchaczy.

Innym błędem, często popełnianym przez początkujących prezenterów, jest mówienie na początku wystąpienia, że są raczkujący w danym zagadnieniu, albo, że się nie przygotowali itd. Jest to spory błąd, bo od samego początku nastawia słuchaczy negatywnie do prelegenta. Można jedynie powiedzieć, że się przykładowo sepleni, ale nie powinno to wpłynąć na jakość prezentacji. Trzeba trochę z tego zażartować, aby rozluźnić atmosferę.

Jest sporo poradników, jak robić prezentację, jak się przygotowywać, ale tak naprawdę to każdy musi wypracować sobie swój sposób. No i wiadomo, że prezentacje robione na kolanie dzień wcześniej nie mogą się udać.

Przygotowania przygotowaniami, ale co z stresem przed widownią? Warto na pewno przyjść wcześniej, poczuć klimat sali, na spokojnie się rozłożyć i przyzwyczaić do otoczenia. A gdy pojawia się stres? Emocje są przez nas rozpoznawane w ciągu 0.3 s i mamy tylko 0.2 s na to, aby nazwać nasze uczucie i zlokalizować, z jaką częścią ciała jest to powiązane. Dzięki temu cukier będzie dopływał do kory przedczołowej, a nie do układu limbicznego.

Sławka osobiście denerwuje, gdy prelegent zadaje pytanie publiczności i sam podnosi rękę do góry sugerując odpowiedź. Ja na to dotychczas nie zwróciłem uwagi i osobiście nie przeszkadza mi to. Dla mnie jest to sygnał, że pytanie nie jest retoryczne, że prelegent oczekuje odpowiedzi, a także sam korzysta z rzeczy, o które pyta. Dodatkowo może to trochę obudzić publiczność i zachęcić do interakcji.

Na koniec Sławek zachęcał do nakręcenia video ze swojej prezentacji. Można to uczynić na większości polskich JUG’ów. Następnie należy je obejrzeć kilkakrotnie. Raz ogólnie, raz zwrócić uwagę na głos, kolejnym na reakcję ludzi, następnym na mowę ciała itd. Na koniec trzeba wyciągnąć wnioski i się poprawić.

Slajdy z prezentacji można przejrzeć tutaj: https://prezi.com/lwiqdtc1oe9u/jak-prezentowac-swoje-pomysy-przed-ludzmi-technicznymi-i-biznesem/

"Are you aware of /bin of your JDK?" Andrzej Grzesik
Na prezentację się chwilę spóźniłem, ale Andrzej ogólnie pokazywał narzędzia, jakie każdy ma w swoim JDK. Było o javac, javap, jps, jar, jmap, jhat, jstack (wypisuje stacktrace’y), jstat, jstatd (monitoring zdalnej maszyny).

Większość tych narzędzi już widziałem w akcji. Nowy był dla mnie jhat. Potrafi on wystawić serwer http i można za jego pomocą analizować to, co znajduje się na starcie naszego procesu javovego. Ponadto udostępnia on OQL - Object Query Language do wyszukiwania naszych obiektów na owej stercie.

W nowym JDK 9 ma wejść nowe narzędzie jcmd, które ma zastąpić wszystkie te pozostałe narzędzia. Sensowne posunięcie, zwłaszcza, że część tych funkcjonalności powiela się między narzędziami. Na koniec było jeszcze o Jvisualvm i plugine visualgc.

"Need for async: In pursuit of scalable internet-scale applications", Konrad `ktoso` Malawski
Konrad opowiadał o wielu kwestiach związanych z przetwarzaniem wielowątkowym. Było o Unfair scheduling’u, czyli gdy jakiś proces jest głodzony przez scheduler’a i jakie są sposoby radzenia sobie z tym, czyli o algorytmach nieblokujących. I tak Lock-free (inaczej Lock-freedom), jak mu się nie uda uzyskać lock’a to się cofa i próbuje jeszcze raz. Wait-free (albo Wait-freedom) dodatkowo wprowadza maksymalną liczbę prób, jakie może podjąć algorytm, aby uzyskać locka na potrzebnym zasobie.

Było jeszcze java nio, czyli o nowym sposobie dostępu do plików. Na poziomie systemu operacyjnego operacje wejścia / wyjścia są bardzo czasochłonne, ponieważ system musi się przełączyć pomiędzy user mode a kernel mode. I to się dzieje wielokrotnie podczas typowej pracy z plikami, a jak wiadomo to kosztuje czas i zasoby. Rozwiązaniem tej kwestii jest korzystanie z Zero-copy.

Było jeszcze parę pobocznych tematów, ale podsumowując prelekcję, to powinniśmy wybierać narzędzia pod nasze problemy, a nie ze względu, że są na hype.

"Vert.x - wydajna i skalowalna platforma", Bartek Zdanowski
Bartek bardzo pobieżnie i marketingowo przedstawił narzędzie Vert.x Posiada ono swoją szynę zdarzeń, za pomocą której przesyłamy zdarzenia, które następnie są wykonywane przez inną cześć aplikacji. Czyli możemy tworzyć aplikacje wielowątkowe. Dla mnie najciekawszy jest fakt, że z Vert.x’a można korzystać z Javy, Grooviego, Ruby jak i JavaScript’a. Jeszcze do końca tego nie pojmuję, jak to jest zbudowane, ale z prezentacji wynikało, że część serverowa, pisana np. w Groovym, może rzucić event’a, który zostanie obsłużony po stronie przeglądarki w JavaScripcie.

Generalnie zabrakło mi trochę konkretnych przykładów, zamiast przymiotników, jaka to nie jest wspaniała technologia. Cała prezentacja chyba zrodziła więcej pytań i wątpliwości niż wyjaśnień, co było widać po ogromnej ilości pytań na koniec.

"Elasticsearch at Scale of Billions of Documents," Igor Kupczyński
Na tej prezentacji spodziewałem się doświadczeń i wniosków z napotkanych problemów z użyciem Elastic’a. Sam z niego ostatnio sporo korzystałem w projekcie, więc byłem w temacie.

Igor sugerował, aby definiować minimum_master_nodes=(n+1)/2, gdzie n to [chyba] liczba wszystkich nodów w klastrze.

discovery:
  zen:
    minimum_master_nodes: 2

Nie powinniśmy również wykorzystywać Elastic’a jako nasze główne źródło prawdy, tylko powinniśmy przechowywać dane w innej bazie / bazach i je replikować do Elastica.

Nie powinniśmy również pozwalać, na ponowne tworzenie utraconych shardów. Pozwoli to nam uniknąć niekonzystencji. Przykładowa konfiguracja dla 4ch nodów w klastrze:

gateway:
  expected_data_nodes: 4
  recover_after_time: 48h

Było też o tym jak przeprowadzać update’y oprogramowania lub sprzętu, aby klaster dalej działał. Cała procedura jest opisana na stronie Elastic’a pod hasłem: Rolling Restarts.

Dalej było o ustawieniach pamięci, której 50% powinniśmy ustawić dla JVM heap’a, a drugie tyle dla Lucynki. Powinniśmy jednak mieć mniej niż 32 GB pamięci operacyjnej ze względu na compressed object pointers. Powinniśmy również tą pamięć zaalokować od razu na starcie:

bootstrap:
  mlockall: true

i sprawdzić, czy JVM nam na to rzeczywiście pozwala:

curl -s $URL/_nodes/process?pretty | grep mlockall

Było jeszcze o Fielddata, garbage collector’ze i paru innych tematach. Powinniśmy raczej obserwować nasz klaster, a nie go stroić, co radzą również twórcy tego rozwiązania. Do monitoringu Igor polecał m.in. Kopf, Elastic HQ, Bigdesk i pluginy do Nagios’a. Spis tego typu narzędzi możemy znaleźć na oficjalnej stronie: Health and Performance Monitoring.

Wykład fajny, ale wolałbym go usłyszeć po polsku. Slajdy są dostępne tutaj: ELASTICSEARCH IN PRODUCTION.

"Czego Javowiec nauczy się od Haskella?", Tomasz Nurkiewicz
Najlepszy, wg mnie, wykład został na koniec. Nie dotyczył on co prawda jakiejś konkretnej przełomowej technologii, ale zmieniał trochę światopogląd na nasz sposób programowania i wywracał myślenie do góry nogami. O dziwo na prezentacji nie było kodu Haskell’a, a chodziło o pewne koncepty z tego języka, a właściwie to, czego tam nie ma: null, zmienne, wyjątki, void, Object, pętle, przeciążanie metod, efekty uboczne. Tylko jak bez tego wszystkiego żyć? A no da się.

W Haskelu już na podstawie definicji funkcji, można wywnioskować, jaka jest jej implementacja. Bardzo często mamy jedną możliwość implementacji takiej funkcji. Dlatego powstało Hoogle, czyli takie Google dla Haskella do wyszukiwania funkcji na podstawie sygnatury. W IntelliJ’u jest to zdefiniowane jako Structural Search Ctrl + Shift + S.

I tak, jak Java w tym roku obchodziła 20-lecie, tak null obchodził 50-lecie. Ile to katastrof z tego faktu wynikło… W Javie i Scali mamy niby teraz Optional, ale i tak może ono być null’em:

Optional<String> name = null;

albo jeszcze lepiej:

Optional<String> name = Optional.of(null);

więc to tak naprawdę niczego nie rozwiązuje. A w Haskellu tak się (podobno) nie da. Tomek pokazywał przykład w Kotlin’ie, jak on nam uniemożliwia wykonanie kodu, który jest niebezpieczny pod względem null pointerów. A propo de facto, czy my w ogóle mamy w Javie wskaźniki?

Dalej Tomek podawał przykłady aplikacji, które nie zmieniają stanu, a jedynie tworzą nowe, z ewentualnymi referencjami do poprzednich stanów. I tak przykładowo działa Git, gdzie każdy commit to nowe pliki + wskazanie ma poprzedni commit. Baza danych Datomic została napisana w Clojure i posiada ona tylko jedną zmienną. Nie można w niej edytować danych - baza trzyma całą historię zmian.

I ostatnia rzecz, która wywarła na mnie ogromne wrażenie, to eksperyment John'a Carmack'a, twórcy Wolfenstein'a 3D, Doom'a i Quake'a, który przepisał pierwszy tytuł do Haskella, czyniąc go czysto funkcyjnym. Pomysł ten mnie zniszczył w pierwszej chwili i dał sporo do myślenia. Myślę, że to świetna metoda nauki. Pozatym kod tych produkcji jest w całości dostępny na githubie: github.com/id-Software.

Podsumowując, Confitura w tym roku była na pewno lepiej zorganizowana (mniejsze kolejki do rejestracji), była walka o wejściówki (ale się udało), a napoi chłodzących było pod dostatkiem w ten upalny dzień. Co do agendy, to mam wrażenie, jakby poza ścisłą, oczywistą, polską czołówką prelegentów, dostało się sporo prezentacji z przypadku. Albo takich, co już były. No ale cóż, taka była wola ludu.

środa, 1 lipca 2015

Devoxx w Polsce - dzień 3 ostatni

Trzeci dzień Devoxxa zacząłem do prezentacji Christophera Batey’a: "Building fault tolerant microservices". Dopiero po jakimś czasie się zorientowałem, że już gdzieś to widziałem… I fakt byłem na tej prezentacji na Voxxed Days Vienna 15. A specjalnie przed pójściem sprawdzałem na blogu, czy to nazwisko nie jest mi znane, ale coś mi poszło nie tak :(

Nie będę opisywał wszystkich praktyk i narzędzi z których korzysta prelegent, tylko zmieszczę jego przykładowe projekty:
Z ciekawostek, to w Spring Boot’cie można za pomocą hystrix-javanica skorzystać z adnotacji @HystrixCommand i możemy metody opakowywać w komendy Hystixowe, bez całej ceremonii.

Na koniec było jeszcze jak sprzedawać takie zabawki biznesowi. Trzeba zrobić if’a w kodzie, który będzie odciążał nasz system w ciężkich chwilach i podpiąć guzik do tego. Jak będzie duże obciążenie i ktoś będzie do nas dzwonił, to musimy kazać mu wcisnąć przygotowany guzik i odciążyć serwery. Jak się będzie to powtarzać to w którymś momencie biznes się zapyta, czy nie da się tego zautomatyzować i wtedy wprowadzamy potrzebne zabawki.

Kolejną prezentacją, na którą się udałem była Pawła Szulca na temat: "Event Sourcing & Functional Programming - a pair made in heaven". Był mały problem z kodem, który na części slajdów był niepokolorowany i zapisanym małą czcionką. Prelegent polecał przeczytanie publikacji Why Functional Programming Matters.

Następnie Paweł tłumaczył jak działają monady, na co zeszło dużo czasu. Później było na temat Event Sourcing’u, czyli to o czym zawsze Greg Young opowiada. Na koniec pozostało 20 minut czasu na demo. Było ciekawe, bo „opowiadało” fabułę filmu. Prezentacja była dobra, trzymająca poziom. Więcej kodu następnym razem proszę.

Następnie byłem na 15sto minutówce, gdzie Roy van Rijn opowiadał o REPL’u w Javie 9: "Watch out, the REPL is coming". Była to prezentacja zgłoszona dzień wcześniej i na kolacji ze speakerami była jeszcze łatana przez speców z Oracle’a. Dali radę, bo na demo wszystko zadziałało. Jest to jeszcze wczesny development, więc jest jeszcze sporo błędów, które mogliśmy zobaczyć pod koniec wystąpienia. Jak na prezentację przygotowaną na spontanie to poszła bardzo fajnie.

Następnie byłem na prezentacji Grega Young’a: "8 Lines of Code". Greg pokazał parę wywołań, które w skrajnych przypadkach mogą powodować jakieś problemy, np: FileStream.Flush(), FileStream.Seek(). Nie powinniśmy ponadto tworzyć nieograniczonych kolejek i w momencie zaczynania projektu powinniśmy się zastanowić, jak będziemy chcieli debugować problemy na produkcji. Warto sobie w logach wypisywać wszystkie zmienne środowiskowe, aby można było odtworzyć środowisko, gdzie występuje błąd. Najciekawszych problemów wielowątkowych i tak nie jesteśmy w stanie debugować :(

Kolejną prezentacją na którą się udałem była Teda Newarda: "Busy Java Developer’s Guide to Three REST API Frameworks". Na początek Ted powiedział: „Chrząszcz brzmi w trzcinie” :)

Ted przedstawił 4 różne frameworki. Na pierwszy ogień poszedł SparkJava (nie mylić z Apache Spark). Jest on inspirowany Sinatrą ze świata Rubyiego. Wygląda on na bardzo małe i proste rozwiązanie, gdzie wiele składni Javy 8 jest wykorzystywane. Hello World:
import static spark.Spark.*;

public class HelloWorld {
    public static void main(String[] args) {
        get("/hello", (req, res) -> "Hello World");
    }
}

Rozwiązanie to pozwala zarządzać sesją tak jak kontenery servletów. Rozwiązanie na pewno przydatne do małych rozwiązań i testów.

Następnie na tapetę poszedł Vert.x. Bazuje on na JVM, ale można z niego korzystać w Javie, JavaScripcie, Groovym i Rubym. Nie wiem jak to jest technicznie rozwiązane, ale brzmi bardzo ciekawie. Model współbieżności jest oparty na Aktorach i ma rozproszoną szynę zdarzeń. Dalej było parę przykładów jak wygląda kod dla różnych języków. Dla Javy poniżej:
public class Server extends AbstractVerticle {
  public void start() {
    vertx.createHttpServer().requestHandler(req -> {
      req.response()
        .putHeader("content-type", "text/plain")
        .end("Hello from Vert.x!");
    }).listen(8080);
  }
}

Tworzenie współbieżnego kodu z Vert.x jest łatwe ze względu na pewne założenia. Kod który tworzymy jest jednowątkowy i każdy moduł (jakkolwiek go definiujemy) ma osobną pętlę z event’ami, która się nie blokuje.

Kolejny był DropWizard. Jest to już trochę większy kombajn, który ma zintegrowane wiele bibliotek Javowych w sobie, aby można go było szybko wdrożyć na produkcję. Trochę jak Spring Boot. DropWizard ma wbudowanego Jetty’iego, korzysta z Jersey'a do RESTa, Jackson’aMetrics do zbierania statyskych z różnych części aplikacji, Guava, Logback, Hibernate ValidatorJDBI dla połączenia z bazą danych, Liquibase dla wersjonowania bazy, FreemarkerMustache dla frontendu, Joda Time i pewnie jeszcze wiele innych. I całość opędzona mavenem. Przykładowy kod poniżej:
public class HelloWorldApplication extends Application {
    public static void main(String[] args) throws Exception {
        new HelloWorldApplication().run(args);
    }

    @Override
    public String getName() {
        return "hello-world";
    }

}

Jako wynik dostajemy dużego JARa, którego odpalamy i działa. Możemy jako argument przekazać plik konfiguracyjny do aplikacji. Wygląda na całkiem ciekawy stos.

Ostatnim zaprezentowanym narzędziem był RestX, czyli lekki, modułowy, szybki… To co dostajemy to samoaktualizujący się shell, wstrzykiwanie zależności, wsparcie dla MongoDB, interaktywna dokumentacja RESTa, automatyczne testy, konsola admina. Konkretne endpoint’y RESTowe można generować w stylu testów BDD (Resource Spec) albo małych klass:
@Component @RestxResource
public class HelloResource {
    @GET("/message")
    public Message sayHello(String who) {
        return new Message().setMessage(String.format(
                "hello %s, it's %s",
                who, DateTime.now().toString("HH:mm:ss")));
    }
}

Po wystartowaniu otrzymujemy od razu dokumentację naszego API, konsolę admina i coś do monitorowania. Generalnie projekt zawiera w sobie DropWizard’a, wszystkie komponenty są bezstanowymi singletonami, architektura jest mocno zmodularyzowana i dev mode wspiera hot-recompile kodu źródłowego.

Na koniec było podsumowanie, że żaden framework nie jest najlepszy, tylko że każdy jest inny - i w sumie racja.

Na koniec całej konferencji zostało motywujące wystąpienie Jurgen Appelo o "The Creative Networker". Jurgen tłumaczył pewien wykres:


Wynika z niego bardzo wiele, a mianowicie, najwięcej uczymy się podczas eksperymentowania. W przypadku popełniania, błędów uczymy się nie wiele, ale nie powinniśmy się tym przejmować. W przypadku praktyk (czyli produkcji masowej), już nie wiele jest nauki, ale za to duży sukces. Zawsze świętujemy sukcesy (a w Polsce pijemy również przy porażkach), ale często nie świętujemy naszych eksperymentów - a powinniśmy.

Prelegent przedstawił siedem zasad dla kreatywnych:
  1. Szukanie wielu pomysłów - najpierw powinniśmy zbierać jak najwięcej pomysłów 
  2. Generowanie wielu pomysłów - później je jeszcze generować w myśl zasady: "The best way to have a good idea is to have a lot of ideas" - Linus Pauling
  3. Tworzenie połączeń - musimy naszym pomysłem podzielić się z innymi i wzajemnie się inspirować 
  4. Poszukiwanie kierunku - mindfulness i unfocus są najlepsze dla kreatywności 
  5. Wykonanie pomysłu - trzeba wizję zrealizować 
  6. Zrozumieć błędy - i wynieść naukę na przyszłość 
  7. Uczyć się na porażkach - w końcu wiele wynalazków powstało przez przypadek 



Omawiane techniki i praktyki nie są jakimś dużym wymysłem prelegenta, a raczej wnioskami z wielu książek i notatek.



Na koniec była jeszcze reklama książki Jurgena: Management 3.0. Był to bardzo motywujący wykład na koniec konferencji, bardzo motywujący do testowania swoich pomysłów i inspirujący do próbowania ze startup’ami.

Było jeszcze krótkie zakończenie konferencji, gdzie można było zobaczyć wszystkich organizatorów i wolontariuszy. Podsumowując 3 dni, to organizacyjnie konferencja była bardzo dobrze ogarnięta. Super miejsce na tak dużą konferencję, dobre nagłośnienie, rzutniki i jedzenie. Trochę brakowało ciastek w przerwach, aby dostarczyć cukru do kory przedczołowej, ale napojów było pod dostatkiem. Trochę mi zabrakło prezentacji najwyższych lotów, które by wywracały aktualne postrzeganie świata o 180 stopni. Mogło by być również więcej tych dobrych, albo ja trafiałem na wiele przeciętnych. Na pewno będę musiał jeszcze sporo prezentacji obejrzeć, jak będą dostępne.

Devoxx w Polsce - dzień 2

Drugi dzień zaczął się dla mnie kiepsko. Byłem najpierw na "Why software developers should care about deployment and monitoring", Michała Kosmulskiego, który tłumaczył bardzo podstawowe rzeczy. Poszedłem więc na "Case Study: Agile @gov.pl", Matta Harasymczuka, ale tam zamiast o Agile w sektorze rządowym było o podstawach Agile. Skoro prelegent ma tylko 5 minut, aby zachęcić publikę do swojej prezentacji, to tutaj czas ten został ewidentnie źle wykorzystany. 
Ostatecznie poszedłem na "Building systems that are #neverdone", Jamesa Lewisa. Było ogólnie o zasadach YAGNIDRY, TDD, SRP, KISS… Nic konkretnego, już Wujek Bob i inni powiedzieli to 100 razy. Jedyne co to biblioteka Pact się przewinęła po raz drugi na konferencji.

Następnie udałem się na wykład Tomka Nurkiewicza pt.: "Hystrix – managing failures in distributed systems". Jest to biblioteka od Netflix’a, który obecnie generuje sporo ruchu internetowego. A sam Hystrix jest implementacją wzorca Fail Fast. Chodzi o to, że w rozproszonych systemach (np. modne ostatnio wszem i wobec mikroserwisy) czasem część usług może ulec awarii. Jakiś serwis / część systemu może być pod dużym obciążeniem, chwilowo niedostępna, lub odpowiada dopiero po długim czasie. Zamiast próbować taką usługę ciągle odpytywać (i robić jej DoS’a) to może lepiej jest się wstrzymać z zapytaniami i od razu propagować błędną odpowiedź w systemie, albo jakoś inaczej na nią reagować. Podejście takie powoduje, że szybciej mamy informację, że coś nie działa. Dodatkowo jak odciążymy daną usługę, to jest szansa, że się ona naprawi, tzn. skończy przetwarzać zaległe zadania i będzie można z niej ponownie skorzystać. System wtedy jest w stanie samemu się wyleczyć.

Jak działa Hystrix? Mianowicie każde wywołanie, które może się nie udać, opakowujemy w HystrixCommand. Po wywołaniu metody execute() zostanie zwrócona wartość tego co zostało opakowane. Gdy serwis nie odpowiada dłużej niż 1 sekunda (oczywiście można to zmienić), to zostanie zwrócona wartość błędu (Fallback), którą możemy sobie zdefiniować (domyślnie UnsupportedOperationException). Domyślnie każda komenda (tzn. tego samego typu) posiada pulę wątków ustawioną na 10. Według twórców Hystrixa nie potrzeba więcej.

Oczywiście mamy też większą możliwość konfiguracji zachowania, np. przy jakim procencie błędnych odpowiedzi, albo przy jakiej minimalnej liczbie błędnych request’ów, w danym oknie czasowym nie męczyć więcej zewnętrznej usługi.
static class CircuitBreakingDownloadCommand extends HystrixCommand {

 protected CircuitBreakingDownloadCommand() {
  super(
    Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("Download"))
          .andCommandKey(HystrixCommandKey.Factory.asKey("SomeCommand"))
          .andThreadPoolPropertiesDefaults(
             HystrixThreadPoolProperties.Setter()
                .withMetricsRollingStatisticalWindowInMilliseconds(10_000))
          .andCommandPropertiesDefaults(
             HystrixCommandProperties.Setter()
                .withCircuitBreakerEnabled(true)
                .withCircuitBreakerErrorThresholdPercentage(50)
                .withCircuitBreakerRequestVolumeThreshold(20)
                .withCircuitBreakerSleepWindowInMilliseconds(5_000))
        );
    }
}


Hystrix oferuje jeszcze domyślny servlet, który generuje strumień statystyk odnośnie każdego rodzaju Hystrix’owej komendy. Widać go standardowo pod /hystrix.stream i maksymalnie 5 klientów może się pod niego podłączyć. W ładny sposób są te dane wizualizowane za pomocą Hystrix Dashboard. Gdy chcemy na naszej "desce rozdzielczej" widzieć informacje z wielu miejsc, to za pomocą Turbine możemy połączyć wiele strumieni w jeden i pod niego podłączyć dashboard. Przykładowy wygląd poniżej:


Możemy również zapisywać sobie te statystyki i ładnie wyświetlać w Graphite. Dokładny opis jak tego dokonać znajdziemy na blogu Tomka. Było jeszcze omawiane pobieżnie parę zagadnień, ale czas już gonił. Z ciekawostek to jeszcze było o Executors.newFixedThreadPool(), które to są niebezpieczne w środowisku EE, bo wrzucają wątki do kolejki, która jest nieskończona. Może to się zakończyć błędem OutOfMemory i to nie koniecznie w tym miejscu.

Z ciekawych trików, to Tomek jeszcze korzystał z Ctrl + C do zaznaczania całej linii w IntelliJ-u. Dobre na prezentacje. I jeszcze korzystał z Apache Bench. Jest to odpowiednik JMeter’a, ale działa w linii komand i jest dołączony (i był stworzony) do serwera Apache httpd. Przykładowy kod z prezentacji jest dostępny na githubie: nurkiewicz/hystrix-demo, a prezentację (i to po polsku) można obejrzeć na kanale Warszawskiego JUGa: WJUG #161.

Następnie udałem się na prezentację programisty z Elastic’a, David Pilato na temat: "Make sense of your (BIG) data!". Akcent francuski i żarty z których siał się tylko prowadzący były straszne, ale prelegent nie okazał się kompletnym francuskim ignorantem. Na koniec nawet próbował powiedzieć coś po polsku.

Na początku prezentacji było o tym jak dużo danych generujemy każdego dnia.



Następnie prelegent pokazał, jak można budować przykładowe zapytania w Elastic’u (dawniej ElasticSearch) i skupił się na aggregacjach. Pokazał jak wygląda Marvel, który służy do monitorowania instancji Elastic’a. Dla instancji produkcyjnych narzędzie jest płatne, dla pozostałych serwerów (typu test, QA, stage itp) darmowe. Z ciekawych funkcjonalności, to można sobie odtworzyć, co się działo w shardami, gdy do klastra dołączały się kolejne instancje węzłów.

Dalej prelegent pokazał jak za pomocą Kibany można w łatwy sposób wizualizować wszelakie dane jakie mamy zapisane w indexie Elastica.



I to chyba tyle z prezentacji. Całkiem dobra, ale dla osoby która miała już kontakt z tymi narzędziami nie była bardzo odkrywcza. Miałem jednak za to okazję zadać parę pytań i tak rekomendowaną biblioteką javową do Elastica jest jej oficjalna wersja która to może działać jako węzeł w klastrze, wykorzystywać warstwę transportową między węzłami (udostępnianą standardowo na porcie 9300) i pytać bezpośrednio do miejsca gdzie znajdują się poszukiwane dane.

Kolejna prezentacja, na którą poszedłem, była o "Flavors of Concurrency in Java" prowadzona przez Olega Šelajeva. Na początku było dużo wstępu i dopiero po 20 minutach pojawił się pierwszy kod, na którym omawiał wątki w oldschool’owym wydaniu. Nie dałem rady i wyszedłem. Byłem jeszcze chwilę na Reviewing Architectures, Nathaniela Schutta, ale nie byłem w odpowiednim kontekście i nie dałem rady.

Kolejna prezentacja była najbardziej futurystyczna z całej konferencji a mianowicie: "WebVR - democracy in Virtual Reality", Marcina Lichwały. Był jeszcze jakiś drugi prowadzący, ale nie był wymieniony z nazwiska. Obaj prelegenci pracują w firmie Unit9, która dostarcza rozwiązania wirtualnej rzeczywistości. Organizowali również pierwszy w Polsce festiwal i konkurs wirtualnej rzeczywistości w Łodzi.

Chłopaki opowiadali, jakie zastosowania ma wirtualna rzeczywistość. I jest to nie tylko rozrywka, kampanie reklamowe, ale i edukacji i medycyna (np.: redukcja bólu youtu.be/jNIqyyypojg).

Nie pamiętam jakimi okularami się zajmują chłopaki, ale trend jest taki, aby całość obrazu była generowana przez przeglądarki internetowe. Dzięki temu staje się to przenośne. W tym momencie jedynie MozVR (z Mozilli) i Chromium wspierają generowanie doznań wirtualnej rzeczywistości. Ostatecznie zawsze zostaje nam wersja dla ubogich w postaci Cardboard.

W ramach prezentacji miałem możliwość (podobnie jak inni chętni) przetestować okulary. Obraz całkiem dobry, widać było jedynie małe punkty, na które składał się obraz. Ale to bardzo dobry kierunek i powoli zbliżamy się do już całkiem porządnego sprzętu. Jedynie niektóre osoby z chorobą lokomocyjną nie będą w stanie do końca korzystać z tych wynalazków, bo patrząc w bok i do góry, ciągle niby biegnąc, może zrobić się niedobrze.

W kolejnym bloku nie było możliwości wyboru, bo był zaplanowany tylko jeden wykład: "Get Past the Syntax, The Real Scare is in the Semantics", prowadzony przez Venkata Subramaniama. Oczywiście była pełna sala.


Zaczęło się od tego, że ludzie rożnie postrzegają te same rzeczy. Programiści dlatego nie lubią nowej składni kodu, dlatego wiele języków programowania jest do siebie podobnych C# jest jak Java, a ta jak C++, a C++ jak C...

Venkat chciał nam przez to uświadomić, że nie powinniśmy zwracać uwagi na składnię kodu, a na jego semantykę. No i nasza strefa konfortu powoduje, że się zawsze doszukujemy w nowej składni, tego co już znamy. Jak dla mnie nic więcej konkretnego się nie dowiedziałem na tej prezentacji.

Na koniec drugiego dnia poszedłem jeszcze na "Painfree Object-Document Mapping for MongoDB" prowadzoną przez Philippa Krenna. Prelegent opowiadał o rozwiązaniu Morphia, które pozwala na mapowanie obiektów Javowych na dokumenty MongoDB. Całość bardzo wygląda jak implementacja JPA (adnotacje na klasach i polach).

Dalej było o sposobach wykorzystania tego narzędzia, przykłady i dobre praktyki. Na koniec było jeszcze krótko o spring-data-mongodb. Niby robi to samo co Morphia, ale twórcom się nie spodobała ta implementacja i w zamierzchłych czasach miała sporo błędów, więc twórcy MongoDb wzięli się za własną implementację. Ciekawie też brzmi Fongo, który dostarcza implementację in memory dla MongoDb. I ostatnie narzędzie: Critter, które daje nam coś ala Hibernate’owe Criteria API dla Morphi. To już zostawię bez komentarza.

Devoxx w Polsce - wrażenia z pierwszej edycji

Pierwszy Devoxx w Polsce (dawniej 33 Degree) odbył się w dniach 22-24 czerwca 2015, w nowo wybudowanym centrum kongresowym w Krakowie, mogącym pomieścić ponad 2000 ludzi. I to było idealne miejsce na konferencję - nowy, ładny i przestronny budynek z ogromną salą z balkonami na trzech poziomach, gdzie mogli zmieścić się wszyscy uczestnicy.



Konferencję otworzył standardowo Grzesiek Duda. W trakcie rozpoczęcia miała być krótka prezentacja Vaadin Designer’a, ale niestety był problem z połączeniem laptopa do rzutnika. Z racji ograniczonego czasu, trzeba było uwierzyć na słowo, że narzędzie jest fajne.

Pierwszy keynote poprowadził Hadi Hariri: "The Silver Bullet Syndrome". Opowiadał o tym, w jaki sposób szukamy rozwiązania starych problemów, czyli o wynajdowaniu koła na nowo, aby było bardziej okrągłe. I tak z make’a przerzuciliśmy się na ant’a, później maven’a i gradle’a… Poszukujemy idealnego rozwiązania, najlepiej naszych wszystkich problemów, czyli tytułowego silver bullet. Powoduje to następujący "cykl przetrwania w IT": nowa technologia -> wciśnięcie jej użytkownikom -> organizowanie szkoleń -> użycie na produkcji -> jak coś nie działa, to telefon do konsultanta i tak w kółko od nowa.

Hadi wyśmiewał jeszcze inne potworki jakie tworzymy, np.: AbstractSingletonProxyFactoryBean, FizzBuzzEnterpriseEdition i JavaScript:


Tak naprawdę, to powinniśmy zadać sobie pytanie, jaką to nam przyniosło wartość biznesową? Jak usprawniliśmy czyjąś pracę lub życie, a nie wymyślamy kolejne frameworki. Nasze CV powinno więc wyglądać raczej tak:


(Sorry za kiepską jakość...) 

Ostatecznie stanęło na tym, że jednak musimy ciągle uczyć się nowych rzeczy. Nagranie z prezentacji (ale nie z Devoxxa) jest dostępne na Vimeo: https://vimeo.com/130202574, a starszą wersję slajdów znalazłem tutaj: http://schd.ws/hosted_files/buildstuff14/a5/wcf.pdf

Pierwszą prezentacją po keynote na którą poszedłem było: "Principles Of Microservices", Sama Newmana. Było o The Twelve Factors, czyli o zebranych zasadach z doświadczeń, jak pisać aplikacje, które są deploy'owane w dużych ilościach, aby było łatwiej nimi zarządzać i utrzymywać.

Z rozwiązań, które warto zapisać (i może kiedyś im się w razie konieczności lub nadmiaru wolnego czasu przyjrzeć) to:
  • Pact - biblioteka do testowania i definiowania kontraktów pomiędzy mikroserwisami (czyli: Consumer driven contracts) 
  • ZooKeeper - do ogarnięcia utrzymania, konfiguracji itp. wielu rozproszonych systemów 
  • etcd - rozproszona konfiguracja dla wielu serwisów 
  • Consul - to samo (albo prawie to samo co dwa powyższe)
Sam na prezentacji przedstawił 8 zasad mikroserwisów i je wyjaśnił:
  • Modelled Around Business Domain 
  • Culture Of Automation 
  • Hide Implementation Details 
  • Decentralise All The Things 
  • Deploy Independently 
  • Consumer First 
  • Isolate Failure 
  • Highly Observable 
Najbardziej mi utkwiło w pamięci, że trzeba mieć jedną osobę, która patrzy na aplikację i co się w niej dzieje, korzysta z kibany i stosując correlation id, śledzi, co dokładnie się dzieje z danym request’em i gdzie najwięcej czasu spędza. A tutaj jakaś starsza wersja slajdów z XP Days Ukraine

Następnie pospieszyłem na "OnConnectionLost: The life of an offline web application", prowadzoną przez młodych pracowników z ThoughtWorks: Stefanie Grewenig i Johannesa Thönesa. Prelegenci tworzyli aplikacje, które musiały działać w przeglądarce i również off-line. Przykładowo aplikacja na tableta dla pracownika supermarketu, który sprawdza dostępność produktów na półkach i zamawia co trzeba. Dawniej korzystano z kartek do tego celu, ale można pójść z duchem czasu i zrobić to lepiej. Połączenie z internetem bardzo łatwo zgubić na sklepie, a zamówienie trzeba złożyć, więc warto w takim przypadku, aby aplikacja działała offline.

I tak za pomocą html5 application cache możemy zdefiniować, które zasoby powinny zostać zapamiętane po stronie przeglądarki, do działania w trybie offline. Mamy również możliwość, wymuszenia aktualizacji tych zasobów, gdy pojawią się ich nowsze wersje na serwerze. Najważniejsze, aby manifest, w którym definiujemy co ma być cachowane, sam nie został zcache'owany. W tym celu warto ustawić w nagłówkach no chache. Alternatywą dla application cache jest Service Workers, ale póki co jest to googlowy wynalazek, zaimplementowany tylko w Chromie i FF.

Jeśli chodzi o przechowywanie wprowadzonych danych offline, to mamy Web Storage i IndexedDB. W pierwszym rozwiązaniu jest sporo problemów (między innymi jak użytkownik chce otworzyć wiele zakładek naszej aplikacji) i prelegenci zalecali drugie rozwiązanie. Oferuje ono transakcyjność pomiędzy wieloma zakładkami. Niestety obecnie jest ono wspierane tylko w Chrome.

Ostatnim problemem, jaki jest do rozwiązania przy aplikacjach działających w przeglądarkach off-line, to synchronizacja danych. Warto korzystać od samego początku ze wzorca Command, czyli wszelkie zmiany, jakie wykonuje użytkownik wrzucamy do lokalnej kolejki i jak stanie się online, to je dopiero przetwarzamy na serwerze. Ewentualnie, aby nie mieć jakiś problemów z łączeniem wyników, to możemy zapisać snapshot’a aktualnego wyniku. Nie warto się spalać nad rozwiązywaniem konfliktów (o ile nie piszemy gita przez przeglądarkę), a w najgorszym wypadku możemy wyświetlić dwie wersje dokumentu i użytkownik skopiuje sobie to, co mu brakuje do nowszej wersji.

Z dalszych rad - danych wrażliwych nie powinniśmy zapisywać w przeglądarce, bo są one dostępne jawnym tekstem, a sama enkrypcja po stronie JavaScriptu może nie być najlepsza. I jeżeli decydujemy się na budowanie aplikacji działającej bez połączenia z internetami, to w pierwszej kolejności powinniśmy zadbać o działanie bez serwera i wprowadzenie wzorca Command zamiast requestów. W innym wypadku bardzo zemści się to na nas w późniejszym czasie. Slajdy można obejrzeć tutaj: http://www.slideshare.net/jthoenes/onconnectionlost-the-life-of-an-offline-web-application-craft-conf-2015

Kolejne wystąpienie pt.: "Co było pierwsze: kod czy architektura?" 
Sławka Sobótki rozpoczęło się od poziomów cywilizacji wg. Skali Kardaszewa, aby zachęcić słuchaczy do aktywnego słuchania. I to się z pewnością Sławkowi udało. Prelegent „zajrzał” na chwilę do umysłu programisty i architekta. Ten pierwszy w przypadku problemu wyboru rozwiązania A i B próbuje wybrać lepsze. Architekt w takim przypadku robi krok wstecz, patrzy z dalszej perspektywy i zastanawia się, czemu w ogóle mamy wybór i czy rzeczywiście musimy wybierać.

Następnie przyglądaliśmy się różnym rodzajom obrazków, jakie malują architekci, aby przejść do tego, jak je malować. Dobry podział tych obrazków jest zebrany w książce Software Architecture for Developers, a mianowicie C4:
  • Context - czyli architektura korporacyjna. Pokazujemy na niej osoby korzystające z systemu, inne zależne systemy i instytucje. Odbiorcami taki obrazów są klienci i zarząd. 
  • Containers - architektura wdrożenia. Tutaj mamy wszelkie techniczne zależne elementy, jak bazy danych, kolejki komunikatów, repozytoria, bazy danych, kontenery, klienci (w sensie przeglądarka, aplikacja na telefon). Jest to przydatny diagram dla administratorów, utrzymaniowców i DevOpsów. 
  • Components - czyli architektura systemu. Obrazek ten pokazuje komponenty / moduły (jakkolwiek sobie zdefiniujemy czym to dokładnie jest). Jest to przydatne dla programistów, dając obraz z lotu ptaka na aplikację 
  • Classes - architektura aplikacji, pokazująca wewnętrzną strukturę dokumentu, bardziej wzorce niż konkretne klasy 
Jak prezentacja Sławka będzie dostępna on-line to umieszczę tutaj odpowiednie zdjęcia.

Z praktycznych rzeczy to zapamiętałem (albo raczej sobie zapisałem) jeszcze parę rad. Jeśli korzystamy z RESTa, to powinniśmy mieć teoretycznie tylko nazwy zasobów w adresach URL. Jednak praktycznie, to warto rozważyć, co częściej się nam zmienia: zasoby czy procesy? Gdy zasoby są w systemie stabilne, to robimy RESTfull, a jak procesy to do RESTa wrzucamy czasowniki.

Connascence oznacza, że jak coś zmieniamy w jednym miejscu w systemie, to musimy to również zmienić w drugim miejscu. Przykładowo mikroserwisy nie powinny korzystać z bibliotek współdzielonych. I dodatkowo powinniśmy rozdzielać pojęcia w systemie, aby lepiej nam się rozdzielało komponenty systemu.

W ten sposób zostało przedstawione, jak tworzenie dużej architektury od początku prowadzi do kodu. Następnie Sławek spróbował pokazać podejście odwrotne, tzn. jak z naszych mikrodecyzji na poziomie kodu wyłania się nasza architektura.

Podsumowując, nie wiadomo który framework jest lepszy, ani który język programowania. Programowanie to dyscyplina polegająca na zmyślaniu - faktura to funkcja, albo faktura to obiekt… A tak to wszyscy powinniśmy się nauczyć assemblera, aby wiedzieć jak działa krzem, aby przestać toczyć wojny religijne, o to który język programowania jest lepszy...

Następnie byłem chwilę na wykładzie "Using JavaScript/HTML5 Rich Clients with Java EE 7", Reza Rahmana, ale musiałem wyjść. W sumie dobrze, bo z późniejszych opinii było nieciekawie, głównie historia, jak to przez lata próbowano ożenić frontend z backendem.

Poszedłem więc na: "Technical leadership – from an expert to a leader", Mariusza Sieraczkiewicza. Nie widziałem początku, ale prelegent mówił o tym, że dobry leader powinien przygotować takie środowisko, że każdy będzie chciał w nim pracować. Następnie było o rzeczach, których każdy powinien spróbować: więcej myśleć niż tylko reagować, robić sobie codzienną retrospektywę, zrozumieć, a nie oceniać - coaching. Aby móc lepiej motywować ludzi, to powinniśmy ich lepiej poznać, jakie są ich potrzeby i zbierać feedback, a w Agile jest pełno narzędzi związanych z feedbackiem.

Na koniec Mariusz ogłosił, że pisze książkę na ten temat i szuka chętnych chcących podzielić się z nim swoimi doświadczeniami. Kontakt można znaleźć na jego blogu: http://msieraczkiewicz.blogspot.com/

Przedostatnią prezentacją pierwszego dnia konferencji była: "Caching reboot: javax.cache & Ehcache 3" prowadzona przez Louis Jacomet. Początkowo prowadzący omówił, co ile czasu zabiera, jak przeskalujemy czas pewnych operacji komputera na bardziej ludzkie, odczuwalne i zrozumiałe jednostki. Miało to na celu uświadomienie sobie, że naprawdę potrzebujemy cache w aplikacji. Następnie było o zmianach w EhCache w wersji 3 w stosunku do wersji 2. Mianowicie Java doczekała się ustandaryzowanego Caching API ujawniającego się pod numerem JSR-107. I nowa wersja EhCache’a implementuje tą specyfikację, przez co wsteczna kompatybilność została złamana.

W standardzie JSR-107 nie ma zdefiniowanych ustawień dla Capacity control, ani Locking Options. Dalej było demo, jak łatwo można korzystać z EhCache. Jest możliwość modyfikowania ustawień w trakcie działania aplikacji. Problemem jest jedynie odpowiednia konfiguracja, a mianowicie dobranie odpowiednich wartości. Jedyne co prowadzący mógł polecić, to pójście na produkcję i obserwowanie zachowania. Największym wyzwaniem przy implementacji EhCache’a jest założenie, że błąd w cache’u nie powinien skutkować wyjątkiem do użytkownika (aplikacji). Prezentacja całkiem fajna.

Na końcu dnia poszedłem na prezentację Adama Warskiego pt. "Supler: complex web forms, not so complex". Adam jak zwykle w wielkim stylu przedstawił rozwiązanie, które stworzył wraz z zespołem w SoftwareMill’u. Supler jest narzędziem, które spaja frontend w JavaScripcie z backendem Scalowym. Pomaga generować formularze (nawet zagnieżdżone i skomplikowane), a jednocześnie nie jest związany z żadnym frameworkiem. Było przez cały czas live demo i niewiele slajdów. Trochę mi umknęło jak ożenić to rozwiązanie z jakimś frejmworkiem JS. Gdybym musiał tworzyć formularze w Scali, to z pewnością bym pozytywnie rozważył użycie Suplera w projekcie.

Podsumowując pierwszy dzień konferencji, to trzymał poziom, ale czegoś mi zabrakło. Początkowy wykład był mocno motywujący i dający do myślenia, Sławek Sobótka bardzo fajnie opowiedział o malowaniu architektury, ale to było bardzo miękkie. O EhCache i Suplerze była całkiem niezła, ale tego drugiego raczej nie będę mógł zastosować praktycznie w najbliższym czasie. Zabrakło mi trochę jakiejś mocno technicznej prezentacji na temat czegoś nowego, świeżego, lub wywracającego myślenie do góry nogami.