 So one of the things that I realized watching the lightning talks last night save your keynote presentation on the first slide I saw like two guys below their jokes by loading it up when they plugged into the projector and it was right on like you know The punchline So this is actually my first slide My name is Adam Wiggins. I'm the author of rest client This handsome devil over here is Blake Miss Iranian. He's the author of Sinatra We want to talk about how you can use these tools to build web services and the first Before talking about what the tools are I want to talk about what they're for To do that, I want to tell the story kind of a vali discovered Sinatra and that story is actually kind of the story I think of Every application that's ever been written When an app is first born, it's clean. It's well organized. Maybe a few dozen classes It's small and beautiful Now if the application provides value people want new features course you write new classes to support those features new views new tests over time it grows organically and over the course of years it proceeds into its middle age and Eventually it seems like all applications end up in the same place Which is hundreds of classes hundreds or even thousands of views this huge test harness that takes forever to run in short a mess and Having lived through this a few times and being working on a new application that I was seeing starting to grow in complexity and I felt like God can we escape this cycle is there a way out of this or is this just always where we end up and That's just the way of it And I had a small epiphany thinking about that which was just that when programmers want to deal with complexity what we do normally is You know if you had a really complicated class for example, you would break it apart you'd break it into smaller pieces That's what we do is break thing break a larger problem down into smaller more manageable chunks You usually we think of applications as being kind of atomic monolithic You don't really break an application down that it all needs to share the same code base It needs to share the same database But actually you can break an application apart and when you do the result is web services now You might think of a public web service probably the most famous of which is the Amazon s3 and But there's not really any difference whether it's an internal or an external service if you're making a service That's internal to your company or your product. It's got an API. It's got it's a standalone application Public versus versus internal actually doesn't matter as long as it's a standalone app Doesn't share a database But that is not in itself a complete end product. It's a piece of a larger hole like in the case of s3 It's providing you a resource by itself. That wouldn't be useful to make an it for an end product It's it's a tool for something else So having realized that web services was a way to deal with this monolithic monstrous app problem that we always seem to face I Dived into trying to divide up my current project this way And of course being a Ruby developer when I go to make a web application I want to carve off a little piece of my big application into a small one And of course I reach for the tool that my big application was written in and that you normally reach for which is rails But and I built it that way, but then I noticed kind of it didn't feel right and I feel As I was looking through it I saw that my service which was actually pretty small bit of code maybe 20 or 30 lines of code And then I compared that to all the the boilerplate code that sort of came out of rails like out That my business logic was actually dwarfed by like the boilerplate Code and I felt like my code for my web service was being lost in the sea of like boilerplate and empty directories So basically rails gives you all this infrastructure, which is great when you need it when you don't need it It feels like red tape In short rails was basically just too much for the specific purpose of building a small web service So then I decided to go to the other extreme and I built a Bear mongrel handler nowadays what you do is a rack app at this time rack didn't exist But I don't know if you guys have ever done this but this is basically the sort of the PHP equivalent For Ruby where you make a script that just its input is the web request and the output is Whatever you feel like and it's just totally unstructured And very basic and this actually worked. Okay. I wrote a couple of web services this way and I and I kind of liked it They they definitely I didn't have the feeling of that. It was too much But as soon as it started to grow a little bit. I felt like it just didn't give enough Certainly not enough like helpers I was sort of reinventing the wheel but also it didn't give enough structure and that's of course the problem with PHP Right is that like it's great when it's four lines long But then when it gets a little bigger the lack of any sort of imposed structure and organization means that it just sort of Gets messy really quickly. So in short these were too little So I decided that what I needed after doing some research was a micro framework and there's a few out there But the one that I is I think the most popular and probably the best known is Sinatra And I think it strikes a good balance between that Providing you the structure and the and the support that you want to write a web service Or a small web app, but not being so minimalist that you just have no You have nothing no structure to work within But it's kind of weird and if you haven't seen a Sinatra app before I'm going to show you a hello world here When I first saw Sinatra apps my immediate reaction was man, that is weird One of the things that that struck me first off is like where's the class definition? There's no there's no classes What's going on? There's really two functional lines in this particular program one is the get slash so that defines the verb the the web Verb and a URI this case slash And then it gives a block that will execute when that action is Hit by a client and in this case and the return value of the block is what will be sent back So in this case, it's just a a static string hello world Another weird thing about Sinatra that I noticed right away is that the way you run it I was used to script server other frameworks have their own standalone binaries when you go to run a Sinatra program It looks like this And I was like whoa, that's pretty weird But really that shouldn't be very weird. I mean, this is Ruby, right? Why wouldn't we run it with Ruby? So that's kind of interesting. Let's look at a slightly bigger example to Or or a real example I should say The everyone's favorite the blog This has got two actions. The first one is a post to slash posts and Here I'm assuming that I've got an active record object defined in the lib posts Could just be a you know a two-line file there And when I get a post to slash posts in the block, I'm going to create it with the params params being a Variable that Sinatra passes you and then I'm going to use a redirect to redirect to posts and the post ID And right off the bat one thing you might notice there is that there's no helper to construct your URL. I just make it And again, the struck me is pretty weird at first, but it grew on me pretty quickly URLs are actually not very hard to build And in a lot of ways this is actually shorter and easier to understand and using some sort of helper So then the second action is a get Here we see a variable inside the URL So I'm getting slash posts slash ID and that will create a named variable inside the params hash And so I can do a post dot find just the way that you might do it in In any framework that's using active record and then I use the ERB helper to render the posts template I find it really impressive that you can put what is basically a real Application, I mean it's a very small application, but it's a real application And it's complete minus the view and and and the the database schema definition This is a whole app and I can fit it onto a slide with 36 or 48 point font or whatever this is I think you'd be pretty hard-pressed to find another web framework or way at all to build a web application That lets you do so much with so little now. That's not to say that Sinatra doesn't have lots of cool features the required bullet list here templating with a bunch of different options like ERB and Hamel or XML builder You can do full testing with whatever test suite. Yep, and the like before filters helpers Defining error handlers for different kind of errors Inline templates, which is a really cool feature. I'm gonna come come back to that in a moment code reloading when you're in development mode So really nice HTTP caching Using e tags and and last modified and so forth And of course, it's a rack Framework which any good framework these days is but Sinatra takes even more advantage of it than just sort of letting You know as a way to to use mongrel or thin or whatever But it actually has inline middleware and a really easy way to take the cool middleware That's available for rack and integrate it into your Sinatra app in a more direct way But overall the thing that I loved the best about Sinatra and made me choose it over all the other choices is that it has a commitment to small That I think is unparalleled and you see this in the app itself The you know the the interior that we've already looked at you also see the fact there's no directory structure There's no boilerplate. There's no routing This is a minimalist nirvana and I find myself going more and more down this path of minimalism and trying to do more with less and fewer lines of code And so that makes Sinatra really attractive to me And it's not just your Sinatra apps that are small It's actually Sinatra itself that is small one thing that you'll notice if you go on github and look at the code There's actually when you require Sinatra. There's really only one file Sinatra dot rb and Just out of curiosity. I ran some line counts on a couple of frameworks Rails of course is a is a heavyweight It includes a lot of stuff that they had to write themselves at the time So it might might not quite be fair to put that up there but Murb core remains Camping which was kind of kicked off the micro framework Style wise why the left key stiffs Framework, which is incredibly small and does of course all kinds of meta magic But Sinatra is actually smaller than any of them even camping and of course it does a lot more So it's it's living the principles that it's That it's that it's feeding you the application developer And one last thing about Sinatra Is that it is a proud Ruby citizen And we've seen that kind of already a little bit in that how you run it you run it with Ruby but You know when rails was made the Ruby ecosystem was not as diverse They had to build a lot of stuff or m's and Templating and test harnesses and all this stuff since then the Ruby ecosystem has grown so massively And there's just so many great options out there for or m's and templating and tests and specs and JavaScript libraries And so forth You know you can go the route of having sort of adapters for each of these Things you might want to use say each ORM Murb does that I think Romea's does that the thing that Sinatra does that I just love again. It tickles that minimalist that minimalist fetish of mine is just that there's no adapters, there's no code and Sinatra that that Helps you define which of these things you can use With with you know, there's a few few helpers here and there for certain Templating things but for the most part it's just like you just use it right you install the gem you require it and you just use it And that to me is is pretty powerful and it makes me feel much more like I'm writing Ruby Unless like I'm writing some special world within that the framework that I happen to be using So I want to show a couple of examples real quick that are open source and you might have seen and Blake knows more about these than I do so I'll probably let him talk about them a little bit Yeah, okay, so this is a kid wiki. I wanted to show this example because You know as Adam said that Sinatra is very small. It's it's tiny and because of that if you look at get wiki again The 355 lines of code it's actually a really really cool a little wiki system that uses get go figure But that's 355 includes the views by the way. That's everything nice so Anyway, the because because it's so small and was so easy to just look at it's all in one file If you go on github and take a look at the network graph It's it's been forked all over the place and the network graph just goes like this I mean it's just everywhere people just started with it and went off in just a million different directions with it and I think that's a testament to The the simplicity of Sinatra because it's so easy that you could just go fork it And you know just start either you don't really have to dig around too much to really understand what's going on with the With all the routing and then in the app itself because Sinatra apps usually the Sinatra part of it is so tiny Anyway, yeah, I definitely go take a look at that. It's it's it's pretty killer. I Wanted to show off inline templates This is one of my favorites because I'm just a huge fan of keeping everything in one file But as you can see here that we can I'm taking advantage of the the end of macro there and being able to Using the add-at-signs we can actually define templates multiple templates in the actual Sinatra app file so here you can see you know you've got your layout in your show and And I just think it's pretty close. Yeah, I'd really like to show off I didn't know about this before I came across this and get wiki the underscore and score end You guys you guys know about this This is actually a standard Ruby thing you can just anywhere in the file underscore underscore and underscore underscore and then everything after that is ignored And so then you can read your own file and use that to do whatever you want And Sinatra cleverly uses it to define some views and here again We've got not only the action, but the view for a complete wiki page This is real code from get wiki that fits onto a slide. I mean actually Actually the end it puts all the data it puts everything after end in the data constant capital Data But I did a little bit of magic with a caller on this because I wanted you to be able to wherever you actually call using file templates I want it. That's the file that has the templates So you can have if you have multiple Sinatra apps and they're all running in the same thin And you need different templates, but you want to use in file templates So I kind of I did some little magic there But but yeah, I just because of the fact that I can ignore all of that and then just split on it and take everything off the bottom It's pretty cool This one. Yeah, this next example is something I put together recently get wiki. Of course It's just a small app, but this is actually a web service And Sinatra just turned out to be completely perfect for it 61 lines of Ruby a little bit of view It's kind of a cheat because the graph is in flash, but This is actually what I mean when I say web service. That's a piece of a larger thing This is not a product in and of itself Really quickly rift graph is just has a rest API You can just post a value to it and you can post these values over time like from a cron job or whatever It's just kind of fire and forget And then you can go and view a graph of the data that you've stuffed in there And the problem I was trying to solve here is the thing we're putting your metrics data inside your application Database is one of those things that makes apps get so huge and unwieldy over time Is of course you always want to track some stuff you put them in a table in your database now your database is huge It's really annoying So this is this is a potential solution to that and it's open source you can install it yourself Or you can use it as just a web service on its riftcraft.heroku.com address But it's it's a little piece of something that you can use elsewhere and it's it's totally standalone It's got its own database and it's its own application But it's but it's something that would be a tool to be used elsewhere Alright, so get up services. How many of you use github? Yeah, that's what I thought So now you know whenever you you know you install like lighthouse or all those posts all those prefabricated poster C folks that you have such as Lighthouse Twitter, you know IRC all of that. That's all it's not trap That's if you go to PJ Hyatt's repository. It's github services and when they open source that it was also again I think it was a testament not only to how awesome github is because you can just fork and they Took advantage of their own software to go and say hey go write all your own post-receive hooks and we'll incorporate them in but if you look at the Sinatra in In github services, it's like four lines of code. It's like this big everything else is all vended off For all the Twitter libraries everything It's it's really cool There was actually a really cool trick in there that someone one of the guys who forked it and refactored it down They put yield inside and I learned something completely new about instant C valve that you could do all this yielding and stuff It's pretty crazy But and one really interesting point on this too is that you know Benefits of web services. I'm speaking mostly in terms of like just the cleanliness of the organization being able to break things off into pieces Into smaller apps, but there's actually like scalability benefits Obviously, if you can run apps you can spread those out easily across machines in a very clean way Since they don't share a database and they don't share and you've got security benefits and in this case They're running something that is potentially user-contributed code that they're running on their servers But they can run that as its own user on its own server. It's very much isolated in a Unix way It's using the Unix security because it's running as its own user and it has no access whatsoever to their to their main database right and also The the traffic that this thing takes is pretty substantial. There's about 5,000 people And I asked to get up guys for this number there's about there's over 5,000 users on github that do use take advantage of these post receive hooks and You can just imagine the amount of pushing that gets thrown to these things and there's only I can't remember the number But I think there's like just a couple model rolls running with running this one app on that server and it just it just stays there So it's it's pretty cool This last example is one of my own that I just threw together recently. I recently realized that blogging software totally sucks Took me a long time to realize this, but I finally did and realized the wisdom of write your own blog is really Is really correct even though it seems like reinventing the wheel I put it together really quickly in a couple of days Less than 200 lines of ruby does everything I need done So I think that's you know again. It's not a service. It's just an app But you know this this minimalist sort of like Path that I've been going down. It's just been I don't know. It's just been So enjoyable to me So that's the server side of web services Now we're gonna talk about the client side and Do you see what we're doing here? He wrote rest client. He's talking about snatching and I wrote snatching. I'm talking about this client See, he couldn't get up and say how awesome snatching was the way that I can because it would just sound like bragging to me Me I could say how good it really is so Anyway, how many of you used active resource once twice thousand times, right? Yeah, it's really cool. I am it was You know that you've got the object model and you can map it to a URL and then everything looks like an object But it's really talking over the web and it's awesome and it's kind of too much sometimes You know, I mean, it's it's great when you're in rails and you're in that environment And it's just kind of fits right in and you know, it's you know, it's it's perfect for that Unfortunately, you're trying to use not sure and then you want to use active resource they don't quite play along too well together and Unless you're fall unless you're following the you know standard format the XML that active resource needs so One of the things that you can use instead is net HTTP. How many of you have tried to You know do a HTTP request with net HTTP. How many of you enjoyed it? It's it's it's pretty cumbersome and it's it's not fun and it's also too little So the the alternative Adam You know had been like he said been using Sinatra for for a little while and I Remember when he was presenting at I see HRS client He was you know, I don't mean to put too many words in your mouth But he was just like, you know, if somebody has got to have done this, you know I need to be able to just make a quick little tiny request so we wound up coming up with a rest client and I first ran across rest client when a friend of mine sent me an email with a link to this and To the to the rdocs on Rubyforge and he just said check it reverse Sinatra And I was like well, that's you know, I took a look at it And it literally is if you look at the code to do a get request. It's Get URL right like we're not scared of URLs and you know Adam and I we're totally cool with them We don't need helpers and all this we just we've got a URL. We've got a resource We just want to throw it in there and we just need to get it, you know make a quick request So that's the get request again, you can do post request the same way And you can send it, you know parameters, you know very intuitively But I think my favorite part is probably because I'm biased and because I contributed this part was the console You can actually go in it defaults to local host 4567, which is the default port that Sinatra runs on So if you just type in rest client and you got a little Sinatra demo app running Then you pop up a console and you can just start posting and getting from it And it's it's it's really cool because I like to think of it as like an interactive curl It's a better curl for us, right from the command line You can do rest client get and then the URL and then you know stream it out to to a file So now you don't actually have to go into the console You can skip that step and then use this right on the command line And if you ever need to drop back down in the command line, just get rid of the get go back in the console but truly one of the coolest things I remember when Adam put this in there and Because we work together and we sit a couple feet apart and always talk through IRC because we're geeks He had sent me this link and he showed me that this this new logging that he had thrown in and I was like this is this is killer So rest client logging if you say you can you can send it to a file to standard outs Wherever you know wherever you need it to go But what it does is it actually prints out the rest client Ruby it prints out exactly what it's doing with the commented You know what your you know the result was? You know as you can see here But what's so cool about that is you could pipe that to like if you're using a map PB copy or you can you Copy it off the console and then plug it right into a file and then hit run You know and just ruby run that through Ruby and it'll replay it all over again exactly what just happened So if you're trying to debug an app that's making recent you know calls out to external resources, and you're like what went wrong I don't know never get this just just go ahead and start up the rest client logging and it's it's it's it's pretty cool So let's go through a couple examples There is the Heroku client Take a look it's on Adam Wiggins branch. This is what this is how you did you want to talk about this? Well, I was gonna say that this is actually not interesting and that's why I put it up here The thing is almost every service out there which any company that's making a piece of technology in this day and age You've got an API and then you often want to give a client which wraps up that API just kind of nicely And so everyone ends up reinventing this same wheel And I was thinking about this just the other day as I was looking at blink sales little client They have a little class and they're named rest client And it's you know They basically end up implementing this because everyone needs it everyone needs to be able to hit their hit their API And and something a little higher level than that HTTP. So the Heroku client uses it. It's not actually interesting It's just an example of when you have a service that needs an API call. This is just a really really easy way to do that A much more interesting example is couch rest Which is done by Chris Anderson I think and this is the Ruby client for couch TV So this is how you interact with couch TV And I don't know if you guys are how familiar you guys are with couch TV But I think it's kind of the premier document database open source document database right now And of course, it's a web server. It serves documents through HTTP So of course again, you're making rest calls and again This is a place where thinking of trying to use active resource with this that doesn't make any sense at all You're talking to an Erlang app. That's a database Active resources very very constrained to the sort of the rails way of doing things so Chris told me that you know rest client was a perfect fit for what he needed He was able to make the couch TV client. So if you're using couch TV from Ruby, you're using rest client I want to talk about some of these principles behind this sort of the one-two punch of Sinatra and rest client and this This path we've been going down one of them is a word that Blake recently made me aware of how do we pronounce this? Oh, Lake Lake? Lagom He doesn't know that's the that's the answer. It's a Swedish word lagom And it I think roughly translated means just the right amount And I think Sinatra is just the right amount for web service But I think in general let's think about this when we pick a tool pick it not because You know partially obviously because it's like I need a web framework or I need a web tool or I need an email thing or whatever You obviously pick it for what it does But I think picking it for the right size is is important something that's just the right amount not too much and not too little And I think programmers are Ten towards the over design side of things and we should make an active discipline Or try to actively discipline ourselves to try to pull that back and try to try to balance that out So that we end up just the right just the right place for the problem that we're trying to solve One of the ways that we see this in in both Sinatra and rest client is Just less less class definition You know obviously classes are great object-oriented programming. It's great But you do get the sense sometimes reading Ruby programs that you know It's sort of the object-oriented programming like when all you have is a hammer kind of thing Java Making a class isn't always the right solution inheriting a class isn't always the right solution and you see this with You see this with active resource. You see this with some other Sort of HTTP clients like one release recently a HTTP party. You can't make a request without first defining a class It's the same thing with with a lot of web frameworks. You can't make an app without defining a class and classes that are obviously appropriate in many cases, but Not just necessarily as the default I think so this is something that's that's in been in my thinking Which is use classes and use inheritance when they're when they're appropriate, but sometimes a function call is what you want sometimes rather than overriding Subclass inheritance what you want is just an options hash, right? How many of you have used sequel the the orm Yeah, it's pretty cool. It's the same thing I mean you don't you don't have to define a class to just start using it You can just kind of you know just stream a hash right into DB. Yeah, it's pretty cool That's one things I like about that. Yeah, I just want to make that point I've been using sequel pretty frequently for for my apps and and yeah, I really like that you can start with that You don't make a class. You just like throw some hashers in there And and then later on if you want to turn that into a full-fledged class you can and you keep the same table in your database So yeah There's this whole question of controller object mapping and routes Versus Well, just URLs As far as I know Sinatra is the only Framework that does not do controller objects and and routing or some sort of resource object and routing where you map a URL to an object and again Ruby being an object oriented language We think we need to make everything out of objects So therefore of course you need some mapping between a URL, which is just a string a path To an object. Yeah, if you ever send me a pull request with anything that looks even remotely close to a router I will send it right back I'm just not a big fan of them And that this has happened by taking because this is so built into our thinking, right? It's like you have to have a router That's just that is a part of a framework like how else are you gonna route things? And my answer to that is don't fear the URLs I did a blog post about this a while back It kind of made the rounds raised a few hackles I think but it's just like URLs when they're restfully created. They're actually kind of pretty I think You know, we maybe we get we maybe kind of got scared of them because of the days when you know You had these long CGI or maybe like a session whatever and we thought of URLs as being this ugly plumbing that needs to be hidden But it can actually be pretty plumbing that can be visible and I find it you know that Working with with say active resource Or another thing like that that kind of hides, you know constructs the URLs for you I like it. I'm like, well, wait, what is this hitting and I'm not sure and like, you know And then you kind of are looking in your logs But it's like if you're just constructing a URL on the client side and then you say what URL you want on the server side It's just it's just obvious and this comes into maybe one of the one of the the biggest overriding principles, which is expose your simplicity instead of hiding complexity They're clearly hidden complexity beats exposed complexity You know if you got a choice if those are your only two choices I will definitely take hidden complexity put it all in a black box and cover it up nicely But even better is when you can make it simple and then just show that and to me the URL mapping is a really great example of that where It's just exactly visible what URLs are being used and you can see that in your browser And you can see that in your client when you're doing an API and you can see that in your server and it's all exposed and I Mean we're hackers right we want to see the interior of things and Particularly if they're if they're pretty and they're understandable show them. Let's see them Let's just got your comb then you just dig into like this dirty stuff and love it So the final principle I'll mention is actually based on a talk from RailsConf And I'll confess this a little odd because I didn't actually see this talk. I didn't go to it at all I just saw it in the I saw it in the in the program guide And and it struck me that the title of the talk is just a great a great quote is Justin Getland From relevance that did the talk. I don't know what the talk is about But I love the title small things loosely joined written fast And that really describes the web services rest clients and after us sort of Mindset philosophy that that I feel like is starting to develop and sequel fits into that as well I think and there's some other some other tools that that follow the same kind of approach Build your things a little build them quickly And loosely couple them right and the web is is obviously very well suited for loose coupling and we can do that in our program code as well and That seems like this Approach finally lets us escape that curse of always that that fate that we thought that every application had to end up this huge monolithic sprawling thing that we just want to take out back to pasture and shoot in the head Now if we're building our applications are actually an assemble An end user product is an assembly of small applications that are talking to each other in loosely coupled ways It's very easy to take one of them and kind of like you know You don't want to rewrite it in a new language so it's faster or use a new framework or use some new tool You can do that right? It's decoupled you need to scale it up. You can do that And you can and You know new people coming into the project They can take one little one little piece of the you know one little app and just understand that and if they understand The apis and how that faces the world Then they are that's an easier thing to get into than coming into the you know You kind of need to understand the whole application at once So to me this is this this approach this sort of universe to building applications is something I'm very excited about Sinatra was the thing that inspired me to get thinking about this to begin with and now I'm building a lot of things in this way And I encourage you guys to try it out too because I think it works really well There's a couple of URLs the Sinatra GitHub which has got a nice read me the rest client our docs my own blog up there just for Self-emotional purposes That's what we got. Thanks. Do you have questions? There's a question question was it's hard didn't under Insufficient documentation on the testing frameworks You had trouble understanding The answer to your question is that there is if you look in In in the Sinatra gem itself in the in the source there is a Test directory under Lib and then so if you require Sinatra test spec then you get test you get test spec And then you have get it put it post it and delete it And you can send session very you can send session information parameters all of that And then that actually returns the value of what you were looking for or no, I'm sorry It doesn't actually return it it it sets up the request for you or even you get the response back So it's using racks internal Mach request so I learned everything I ever needed to know from Sinatra just from the read me That's kind of part of why we put this URL up here because you know get hope shows the read me by default Basically the read me has everything you ever need to know yeah, again Maybe fitting in the documentation kind of that same style of you know how the applications are built right when big file That tells you everything right well I mean one point I want to make with testing Sinatra is that that you have get it post it put it delete it, right? And I find it easy to use it if it's not then let's let's work on it because it definitely needs to be easy but One second the one point I want to make though is that when you're that's all you need to test Sinatra You don't need all of this other stuff because your your URL should just be wrapped around like three lines of code One line two lines three lines once you start getting around five lines inside that proc Then you need to start breaking that out into other classes or breaking it out into other things and test those in isolation And then so you're basically get it post it put it delete it those are actually functional tests So you you know that's that's what that's intended. Yeah, can I say something here really quick Controller and view tests suck Yeah, so just like if your controllers are short and you don't have to test them and all of your logic is in your model and model You know unit testing works well and is easy and does not require any framework integration Then like you know the whole thing almost becomes moot. I mean I find it pretty easy to use not yeah I mean you don't know anything by integration to some time, but you know put the hard put the hard stuff in your models Those are easy to test that's pretty much it yes I think Multi-file synod trap, so that's a really good question because it doesn't there isn't a generator right like you know like rails and Remains a murb and all those have where they create the directory structure for you. I Typically if my if I have app foo I'll have my directory foo and then I'll have a file in foo called foo.rb And then from that I usually have a lib directory and then that's where I keep everything And then I always do the require file file plus slash you know whatever and then that's that's just typically the Standard convention I stick with Some other people do other things Use it other ways, but that's that's just typically how I how I do it But if you go look if you go look at some of these examples like scanty or some of these others that are up here They they all kind of follow a similar pattern models and stuff in lib using views specs in either specs or tests Done say that again Uh Get wikis one you could do his your scanty his blog sure. Yeah, that's probably an easy one just right this short So there's an easy one right there anything else Right so Is the roadmap for Sinatra and number two whose branch is the canonical one that you should watch for what's really going on with it Right now watch Ryan Temeco Art Temeco on github. He's been maintaining the gym bug fixes all of that and So and he's usually always has great really killer patches that he's always doing the other I mean the other is obviously myself I'm at the top of the network graph. I'm easy to find so You know, I've got I have a redux branch that's been sitting there for a few months. I got really far with it and then Then well investors said we had to start really doing some cool stuff at Haroko So we kind of like kind of tapered off that so But a short answer watch Ryan for stable changes watch Blake for right for what's like the Development on on my stuff should be should pick up pretty pretty soon. I hope so anything else. Yeah Oh Okay, so you mean cause so your case question is is how do you scale a snot trap? I think what you mean in terms of lines of code like you in terms of Did Move to Merb You know or like or start going to back to rails if it becomes so big But Usually if it's becoming that big you should probably start thinking about breaking it up into little other little apps, right? So that's that's one method you can take but if that's if that's not if that's a path that you just can't do then Yes, I'm moving to Merb go to you know, go back to you know, go to rails Yeah Question is does rest client automatically parse the results Which is a really cool feature that HDD party which was written after I wrote rest client does No, and that's actually one feature I might want to steal part of what I wanted to do with rest client is keep it really simple where you do the get and you Get back the raw results, and it's just a string and I really like the simplicity of that You don't get back a result object that then you have to deal with And it's very very easy to parse things. I mean I mean talking about like json It's required json and then json dot parse Space rest client dot get space URL. I mean so it's it's so easy to do that But it but it would be a it would be a cool cool feature to add that potentially I don't know if we fully answered the question about the roadmap or at all I mean, maybe what he's asking is is there any cool stuff that's upcoming that you want to tell us about Yeah, I've got this this new concept of filters that if you currently look at the way get post put delete work. They actually are There it's kind of there's already like this request type like event like object I'm doing away with that and what you have is just raw filters and then get post put delete or actually prefabricated Chain filters, you know chains of filters so which once I started on that concept I got really excited about it and went to town on and then eventually just kind of For a minute for a little while so but that's that's that's where I want to go with it I want to get it get it that way so The code is not your changes a lot Any others all right, thank you very much. Yes, we're done. Thanks