This talk will leverage the experience of introducing reactive programming into existing imperative, blocking codebases to demonstrate how it can be done and when it can make sense to do so.
In this talk I will cover the basics of ReactiveCocoa and the principles of Functional Reactive Programming. Through simple practical examples I will show how ReactiveCocoa and Swift form a beautiful partnership.
This talk will leverage the experience of introducing reactive programming into existing imperative, blocking codebases to demonstrate how it can be done and when it can make sense to do so. Not all benefits of reactive programming can be obtained without a greenfield, fully async architecture, but many can. Subjects to be covered will include the mental shift from imperative to declarative, working with blocking IO such as JDBC and RPC, service composition, debugging and unit testing.
Learn the components of Spray, how they build on each other to offer convenient abstractions, and how you can easily combine the different abstraction levels in your code. Jan will show how Spray makes the implementation of even complex APIs easy and understandable.
Learn about the design principles and motivation behind Vert.x and why we are heading for a reactive future. You will also hear an overview including demonstrations of some of the key features of Vert.x including the distributed event bus which extends right into the browser, high availability, and the module system.
Functional Reactive Programming (FRP) is a simple and elegant way to design and structure interactive code, like games and GUIs. Elm is a young functional language that brings this approach to the web, allowing you to easily create complex interactions.
The game has changed: we write interactive web applications, we distribute the processing of huge data sets and our services need to be available at all times. This new breed of applications comes with its own set of requirements and forces us to establish new blueprints for designing our systems. In this talk, we ask … Read More
The reactive paradigm is a wonderful thing. The basic idea is that a reactive application, as much as possible, is asynchronous from beginning to end. It should be event driven, fault tolerant, scalable and responsive. Writing an asynchronous application, however, has it’s own set of unique challenges. In this post I’ll demonstrate an approach we took to solve the challenge of maintaining a definite order, specifically when performing database updates in asynchronous code within an actor.