 So I've prepared a joke in case we have something like this and we need to take time to set up. But I'm not sure if you guys want to hear it. It's really lame, okay? So a front-end developer walks into a bar but turns around and leaves because he doesn't like the table layout. I warned you it's really lame. Anyone else have any jokes? Can you repeat the joke? Sorry? Can you repeat the joke? A front-end developer walks into a bar but turns around and leaves because he doesn't like the table layout. I still don't get it. Come to Rails Girls, bring a girl, and we'll explain it to you. How are you doing? I'm doing okay, but you're not coming up next week. So it takes a little moment to search. I think that we're going to try not to switch computers too much today. It's a little bit slow. Yeah, what it does is it cycles through one of the different channels. So eventually it's a little bit slow, yeah. Do you want more jokes? I have no jokes. Do we need the girls to go to Rails Girls? Ideally. It's preferred for you to bring a lady as well, but you know... That's the girls of couples. No, no, no. You can just bring your friend. Rails Girls is really targeted and we don't need to get started in tech, but it's fine. We will come to you as well. Just that we do not want to go off the pitch and anyone can come, but that might be more men than women, that might make the ladies feel easy. We didn't want to go out there. Okay, next time I will prepare us to send men jokes. Ladies and gentlemen, self-show. So I'm going to talk about this project online. It's actually a lot of self-promotion here because I created this project and I wanted to get this a bit out. That's the reason why I'm talking about this. I'm going to talk about how you can write a web application in six programming languages. The number itself actually switched when I first started writing the slides. It was three, and then sort of grew, and after 12, it was six. You'll probably become more as I talk about it a bit more. Excuse me. Quick question first here. Anybody here programmed in anything else other than web applications? So what are the other languages you use? C++? For web applications, sorry, I forgot to mention that. For web applications, people have to learn not a lot to talk. That was great. Python? Right? I think it's just going to be later. So there's this particular survey that actually did survey the number of programming languages around and the popularity, and there have been a few of these. This is quite recent. I think this is in 2014. We had Java at the top and then a bunch of other programming languages. We also have C++, Ruby, Python, and so on. So all these are popular programming languages, right? And a lot of people have been writing in all these different kinds of languages. I have been writing in a number of them, but although I think the most recent one has been Ruby and also because there are so many programming languages out there. So what is really the main thing when you try to write a web application? What are the languages that you choose? What is the first thing that comes to your mind when you choose a programming language to write your web application? Is it used? How fast do you create it? Anything else? Formants? Communities? How familiar you are with it? For those who are more business oriented, it's like, how can I build a team that has these fields, right? How can I maintain it over a long run? So there are a lot of questions when it comes about. And of course, when you get a... But not really when you're in the right application. But as you build a team to actually build applications, and you start to gather people, then the first question comes to mind, so what are we going to build this thing in? And then this group here, everybody has a different opinion. We have a couple of people who are like, Ruby is the way. And a few say PHP is the way. And a few say, let's go for Node.js. And then student escalates into all out wall, right? What's up with it to compare? In fact, just now as I was talking to somebody, somebody was asking me that, so what's the best programming language to write? How do you compare this programming language to that programming language? And very often you can't really compare, because it's so difficult to say which one is the best feature of that. And you actually use more and more programming languages because it's increasingly more difficult. So programming language was, and choosing a correct programming language has always been a problem. The other one is dependency wall. Dependency health. How many of you actually developed an application that eventually that you need to maintain? Nope, nobody. So most people when they develop application, the first thing in your mind is that you develop this so that six months later I can maintain it. Or I say I develop this, I'm true to my client and I run away. Very often you need to. Even if you don't, you tend to orally after a while you will need to. And then six months later, guess what happens? Your libraries change. The gems need to be upgraded. The Java apps need to be changed. Your version needs to be changed. Somebody came up with a new version. Just talking just now. Ruby 1.8. And now it's Ruby 2.2. And along the way all the top versions, right? So you have dependencies in the libraries, the programming language depends on the platform. So how are you going to deal with all of this? Of course, my answer is polyglot. It might not be answer, but I just want to introduce this to you. So what's the premise of polyglot is that you can build a robot application with any language. So you don't really need to fight anymore, right? So if you like PHP, go ahead and use PHP. If you like to use C, go ahead and use C. If you like to use Ruby, go, know whatever it is. Go ahead and use that. But of course, you already know that, right? Because you can already write your applications in Node. You can read your applications in PHP as well. So what's the special about it? In polyglot, what I wanted to do is that you can write your application in all of the languages at the same time. So you have one single application that's written in multiple languages at the same time. You're not talking about writing in one application, one application in one language, and then moving it to another language, or maybe writing in separate applications and integrating them together. I'm talking about a single application written in multiple programming languages. So some terminology now. So what I have is what I call an acceptor. Acceptor takes in HTTP requests. And then the acceptor talks to a broker through 0MQ. 0MQ is the messaging queue protocol. And then of course the 0MQ would talk to something that, sorry, the broker would talk to to play out what I call a responder. The responder is the thing that would actually do most of your work. It's like a business logic. Here I write something in Ruby. But of course you don't really need to just write it in Ruby. You can write it in other languages as well. So you can write responders in Go, you can write responders in Java. And they all respond to the same broker. I mean, they all interact with the same broker and goes back to the acceptor which in returns a response to the following browser or application that you call. Beyond that, you don't need to just have one single acceptor. You can also have one split acceptor. So I have an acceptor and a broker, but you can switch to creating your own acceptor in a different programming language. Therefore you could have a hundred that's complete. Let's see how this works. So acceptor. Acceptor basically takes in the HTTP request on a browser from the application. It would be a pure HTTP request comes in and this is already done. So I've done a default acceptor in Go. So that's done. A broker, what it does is it will take in all the request that comes in and then it will distribute it to the correct responder. This is also done. I've already done this as well. So what do you actually need to do? You need to do this. You only need to write your responders. Basically this is your application. See how a responder looks like. So this is a responder in Ruby. You have the first part here which is setting up all the gems. So you guys are all Ruby, so you know what it is. First you need to define a route ID and a unique responder identity. So basically you need to define what is the route. Say here I want to define a route that is underscore hello slash Ruby. And I set the identity of this particular responder. It needs to be a unique identity among all the responders. I create a random GUID. Next I need to connect to the broker and this is all just syntax that allows Ruby to connect to Ruby responder to connect to the broker. After that you need to register a responder. You tell the broker say hey, I exist, this is me on the responder. After that you are ready to go. You are ready to accept requests, come in, you can do whatever you want with it. Here of course nothing I am not doing anything with it. I am just receiving the request. But you can imagine that this guy can actually do a lot of stuff. He can process the request to do other stuff. And then when you are done with it you want to return the response. You just return it in a array of four elements. You have to return the route ID to tell the broker where this is supposed to go to. You turn the status. This is the HTTP status. The haters. And then your content body if there is any. If there is no content body then you are going to return it in. And finally you need to send the response back. This is all you need. This is an application. So besides writing in multiple languages which is kind of a novelty. Sometimes I think why would I want to even do that at all? I can just write in one program. And sure enough you can. You can actually write a polyglot application in just Ruby for example. And then so what difference does it make? Why wouldn't I want to deploy in any of the nicer, that app servers to Ruby app servers? Well there are a couple other reasons. So one thing is just to do it by default. As you look here I have an acceptor. I could deploy an acceptor in one server broker in another server and then I could deploy the responders in multiple servers. I don't need to deploy a single one. And as long as they are connected to the same network they are reachable then the responders will be able to try to deploy the broker. The second is that as you build the application you don't need to build everything all at once. You can actually scale it up. You can scale it up dynamically. So what I mean here is here you have the same setup. Say you have the responders here you can add in another acceptor to scale it up as long as it connects to the broker. And you can add in more responders and add in as many responders as you want. It should be written in the same programming language. You can write in different programming languages. So what I think it means is that as you build your team you get a new guy coming in and you get a seed expert. So go ahead and write seed responders. Put in another server. Does it serve the same different route only? No, it can serve the same route as long as it does the same thing. So as soon as they are popped the probability of errors coming up if you serve the same route using different responders is high. But none the less you can if you want to. All these are risks that as a developer you need to take. You can also evolve your application. This is what I meant just now. Let's say you have this setup and tomorrow this particular set of responders you want to switch them out. The logic is you want to move the logic you want to do a different kind of logic. What you need to do is just shut down the responders and then swap it with a different set of responders. Serving the same route and then you can actually don't even need to shut down the application at all. You just swap them out and swap it with it. So these are some of the advantages and Polyglot is still evolving. It's not a fully computer project and it still needs a lot of work. So I'm actually going out trying to sort of get feedback and get say help as well. If you guys are interested you can contribute. Everything is in GitHub. You can go to the GitHub repository fork it out own it and then after that play around with it. If you want you can add additional languages and you can also see what else you can do with it. There are still a lot of things that I'm missing here. I think you can do a lot more things with it. But let me just go very quickly to show you the actual code. Because I'll be just talking about slides here so far. By the way this is the original sample app I call Polyglot. It shows you how to you can see I actually started with trick language and then I actually evolved it to more. And in this particular example shown here I have written a responder in Ruby I have written another responder in Java. You can see the Java one is big. But actually it's not because it's just Java. Although control go here but actually it's big because the Ruby one was just responding with thing string. This one I actually need to connect to the database and return some code. So if you look at the one in Ruby so what I did was I actually used Hamel to talk a little bit about this. So I actually use Hamel and I have Hamel layouts as well. So whatever you're familiar with you're familiar with using Hamel you can do this. You're familiar with using ERB you can use something else. You're familiar with whatever it is that you want to use. For Java it's just this guy that I use to Java. It's a bit smaller. And go this is a gold template for this to go code. But beyond that I have this in other languages as well. I have as of today I have this in six different languages. I have done this in C so this is the C code. This is Ruby. So I show you a bit just now. I've done this in gold. I've done this in Python. I've done this in Java. I've done this in Node. So as long as the language actually supports zero MQ essentially it's a communication protocol. You can add that language here. So I didn't actually do more because I actually do a lot more. But that would require a little bit more time. But you get a picture. You can actually add languages as zero MQ and zero MQ I think it supports 20 different languages. So they actually support bash as well. If you really want to I suppose you can write that. So that's the end of my presentation. Any questions? So it runs on a separate process. I didn't actually talk about it. So basically it runs on a separate process. And it's scalable in the sense that today you can run say I created C you can run 10 copies of it on one server. And then of course you need to do the usual stuff to manage the same processes. Then if you think that you need more, because what happens is the broker will do round robin and basically allocate according to the different processes. If you need more just start on another time. Start on another 15. As many as your server can take it. If your server cannot take it anymore code to whichever posting provider you will start on another server and then run the other process. So it's scalable in the sense that's the same protocol that came up with Facebook, right? Yes. I think about Facebook in 2007 and trying to solve the problem of it's an RPC but it's also kind of actually different program languages. Right. So I've not really looked into this. I know about it but I've not looked into it. So in reality this is kind of normal. Some of you might look new but actually this approach as I sort of try to get responses and feedback on Facebook somebody told me that there was somebody who actually did something very similar to this called Mongrel 2. We probably have heard of Mongrel, right? So that show that Mongrel project after some experts and then after that when you create Mongrel 2 and Mongrel 2 uses that MQ as well just your MQ as well. So there are similarities. I've not really actually used Mongrel but there are some similarities. But truth I'm not trying. Do you want to try? I've not tried it out and I know it solves a similar problem so it's not really a check out project similar ideas. Oh no, I did not check them out because I thought that truth is a protocol therefore I did not actually check it out. Truth is a protocol I thought it was a protocol like 0 MQ so I like 0 MQ so I can categorize the 0 MQ true so let's say we set it harder than You can, you can do multiple as well. I have an example that actually sends a binary back it does pose it does Yeah, it actually does get and pose at this point in time and it actually doesn't do anything else but I suppose it can actually do other stuff. How would you like to pick but the route if I want a binary you are a binary you are let's say post slash post slash anything so you need to set the route ID so as long as you're post slash something then whatever so you need to actually go to a particular URL and then from there on whatever you send as a part of the HTTP request you write in and you can pass it so dynamic URL as you get you have slash whatever that does not actually exist I think it can be added in but I am personally not in favor of that because I'm more in favor of having fixed URLs and then the fragments itself in the data or you will be in a post so that's sorry processing the fragment that's my preference but I think it can be done how do you make sure that broker is not a single point of failure request so the way it is a single point of failure is of course the project is not production quality so it should be it should be somehow be able to load balance itself you can probably have another broker and then do some heartbeat between the brokers so there is a particular pattern that allows you to do that I have not implemented that if you are interested what are the I have recorded but I think they are useful to sure next few big items that you have so I think one of the reasons broker is a single point of failure without having that then I think a lot of these things that I have talked about so a lot of things about it is like future looking because really the broker is a single point of failure and the broker goes down then it goes down the second thing is it needs a lot more rigorous testing so I think that is the second one and then flashing out the rest of the STPAC method but by far it can be used as a simple application except that it is definitely not the best and I saw somebody ask what is the advantage of using this over a system like in the next little month and running all the applications multiple web applications so that is multiple applications this is a single application still use a different browser still need different processes for each one you see different processes but it is a single application in the sense that if you are front end but if you are front end actually if you manage to maintain the session you can actually maintain the session your back end processes you can send in a cookie to the store in the browser for example and another color responder will actually take that and use that to the server nginx doing that to be honest I have not tried all this one I know very well so I thought this is a good way of doing this and allowing it to be distributed so that is why I have not actually tried so if we do that I am not really like compare it the MQ is to pass all the HDI yeah so the zero MQ is a protocol that allows different components to interact with each other you have more questions for Sasha please come up and talk to me more after the rest of the talks and we are going to move on to the next topic now please thanks Sasha