Niebawem.

I znowu ten moment: w swoim procesie wywołujesz API zewnętrznego systemu. Co robisz? Jeśli jest piątek popołudniu – wołasz synchronicznego POSTa i super 🙂 Implementacja prosta, szybka, testy implementujesz błyskawicznie. Ale w weekend nie odpoczniesz. Bo przecież co jak POST nie dojdzie bo sieć zawodna. A Ty już po swojej stronie zrobiłeś commit nowego rekordu w bazie. A jak POST dojdzie, ale będzie długo? User będzie czekał na UI a przecież co go interesuje że pod spodem jakiś zewnętrzny system jest powolny. No chyba w poniedziałek trzeba będzie doczytać o tych rozproszonych transakcjach i Two-phase commit. I już wiesz że kawa się będzie lała strumieniami. Opowiem o komunikacji asynchronicznej z zachowaniem spójności końcowej z użyciem wzorca integracji Outbox. Sprawdza się gdy zmiana musi się zakomitować w kilku systemach które pojedynczo może i są transakcyjne, ale jako całość nie są. Zmiana zapisuje się do bazy ale musi trafić też na kolejkę? A co jak zapiszesz na kolejkę ale transakcja na bazie się nie powiedzie? Trzeba rollbackować z kolejki? Oby tylko ta wiadomość jeszcze tam była, prawda? 🙂 Historia oparta na case-study integracji systemów rożniących się od siebie. Wymienię jakie problemy dzięki Outbox macie rozwiązane za darmo, a jakie problemy wygenerowane. Też za darmo 🙂 Po to abyś wiedział i świadomie podjął decyzję.

W Java 11/12 pojawiły się dwa nowe bardzo wydajne collectory ZGC i ShenandoahGC. Ich głównym celem jest skrócenie pauz GC do kilku milisekund tak, aby już developer nie musiał niczego „optymalizować”. Przejdziemy przez każdy z tych kolektorów i porównamy je z G1, który jest obecnie domyślnym GC od Java 9.

Wszystkie cztery najbardziej popularne technologie bazodanowe mają wspólny człon – „SQL” w nazwie (źródło: bit.ly/3BwaK0y). Ale czy relacyjne modele spełniają pokładane w nich nadzieje? Podważę światopogląd, w którym wszystko kręci się wokół jednego typu baz. Jako pierwsi dowiecie się, kto stoi za naszymi wyborami technologicznymi. Ta autorska teoria spiskowa o dziwo może pomóc w podejmowaniu bardziej racjonalnych decyzji.

Słyszeliśmy niejednokrotnie, że Domain Driven Design to nic innego jak właściwe wykorzystanie paradygmatu Object Oriented. Czy to stwierdzenie jest jednak zawsze prawdziwe? Myśląc o procesach biznesowych jak o przepływach (workflows) i strumieniach (pipelines) możemy zmapować nasze problemy na koncepty ze świata funkcyjnego, przenosząc nasz kod na zupełnie inny poziom. Podczas tej sesji zaaplikujemy pewne idee z programowania funkcyjnego do aplikacji napisanych w Javie, analizując wpływ na bezpieczeństwo, testowalność, czytelność.

Macie czasem poczucie, że w pracy czujecie się jak w piekle? Mimo ‘software developer’ w nazwie stanowiska kodowanie zaczyna być rzadsze, albo wręcz całkiem znika z dnia pracy. Cały czas zalewają nas nowe wymagania, ale nie zawsze wymagają napisania chociażby linii kodu. Spotkania, calle, ustalenia, discovery, modelingi, stormingi zamiast starego, dobrego naparzania kodu. Nie gwarantuje, że z tego piekła da się wydostać, ale może chociaż postarajmy się żeby było nam w nim łatwiej.

Podczas prelekcji podzielę się z Wami moimi doświadczeniami z różnych organizacji i ról z mojej 10 letniej kariery w branży. Zwrócę uwagi na pułapki myślenia i błędy, które popełniłem lub widziałem jak inni popełniają. Jeśli zastanawiasz się jak świadomie budować swoją karierę, albo jeszcze tego nie zrobiłeś, to nie powiem Ci jak ona powinna wyglądać, ale na co powinieneś zwrócić uwagę.

Zaczęło się od tego, że prosty serwis REST spełnił wymagania klienta. Przecież powinno zaczynać się od prostych rzeczy. Problem w tym, że zbyt proste rozwiązania mogą komplikować osiągnięcie kolejnych celów. Poszukajmy wspólnie lepszych rozwiązań. Od antywzorca do gRPC.

Czy zastanawiałeś się kiedyś, co trzeba zrobić, aby Twój kod działał szybciej? Czy zastanawiałeś się kiedyś, jak zostać „człowiekiem od wydajności””? Być może zajmujesz się wydajnością, od czasu do czasu, od jednej awarii do kolejnego incydentu o „”severity 1″”? I masz w sobie to dziwne uczucie, że robisz to źle? Być może nigdy nie przejmowałeś się jak szybko działa Twój kod. Od wieków wiadomo jest, że zawsze jest to problem z bazą danych (lub kogoś innego problem). A może, po prostu trudno się przyznać, że nie wiesz, jak usprawnić działanie swojego kodu? Podczas tej prezentacji pokażę, jak zostać programistą świadomym wydajności swojego kodu. W towarzystwie narzędzi takich jak JMH, JFR i flamegraphs. Skupimy się nie tylko na narzędziach, ale także na procesie optymalizowania wydajności. Porozmawiamy o tym, jak dobrej jakości, tzw. „”clean code””, wpływa na wydajność, dlaczego zbiory danych, które wykorzystujemy, są kluczowe, a także kiedy więcej nie znaczy szybciej. Podczas całej prezentacji będziemy refaktoryzować i ulepszać jeden, nie tak trywialny przykładu. Coś, co wszyscy z nas znają, lubią i wiedzą jak zaimplementować.

IF IFowi nierówny! Niektóre IFy robią więcej pieniędzy dla biznesu, a inne mniej. Niektóre zmieniają się częściej, a inne rzadziej. Niektóre zmienić łatwiej, a inne trudniej. Niektóre może napisać pre-junior-kontraktor, a inne już nie. Podczas prezentacji będziemy wyłuskiwać z ośmiotysięcznych pagórków obornika różne rodzaje logiki i zamykać je w odpowiednich building blockach. Ale nie takich z frameworków do CRUDów!

Ujawnimy już niebawem.

Czym jest kula śnieżna i jaki ma związek z synchroniczną komunikacją po http? Jak poradzić sobie z wymianą informacji między systemami gdy nie jesteśmy pewni czy system docelowy odpowie i po jakim czasie to zrobi? Na te pytania odpowiem podczas mojego wystąpienia i pokażę jak działa mechanizm Circuit Breaker i jak można zaimplementować go w aplikacjach opartych o framework Spring Boot.

Obserwowalność i monitoring nie są nowymi konceptami, natomiast do tej pory trzeba było używać różnych narzędzi żeby zbierać wszystkie sygnały – logi, metryki i trace’y (trejsy? tropy? ślady?). Ale krajobraz się zmienia, a jeden z projektów zasługuje na szczególną uwagę – mowa o OpenTelemetry, który aktualnie jest drugim najbardziej aktywnym projektem w CNCF. Podczas prezentacji dowiesz się czym jest OpenTelemetry, jak pomaga w obserwacji oraz jak zacząć kontrybuować.

Czy czujesz, jak w Twojej aplikacji dane przeciekają Ci przez palce? W dzisiejszych czasach informacja i dane to najcenniejsze zasoby. Tradycyjny sposób nadpisywania aktualnego stanu może nie być już wystarczający. Na prelekcji pokażę, dlaczego Event Sourcing jest wzorcem, który pozwala bezstratnie zachować, a następnie analizować operacje zachodzące w naszym systemie. Poparte to będzie praktycznymi przykładami z użyciem Javy, EventStoreDB i Spring Boot.

Niemutowalność zapewnia spokojną pracę w wielowątkowym środowisku oraz upraszcza przechowywanie danych w pamięci. Dlaczego więc tak dużo klas jest mutowalnych? Kto miałby czuwać nad poprawnością implementacji?

Zapewne wielu z Was wie, że Hazelcast to rozproszony cache… i robi duże oczy kiedy ktoś wspomina o stream processing, HyperLogLog, CRDT, Serverless, czy CP Subsystem. Podczas tej prezentacji wybierzemy się na wycieczkę po ekosystemie Hazelcast 5.1 i rzucimy okiem nie tylko na podstawowe przypadki użycia, ale również na ukryte smaczki oraz to, co czeka Hazelcast w przyszłości a dużo się dzieje.

Ujawnimy już niebawem.

Ujawnimy już niebawem.

Konkurencja nie śpi. Firmy ścigają się, aby zainteresować rynek kolejnym pomysłem. Inni próbują obronić swoją aktualną pozycję. W czasie kryzysu utrzymanie się na rynku może być dla części wyzwaniem. Dostarczenie zadowalającego produktu ma tym większe znaczenie. Jednym z elementów, mogących decydować o długoterminowym sukcesie jest jakość kodu. Tworząc szybki prototyp, możemy nie odczuć skutków na dłuższą metę. Niestety pod przykrywką prototypu często dostarczamy tak naprawdę MVP (Minimum Viable Product), który będziemy rozwijać. O czym często zapominamy, jakie błędy popełniamy i o czym powinniśmy pamiętać?