Tutorials:

Writing a chat system in Pony

07 Nov 2018
09:00 - 12:30
Sylvan Clebsch and Sean T. Allen

09:00 - 12:30

Let's write a chat system in Pony together. The actor model is a natural fit for network programming, so let's use it along with reference capabilities to write an event-driven chat system. By the time we're done, you'll be able to write message-passing based Pony programs, use reference capabilities for performance and correctness, and produce native binaries with C like performance.

OBJECTIVES

Write a chat system in Pony. The participants will be able to write event-driven Pony programs that read from and write to network connections, and they will understand the Pony actor system and reference capability system.

AUDIENCE

Developers who are interested in getting their feet wet and learning about the Pony programming language in a friendly hands-on environment.

 

Production-Ready Serverless: operational patterns and best practices

07 Nov 2018
09:00 - 12:30
Yan Cui and Domas Lasauskas

09:00 - 12:30

Getting started with AWS Lambda is easy, but understanding the operational challenges and tradeoffs is a much more nuanced topic, and one that you need to grasp before you can be confident in operating a serverless architecture responsibly. Come to this workshop and learn all about Serverless ops.

OBJECTIVES

We would cover common operational concerns such as CI/CD, authentication & authorization, logging, monitoring, distributed tracing, tracking correlation-ids and canary deployment. The students would also learn how to test Lambda functions, and how to run and debug functions locally. I would teach these concepts using a demo app which the student would build step-by-step and apply the operational patterns against the demo app as they go.

AUDIENCE

Developers who want to go beyond the basics and learn how to makes a production-ready serverless architecture.

Thinking Concurrently

07 Nov 2018
13:30 - 17:00
Francesco Cesarini

13:30 - 17:00

How do systems built in Erlang, Elixir or any other BEAM Language differ from other systems? To start with:

  • They are designed from the bottom up to run 'forever.’
  • They are designed from the bottom up to expect, and recover from errors.
  • They are expected to evolve.
  • They scale seamlessly

How is all of this achieved?

The answer is simple - by making systems from sets of isolated communication processes, and by treating errors and code as first class objects that can be sent in messages over a network.

In this tutorial, Joe Armstrong will introduce what he calls the `Erlang way of thinking.` He will cover:  

  • Basic data types
  • Sequential Programming
  • Concurrent Programming

In Basic Data Types & Sequential Erlang he’ll introduce the foundations and talk about Modules, Functions and Pattern Matching. Once you've understood the basic pattern matching mechanism the rest is easy. In concurrent programming he'll talk about processes and their life span. You will look at sending and receiving messages, selective reception, and passing data in the messages. Joe will conclude this section by introducing the simple but powerful error handling mechanisms in processes which help detect and isolate failure. Time permitting, he will also cover distribution, showing you how, by doing it right form the start or with very few changes, you can write a program intended to run on a single VM and distribute it in a cluster.

OBJECTIVES

To learn the Erlang way of thinking when architecting and developing systems.

AUDIENCE

Developers and Architects interested in the principles which make Erlang, Elixir or other BEAM based languages unique.

Just the right kind of Consistency!

07 Nov 2018
13:30 - 17:00
Annette Bieniusa and Nuno Preguiça

13:30 - 17:00

You need a data store that allows for high throughput and availability, but you are worried about the consistency of your data under concurrent updates when replicating across data centers? Current designs for data storage forces application developers to decide early in the design cycle, and once and for all, what type of consistency the database should provide.

At one extreme, data stores with strong consistency (such as Spanner and CockroachDB) require frequent global coordination; restricting concurrency in this way greatly simplifies application development, but it reduces availability and increases latency.

At the opposite extreme, there are systems like Cassandra that provide eventual consistency only: they never sacrifice availability, but application developers must write code to deal with all sorts of concurrency anomalies in order to prevent violation of application invariants. But the system just needs to be consistent enough for the application to be correct!

In the training day, we will review different approaches and tools for choosing just the right kind of consistency for your app.

OBJECTIVES

You will learn how conflict-free replicated datatypes (CRDTs), transactions, and causal consistency interact to keep your data safe. Further, you will see how to analyse your application and its invariants to obtain a provable correct model. This tutorial is hands-on with many interactive elements to explore the features and limits of the Just-Right Consistency approach.

AUDIENCE

Application developers and system developers.