 Let me go ahead and introduce myself. I'm Blake and I'm the creator of Snatcha. I started in about two years. I work in Oracle. How many of you have used it? So, again, I was supposed to work with this company called Blazeless, and we were doing all this crazy stuff in the second five that I really didn't like it, but they had this, they gave me the standard pitch that this new project that we're doing for our company was going to get like, five in request per second. You know, day one on launch. We got about ten. But I had to prove that my system could take it, and I don't know where I'd be at the time. Where else was a little bit bulky? I was hosted on Engine Yard. Back when they were a slice, and I think I was it. And I was working with Ezra and, you know, he had showed me Merg and Merg was like this directory structure, and it still had the NBC and all this stuff. And I was just like, I got like three rounds I need to do, man, and I don't really need all this. And so I kind of tried to write a little, you know, ERB thing, and then Snatcha was born. Get that. So, I just, I kind of want to go with like the basics of Snatcha. I want to go for just a couple minutes, and then I want to get into something that I think is really cool is becoming a very emerging path for people doing, which is including snatching in their jets. But let's get started here. You can find it on GitHub, it's Beems or any. I've been doing it for years, it's 2001 for Rails. But what Snatcha does that I think describes the best is it tells the story about HTTP. When you read Snatcha, or when you look at HTTP, it's the most basic request. This is what you have, right? Because I bet it's a lot of work, so you don't have to do that. But if we were to look at that and compare that to what Snatcha is, the exact same thing in Snatcha would look like for response, whoops, looks like that. Looks just like it, right? So it's just the only difference here is that I actually got responsive. I'm describing exactly the response I want for what the HTTP is supposed to look like. It's very simple, very concise. Obviously, I'll get into how those things work a little bit and how that matches. I'm just going to be a little bit done in here, but I want to show all of that. We have a classic Snatcha. So in order for me to show you how to do Snatcha in a jet, I'm going to show you a classic Snatcha that I'm going to show you so you can do Snatcha. Classic Snatcha. You start off by creating a HelloRD. You require RubyGems, Snatcha, and you do your git slash, and you enter it at that stage. And run it with plain old Ruby. It's started up, then you get your browser, and it's running. So why use Snatcha? Why would I even bother with this? I've got Rails and Dan was saying, you see, I need the same stuff about Snatcha. I've got Rails, man. I don't need this. But the thing is that this is small. It's very, very tiny. The code base for Snatcha is very, very minimal. The code base on our Ruby will use the core of Snatcha. It's like, I think when I ran it through my breath and all this stuff, it was like less than like 700 days out of line to go. So it's very, very fast. Right now it is the only microgrammer out there that is the fastest. You can get, I mean, once outside a barrel rack, or maybe have a couple of if statements in your rack apps, once you need a little more proof, then you need Snatcha. Snatcha is the fastest. And what do I mean by that? How do you guys just use Rack? See, this is where, okay. We need to see more hands coming up. Because Rack is so important these days, for all of you at the top of this object, that Rails is now being, you know, a rack, it's based on Rack. Merge has been based on Rack. Snatcha has been based on Rack. Waze has been based on Rack. All of these are based on Rack. And if you don't have a real understanding of how Rack works, you're not going to be able to utilize these tools. How does this work? I mean, understanding Rack is so important these days. So I highly recommend all of you learn how to write a basic, helpful Rack app, and understand the Rack couple, understand the request objects and the response objects, and just how to really just work with these things. And then learn about the older, as well. So hopefully next time I ask you some questions, we'll see more hands up, because understanding that is really, really good for the best. How do these take off? It's really important to work. But why, I'm kidding, it's still why I want Snatcha. It has a very strong focus on HTTP. You don't hide it from you at all, right? Your URLs are there. You do not have link to. I'm going to use link to in Rails. Right? Right? Link to. But that's assuming that you're linking to an action view, or a modeling controller, or an action controller in action. I'm sorry. It's, it's, we don't, we just write, write an, you know, write an action. Don't worry about these helpers. HTTP caching helpers are built in. How many of you have done HTTP caching? Not real caching. It's a P caching. Right? Like a varnesh, maybe Rack Cache, all that stuff. It's not just how this is in there in Florida, it's cool. But again, if you're unfamiliar with that, I've been looking into things like Rack Cache. I would start with that, take a look at Rack Cache as well. Content negotiation is built in, but the thing, this is the cool thing about Sinatra, what I mean by it's a great Rack Citizen, is that we have a content negotiation we built in, but someone wrote this really cool piece of middleware that I can just stick right in front of my Sinatra app, and it will tag on. If, if the URI does not have an extension on it, it will tap it on to that, to the path of it. So then now in Sinatra, it's got this, it's got an extension to it. So now I can actually do a two minute round, based on that extension, versus having to actually have content in which each person is about it. So when people start coming out, and you want to use the Rack middleware, you should strip it out of Sinatra. We're leaving it in front of you because it's called Rack Accept. For those of you who haven't heard of it, it's in the Rack and Trip. If you go to github.com, slash rack, slash rack, dash and trip, you'll see it in there. It's really cool. It's still a little new, so we're waiting it out, we're gonna get up and contribute to it, and make sure to put, hopefully most rack has a nice, because middleware can strip it out of Sinatra. There's no reason for us to have to maintain that, and that's what we love about rack. We don't hide rack from real well, but every year we brought Sinatra top, you're always gonna get a rack along with it. So, no boilerplate. You don't have to have a controller just to get started. You don't have to have a nail and database can fit. You don't have to have a 72 files that Rails generates for you, just when they start, but it's all on. It's none of that. Dead simple configuration. If you look at how configuration works in Sinatra, I'll show you some examples for you soon. It's just super, super easy. How many of you, whenever you're writing applications, you have custom configuration information. You need if you're at it. Right, I should see you at home. Right, how many of you just start when you drop in another YAML file and do the YAML file reparsing and then get it out of there in a hash? How many of you do that just to get the custom config, right? You know, in Sinatra, we have such a basic system for configuring Sinatra itself that as long as you don't use any of the few keyword configuration options, you can use the same exact package to just keep your own configuration information in there and have the Ruby instead of having the YAML. So, there's smart configuration as well, which you'll see an example of soon, but if you are daring and you want to go for the Sinatra source, take a look at the options for app file and for run to see how those work. Docs. Sinatra over the past eight months is just kind of a more of a Sinatra configuration with its documentation. You go to SinatraRB.com and take a look. It's very, very, the guys in the work are really, really hard. We have guys that just, they love writing documentation and just doing an amazing job at that. Plus, let's get other patients as well. So, if you don't like it or you want to contribute to it, it's simply for free, but it's simply for free. But it's a great bus to go to play. And again, a large, great community. All right, also, Extending Sinatra is super, super easy. We've got this really cool system in there after creating. We're extending DSL and we're also extending just helpers to general. We've been adding really cool hooks in there. Like, around added and also some other cool things, which I'm not going to get into today, but if you want to come to Minneapolis and you got curious and immoral and copy to show you. Rack is the only dependency. If you need hammer or ERB or erubius or whatever, you absolutely can use it. Second, you use hammer. The hammer helper inside Sinatra, if you do not have the hammer itself, it will die out on you. But we don't require you to have it installed. There is no Sinatra-hammer. That's what I love about it, right? And there is no Sinatra-ERB, and all these other crazy gems. What I was enraging for inch, Jeremy Alehi, he did this really great presentation on why you should write your own framework before using another one, which I completely agree with. Why on the original, you just start with RAP first, then learn RAP. It only moves Sinatra when you really have to. But he said out of all of them, the lead to F2 long ratio was the lowest on the scale. So I was pretty proud of that. When you use it, how many of you have fired up rails and created a controller and then a model and then sat and stretched your head when you need to script generate? Why am I getting this controller? I only have one, and I'll just call it lead, right? How many of you have done that? Five. Why are you creating a controller for something that's just not even really a controller? You only get PC at these points. Maybe you only have one model or a few models, no models, right? Start with Sinatra. Maybe I have two or three views. They're am or you're d, or whatever I want, but it's not, I don't know. Start with Sinatra. Pretty much I just made this point, but I usually say, if you want to start with Sinatra, I might remember you starting with any application. But how can you understand RAP? I need to practice that. Once you understand RAP and you learn how to build a RAP, just prepare for RAP. Starting with Sinatra is okay when you're going to have more than a couple of routes, but you need to use the RAP box really fast, and you need to point it out. But otherwise, usually you just take RAP and do the trick just for one route or something. You need reasonable apps and reasonable resources. Here's a really, really cool thing about the United Series of Sinatra. It's Sinatra not only can be your top level application, your only application, but it can be one of the many Sinatra applications running in the same VM. It can also be middleware. And how many of you have gone out there? I think that's the ratio here. How many of you know what middleware is? You've heard that term at least, right? Middleware? Middleware allows me to take a simple, a very simple step. I have a class that has to respond to new. New has to take at least one parameter, which is app. And it must respond to call, which takes one parameter and call must respond to the RAP top. You go to the RAP stack, it's that easy. I know I'm trying to, without a slide, it's kind of hard to imagine. You have to not look at it. The cool thing about Sinatra is that it's got something that you can call forward if I'm going to get into middleware and then two. So a lot of you ask me, I know I'm starting with Sinatra, and I know eventually it's going to be Rails, and how would I do that? Or is this going to be a big pain in the butt when we have to do it? And the reason now that we have Rails metal and Rails is moving to, you know, to be RAP-based, cool thing now is that you can take Sinatra, and it automatically knows if it's a piece of middleware or if it's the actual target application for RAP stack. If it knows it's the target application, it will respond with the top off. If it knows that it's a piece of middleware, and it can't find it, it can know the Rails match and it will forward to the next available application. This means you can take Rails and stick it on the business end of Sinatra, and then start piecing and pooling those little routes and those little pieces over into your Rails app without having to migrate the entire thing. This is really, really exciting stuff. Also, we need speed. Another great thing is, let's say you have a Rails app that's already been written, and now you need a few Rails that need to go to you and you need some cash and helpers, and you need some nice things about Sinatra, but you don't want them buried inside of Rails making Rails. It's going to carry your rooms with some speed. The nice thing now is that I can actually do a reversal that I just said and create a little piece of middleware that's Sinatra, right? It's like three lines, you go to do it, and then stick it in front of Rails and after about those requests, we'll just stick it in against the developers. Who's using it? I don't know if you're using it, obviously. I don't know if it's one of the biggest funders of Sinatra. Both for Sinatra Team, there's myself, Ryan Tanaco, both work for Rails, and I think in two days, we can just do things in Sinatra and have fun and play in the community. So... It's awesome. Yeah, GitHub uses it for a lot of their internal stuff. There's not many of those new download stuff that they've been doing, and then there's the same credits that's because there's a Sinatra in the background process again. GitHub Services was one of the original large-scale Sinatra years. So I think how many of you use GitHub Services, which is like the lighthouse, or Twitter, or the A-bots, or anything like that. So, I mean... So every time, think about how many people... There's a whole lot of people using these things. I mean, thousands and thousands of repos are all open to these things, and that's actually being counted in Sinatra. Every time you do something that doesn't get pushed, it's a nail in Sinatra, and that's when you have to lift it to your IRC channel so that you can look in closely at all those messages. SCAPS is a fairly new application. We're using it at the open, but it's open source. A lot of you have streamed databases to transfer trans-meric pipelines, streamed databases back and forth via HTTP. It's a really good project. I'll have everyone take a look at it. Integrity. How many of you have integrated a continuous integration tool? Dude, this was like... People told me about it, like, months after I started using it. I can't help you guys with that at all. It's so sick. You've got to check it out. Let's see. And there's so many more. I'm going to take a look at Sinatra and review that comment for those other questions. All right, so now... So now I want to talk about... I don't know if I can do that. I want to talk about using Sinatra to give you a chance. How many of you have used, like, like, little tiny micro apps or something just to draw a little bit of the idea of a post, just to, like, I don't know, get some nice UI or disabilities, maybe system information or, you know... For instance, things like, let's say I don't want to build any GitHub. Right? I travel a lot of planes a lot. I don't really always go out to America, so I don't have wireless access. I pull a higher lift heart when I get jumped. So... I want to be able to create a little app. So before I go on, I'd like to be able, for anybody who ever wants to use it, to just simply install a jam, and then run this server. Sinatra is really great for this. Maybe, like, a local plug-in with Wiki or maybe get memcache utilization programs to sort of pull a little app. I'm going to take Lynette, which is an Amnesia, but then Schwartz. Shows, like, really nice pretty graphs about your memcache, this ratio, and all that and every utilization. Maybe I can figure out what would be a useful GitHub plug-in, right? So what we're going to do today, just a few minutes of time, I work for a company in a big, cute farm, and they've got me firewalled from clear. Right? But they don't want me reading those tweets, I need the company tied. But I do have a Roku, and I can deploy that really easy, and they have a lot to Roku.com, so I can do a little firewall reversal. So this is what it would look like as a classic application. This is what it means it's the one we need to actually clone down and then set into configurations. So, let me look, first off, if you look at set, use an Amnesia password. That's what I mean by that simple configuration, right? Like, that's custom stuff. I'm just setting that. I set it as a clock as well. That's one of the things that will only execute when the value will be returned when I ask for it. It's kind of like defining a method, but a little bit nicer for configuration purposes, because now I don't have to ask people to create this couple of methods, right? And then they have to be here from class and overwrite it and all of this. It's already, it's a nice multi-assault for this. And then I'm saying, I've got my little clear gem that I'm using, whatever one I set shoes. I said I'm very involved, so you get to explore your username and password, and then I'd be able to handle it to my indexing people, right? So, in order to get something like this for running in a gem, so I'm going to have to do three things. It's this simple. I need a require, where it says requireSnapDrop, I now requireSnapDropBase. So when you use snapdream, you're running in the group, and the reason you want it is immediately, because you're without having to specify there all the learning that, because this is an app exit, how many of you can use that and exit things to know what they are? Okay, that's cool. It's just like, whatever, at the very end, right before you exit, exit people's prop, right? You also have to take some advantage of that, and it just says, right before you exit, run the server. How many of you use TestGender? Okay, right. So whenever you run it, I mean, when you run it, it's just rude, but everyone's going to test magic, or something like that. Let's suppose it has an ad exit. So, when you requireSnapDropBase, you're no longer requiring the regular, so not all the other, the extra nice stuff that comes with the classic app. Which is automatic, I think, for you. All those methods, if I am on main, will disappear when you require SnapDropBase, so it's just playing with all the time. Because in your gem, you're not going to, if you want people requiring your gem, you do not want to have all those extra web TSL methods on there, because they may not be using it for the web app, or they may be trying to use another library. So then, the next thing I need to do is simply this, indent, you know, wrap it in a class. It's easy, right? So you knock on your web, and then you go to the web, and then American SnapDropFault. So SnapDropFault is, is a SnapDrop application with sensible defaults for you. Right? These are sensible defaults for web apps. They're not sensible defaults for middleware. If you need middleware, if you're trying to go middleware, you're actually going to go to SnapDropBase instead. Because now you have to insulate to the light. You don't have to use all of these config, and all these extra things for you. So, if we want to run it from an executable, we want to have like, you know, bin not Twitter, in our channel, right? So that someone can want to install the channel, just like any prop, just say, not Twitter, and have a server running. This is what you would do. Set that Twitter, what is that user password to say like, you know, the first argument, first and second argument, and so forth, but the family script. And everybody's going to say, well, now we're running the defaults on port five, port five six seven, and it'll automatically you can pass a hash in a run to get a separate, to get an extra license and get BV, but the defaults are usually just enough to get this running. The thing is, I want to be able to deploy this to passenger, right? And in order to do that, I need a config. Are you, I mean, how many of you are using passenger and all of that? Right? Okay, so that's wrap. That's very, very, very, very wrap. But you can pick our user if you want to, or if it's over for passenger and you want to be able to. So, the nice thing about this is that the username and password are going to be in my config, aren't you? They're not going to be, I'm not coding a repo now from GitHub, changing, putting in sensitive information saying set username, my actual username and my actual password, and then having to put it in a private repo on GitHub. What I can do and then upgrading becomes a huge pain in the butt too, right? It's, you've got to do three basic, you've got to keep a constant with it. It's just easier to upgrade your gem and then just have the same thing with you all the time. So, what we can do is in our gem, we can create something called install.logware. And all that does is, we can figure out you, the current working directory and wherever this handle's run. And also, obviously, in .gems file for easy deployment to root. Sorry, I haven't changed the plus for root, but I got to do it. So, the .gems file on RU, how many of you saw in the long post, how that works, right? And it also can deploy all that in installs.gems.org. And this is nice because now your repos are really, really tight-handed. It's the only thing in there for this to configure in the .gems file. It'll actually install the, it'll install the .tweiter gem. So, I can figure out you look much like the, the not-tweiter execute one, right? So, instead of not-tweiter.run, I'm saying run This is my way of telling RAC. This is my target application. This is, this is the main one. This is what I want to be one. Okay? Got gems file, looks like this. And because I put my, my gem upon, on get up, it's going to be in this RU, not-tweiter, but then specify the source. It's just get up. To simply deploy it, I end it. Rebo. I add everything to it. I end it. I already create, which automatically adds. I already promote for me with the application that was created. I don't specify an application in any way because I just like all the really cool, fun names that RU can generate for me because I'm going to get in it later. And then you get to show it faster and then a little bit. That's it. Now it's deployed and launched. It's in production. It's got partitions. It's got connections. It's got everything I need. It scales loudly. It's, it's significant. So, and I don't have to manage it. So any questions about that? That was just one little feature I kind of would show off, but now I'm starting to get into this. Any? Nope? Okay. I just want to talk about three of my favorite features. That's not sure. Which are, starting with pass. Pass is a cool new one. They go night series, right? So let's say I have a route hit. I'm inside the route. Actually, that block has been executed. But in the very first line I've realized, wait a minute, the route hasn't matched. The route hasn't matched. But let's say something like the close name doesn't match. So, if you remember this in the very first line, close name uses pass. It's just an implementation that says pass and less or something like that. Close name, right? This is a really nice little helper for me. But what that does is it'll pass down the next route. So then the next route will get it, it'll ask it to go through the hole, go through the hole, which is all over again for that one. You can continue on down the chain. And there's forward. Forward is when you're a piece of middle there. I can say forward. I haven't done my job. I've done as much as I can. I'll let the next route go down the line. And this is where it really gets caught. This is where it gets just totally caught. Because when Sinatra knows that it's a piece of middle there, it'll automatically go forward before you know where else it has to pass. But if you can explicitly forward and assert the back or sort of tie, you can do so just by explicitly saying forward. Use. Use is a basic wrap connect. This is how you install middle there in the middle of the pipeline. Use does is use me because Sinatra knows we just re-implemented use inside Sinatra. So that you could actually use use and use middleware inside the class cap without having to break out into bare rack. So it's it's yeah, it's cool. So these are my three favorite features. Those of you who want to get into more of my resources I think it's notjrv.com. I would definitely again go to get on that com and look at crack slash where those understand that. And also take a look at how to make this wrap cache. Because of all the nice caching colors that we have in Sinatra and burning HDD caching. Right, wrap cache, you just say very beginning of your app just say use wrap cache and that's it. Now you have HDD caching built into the front of your application. Right. Without having to install launch. The nice thing about this is that it also it's so it's so bare metal down there's this basic rack. This rack is about 4,000 watts per second. Right, it's a enormous amount of watts per second. You know, you just get some out of the front of that now. So let's go down a little bit because it's a little more complicated really. The thing about wrap cache and still down there in metal is that now it's like if wrap cache realizes based on the caching the caching rules you can get any cache from the file store you can get it's all it's all very configurable but it's just a random memory hash right out of bounds. Now I got about 4 minutes and 30 seconds left. Are there any questions? Anybody? You can look out some of these. The easiest place to go to to learn that I mean is the rack documentation. I think it's rack, it's rack already before it's at work and then somewhere in the middle of the screen it says here's some documentation and then it's like that now it's been 2 years to play that I mean I was already gone there There's other documentation it's really hard to find in the middle once you find it I would also the link right before is the stack I would take a look be sure to look at the stack and understand the stack too but yeah it's still pretty poor baby if you're I would say okay and the next is body which responds to each and the last is going to say hello but this is this is really really basic stuff so to use middleware it just looks like this I can say class middleware I don't know you know I'm just saying I am right one more method which is define all that takes 10 the environment hash the environment hash is all over each of the headers and all of the information about the request and then the easiest thing to do for you can say like I don't know like let's do like a benchmark right VM for example and then we'll run that we'll say add app which will now get passed down in the pipeline to the next app it's a very simple basic piece of middleware and then that's the target application so every time I run that application it's going to run a benchmark for me is anybody confused by that does that make sense to everybody cool that's how easy rack is which is that simple I just want to mention there's actually a great series of screencasts that are free and it goes all the way from the hello world rack app all the way to re-implementing Sinatra it's on it's a blog called Remi R-E-M-I and then to search Remi Rack here it says if you search Remi Rack there's a good screencast that'll show all the basics everything from the basic barefoot app like this to re-implementing Sinatra or ask me because those are mine oh are you serious oh there he is oh I'm sorry thank you so that's one of the other things that I want to talk to you about is that not only how long have you been like doing that but one of the 14 number things about Rack is Ryan's makeover where he also used Sinatra so we're reacting to both communities so we'd like to keep up with you and we'll all marry so I mean actually any more questions