Jan Weinschenker
Architect and Senior Consultant
Hamburg, Germany
Jan Weinschenker works at Holisticon AG in Hamburg as a senior consultant and software architect. He is a big fan of cloud based architectures and reactive programming with Java and Kotlin.
Area of Expertise
Topics
Side-by-Side: Reactive vs non-reactive Java
I like to write code that works. It should perform its job correctly, efficiently and resiliently. It should work under heavy load and even if some errors occur along the way.
In order to fulfill all these requirements, I preferably chose one of Java's reactive frameworks for coding. There is a range of them available: Java Reactive Streams, RxJava, Project Reactor and even one called Mutiny.
Those Java frameworks can be a lot of fun to use once you get the hang of it. But in my experience that "getting the hang" reactive coding can be quite a challenge.
Written mostly in a stream based way, it looks and executes differently than classic imperative code. The learning curve is steep.
However, it can be fun. And to proof that, in this live session I am going to write two snippets of code that basically perform the same job.
One of them will be written imperatively, the other one will be reactive. I'm sure I'll like the latter one better. What about you?
Reactive Java - The Good, the Bad and the Ugly
Die Versprechungen der reaktiven Softwareentwicklung sind beindruckend und vielfältig. Unsere Anwendungen werden non-blocking und sind immer responsiv, also ansprechbar. Sie brechen nicht unter hoher Arbeitslast zusammen. Sie sind elastisch und verbrauchen nur die wirklich nötigen Systemressourcen. Sie sind resilient und können gut mit Fehlerfällen und Lastspitzen umgehen. Sie sind nachrichtenorientiert, reagieren auf Ereignisse und wir haben deswegen wenige oder gar keine wartenden Threads in unserer JVM. Viele unserer Träume werden endlich war – das goldene Zeitalter der Softwareentwicklung bahnt sich seinen Lauf!
Wirklich? Viele von uns arbeiten schon seit Jahren mit reaktiven Frameworks wie Vert.x, Spring-Webflux (Reactor), Akka und vielen anderen. Sind die Vorhersagen wirklich alle eingetreten? Wie sieht es in der Praxis aus? Es gibt weitere Aspekte, die ein gutes Framework und ein Programmierparadigma auszeichnen. Wie hoch ist die Lernschwelle? Was ist mit Wart- und Testbarkeit?
Mit mehreren Jahren Erfahrung, die ich in Projekten mit Vert.x, Webflux und anderen Frameworks sammeln konnte, möchte ich meinem Vortrag eine Bilanz ziehen. Wo liegen die Stärken von Reactive Java und wo ist noch Raum für Verbesserungen?
Creating Awesomeness with Pizza, API First! and OpenAPI
I like pizza. I like it a lot. I want to use the sensation of ordering a pizza to demonstrate how easy it can be to develop microservices with contemporary and modern methodology - that being the API First! approach.
In this lightning session I will show on the beamer how easy it is to write a small OpenAPI Spec for a tiny microservice. I will use the mighty OpenAPI Code Generator to generate initial projects from this spec file for a couple of programming languages.
So the generator automatically does a lot of work for you, taking the task of project setup and the writing of boiler plate code off you shoulders.
This demonstration will show that developing the "API First! way" can save you a lot of time and also forces you to think first of a clean and understandable API before you implement it. Thus enabling you to design awesome APIs to be used by consuming applications.
The developers who are going to use your API to build their own applications will thank you for that.
You should bring with you a basic understanding of microservice development. Furthermore, it will help you to be able to read YAML code, as I write it live on the beamer.
Eine Stunde was mit API First --- Microservices bauen mit OpenAPI, Vert.x und Kotlin
Dieser Vortrag soll ein Appell dafür sein, Microservices nach dem API-First-Ansatz zu entwickeln. Beim Entwickeln von Microservice-Anwendungen kommt es darauf an, dass bei allen Beteiligten Klarheit über die verwendeten und angebotenen Schnittstellen der einzelnen Dienste besteht.
Der API-First-Ansatz verlangt, dass sich Analysten und Entwickler diesbezüglich auf ein Vertragsdokument, also die API-Spezifikation, einigen. Mit OpenAPI steht dafür eine einfach zu verstehende YAML-Notation zur Verfügung, um REST-Schnittstellen zu beschreiben.
Vert.x wiederum ist ein schlankes Framework zum Entwickeln von Microservices. Vert.x kann die OpenAPI-Spezifikation weiterverwenden, um damit ohne Medienbruch die angebotene REST-Schnittstelle zu implementieren.
Die Endpunkte des Webservice und auch die Validierung von Requests werden direkt aus der OpenAPI-Spezifikation heraus konfiguriert. Einen web-basierten API-Playground zum Ausprobieren der Schnittstelle bekommt man praktisch geschenkt.
Im Vortrag gehe ich auf die Vorteile des API-First-Ansatzes im Microservice-Umfeld ein.
Ich werde anhand eines Codebeispiels den Weg vom Schreiben einer OpenAPI-Spec bis hin zur Implementierung mit Vert.x und Kotlin vorstellen. Dabei zeige ich, wie man mit dieser Tool-Auswahl mit wenigen Zeilen Code und fast ohne Boilerplate einen schlanken Microservice bauen kann.
Slides: https://www.slideshare.net/JanWeinschenker/eine-stunde-was-mit-api-first
WeAreDevelopers World Congress 2023 Sessionize Event
Java Forum Nord 2022 Sessionize Event
JavaLand 2022
The promises of reactive software development are impressive and diverse. Our applications are non-blocking and are always responsive. They don't break down under heavy workloads. They are elastic and only use the system resources that are really necessary. They are resilient and can deal well with errors and load peaks. They are message-oriented, respond to events and therefore we have few or no waiting threads in our JVM. Many of our dreams are finally coming true — the golden age of software development is upon us!
Really? Many of us have been working with reactive frameworks like Vert.x, Spring-Webflux (Reactor), Akka and many others for years.
Did all the predictions really come true? What does it look like in practice? There are other aspects that characterize a good framework and programming paradigm. How high is the learning threshold? What about maintainability and testability?
With several years of experience that I was able to gain in projects with Vert.x, Webflux and other frameworks, I would like to take stock in my presentation. What are the strengths of Reactive Java and where is there still room for improvement?
Java Forum Nord 2019 Sessionize Event
JVM Con 2018
Kotlin – the new best programming language for the Java Virtual Machine (JVM). Really?
The programming language from JetBrains makes many promises. There's talk of near-perfect interoperability with Java, significantly less boilerplate code, and better scalability, to name just a few of the benefits.
Does Kotlin deliver what it promises?
We think: yes. And we say this as seasoned Java and Spring Boot disciples. After the first steps in tutorials and projects in everyday consulting life, we are convinced.
JavaLand 2018
Java EE 8 and Servlet 4.0 bring to the Java world what the JDK9 failed to do: support for version 2 of the HTTP protocol. HTTP/2 brings HTTP push, request multiplexing and header compression to the web. The network bandwidth should be better utilized. Latencies should be reduced. So far, websites and browsers have primarily benefited from this. With the Servlet 4.0 standard, these innovations are coming standardized into the Enterprise Java world for the first time.
JBoss EAP or Wildfly and Spring will (hopefully) support Servlet 4.0 with their current versions in spring 2018, so that the lecture and demos can show how HTTP push can be implemented. Furthermore, the advantages of multiplexing and header compression compared to an implementation based on HTTP/1.1 will be shown.
The lecture is also dedicated to the aspect of HTTPS encryption, which is mandatory with HTTP/2. This is about creating, distributing and managing SSL/TLS certificates and how developers and architects can and should deal with them at development time. The lecture concludes with a brief assessment of the Servlet 4.0 implementation available at this time in terms of its usability and maturity from the speaker's perspective.
OOP Conference 2018
All the advantages of HTTP/2 (multiplexing, HTTP push and also HTTP header compression with the HPACK algorithm) have the potential to make web service communication more performant. Many enterprise applications are based on SOAP or RESTful web services.
Reason enough to investigate whether new web services should be implemented based on HTTP/2. The HTTP request methods, i.e. the command set including GET, POST, PUT, DELETE, have not changed with the version jump. Is it even worth migrating from HTTP/1.1 to its successor for existing applications?
One reason that would speak against this is the use of encryption with HTTPS. Although this is not required by the protocol definition for HTTP/2 (RFC 7540 and 7541), there is no HTTP/2 implementation that does not require HTTPS.
The use of HTTP/2 therefore always means that you have to think about creating, managing and distributing SSL or TLS certificates.
The advantages of HTTP/2 are always bought for an IT system through increased complexity.
Do the advantages for web service communication justify this additional complexity?
What about support for HTTP/2 in the current Java environment? JDK9, Java EE8, Servlet 4.0, JBoss EAP 7, Tomcat 8.5 and 9. Do these technologies support HTTP/2?
This question will be discussed in this lecture.
SEACON 2017
My Pecha Kucha will be short and sweet with a topic that isn't exactly what you'd expect: a selection of monsters and monsters that can get in the way of the team over the course of the project. Together with the other Pecha Kuchas at SEACON 2017, this talk starts on Thursday, May 11th, at 5:05 p.m.
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top