J-Santa

We are going to show you what happens when the management lets enterprise Java developers and architects decide how we can control the IoT devices in our new office. While it’s easy to figure out why Microprofile is cool, it’s harder to see how to get in into your project.

Stworzenie wydajnej implementacji niemutowalnych struktur danych były wyzwaniem, którego podjął się Chris Okasaki ponad 20 lat temu.
Podczas tego wykładu zastanowimy się nad względną użytecznością niemutowalności, poznamy koncept persystentnych struktur danych, oraz jak wyglądają najpopularniejsze triki implementacyjne, co pozwoli nam zrozumieć, że niemutowalność jest tylko z pozoru łatwa.
Zobaczymy ile krwi, potu i łez wymaga wyciśnięcie minimum wydajność z niemutowalnych struktur danych.

Jako programiści chcemy szybko dokonywać iteracji i zmieniać oprogramowanie, nad którym pracujemy. Z drugiej strony chcemy również, by było niezawodne, a w wyniku wprowadzanych zmian często coś się psuje. Kiedy tak się dzieje i nie da się tego uniknąć, zespoły operacyjne są niezadowolone, poniewaz skupiają się na niezawodności, a zmiany są jej wrogiem numer 1.
Pojawia się luka, tarcie pomiędzy zmianą a stabilnością. Musimy zbudować most nad przepaścią, by móc ją przekroczyć. Czas obalić schematy, posiąść i uruchomić to, co stworzyliśmy. Przenieśmy inżynierię oprogramowania do operacji. Co może pójść nie tak?
Podczas mojej prezentacji podzielę się tym, czego nauczył mnie pierwszy rok pracy jako Site Reliability Engineer, w tym tematami takimi, jak:
• określenie, czym jest niezawodność oprogramowania i dlaczego nie jest to takie proste, jak mogłoby się wydawać,
• pomiar niezawodności, wyznaczanie celów dotyczących niezawodności, praca z SLI, SLO i budżetem błędów,
• w jaki sposób oddanie operacji w ręce programistów może ulepszyć oprogramowanie,
• zadania, którymi na co dzień zajmują się specjaliści SRE,
• triki i wzorce, które mogą zwiększyć niezawodność naszych serwisów,
• umiejętności przydatne w pracy SRE.

Czy zdarzyło ci się kiedyś przebudować całą aplikację, bo trzeba dodać nowe pole na frontendzie? Albo gdy zmiana organizacji tabel w DB zmieniała całą twoją domenę? Jak radzić sobie ze zmieniającym się światem i wymaganiami? Jak utrzymywać porządek wewnątrz aplikacji i skupiać się na jej domenie? Jak sprawić, by zewnętrzny świat stał się detalem implementacyjnym? Odpowiedzią jest architektura portów i adapterów.
Na prezentacji opowiem o doświadczeniach z budowaniem aplikacji, gdzie twoja domena jest najważniejsza i odpowiem m. in. na pytania:
– Co mi to da?
– Jak to zrobić?
– Na co uważać?
– Dlaczego to jest trudne?

Spring is the premier cloud native microservice framework for Java. See how the automatic integrations with Kubernetes strips away all of the operations toil of deploying and maintaining production applications.

Paul will introduce the audience to Kubernetes, and Spring Cloud Kubernetes, He will talk through the various automated integrations for service discovery, configuration, etc. He will demonstrate building a CI/CD pipeline for deploying a spring app and show how Spring integrates seamlessly with Kubernetes as well as CNCF ecosystem projects such as Prometheus and Zipkin for observability.

Wszyscy znamy ból przeglądania dużych pull requestów. Dużo czasu zajmuje zrobienie przeglądu kodu, wprowadzenie uwag i merge do mastera. Robienie małych pull requestów wymaga samodyscypliny.

test && commit || revert (TCR) to alternatywa do Test Driven Development. Jeżeli testy przejdą, zmiany zostaną zakomitowane, w przeciwnym razie wszystkie zmiany wprowadzone od ostatniego zakomitowania zostaną odrzucone.

TCR to technika, która zachęca do robienia małych zmian w małych krokach. Rezultatem jest szybsze wchodzenie na produkcję, wprowadzanie małych zmian oraz dojrzałe podejście do refaktoringu.

Technika ta została stworzona przez Oddmunda Strømme, Ole Tjensvoll Johannessen i Larsa Barlindhaug podczas warsztatów z Kentem Beckiem.

Podczas tej sesji dowiemy się, co to jest i jak działa TCR, oraz zrobimy porównanie z TDD. Poznamy wady i zalety i możliwe zastosowanie w komercyjnych projektach. Zastanowimy się, czy TCR jest realną alternatywą do TDD, czy ciekawostką, która przeminie.

W zależności od wielkości systemu, dzieje się to od kilku razy na minutę do kilku tysięcy razy na sekundę. Żądanie HTTP dociera do usługi napisanej w Java. Jego obsługę możemy podzielić na kilka etapów: magia, kontroler, serwis, repozytorium, magia. Co gorsza elementy magiczne występują często też między kontrolerem a serwisem, serwisem a repozytorium..

W czasie tej prezentacji chcę pokazać, co kryje się pod warstwami magii, zwanej również abstrakcją. Zrozumienie tych mechanizmów pozwoli uniknąć błędów i problemów, które najczęściej dopadają nas w czasie największego ruchu na produkcji.,,

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ć.

„Benchmark, profile, refactor, repeat”

Are you struggling with concurrency? Do you happen to hit strange bugs when executing asynchronously? Are your async functions unreadable even to you? Come and see Kotlin’s concurrency model which addresses all these issues! Start using Kotlin’s coroutines and forget about struggling with Java’s threads or futures. We will go from the basic explanation of what coroutines are, how they help you out in your concurrent programming, how they work under the hood and finishing with the latest additions: Flows, which are Kotlin’s reactive streams built on top of coroutines. Treat yourself to a little comfort this Christmas and start using coroutines!

Czego nauczyliśmy się jako inżynierowie przez ostatnią dekadę? Jakie błędy popełniliśmy w naszych działaniach DevOps? Czy słowa takie jak „monolit” wciąż stają nam ością w gardle, a mikroserwisowy paradygmat wydaje się jedynym słusznym? Czy Kubernetes rozwiązuje każdy problem, a jeżeli tak, to jak i dlaczego?

While helping organizations move to microservices and public clouds, I’ve noticed a lot of common problems. Architecture is described at infrastructure level (k8s, cloud services, etc.) without any focus on domain architecture. Enterprise architects are put in charge of software architecture. Architecture guilds are created without introducing the required practices and culture. QA still thinks that end to end tests are possible. Managers want to sign-off and control deployments. Pipelines and processes are forced on devs, not allowing them to become devops (the culture doesn’t change). Devs do not learn the different flavors of event based architecture, relying on REST everywhere. Kafka is treated as a message queue (no streaming, no read models, no persistence). Half-baked tools provided as a service by the cloud are assumed to be cheaper/safer to use than self-hosted open source. Teams are created without repo ownership, creating an error prone setup. Finally business pivots are not taken into account, when designing the system. I’ll discuss all those problems, and hopefully provide some usable solutions.

Java 8 core features: Lambda expressions and Streams API have been widely adopted and popular since their launch. They promote benefits like: conciseness, readability, code reuse and less error prone. Even though they are embraced by the community, many developers are not familiar with under the hood aspects of these syntactic sugar, neither performance considerations involved.

Jak osadzić swoją aplikację napisaną w Javie na AWS?
Robić to szybko, ale mało elastycznie, a może poświęcić trochę czasu na porządną konfigurację?
Czy można z dockerem na chmurę?
Jest jakieś wsparcie dla mikroserwisów?
Jakie problemy mogę „zepchnąć” na chmurę?
O tym wszystkim powiem na wykładzie, wskazując na wady i zalety każdego z podejść oraz pokazując, jakie mamy dodatkowe narzędzia i usługi pomocnicze w AWS.

Prezentacja będzie sesją programowania na żywo, podczas której poddamy refaktoryzacji część systemu legacy. Podejdziemy do zadania pragmatycznie, identyfikując w kodzie problemy i naprawiając je poprzez stosowanie reguł i wzorców związanych między innymi z modularnością, kohezją, testowalnością. Zobaczymy także jak Domain Driven Design pomaga nam zbudować czysty i solidny kod. Przykłady kodu pisane będą w języku Java.

Testy jednostkowe są tanie i powinno ich być najwięcej. Wiele osób uważa testy jednostkowe za zbędne, ponieważ napatrzyło się na na złe testy, które zamiast budować pewność wprowadzają koszty utrzymania. Jednak dobrze napisane testy jednostkowe pomagają sprawdzić wszystkie ścieżki i unikać regresji w kodzie biznesowym. Pokażę kilka ciekawostek i omówię kilka kontrowersyjnych tematów, nad którymi każdy junior i mid powinien się zastanowić.

Mapowanie obiektowo relacyjne stosowane jest w wielu aplikacjach w ekosystemie opartym o JVM. Ma ono swoje plusy jak i minusy. Ma swoich zwolenników jak i przeciwników. Nie można jednak powiedzieć, że jest jedynym słusznym sposobem na wymianę informacji pomiędzy aplikacją a bazą danych.

Podczas tej prelekcji postaram się pokazać alternatywę dla ORM – jOOQa. Będą przykłady z produkcji. Pokażę jego plusy i minusy. Zaprezentuję zalecane przypadki użycia. Opowiem też o tym dlaczego jOOQ ma według mnie najlepszą dokumentację ze wszystkich mi znanych. Przyjrzymy się również niecodziennej polityce licencyjnej.

Jeśli nie chcesz lub nie możesz używać ORM to ta prelekcja może cię zainteresować.

„Just because you’re using Hibernate, doesn’t mean you have to use it for everything.” – Gavin King, twórca Hibernate.