 For somebody else, Ian uses Ruby to take over the world for himself. And today he's going to be talking to us about one Ruby app to rule them all. So I guess we're about five minutes early, but we should get started. So welcome Ian. Here today to talk about one app to rule them all. So my motivation for this is we need to build a fully functioning web API mobile experience for my company, Zarly, in about two and a half weeks. Can everybody hear me? We saw launch at South by Southwest. It was a rather interesting experience. It was more or less an exercise this week for the Ravlers. This is not an argument against mobile app architecture. This is merely just kind of a seed organization on how to put it. So I'm DC Ian on Twitter. I'm the founder of Zarly.com. Founder of Zarly.com, I thought it worked really well because Minkazi is a local brewery. I really like looking forward to tasting something like that. I'm also a nomad. I've lived in ten different places in the last year. I don't really have a home anymore. I'm just kind of circling it around making friends with people with Ruby app. So let's talk itinerary. So what we're looking to do here today is basically put together a quick, basically a rack application. Incorporate an API layer with rape. There's some authentication in there using Ravler. And then do some CMLQ messaging to you. So we all start chained for this. Rails, Sinatra, Petrino, which I have been very fond of right now. Grape, which is API layer. And ZQ drip drop. Anything else you need to do, just do the rack. So just a quick overview for people who may not know what these are. Sinatra is a really sweet DSL on top of that. Very clear. I think it's very semantic. So you know exactly what's going on. What you're responding to. Petrino is built on top of Sinatra. It adds a lot of the... At a lot of the web stack, you don't get with Sinatra. So some of the things you may be familiar with. It is an awesome Sinatra inspired DSL. It's written to be kind of an API layer. I guess Michael Lee was going for something like Grape. And then I went with Grape as the name of this. But it's fast as hell. And it handles formats really sweet. And in doing the source definitions. ZeroMQ is a high performance, a secret specialty library. I stole it straight from Wikipedia. It's a really good article. And it's good to see the queue. I'll get you a little bit more about it. And drip drop is an abstraction DSL library for wrapping events. So how do we bundle all this together? This is an initial interface we have called RAC. As a Rails 2.3, and I'm probably wrong about this. Was it 2.2 or 2.3? 2.3, okay. We ended up switching over to RAC on Rails. Anyone else who knows it as well. And RAC basically provides agnosticism between the web server and the Ruby game. So getting started, I tend to prefer Petrino at this point. Petrino's is a Rails conference, so I did all the examples of Rails. But it either just basically starts up and up, or we want to buy it. Real quick, for people who don't spend enough time in RAC, this is a, our view is kind of what RAC is driven off of. So if you look at the default with our view, or for Ruby, or sorry, for Rails, it's pretty basic. So let's get to mounting some stuff. I prefer RAC Cascade. There's a couple others. There's a RAC Builder and a RAC URL now that you can use it. This is basically just going to cascade through each of the apps in sequence. And Cascade is basically terminated and returned back to Ruby 2.8 by the first application, not returned up 4.4. So here's just a real quick skeleton for Grape. See one of the nice features that it does have in its version. So it'll prefix all of your requests that you want or whatever you'd like to use. This is a nice one. This is nice that it, at the API level, allows you to duplicate old ones. It doesn't have any resource examples in this, but you'll see one later. You can see that basically returning a hash will depend on what format you send it in for 8. It doesn't really care. It'll turn it into JSON. So this is a big one. This was kind of a, maybe my existence for a little bit, of getting shared sessions working across all of these applications. So the big thing to do is basically set up RackSessionCookie. There's some modifications you have to do to Rails, session management itself. But the big thing is that you have to use the RackSessionCookie. The rest are optional. So add an awnt in, notice these for the RackSessionCookie, and then just basically use a RackMillware. It's really, really nice to see yourself with this. Just basically specifying your providers. Here I'm using Twitter and Facebook and password, but there's pretty much the support for everything out there. You have probably 20 or 30 different applications here. So let's modify my API. I basically created a shared module that we could put any of the login session management code in. You can see that on the right. In our controller, just basically include the shared module, and you can create this as well. Notice you have to wrap it in great in a helper's block, and just basically have to define the component. But overall, it's pretty much the same as something you might get out of the box with some other user management library. It'll promise you how to build it yourself. So, on and off, it's going to give you right out of the box basically map to a bunch of slash off, slash whatever the provider is that you give it. So, doing your links, and use, you just basically specify blogging by Twitter, or wherever your provider is, and off slash whatever the provider. And you do have to define a callback though. So I've done this one in API, but you can really do it anywhere you want to in Sinatra, in Grave, in Rails. With, particularly with Twitter, particularly with Twitter or Facebook or anything else, basically can assume that they've pre-done all of the user checks for you. So you notice here, I just basically I'll show you in a second, but here on the Twitter Authenticate call that I've done, we basically just either try to find the first user or we create one for them on the spot. On the Authenticate, I'm just going to give you a off hash with a bunch of information. In this case, the UID is going to be the app to your Twitter ID. And then there's a user ID, both hash of the game and home page, profile image, anything else that you want to store. So after we've set this up, basically this is the workflow that On the Authenticate is going to provide for you. As soon as you get it off Twitter, it's just going to basically re-react to you straight into Twitter, and then Twitter, you basically pass it in a lot of callback, which is all done by Avnan. It sends you right back to your callback URL. Pretty sweet. And yeah, seriously, Kudas is my go-believer for putting this up there. This is great. There are device binings. I have not been in work. I don't know if anyone else has done kind of what we're trying to do here with the rack session cookie stuff. There's a lot of hard-binding, there's a lot of hard-binding in the device to a specific session hash object that it would take a little bit of hackery it looks like, but I'm sure it's possible. So, event machine and drip job. Basically, getting set up with DripGuard with DripGuard is pretty easy. I believe there's a brew install as well, but I took this straight off his GitHub account here, just basically installing it right up. I did have to. He says that, you do have to select. So, creating a server. There's really just basically one action handling method. You declare some sort of route in the type of socket that you want to create. In this case, we're going to be doing a web socket server. I just started on 1992 because Rails is going to want to be on 3000, but you can obviously put it anywhere you want to. In this case, this is probably the most basic example ever, just to kind of get you up and going. On Open, we basically do an event machine periodic timer, and we just basically are every second sending out a message back to anyone who's listening. So, this is definitely a hack. I apologize if anyone is a little frustrated with this one. The reason I like doing it this way is because Veroku is really nice in that you can just use a Veroku.yaml file and specify which apps you want to deploy to and the environment that you want to deploy to. So, if you just basically deploy this app in two different locations and you specify two different environments, it's just up and running just like that. So, here I've just required the file since the server is starting to be in there. A really quick WebSocket example. This probably only works in Chrome and Safari. I believe Firefox 4 has WebSocket turned up by default, but you could very easily implement some sort of pulling mechanism here. Just starting dual servers, just one example. We just passed a different mail today. So, I want to just basically give a shout out to my startup here. We are about, by lease into this now, definitely looking for Rails programmers. We are in San Francisco and we've been on TechCrunch many times before. That's a celebrity list of investors. So, questions that keep in mind, I only have one copy of it. Explain what you're using a back machine for. So, using Drip Talk once, the ZMQ machine. It's a really nice fancy DSL around ZMQ machine, which is built on top of that back machine. We're not really doing anything crazy in the back machine itself, but just use that for the underlying rotation. So, in session initialize, I think it's the only place you have to change it right now. It has its own cookie setup and you just basically change that over to use back session cookie.