 So as Kevin mentioned, we are mostly tonight going to focus on things that we've used ourselves here in Singapore and things that have appeared on the radar this time. So we were lucky enough in the last year to work with the local bank on a voice platform. So they didn't come to us specifically asking for a voice platform, but they came to us because they had a conference coming up and they wanted to do something innovative to show off at the conference. So we went into the bank, we organised a couple of innovation sessions so, not loud enough? Yes, so we organised some innovation sessions where we asked a whole lot of thought workers as well as, we can see the innovation session here, as well as people from around the bank to come and talk about what we could build within the time available. I think we had about two months or so before the conference. So one of the things they had at their innovation lab was the Amazon Alexa that you can see here. So after a few days of talking about it, we decided that we could pair the Amazon Alexa and create a smart mirror. Now if you haven't heard about a smart mirror before, there's been quite a few showing up on the internet over the last year or so. Basically the smart mirror is a two-way mirror with an LCD panel mounted behind it. So a two-way mirror is the same kind of thing that you would use to build like an interrogation room or a UX lab where you have a piece of glass between the two rooms and you can see through from one side and not from the other. The reason that works is that if there is more light coming from one side, that will reflect and the user on the side with more light will just see their reflection. If there's more light coming from the other side, the light will come through the mirror and you'll see straight through as if it was a piece of glass. So we've used that here in the smart mirror. We've mounted an LCD behind it when the LCD is showing a black screen that looks like a mirror and when we decide to show some text on the mirror, it comes up and shines through. So what we were aiming to achieve here is something that you would have in your home. You can talk to it and ask it for things like your bank account balance and financial advice and it will show it to you on the mirror. So you can imagine this hanging in your hallway as you walk out of your home and you say what's my account balance? Make sure you've got enough money for your day's activities and then off you go. So I'm going to try and do a quick demo and then I'll talk to you a little bit more about how it works. Alexa, ask the bank for my account balance. No, account found. Alexa, ask the bank for my current account balance. You have $3,230 in your current account. I'm sure you can't all see that but the account balance is also shown up on the screen. So how do we achieve this? So what's actually happening here is that we're speaking to the Alexa device. It's streaming the audio to Amazon. Amazon is doing some intent analysis on what we've said and it's using the intent configuration that we've uploaded to the Amazon service to identify which intent the user was trying to achieve. So in this case, I was trying to fetch my account balance. Once the intent has been identified, Amazon will send our web service request. This is pretty much just a standard JSON call informing us of the intent and any additional parameters the user has provided. In this case, because this was an innovation project, we took an opportunity to try out some other technology here. So we're using Alexa and the Phoenix framework which I'll talk more about in a moment. So our service is responsible for fetching the user's account balance at that point and forming the words we would like Alexa to respond to the user with. So we will respond with JSON again back to Amazon. Amazon will convert that to audio and stream it back down to the speaker and that's what you hear in the response. So the account balance. So that's all well and good but how does this actually integrate with the mirror? So one of the reasons we chose the Alexa and Phoenix framework here was Alexa is very good at maintaining persistent connections. It can hold quite a large number of open connections, not that we needed it for this project. So we have a web interface that we display on the mirror and it has a web socket connection with the web service. So every time we receive an event from Amazon, we also forward that information down to the mirror through a web socket so it happens in real time and we can display the balance at the same time as Alexa is responding. So I'm just going to do another slightly more in depth demo. So one of the key differences with voice platforms at the moment, I mean voice platforms have been around for a while, we've all seen Siri and others but they're getting more conversationally aware. So the demo I'll try and do is a bit more conversation oriented. Alexa, ask the bank to transfer some money. Okay, to which account? To my credit card account. Okay, how much? $100. Okay, when shall I make the transfer? Transfer tomorrow. Okay, I will be initiating a transfer of $100 Singapore dollars from your currency account to credit cards account. Is this okay? Change the to account to Stuart's account. Okay, I will be initiating a transfer of $100 Singapore dollars from your currency account to Stuart's account. Is this okay? Yes. Transfer submitted. So you can see that there was really a conversation going on between me and the Alexa and as that was coming up each new piece of information was appearing on the mirror so I could maintain the context of what she was going to be doing. So moving on, as I mentioned we got an opportunity to use Alexa in this project which it's made its first appearance on the radar. Sorry, no, it was on the previous radar as well, my mistake. So before I talk about Alexa, I would also like to talk about Erlang. So I guess a quick survey, who in the room has heard about Alexa? Okay, there's a few. And has anyone used Alexa? Tried to write some Alexa code? Two. Okay, both thought workers. And I've both worked on this project. So Erlang is quite an old language. It's been around for a long time, as you can see here, it's been around since 1986. It was built by Ericsson and it was really designed from the ground up to be very fault tolerant, scalable and distributed. So it was really targeting telco exchanges. So they had some very high demands on how much traffic they needed to handle and they really didn't want those things to go down. It's not like a server today where you can remotely restart it. You had to send out an engineer and get your hands dirty. So they came up with a pretty good model. Erlang has the Beam VM, which basically can handle a lot of processes within the VM and they're very, very lightweight. They're not the operating system processes or threads that we often talk about. One of the other cool features of Erlang is they can have zero downtime updates. So you can actually push new code into the virtual machine while it's running and it can pick that up and start executing new code without having any issues with the existing running code. It's a bit in depth to tell you exactly how that works at the moment, but each process can maintain its state and is basically a loop. So after it loops, it can actually change the code and when it next executes, it will have the same state but with a new set of processing code. And you can even include migrations for the state that's in there when it picks up the new code. Unfortunately, it never really got heavily adopted because as a common opinion along a lot of developers, it had a very strange and hard to understand syntax. But it really was a very effective language. So there's a lot of success stories about Erlang. You probably don't realize that about 50% of the telco switches are actually running Erlang on them to operate the switch. One of the flagship projects created by Erlang managed to achieve a 9-9's of reliability, which is pretty much unheard of. Essentially, this boils down to about one second of downtime over a 20-year period. That's not per server. This is for the whole server, so this is a distributed system. It's a very impressive number. So one of the apps that we have all probably used, that is written in Erlang, is WhatsApp. So they managed to build WhatsApp with about 32 developers, and they were supporting about 450 million users when they were acquired by Facebook. So that's also some pretty impressive numbers. And reportedly, they've said that they were running 2 million concurrent connections per server at that point. Some of the other success stories are Facebook Chat, React, CouchDB, and RabbitMQ. So in comes Elixir. Elixir was created by Jose Bellin in about 2012. It basically compiles down to bytecode that runs on the Erlang VM. So even though it's a new language, it's run time is battle-hardened and proven over the 30-year period. And he's really leveraged all of the great things Erlang had to offer, but has provided a much better syntax. So a lot of people compare the Elixir syntax to Ruby. There's some good reasons for that. Jose was a Rails core contributor before he started working on Elixir. So he's very experienced in Ruby, and a lot of that came over. But really the way the languages operate, almost nothing like each other. And you can actually integrate Erlang functions directly with your Elixir code. So there's no bridging, there's no cost at runtime. Some of the Elixir language features of note, it's purely functional. It's totally immutable. All the data structures are immutable. This is one of the key reasons that they can achieve what they do achieve in terms of the optimizations, the hot swappable code. It's got very powerful pattern matching, which I'll show you an example of. Unicode support, which you really need these days. The pipe operator, which is one of my favorites, which I'll give you a quick demo of. And just like Ruby, they've come with some really good tools out of the box. Mix is the package management tool, much the same as Bundler. And it's got an interactive shell, which all good languages should have these days. It's even got metaprogramming. So I'm not going to go into metaprogramming tonight, but it's quite cool that basically half of the Elixir language is written in Elixir. And if you know how to use it, it can be very powerful. Okay, so just jumping into some code quickly. I just wanted to demonstrate, give you a little bit of a glance at what some Elixir code looks like. This is a little bit trivial, but... So the pattern matching, if you haven't seen pattern matching before, these are two tuples that are... There's an assignment here, but it will pattern match. It's seen that the two okays match, and it will basically assign the value of this key into the variable. So this is a very basic pattern matching. And it comes in very handy when you're defining functions with Elixir. So this function, for example, is looking for a single parameter coming from a map with a key of a. And you can see here when I call it, I've given it two keys, but I'm only interested in the key of a, and it's pattern matched on that. So my input parameter a has been assigned with the value of food. So that's a basic example of pattern matching. And this is the pipe operator. So it may look a little bit weird when you first look at it, but basically what the pipe operator is doing is taking the first value and piping it into the second, piping it into the second function. So the input parameter now becomes the first parameter of the second function. This is much the same way that Unix pipe operators work. And you can see here, so we've taken a string, we then split it by the underscore, which gives us an array. We then pipe the array into the next function, which capitalizes each string. That produces an array, that pipes into the next, and then we join them back together in space, and we get our hollow world out. This is a trivial example, as I say, but it's very declarative. You can see what's going on, and it follows the same way you would think about it. This is kind of the reverse to a lot of object-oriented languages, where you kind of string a lot of these commands together, and it's not nearly as readable. Before I move on, I think this is a great quote. So Pinterest came out and said that they've been using Elixir. They rewrote one of their notification systems, and basically it went from 10,000 lines of Java code to 1,000 lines of Elixir code, and they ended up using half the service. If you want to know more, I can personally recommend these three books. They're very, very good. Jose himself was involved in the first book. Chris McCord is actually the author of the Phoenix Framework, which I'll talk more about in a moment. And this book right here is actually written by a Singaporean, so you can go out and buy it and support him. Now, I don't have enough time tonight to go through all the features of Phoenix as well, but Phoenix is essentially a web framework that's written in Elixir. So you get a lot of the benefits of what I've been talking about, scalable, distributed, purely functional. And basically it is kind of a clone of people. Some people talk about it as a clone of Rails, and in many ways it is. So they've taken a lot of the lessons learned from the Rails framework and applied it to this, but really the closer you get, they're nothing alike. But they have some of the great features of the generators that you get in Rails. You can generate a new project, get up and running really quickly. And it's a great way to get an introduction to Elixir. So I recommend you all go and give it a try, which is why it's in the trial radar. Okay, I'm going to hand over to Stefan.