J-Santa

Jesteś ciekaw, czym jest FRP? Ciągle słyszysz o RX, ale nie wiesz co to? Zapraszam cię w podróż do magicznego świata programowania funkcyjno-reaktywnego! Pełnego potworów (flatMap), zasadzek (hot vs. cold), i labiryntów (zip, merge, combineLatest)…
Temat nie jest prosty, ale nie jest też niemożliwy do ogarnięcia.
Jako że jestem pragmatykiem, skupimy się na praktycznych zastosowaniach tego paradygmatu. Na czym polega i co nam daje? Jakie problemy rozwiązuje? Jakie problemy generuje?
Zaopatrz się w dobrą kawę, otwarty umysł i zaczynamy 🙂

The Eta Programming language is a dialect of Haskell for the JMV. Eta has a set of characteristics that differentiate it from other languages. It’s functional, pure, lazy, statically typed and interoperable with Java. I will describe what each of this characteristics mean and how they compare to other programming languages, including some code examples. I will also enumerate the benefits of using this language and why I think it is a language worth to learn.

Kolejny raz nie wyrobiliście się z zespołem w terminie mimo silnego technicznie zespołu? Klient jest zawiedziony, ponieważ nie dostał tego czego potrzebował? Albo dostał… tylko częściowo? Podczas prezentacji zobaczysz co programista może zrobić, żeby zapobiec takim sytuacjom. Zaprezentuję co dzieje się w przypadku, kiedy nie zwracamy uwagi na umiejętności miękkie i co możemy zyskać przykładając się do ich rozwijania.

Consumer driven contracts (CDC) są jak Test Driven Development (TDD) dla Twojego API. Jest to wyjątkowo istotne podejście, w szczególności w świecie mikroserwisów. Z racji, iż jest sterowane przez konsumentów API, jest to pojdeście wyjątkowo zorientowane wokół użytkownika. Naturalnie wiemy, iż teraz mnóstwo inżynierów postanowiło iść w stronę mikroserwisów, natomiast rzadko kto zastanawia się jakie będą implikacje takiej decyzji (w szczególności dotyczące kompatybilności wstecznej). Wówczas, zamiast częstych zautomatyzowanych wdrożeń, frustracja może doprowadzić do załamania nerwowego inżynierów i tragedii na produkcji.

Napiszemy system, który używa podejścia CDC. Użyjemy do tego technologii Spring Boot oraz Spring Cloud Contract. Pokażemy wam jak łatwo można napisać aplikację, której API jest sterowane przez konsumentów oraz, że podejście takie pozwala przyspieszyć proces wytwarzania oprogramowania i zwiększyć jego jakość. Prezentacja będzie zawierać wprowadzenie teoretyczne oraz kodowanie na żywo.

Java Platform Module System to niewątpliwie jedna z flagowych cech języka. Jest to duży krok naprzód, wyznaczający początek nowej ery dla modułowego rozwoju oprogramowania w Javie.
Modułowość jest kluczową zasadą architektoniczną, jeśli chodzi o tworzenie elastycznego, a jednocześnie łatwego do utrzymania kodu. Sesja pokaże, jak tworzyć aplikacje modułowe, które pomogą ci zarządzać i zmniejszyć złożoność oraz czy naprawdę warto stosować JPMS w komercyjnych projektach.

Łatwo jest zbudować zbyt skomplikowaną, przekombinowaną aplikację. Prostota może być kluczem do zbudowania dobrze działającej aplikacji. Podczas sesji przyjrzymy się różnym aspektom prostoty. Nauczymy się także interfejsu do S3 jako doskonały przykład prostoty.

Jako developer dowiesz się jak prowadzić sesje “analityczne”, aby wynieść z nich maksimum informacji i nie wystraszyć klienta prostokątami z wbitymi w nie dzidami. Zobaczysz też jak przekuwać
wiedzę biznesową prost na kod Agregatów DDD. Jako manager dowiesz się jak zaangażować developerów w problem biznesowy aby nie był to dla nich kolejny smutny projekt. Jako klient dowiesz się jak wykorzystać logiczne myślenie developerów do czegoś więcej niż implementacja.

Dzisiaj niemal oczywistym jest, że konfiguracja aplikacji jest oddzielona od kodu, ale czasem tradycyjne pliki properties/yml w naszym repozytorium, to po prostu za mało. Podczas tej prezentacji skupię się na problemach dotyczących konfiguracji mikrousług. Nie martwcie się – nie będzie za dużo slajdów – w sesji live-coding’u pokażę Wam jak można udoskonalić zarządzanie konfiguracją z wykorzystaniem Spring Cloud i Apache Kafka oraz jak łatwe jest rekonfigurowanie aplikacji na żywo bez konieczności ich przebudowywania lub restartowania

Kiedy czytasz ten opis zapewne wiele rzeczy dzieje się w tle. Być może gotujesz wodę na herbatę, czy ściągasz jakiś plik w przeglądarce. Robisz to asynchronicznie, ponieważ nie chcesz czekać na zakończenie tej operacji i chcesz zająć się czymś innym w międzyczasie. Dokładnie to samo może dziać się w naszych systemach począwszy od kodu, a skończywszy na integracji komponentów. Mowa tutaj o asynchronicznym kodzie, programowaniu reaktywnym, architekturze wydarzeń, modelu aktorów, message brokerach czy serwerach z nieblokującym wejściem-wyjściem (NIO) itp. Matką tych wszystkich rozwiązań jest asynchroniczność. Niesie ona za sobą pewne korzyści, konwencje, ale również wymaga zupełnie innego podejścia. Podczas tej prelekcji postaram się wam to wszystko pokrótce przybliżyć. Czy twoja woda już się zagotowała? 🙂

Java 8 była jedną z najważniejszych wersji Javy… ale nie była wolna od błędów, wtop, czy rozwiązań, które mogły by być znacznie ulepszone niewielkim kosztem.
W trakcie tej prezentacji przejdziemy przez sesję post-mortem i odkryjemy co poszło nie tak ze Stream API, Lambda Expressions i innymi. Przyjrzymy się błędom implementacyjnym, brakom spójności i sposobami na radzenie sobie z nimi.

Uczestnicy dowiedzą się w jaki sposób projektować i tworzyć aplikacje w oparciu o metodykę UCD. Jak wyglądają kolejne etapy, wywiady, projektowanie i badania. Czy budowanie person jest istotne i po co persony developerowi. Makiety, prototyp i co dalej? Spróbujemy pokazać, że iteracyjne tworzenie aplikacji pozwala uniknąć wielu rozczarowań.

Najnowsza wersja Scali 2.12 ulepsza kompatybilność binarną oraz wymienność kodu z Javą. Rozszerzenie istniejącego projektu Javowego stało się dla nas niezwykle proste i obu języków możemy w zasadzie używać zamiennie. Na prelekcji dowiecie się dlaczego wartę poznać Scalę, zwłaszcza będąc programistą Java i zobaczycie jak potężne może być programowanie funkcyjne oraz type-level. Pokażę jak Scala łączy elastyczność języka na równi z dynamicznym z bezpieczeństwem, jakie zapewnia silne typowanie. W końcu zaprezentuję także jak łatwo można dołączyć Scalę do istniejącego projektu w Javie.

Wyobraź sobie, że dostajesz swój wymarzony projekt. W końcu “greenfield”! Ale jest to projekt biznesowy i to ty jesteś odpowiedzialny za wybór technologii, a jako specjalista czujesz się też odpowiedzialny za całość. Co robisz? Zaryzykujesz tak po prostu i wybierzesz same “nowinki” z rynku, które cię kręcą i których chciałbyś spróbować? A jeśli uznasz, że jednak trzeba podejść do tematu “poważnie” to czy tak na prawdę aż tak dużo się nauczysz? O ile lepszym architektem i programistą się staniesz korzystając już ze znanych sobie wzorców i podejść? Prawda jest taka, że jak masz już młotek to wszystko staje się gwoździem. A każdy z nas ma swoje ulubione młotki. Oczywiście – część problemów będzie nowych, będzie wymagała nowych podejść i rozwiązań – ale nasz umysł skonstruowany jest w taki, a nie inny sposób – będziemy stosować utarte i pewne praktyki, szczególnie jeśli potrzebujemy udowonić swoją wartość w (nowym) zespole.

Chciałbym wam pokazać dlaczego można zakochać się w “legacy”, dlaczego te projekty mogą i powinny często być naszym pierwszym wyborem (o ile znajdują się w określonym środowisku). Prawda jest taka, że najwięcej uczymy się popełniając błędy, rozwiązując nowe problemy, ale także pracując w bardzo ograniczonej przestrzeni, która wymaga ostrożnych modyfikacji. Szczególnie, gdy nadchodzi wielka fala i wymagane są duże zmiany.. Wtedy wchodzimy na scenę i chcemy zejść z niej niepokonani.

Prezentacja nie będzie opowieścią o tym dlaczego to jest piękne i wspaniałe. Ten temat zarysowałem powyżej i pozostawię waszej indywidualnej ocenie. Chcę natomiast razem z wami przejść przez kilka ciekawych problemów architekturalnych, o które ciężko w nudnych greenfieldach. Chcę razem z wami zakochać się na nowo w rozwiązywaniu problemów tworzonych przez wymagania biznesowe, technologie i wcześniejsze decyzje. I w końcu chcę razem z wami popatrzeć na wytwarzanie oprogramowania nie jak na sprint, ale jak na maraton, w którym kluczowe jest nie tylko rozłożenie sił w czasie, ale odpowiednia kontrola całego organizmu i umysłu. Będzie dużo kwadracików, kółeczek i strzałek, będą technologie i braki technologii.

Dwa lata temu wdrożyliśmy Apache Flink – silnik przetwarzania strumieniowego w jednym z największych polskich telkomów. Na początku był używany do Real Time Marketingu, następnie także do wykrywania fraudów i innych zastosowań. W tej chwili mamy ponad 50 procesów, które w szczycie przetwarzają w sumie ponad 150k zdarzeń na sekundę. Chciałbym podzielić się naszymi doświadczeniami. Część z nich to sprawy techniczne – jaka jest nasza architektura (Flink, Kafka itd.), jakie są wyzwania związane z przetwarzaniem dziesiątków tysięcy zdarzeń na sekundę, jak uporać się z dużym stanem itd. Część jest bardziej organizacyjna – czym się różni tworzenie procesów strumieniowych od batchowych lub ‘normalnych’ aplikacji. Opowiem też trochę o projekcie open source który stworzyliśmy w trakcie – Nussknacker jest narzędziem (GUI) do tworzenia procesów na Flinku i jest używany przez analityków którzy niekoniecznie potrafią kodować…

Monitorowanie aplikacji? Tak – zdecydowanie. Tym bardziej w środowisku mikroserwisów, gdzie usługi wywoływane są przez inne usługi, które wywoływane są przez kolejne. Która z nich działa za długo? Jest sposób, żeby to sprawdzić… Jak? Tego dowiecie się na prezentacji, w której przedstawione zostanie rozwiązanie Spring Cloud Sleuth z wykorzystaniem Zipkina.

Podyskutujmy na temat architektury i jej wpływu na wybór technologii w projekcie.