Devoxx 2017

Devoxx 2017   

Tegoroczny Devoxx w Krakowie trwał  od 21 do 23 czerwca  i odbył się w centrum kongresowym ICE, które według organizatorów może pomieścić ponad 2 tysiące osób, jest to zatem jedna z największych o ile nie największa konferencja dla programistów w naszym kraju. Dzięki uprzejmości JUG Łódź miałem okazję wziąć w niej udział za co jestem niezmiernie wdzięczny.

Przejdźmy zatem do opisu samych prelekcji. Zaraz po otwarciu na scenę wyszedł Venkat Subramanian, który mówił  o potrzebie coraz szybszego wytwarzania rozwiązań programistycznych, o znienawidzonym przez wszystkich programistów pytaniu “Are you done yet ? “ i o tym, jak bez odpowiedniego podejścia doprowadzić projekt do fiaska. Prezentacja pokazała również dlaczego programiści powinni pisać testy i dbać o quality swojego kodu, tak by nie utknąć w JDD, czyli Jesus Driven Development. Kolejną interesująca prezentacja z dnia pierwszego była autorstwa Douglasa Howkinsa zaś jej tytuł to “Concurrency concepts in Java” , zatem coś  czym słyszeliśmy już wielokrotnie, prezentacja ta była jednak nieco inna, autor nie skupiał się na konkretnych przykładach programistycznych, ale zamiast tego próbował pokazać jak to wygląda “od środka”, czyli w jaki sposób kompilator może reorganizować kod i jaki to może mieć wpływ chociażby na widoczność zmiennych między wątkami. Następnie trafiłem prosto na wykład o Clean Code prowadzony przez Victora Rentea, poza konceptami szeroko poruszanymi we wszystkich ksiażkach na temat clean code’u, a więc odpowiednim nazywaniu metod, rozważaniami ile linijek może mieę nasza klasa a ile powinna miec metoda, autor mówił również o Javie 8 i o tym jak używac Lambd i Streamow, by nie doprowadzić do sytuacji w której nasz kod staje się zupełnie nieczytelny - każdy kto pracował z Java 8 wie, że o to nietrudno. Następnie rozpoczęła się sesja  Meet & Greet w trakcie której kilku prelegentów prowadziło dyskusje, jedną z nich była dyskusja na temat popularnego ostatnio Kotlina i jego zastosowań w firmie Allegro, z dyskusji można się było z niej dowiedzieć między innymi, dlaczego używają oni Kotlina “na produkcji” w czym jest lepszy od Javy i dlaczego w ich przypadku zdeklasował Scale.

Dzień drugi to między innymi kolejny temat “na topie” a więc nowa Java, Simon Ritter i jego prezentacja “55 new features in JDK 9” jak sama nazwa wskazuje skupiała się na tym co nowego zobaczymy w nowej wersji języka. Poza omawianymi szeroko Jigsawem, czyli modularnością i długo oczekiwanym jshellem, Simon opowiedział również o usprawnieniach związanych ze strumieniami i wielowątkowością, prywatnymi metodami w interfejsach, czy zmianach związanych z zachowaniem struktury kodu w czasie kompilacji. Warto również wspomnieć o prezentacji Sama Newmana, który opowiedział o bezpieczeństwie w mikroserwisach, o tym w czym mikroserwisy są lepsze od monolitu jeśli chodzi o kwestie bezpieczeństwa i dlaczego, ale żeby nie było tak kolorowo, była również mowa o ich wadach w szczególności problemach z maintenance’ m  i wykrywaniem ataków. Jeżeli mielibyśmy zapamiętać z prezentacji tylko jedną rzecz, niech to będzie fakt, że najlepszą metodą reakcji na atak jest usunięcie wszystkiego i przywrócenie backupów z momentu co do którego jesteśmy pewni, że system był “czysty”. Kolejna interesująca prezentacja to znowu Doug Hawkins i  “Java Performance Puzzlers”. Jeszcze raz była mowa o JVM i jego wewnętrznym działaniu, o tym jak architektura CPU wpływa na optymalizację JVM, i dlaczego ta architektura nie zawsze działa na naszą korzyść. Była mowa o tym, jaka jest maksymalna długość bytecode’ u która JVM będzie próbował optymalizować. Dzień drugi, podobnie jak pierwszy zakończył się sesją Meet & Greet przy piwku.

Dzień trzeci to talki głównie o architekturze i mikroserwisach, pierwszy z nich “Resilient Architecture” prowadzona przez Matta Stine, skupiła się na pokazaniu różnic między architekturą, którą tworzymy dziś a tą która powstawała dziesięć lat temu. Największą różnicą jest zasada “Embrace Failure”, której trzymamy się dziś. Nie tworzymy więc aplikacji, która jest niezawodna, ale zakładamy, że prędzej czy później dojdzie do jakichś błędów, które spowodują niedostępność części systemu i staramy się na to przygotować,  tak by zminimalizować straty. Pewnym rozwiązaniem tego problemu wydają się mikroserwisy. Które nie rozwiązują jednak wszystkich problemów związanych z resiliency. Na prezentacji była mowa o kilku technologiach, które mogą pomóc w budowaniu tego typu aplikacji. Są to między innymi  Hystrix czy Chaos Monkey. Dalej o architekturze mówił Jakub Kubryński w prezentacji “Microservices - the naked truth of maintainability”. Ta prezentacja była inna niż większość prezentacji o mikroserwisach, zazwyczaj słyszymy jakie to wielkie zyski przynosi przeniesienie się z monolitu na mikroserwisy, mało zaś mówi się, że utrzymanie architektury mikroserwisowej jest zdecydowanie trudniejsze i dużo bardziej wymagające. Testy integracyjne mikroserwisów są zazwyczaj zarówno trudne, drogie i czasochłonne. Jakub starał się pokazać, że z odpowiednim podejściem, możemy ograniczyć koszty i ilość testów integracyjnych, skupiając się na unitowych i pozwalając użytkownikom zweryfikować pełną funkcjonalność.Ostatnia prezentacja miała nieco dziwny i intrygujący tytuł “PsyPhilProg”  i była prowadzona przez Teda Newarda, który mówił o podobieństwach między programistami, psychologami i filozofami, o tym, że przedstawiciele tych trzech grup muszą się zmagać z wielopoziomowymi abstrakcjami, które są niespotykane nigdzie indziej. Jedną najcenniejszych rad wynikających z tej prezentacji była ta, że programiści w pracy powinni zadawać filozoficzne pytania jak “po co?”, “dlaczego?”, gdyż mogą one zmienić nasze postrzeganie problemu z którym się zmagamy.

Tegoroczny Devoxx miał bardzo mocny “skład” i w ciągu wszystkich trzech dni można się było dowiedzieć masy ciekawych i przydatnych rzeczy, trudno by mi było wybrać najlepszą prezentację czy też najlepszego prelegenta. W tym krótkim poście starałem się zawrzeć opisy najciekawszych moim zdaniem prezentacji ze wszystkich trzech dni.

Do zobaczenia za rok w Krakowie!
Dominik

MCE 2017 - wygrany bilet “Bo mam szczęście”

Dzięki Łódzkiemu JUG-owi oraz firmie Proidea wygrałem bilet na jedną z największych konferencji w Polsce dotyczącą technologii Mobilnych. Konferencję uważam za naprawdę udaną. Na duży plus zasługuje podział na poszczególne bloki tematyczne (ANDROID, DESIGN, IOS) sprawia to że konferencja skierowana jest do szerszego grona odbiorców nie tylko do developerów ale także designerów jak i grafików. Konferencja trwała 2 dni organizatorzy zapewnili wszystko Prezentacje, Jedzenie, jak i rozrywkę(konsolę, oraz gra networkingowa).  Mnie osobiście podczas całej konferencji spodobały się 3 prezentacje.

1 Psy i Koty w której prelegenci opowiadali jak trzymać w ryzach team - war czyli wojnę pomiędzy Androidem oraz IOS i uwaga jest na to rozwiązanie KOTLIN(nie ten ketchup, tylko język) . Według mnie najbardziej udana prezentacja wiele żartów oraz wzajemne przygryzanie sobie nawzajem prelegentów sprawiły że prezentacja była według mnie najlepszą ze wszystkich.

2 Odchudzanie aplikacji, według mnie najbardziej merytoryczna prezentacja całego MCE. Czyli co zrobić żeby nasze aplikacje zamiast 40mb ważyły tak ze 27mb ,sposoby na oszczędzanie pamięci,(bawienie się formatami grafik, zasady czystego kodu itd...).

3 Aplikacje dla Afryki, Prezentacja przeznaczona bardziej dla freelance’rów. Afryka nie jest kontynentem opóźnionym o 1000 lat, mieszkańcy posiadają smartphon’y i internet. Natomiast na tamten rynek nie ma przeznaczonych tak wiele aplikacji, dlatego należy uznać tamtejszy rynek jako łatwiejszy do ekspansji niż rynek Europejski, Azjatycki czy “Hamerykański”. Także do dzieła :) piszmy i zarabiajmy :)

Pragnę dodać że mnie interesowały tematy dotyczące Androida, nie byłem na żadnej prezentacji dotyczącej designu - teraz trochę żałóuję ponieważ wielu ludzi zachwalało sobie szczególnie ten moduł. Zachwalaną prezentacją była również prezentacja dotycząca linkowania.
Pozdrawiam i jeszcze raz dziękuję naszemu JUG-owi oraz firmie ProIdea.
Paweł Dawiduk  

Scalasphere 2017 by Jędrzej Nowowiejski & Sebastian Szyller

Beginning of March in Cracow brought us the 2nd edition of this conference. Scalasphere could be categorized as quite unusual as it's focused not on academic discussions, frameworks or languages themselves but rather on tooling. Tooling, which usually is not perceived as valuable itself (that's a shame). Fortunately, we know the truth, the truth that these 'secret friends' help us be effective and successful on a daily basis. All developers using such complex and rich languages as Scala will probably agree that without proper automated help they would spent significantly more time doing things that seem trivial in other languages. Frankly, it's amazing that this conference gathered around 200 people that are not only interested in this kind of software but also eager to spend their free time on improving these tools. Congratulations to organizers and kudos to everyone that participated! Let's start with a few words about the venue. Beautiful view on Wisła river and real palms growing inside a building were so impressive and made us curious what would come next. Big lecture-rooms, interesting sponsors’ stands and nice coffee service and we were finally prepared to absorb knowledge. To write about all talks that we attended would take too much space and time to read about, especially that all of them are available on the conference website/youtube (scalasphere.org/). Therefore, in this review we decided to focus on "the things", sthe things that we as participants are taking home (of course except sponsor's gifts;)). Bear in mind that it's very opinionated and does not cover everything that was presented at ScalaSphere, so we strongly recommend to check talks online by yourself.

1. Scala compiler is slow, but this is not a curse. We believe that many new Scala coders are not aware that the way they are writing apps may radically change the compilation time. The great example are implicits. They are a really powerful tool that may be applied in many different contexts. However as one of the comics says: "With Great Power Comes Great Responsibility" and that's really true when it comes to implicits. Compiler is doing many things for you and one of them is resolution of implicits. It has to take time, if you have many of them in scope and you don't want to help compiler hunt them. Advice: always think about their scope, it will save a lot of CPU time. But that's not all that you can do to decrease compile time:)

   Secondly, there was a common theme that was present during different talks and that’s speed of the type parser. We all know that compilation consists of different subtasks like indexing or bytecode generation and the abovementioned type parsing is also one of such steps. Long story short, the role of the type parser is to analyse all types in the code and generate a syntax tree that can be later used to validate the type-safety of the code and then make the bytecode from it. It’s worth pointing out that this task is crucial because at the bytecode level JVM does not handle any types explicitly, but only implicitly through static type inference. This is particularly important in case of Scala as its generics are a lot more powerful than the Java counterparts and more widely used, when it comes to mainstream development. As a result, many people tried to come up with a solution that would speed up the overall compilation time e.g. via caching partial compilation results (Krzysztof Romanowski @RomanowskiKr from Virtus Lab), using distributed version of the Scalac compiler (Hydra compiler from @triple_quote - you can see that they already helped a lot Zalando to make their builds over a 3x faster) or trying to reinvent the type parser itself (Scala.meta). Let’s focus on the last case. It should be noted that at the moment there are three official type parsers in Scala - in Scalac (used in sbt, comes with the Scala distribution), in dotty-compiler (next version of Scalac that will come with Dotty i.e. Scala version 3.0) and in IntelliJ’s (or rather IntelliJ Scala plugin’s) implementation of the Scala compiler and presentation compiler. They do not differ substantially but unfortunately in all cases the type parsing step is quite slow. This is where Scala.meta comes to the rescue. This library is supposed to work on the meta-level of the language and fill the role of the Scala’s reflection API as well as replace or at least aid the procedure of the building the abstract syntax tree. But what is abstract syntax tree? Every language has types, keywords and syntax features that define how the code is written. AST is a tree representation of all those constructs and in the end it corresponds to a semantically consistent structure that represents our code. So far, Scala.meta is in quite early stages but it already shows promising results. Furthermore, rumour has it that JetBrains is planning to invest time in Scala.meta and rewrite its Scala plugin using that library. The only thing that is really needed are contributors so feel free to have a look at the git repository and drop a pull request or two!

2. Find new usage of already existing simple language mechanisms. That point was inspired by Jon Pretty @propensive talk about contextual. Library that allows you to use String interpolation to validate your inputs. It already supports: some bash command’s syntax, emails, jsons, xml and some more. You can also use it to add your own implementations and that sounds great. To be honest we were sceptical about that as interpolators are applied during compilation phase, so it will work only for strings that you as developer put directly in the codebase. However (thanks to Kamil Owczarek) we found a way to use it in our daily work, we can use it when we want to write some tests with jsons and validate their content (at least on the json specification correctness level). Also bush support sounds promising and may be a true friend, which helps you to avoid unexpected problems in Production runtime as again it works during compilation, so you will know that you made a mistake, before you will try to run it! It took our some time, but we realized that the real greatness, which stands behind it, is to move runtime errors to compilation phase and solve them there. Genius! That conept is amazing. Now we are thinking, if we can’t use some other similar concepts to move further - really interesting homework :)
   
3. Building community is really important and Scala have great one. After conference organizers invited everyone to join hackathon. What's more during this event people made some PRs for scalafmt etc. (Ólafur Páll Geirsson about hackathon). We think that's cool, that we are not only using, but also actively trying to help develop tools.

To sum up conference was really nice, great after party and comfortable venue. There was also chance to participate in sister ReactSphere that was taking part at the first day of ScalaSphere (where Jan Pustelnik and Kamil Owczarek from Lodz have their talk), but we were too interested in tooling and missed almost all talks there. Can we recommend this conference to other people - yes and no at the same time. If you didn't work with Scala, we have a mixed feelling if you should go there. You would see that Scala compiler is slow and people work on improving it, developing tools to help you with refactoring, debugging and dependency management, but this is still WIP. That may discourage you from trying to work with it. That's a mistake! You can do many things in this language (for sure more than in Java), but you have to be aware that Scala compiler is doing many things for you, just to let you reduce time of writing code and that comes with price. If you want to spend less time coding, compiler have to do more things for you and that's the tradeoff. You have to choose wisely what you prefer: lower compilation time or flexibility and powerful type system. From the other hand we can recommend this conference to all people who already worked with Scala. It was a real pleasure to be 'an ambassadors' of JUG Łódź at this conference (thanks again for tickets JUG!).

Jędrzej Nowowiejski & Sebastian Szyller

Lambda Days 2017

Konferencja Lambda Days 2017 odbyła się 9-10 lutego 2017 roku w Krakowie. Dzięki temu, że JUG zorganizował nam możliwość uczestnictwa w tym wydarzeniu, odrobinie szczęścia oraz temu, że opłaciłem składkę członkowską, miałem okazję odwiedzić Kraków i posłuchać ciekawych prelekcji z tematyki programowania funkcyjnego. 

Zanim przejdę do relacjonowania wysłuchanych prelekcji, opowiem Wam trochę o kwestiach techniczno – organizacyjnych. Konferencja, podobnie jak w ubiegłym roku, odbyła się w budynku Auditorium Maximum UJ. Uczestnicy i prelegenci zajmowali trzy aule – dwie małe i jedną dużą. Jak na prognozowane 500 uczestników, miejsca było wystarczająco dużo. Nie zdarzyło się, żeby dla kogoś zabrakło krzesła na sali, jak widywałem na bardziej obleganych prezentacjach GeeCona. Organizacja konferencji również przebiegała dość sprawnie – szybka rejestracja, dobrze zorganizowana szatnia, catering i rozrywki w przerwach między prelekcjami. Doskwierał mi jedynie (z resztą nie tylko mi) problem z dostępnością gniazdek do podłączenia laptopa, zarówno w aulach jak i na korytarzach. Pojedyncze wolne gniazda były „porezerwowane” do przodu. Dało się jednak obyć bez laptopa. Jeśli chodzi o organizację, muszę również pochwalić catering. Lunche i przekąski były naprawdę dobre i w wystarczających ilościach. Nie zabrakło również słodkich przekąsek w wersji light, co również było na plus. Pojawiło się nawet bezglutenowe ciasto, strefy crossfit niestety nigdzie nie znalazłem :)

Przejdźmy jednak do rzeczy. Pierwsza prezentacja rozpoczęła się z kilkuminutowych opóźnieniem, warto było jednak być cierpliwym i nie uciekać z głównej auli. Jako pierwsi wystąpili John Hughes oraz Mary Sheeran. W swojej prelekcji pt. „Why Functional Programming Matters” zainspirowanej artykułem Johna o tej samej nazwie z przed przeszło 25 lat. Para mówiła o historii i znaczeniu programowania funkcyjnego. I tak cofnęliśmy się do roku 1940. John opowiadał o koncepcji programowania funkcyjnego wymyślonej przez Alonzo Churcha, w której typy czy struktury danych były zastąpione funkcjami. John przytoczył również artykuł P.J Landina  pt. „The Next 700 Programming Languages”, w którym autor opisał koncepcję języka ISWIM (“If You See What I Mean”). Po chwili na scenie pojawiła się Mary z artykułem Johna Backusa “Can Programming Be Liberated from the von Neuman Style? A Functional Style and Its Algebra of Programs” opisując matematyczny koncept programowania funkcyjnego. Po kilku artykułach autorzy przybliżyli nam swoje koncepcje opisane w ich autorskich artykułach. Po drodze spotkaliśmy się również z funkcyjnymi językami jak Lava czy Bluespec. Podsumowując, była to bardzo ciekawa prelekcja poprowadzona w interesujący sposób, z czystym sumieniem mogę powiedzieć, że jest warta miana Keynote. Nagranie prelekcji jest już dostępne na YouTube.

Po keynote udałem się na dwa krótkie talk’i w ramach ścieżki Research Track. Najpierw profesor Uniwerytetu Warszawskiego Stanisław Ambroszkiewicz mówił o koncepcji sprzętowego programowania funkcyjnego. Następnie gość z Univeristy of St Andrews Kevin Hammond zaprezentował swoją pracę pt. „Automatically Deriving Cost Models for Structured Parallel Programs using Types and Hylomorphisms”. Obydwie prelekcje mnie nie porwały, sam pomysł ścieżki również, dlatego to były jedyne talki, których wysłuchałem w ramach tej ścieżki.

I can haz no Futures? Pierwsza, bardzo udana prelekcja z live codingiem. Michał Płachta z Ocado Technology pokazał na żywych przykładach, w jaki sposób poprawić czytelność asynchronicznego kodu w Scali poprzez refaktoring i pozbycie się nadmiarowych Future’ów. Bardzo udany talk, fajne przykłady, poprowadzone w zachęcający sposób – polecam!

Po lunchu udałem się na prelekcję Choucri Faheda „Full Stack Type-safety: Elm with Scala”. Był to talk, na którym mogliśmy poznać podstawy języka Elm oraz architektury TEA (The Elm Architecture), wykorzystywanych do tworzenia aplikacji webowych. Z całej koncepcji najbardziej spodobał mi się debugguer ELMa, z możliwością śledzenia historii życia aplikacji.

The Dramatic Consequences of the Open Source Revolution: Unrecognized Challenges & Some Modest Attempts at Solutions in Scala Heather Miller, która niestety nie dotarła do Krakowa i prowadziła prelekcję zdalnie, próbowała przedstawić zalety, ale również problemy i ryzyka rozwiązań OpenSource na podstawie głównie ecosystemu Scali. Okazuje się, że technologie OS są już na tyle popularne, że większość firm czy zespołów developerskich w ogóle nie zastanawia się nad komercyjnymi alternatywami. Naturalnym wyborem staje się Open Source – i to jest super. Jest tylko drobny haczyk. Jak mówiła Heather, „życie” wielu znanych i wszechstronnie wykorzystywanych projektów OS jest uzależnione od kilku programistów. Jest to tzw.niski Truck Factor (designates the minimal number of developers that must leave (i.e., get hit by a truck or bus, or win in the lottery) before a project becomes unsustainable [1]). Dlatego musimy znać to ryzyko, analizować i myśleć o potencjalnych problemach w momencie, kiedy decydujemy się na OS. Ale jeszcze ważniejsze jest to, żebyśmy jako programiści angażowali się, tworzyli, dołączali do środowisk ludzi zajmujących się projektami OpenSource. Mimo, że prelekcja nie była ściśle techniczna, bardzo przypadła mi do gustu. Dodam, że fakt braku prelegentki na auli wcale nie ujął nic samej prelekcji i nie dało się odczuć problemów technicznych.

Distributed Computing challenges in the gaming and betting industry Sławek Zając, Dyrektor Techniczny w Grand Parade opowiadał, z jakimi wyzwaniem przyszło się zmierzyć jego zespołom w trakcie projektowania i developmentu systemu bukmacherskiego. Sławek najpierw przybliżył nam jak działa taki system oraz jakie wnosi problemy - obsługa milionów wewnętrznych i zewnętrznych zdarzeń, procesowanie 160TB danych dziennie czy 5 milionów dziennych zmian stawek oczywiście przy zachowaniu transakcyjności. Zespołowi udało się to osiągnąć z użyciem aktorów Akka w Scali.
Keynote, który miał zakończyć dzień pierwszy niestety się nie odbył. Idalin Bobé miała poprowadzić prelekcję pt. „The Gap Between Diversity and Social Justice”. Dzięi temu było troszkę więcej czasu na Lightning Talks. Ochotnicy zgłosili 5 krótkich talk’ów – jedne mniej, niektóre bardziej interesujące. Najbardziej utkwił mi w pamięci kolega, który zaprezentował grę wymyśloną i napisaną przez siebie w Elixirze.

Drugiego dnia wszyscy wyraźnie zrelaksowani po czwartkowym after party. Zaczęło się interesującym keynote’em „Build Good Software: Of Politics and Methods” od Briana Troutwine. Brian postawił dwa pytania: 1. How do we make software that makes money? 2. How do we make software of quality? Na historycznych przykładach mówił, jak skomplikowane mogą być systemy, które wytwarzamy i jak duże jest prawdopodobieństwo wystąpienia katastroficznych błędów. Sformułował również kilka zasada, które powinny być przestrzegane przez wytwórców oprogramowania. Wszystkie przykłady dotyczyły „dużych” systemów np. rektor jądrowy w Czarnobylu, jednak wydaje mi się, że przesłaniem tej prezentacji było to, że liczy się jakość każdego, choćby najmniejszego wytwarzanego przez nas oprogramowania.

A song of types and errors, or how I found myself leading teams of Scala developers Valentin Kasas porównał plusy i minusy pracy w mainstrem’owej do niszowej technologii. Przyznam szczerze, że z mojego punktu widzenia oraz doświadczenia było to bardzo udane porównanie. Całość prezentacji skupiała się nad doświadczeniami autora jako developera Scali. Opowiadał jak z mało doświadczonego developera Scali stał się w krótkim czasie ekspertem oraz liderem zespołu developerów. Mówił o problemach z jakimi się zetknął oraz podał kilka porad dla ludzi, którzy znajdą się w podobnej sytuacji. Prezentacja była okraszona trafnymi ilustracjami ze znanego serialu z kanału HBO.

W prelekcji pt. „The Origins of Free” Adam Warski mówił o “Free Monad”, co to jest, z czym się to je i jaki sposób możemy to wykorzystać. Mimo, iż autor podkreślił na początku, że programistyczny background jest wystarczający, to w mojej ocenie cała prelekcja była z byt bardzo „matematyczna”. Po tym wykładzie algebry udałem się na kolejny wykład, którego obawiałem się, że również będzie bardzo teoretyczny – „Going bananas with recursion schemes for fixed point data types”. Na szczęście okazało się inaczej. Paweł Szulc na żywych przykładach kodu w Scali pokazywał, czym jest „ZOO of morphisims” – katamorfizm, anamorfizm i hylomorfizm. Na koniec konferencji trafiłem na prezentację – live coding, na którym Jacek Kunicki pokazywał praktyczny przykład wykorzystania Akka Streams.  Bardzo udana prelekcja, szybkie wprowadzenie do Akki.

Konferencję uznaję za bardzo udaną i cieszę się, że mogłem wziąć w niej udział.


[1]https://medium.com/@aserg.ufmg/what-is-the-truck-factor-of-github-projects-bb0d5f019a6f#.h14c6ccti