Technologie

7 kwietnia 2017

W tym roku po raz kolejny mieliśmy przyjemność bycia jednym ze sponsorów konferencji ScalaSphere. Przeczytajcie naszą relację!

Tegoroczna konferencja ScalaSphere była poświęcona szeroko rozumianym zagadnieniom wspierającym pracę osób programujących w języku Scala takim jak kompilatory, IDE, narzędzie do refaktoringu, rozwiązania wykorzystujące koncepcję metaprogramowania itp.

ReactSphere był natomiast cyklem prezentacji związanych z paradygmatem programowania reaktywnego. Prelekcje wykraczały poza kodowanie w Scali i dotyczyły również rozwiązań w Javie czy też typowo frontendowych w JavaScript.

Programowanie reaktywne staje się z roku na rok coraz bardziej popularne, a wynika to z faktycznych potrzeb skalowania systemów informatycznych, przetwarzania dużych wolumenów danych, popularyzacji IoT i serwisów, dla których niezawodność i nawet niewielkie opóźnienia grają kluczową rolę. Jednocześnie w różnych językach programowania powstały dojrzałe rozwiązania wspierające te wymagania – oparte na strumieniach oraz asynchronicznej wymianie komunikatów.

ScalaSphere – dzień pierwszy

Pierwsza prezentacja z cyklu ReactSphere (Building multiplayer game using streams) w świetny sposób wprowadzała słuchaczy w świat programowania reaktywnego. Michał Płachta w bardzo uporządkowany i ciekawy sposób pokazał, jak krok po kroku zbudować aplikację do gry w węża, znaną z najbardziej kultowych Nokii, w oparciu o streaming. Programowanie wykorzystujące koncepcję streamingu najczęściej kojarzy się z przetwarzaniem danych. Tymczasem Michał pokazał, jak w elegancki sposób można modelować w postaci strumieni interakcję z użytkownikiem, mijający czas, ruch postaci w grze i komunikację z serwerem.

W ramach omawianego przykładu poznaliśmy sześć podstawowych operacji: map, scan, filter, merge, sampledBy oraz slidingWindow. Te działania, zaimplementowane w ramach biblioteki Beacon.js,  wystarczyły do tego, aby utworzyć zestaw strumieni stanowiący logikę części frontendowej gry. Dalszym rozwinięciem omawianego przykładu było wprowadzenie obsługi wielu jednoczesnych graczy. W tym celu została dodana część serwerowa oparta na Akka HTTP oraz Akka Streams. Odpowiadała ona za wymianę informacji o pozycjach węży, owoców stanowiących ich pożywienie oraz zliczanie zdobywanych przez graczy punktów. Komunikacja między częścią serwerową a frontendem odbywała się z wykorzystaniem WebSocketów.

Prezentacja Michała Płachty stanowiła doskonałe i praktyczne wprowadzenie do programowania reaktywnego. Dla osób już stosujących te rozwiązania była okazją do uporządkowania wiedzy, inspiracją do tego, w jaki sposób można modelować  bardzo różne zjawiska za pomocą strumieni.

Cykl ScalaSphere rozpoczął się od prezentacji znanego z poprzedniej edycji prelegenta: Jon Pretty pokazał bibliotekę Contextual oraz jej możliwe zastosowania. Omawiana biblioteka pozwala na pisanie własnych interpolatorów (strings interpolators), oferując możliwość sprawdzania ich poprawności w czasie kompilacji, ale bez konieczności pisania własnych makr.  Pomysł zastosowany w tym rozwiązaniu polega na dostarczeniu na tyle ogólnego makra, że wystarcza ono do zrozumienia deklaracji interpolatora korzystającego z API Contextual i jego sprawdzenie podczas kompilacji. Bardzo dobrym przykładem tego, jak można wykorzystać Contextual, jest biblioteka Xylophone do obsługi XML.

Kolejna prelekcja pokazywała, że program napisany w Scali nie musi wykonywać się tylko na maszynie wirtualnej Javy. Nepomuk Seiler w prezentacji zatytułowanej „Choose your target – JVM, Node, Native” pokazał, w jaki sposób używać sbt oraz wtyczki sbt-native-packager do budowania aplikacji, które mogą być uruchamiane tradycyjnie na JVM, ale nie tylko.

Stosując scala.js oraz ScalaJSPlugin i archetyp NodeAppPackaging, możemy przygotować aplikację dla Node.js. Z kolei przy użyciu ScalaNativePlugin oraz NativeAppPackaging budujemy aplikację natywną. Części współdzielone pomiędzy poszczególnymi rodzajami wyjściowego programu budujemy za pomocą sbt-crossproject. Przykładowa konfiguracja sbt znajduje się w repozytorium Nepomuka.

W ramach ReactSphere kolejną bardzo ciekawą prezentacją była „Circuit Breaker monitoring at scale”.  Wzorzec circuir breaker stanowi zabezpieczenie przed kaskadowymi błędami skutkującymi degradacją działania serwisu w systemach rozproszonych.

Działanie circuit breaker opiera się na opakowaniu wywołań zdalnych (przy których łatwo o błędy komunikacji, timeouty, a nawet brak jakichkolwiek odpowiedzi) w byt posiadający trzy możliwe stany: Closed, Open oraz Half Open. W stanie Closed wywołania realizowane są standardowo, w stanie Open każde skutkuje natychmiastowym błędem, zaś w stanie Half Open dochodzi do ponownej próby zwykłego zrealizowania wywołania, co – w przypadku powodzenia – skutkuje przejściem do stanu Closed.

Maciej Ciołek w swojej prezentacji zwrócił uwagę na to, jak istotne jest stosowanie wzorca circuit breaker w przypadku rozwiązań opartych na koncepcji mikroserwisów. Ważna jest również możliwość monitorowania działania integracji korzystających ze wspomnianego wzorca. Ciekawym przykładem tego typu rozwiązania jest Netflix Hystrix i monitorowanie jego działania z wykorzystaniem narzędzi Netflixa. Prelegent pokazał natomiast implementację korzystającą z Akka Streams – metryki związane z wywołaniami za pośrednictwem circuit breakera są dostępne w postaci strumienia. W prezentowanym przykładzie strumień ten został udostępniony poprzez WebSockety do aplikacji pokazującej w przeglądarce wykresy ilustrujące w czasie rzeczywistym zbierane metryki. Wykorzystanie Akka Streams otwiera równocześnie inne możliwości udostępniania zbieranych metryk – zapis do Kafki z wykorzystaniem reactive-kafka, wysłanie ich z użyciem protokołu AMQP (np. do kolejki RabbitMQ)  jako Server Sent Events lub w inny sposób – np. przy użyciu biblioteki Alpakka.

Osoby zainteresowane uczeniem maszynowym z pewnością z zaciekawieniem wysłuchały prelekcji Jana Pustelnika i Kamila Owczarka „Reactive Machine Learning with Akka Streams”. Temat uczenia maszynowego kojarzy się najczęściej ze Sparkiem w świecie Scali/JVM i bardzo szerokim wachlarzem rozwiązań w Pythonie. Tymczasem Jan i Kamil pokazali, w jaki sposób implementować algorytmy online machine learning  w oparciu o Akka Streams. Prezentacja była bardzo ciekawa z dwóch powodów:

Po pierwsze, pokazywała, jak mocnym i elastycznym narzędziem jest biblioteka Akka Streams, której API na pierwszy rzut oka może wydawać się skomplikowane, ale im więcej się z niej korzysta, tym bardziej okazuje się jak bardzo przemyślane i spójne jest to rozwiązanie. Korzystając z Akka Streams otrzymujemy lekką i elastyczną implementację strumieniowego przetwarzania.

Po drugie, mogliśmy zapoznać się z kilkoma wybranymi algorytmami online, czyli takimi, które nie znają od początku wszystkich danych wejściowych, lecz otrzymują je partiami.

Wszystkie przykłady algorytmów (takie jak znajdowanie maksymalnej podtablicy – algorytm Kadane, filtr Blooma, inkrementalne uczenie drzewa decyzyjnego w oparciu o algorytm Hoefding Tree pozwalający dokonywać klasyfikacji w strumieniu danych, rekurencyjna metoda najmniejszych kwadratów oraz algorytm śledzenia lidera) zostały zilustrowane kodem opartym na Akka Streams.

Tymczasem w ramach ScalaSphere interesująca była prelekcja dotycząca kompilatora Hydra (Triplequote Hydra Compiler: a bigger hammer). Wg twórców tego rozwiązania – Iuliana Dragosa i Mirco Dotty – dotychczasowe testy wykazują kilkukrotne przyspieszenie kompilacji programów w Scali. W prezentacji omówiono również to, jak poszczególne elementy języka wpływają na czas kompilacji. Dobre zrozumienie tych zagadnień pozwala pisać szybciej budujące się programy.

Równie ciekawą była wygłoszona przez Ólafura Pálla Geirssona prezentacja „Refactoring with scalafix and scala.meta”. Olafur pokazał bibliotekę do refaktoringu scalafix. Bodźcem do powstania tego rozwiązania było zautomatyzowanie przyszłej migracji kodu ze Scali do Dotty, kolejnej generacji kompilatora Scali. Już teraz można używać scalafix do automatyzacji refaktoringu. Ciekawym pomysłem byłoby dostarczanie poprawek w postaci odpowiedniego kodu opartego na scalafix, zamiast ograniczania się do zaznaczania elementów API jako deprecated.

Ostatnią prezentacją w ramach ReactSphere była „Introduction to observables and reactive programming in JavaScript – explained by example”. Prelekcja ta w całości dotyczyła rozwiązań reaktywnych we frontendzie. Marcin Baraniecki wymienił trzy popularne biblioteki dla JavaScript umożliwiające programowanie reaktywne: RxJS, Bacon i Kefir. Następnie przedstawił kilka ciekawych i praktycznych przykładów wykorzystujących we frontendzie koncepcję strumieni i programowania reaktywnego.

Dzień pierwszy zakończył się spotkaniem w Starej Zajezdni – była to okazja do swobodnej rozmowy nie tylko na tematy techniczne i zawodowe.

ScalaSphere – dzień drugi

 

Kolejny dzień składał się już z jednej ścieżki prezentacji – wchodzących w skład konferencji ScalaSphere.

Wśród prezentacji pokazanych tego dnia na szczególną uwagę zasługiwała prezentacja „Scala.meta support in IntelliJ IDEA” pokazująca wsparcie dla metaprogramowania w Scali, które oferuje Intellij IDEA oraz prezentacja „The state of sbt 1.0 and sbt server”, w trakcie której Eugene Yokota i Dale Wijnand opowiedzieli o rozwoju sbt. Intellij Idea jest postrzegana bardzo często jako najlepsze IDE do Scali, natomiast towarzyszący jej plugin do Scali z każdym wydaniem zyskuje coraz to ciekawsze funkcjonalności.

Prezentacja dotycząca sbt pozwalała natomiast zorientować się, w jakim miejscu znajduje się rozwój tego narzędzia oraz jakie wyzwania stoją przed wersją 1.0 – jak zwykle w takich przypadkach problematyczna jest kompatybilność z poprzednimi wersjami, w szczególności w odniesieniu do już istniejących pluginów.

Kolejna ciekawa prelekcja zatytułowana „Using Chaos Engineering to Build Resilient Distributed Applications” została wygłoszona przez Carla Pulley. „Inżynieria Chaosu” to technika testowania rozwiązań rozproszonych. Jej celem jest przekonanie się, czy testowany system jest w stanie poradzić sobie z problemami, jakie niechybnie mogą zaistnieć w produkcyjnym środowisku. Bywa i tak, że wspomniane testy wykonuje się w samym środowisku produkcyjnym poprzez świadome wyzwalanie sytuacji błędnych i obserwowanie, jak system radzi sobie w zaistniałej sytuacji. Szczególnie mocno takie podejście jest promowane przez Netflixa.

Przeprowadzanie takich testów nie jest proste, ale Carl Pulley podsunął rozwiązanie: docker-compose-testkit – bibliotekę, która ma ułatwić sprawdzanie odporności rozproszonych systemów na możliwe turbulencje w działaniu.

Typowy scenariusz testów, zgodny z koncepcją inżynierii chaosu, składa się z dwóch części:

– zdefiniowania obrazu działającego systemu w postaci zestawu określonych metryk systemowych i biznesowych (co pozwala określić, co jest poprawnym a co niepoprawnym działaniem)

– losowym wstrzykiwaniu błędów – np. poprzez unicestwianie kontenerów dockerowych, ich pauzowanie, wywoływanie problemów sieciowych itp.

Jako przykład ilustrujący działanie swojej biblioteki Carl pokazał rozwiązanie oparte na Akka Cluster składające się z kilku węzłów uruchomionych w ramach kontenerów dockerowych. W trakcie eksperymentu badano rozłączanie sieci oraz pauzowanie kontenerów i sposób reagowania systemu na zaistniałe problemy.

Na koniec należy podkreślić, że organizacja całego wydarzenia była na najwyższym, profesjonalnym poziomie – wszystko było zrealizowane doskonale, a na dodatek w przyjaznej, luźnej atmosferze.

Co nas czeka w przyszłym roku na kolejnej edycji konferencji? Organizatorzy zapowiedzieli, że równocześnie odbywać się będą trzy ścieżki – oprócz ScalaSphere i ReactSphere, planowany jest także ViewSphere – cykl poświęcony modnym tematom Big/Fast Data.


Komentarze (0)

Dodaj komentarz

Twój adres email nie zostanie opublikowany.