The Changelog: Software Development, Open Source - Padrino Ruby Web Framework (Interview)

Episode Date: June 17, 2010

Adam and Wynn caught up with Arthur Chiu and Nathan Esquenazi from Padrino, the Ruby web framework built on top of Sinatra.

Hi, this is Rick Olson, and you're listening to The Changelog Podcast. Welcome to The Changelog, episode 0.2.7. I'm Adams Tachowiak. And I am Winn Netherland. This is The Change Log. We cover what's fresh and new in the world of open source. If you found us on iTunes, we're also on the web at thechangelog.com. We're also up on

GitHub. Yep, head to github.com forward slash explore. You'll find some trending repos, some feature repos from our blog, as well as our audio podcasts. And if you're on Twitter, follow Change Log Show. And I'm Adam Stack. And I am Penguin, P-E-N-G-W-Y-N-N. Back to Ruby this episode.

Taking a hiatus from some of the JavaScript coverage to talk with the Padrino team. Yeah, it was awesome. Yeah, Padrino is a cool lightweight framework built on top of Sinatra, kind of like Rails Lite or Sinatra Plus, however you want to say it. I wonder why they didn't call that Sinatra More.

That was the original, I guess, gem behind it. Padrino is Godfather. So I think it's a take on the whole Sinatra name. It fits. It does fit. It's a classy little framework. I think it fits the Sinatra vibe. I've been having fun with it on a couple of projects. I'm excited about what it offers,

too. All this expandability without the complexity of engines and subprojectss, and what a mess. Yeah, and usually when you bite off a Sinatra application, it seems like there's times when you miss a couple of things from Rails, and I haven't found that with Padrino yet. Fun episode, should we get to it? Let's do it. All righty, we're joined today by Arthur Chu and Nathan Eskenazi, two of the brains behind Pedrino RB, new Ruby web framework.

Arthur, why don't you give us a little background on yourself and your role on the team? Hi, my name is Arthur Chu, recent UCI graduate, currently working at a company called Stuck Pixel in Newport Beach. I'm one of the main core developers of Pedrino. type thing since I was in high school, actually. And I've been using Ruby for two years. Recently, I started using Sinatra a lot. And so I'm also one of the core developers of Padrino. I focus primarily on the core gem and also the helpers gem. Cool. Before we dive into the project, why don't you give us an idea of how big the team is and where you're located? Sure. So there's actually six of us now on the

core team. And it started out, it's kind of interesting. It started out with, I built this gym called Sinatra Moore. And it was actually just me and Arthur working on that originally. And then we were joined, the third core team member was this guy in Italy. And he actually loved it so much that he became a really passionate contributor and we uh converted snatcher more over to padrino and so it was just the three of us for a while and then and then three more added on just recently just very recently uh we have joshua uh one of the guy the guy who created usher which is so that was that was great laurie holden who's um she's one of she used to be a merb core team member and now she's going to be helping us with the routing and the tests for Padrino.

And finally, we have Skade, Florian Gilcher, who is just another very, very talented Sinatra developer. He found us early on, and we added him to the project because he was so interested in helping contribute. I believe he's also one of the main guys for the German Ruby group. That's right. And so we've actually, we're actually located different places. Me and Arthur are in Irvine.

David's in Italy. And then I believe that Joshua right now is in Toronto. And Lori's out in Colorado too as well. So we're a distributed team. Well, that definitely explains why the IRC channel is so well manned. No matter what time of day I'm in there, it's just like 30 people. It's funny because it's actually perfect. Right when I'm going to bed, David is waking up and going to work. So the second I'm off the IRC, David's in there helping people. And then when he leaves, he tags me back in and I'm back. So it's kind of convenient. So usually the first

question that comes up when I'm talking about Padrino, because Adam and I are big fans, is why Padrino? We've got Sinatra, we've got Ramez, we've got Rails. Why Padrino in this day and age? Well, that's an excellent question, actually. And that's something, obviously, that comes up right away, very often, whenever we're talking to people about Padrino. And the simplest answer is that we never actually set out to create a framework originally.

We were all just really big Sinatra fans, to be honest. I mean, I used Rails a lot, and Arthur used Rails, and we always felt like there was something very enticing about the Sinatra philosophies. Yeah, it actually, it's a funny thing. It started with Nathan and I. We were actually working on a little pet project before. And then we wanted to try something different. And then instead of just using Rails, we decided like, hey, let's give Sinatra a go.

And then Nathan suggested, you know, like there's a lot of things from Rails that we did miss a lot. And Sinatra being as bare bone as it is, like we wanted to bring some of those extra functionality back. And that's sort of what led us to this point now. Right. So, I mean, what happened was essentially we started with Sinatra. We were loving it. We were both using it for all our projects as best we could. And I just kept running into the same, let's say, six pain points over and over again.

I needed helpers. I needed form builders. I needed a reloader for the development that wasn't shotgun so that it didn't reload the entire thing every time. I wanted more intelligent reloading. I wanted a mailer that was integrated. There was just a number of things that basically I loved Sinatra, but I just couldn't, I just kept having to rebuild into each project. And so as we started to notice that, we were like, hey, you know, it would make sense for us to take these things, extract them out of our projects, and sort of create like a combination, a comprehensive set of these extensions

that we need for every project. Hence the name Sinatra More. Yeah, and so originally, we actually didn't plan to make a framework. We were looking simply to create sort of like, it's almost like Merb Core, Merb More. We imagined Sinatra was Sinatra Core, and we loved it because it was one file implementation.

It was thin, it was lightweight. And then Sinatra more would be additional features on top of Sinatra for people who needed them. And so we always viewed it like that, even to this day, to be honest, I don't really view Padrino as an entirely new framework. I view it as a sort of a natural extension to what Sinatra already could do, but to give it a little more power and a little more flexibility. And I think people can see that very quickly when they start using Sinatra, that there are just some great things from Rails that you're going to miss. And so that's what we were trying to do with Padrino,

is just give people those things by default instead of having to have them hunt it down, you know, all the individual extensions to get those things. Exactly. We still wanted to keep the whole elegance of Sinatra, yet at the same time still provide some of the, at least the powers and features that Rails provided. So, I mean, that's what gave birth to Pad those things. Exactly. We still want to keep the whole elegance of Sinatra, yet at the same time still provide some of the, at least the powers and features that Rails provided.

So, I mean, that's what gave birth to Padrino. Yeah. You know, one of the things that I was pleasantly surprised about was that it's still Sinatra under the hood. So if you're in a Padrino app and you have a code sample from Sinatra, 90% of it still applies. I mean, it's still Sinatra. Yeah, that's absolutely right.

And it even goes a little one step further, which is something I had mentioned in a blog post I had recently, which is that not only is it just Sinatra, but since everything we have is a superset of Sinatra, you can follow the Sinatra tutorials using Padrino

and you won't run into almost anything that would break it. I mean, all the routing still works the same way that you learned. All the basic features are still there. There's nothing that we take from Sinatra and we say, oh, that's not going to work. All we do is we take Sinatra, we leave it there, and we just extend it naturally with more powerful features on top. And so when you're working with Arduino, you really are working with Sinatra. I mean, they're synonymous.

And you can still use Sinatra extensions. You can still use all the same rack middleware. This is really the great thing about Padrino. We did not reinvent the wheel at all. We simply provided extensions and tools on top of the existing foundation that we loved with Sinatra. You know, web development and desktop development 10 years ago, we were touting these components and how there was going to be this marketplace where you get these reusable parts like, you know, they exist in the real world in manufacturing, right? One of the things that I love about Padrino is that it's still Sinatra, still has this rack heritage under the hood. You can mix and match rack middleware to build your application,

but also you can mount other Padrino applications in a sub directory. Talk a bit about how you can stack Padrino apps on top of each other. So yeah, this is actually a great part of Padrino is that we built it from the beginning to be a little more Django-esque in a few ways. And I'll talk about the one that you just mentioned, the mounting of apps. I always liked the idea of Merb slices. They were interesting. And I liked the idea of the Rails engines. But the problem that we saw was I didn't really understand why we couldn't just have true mountable apps, which is something Django has for Python. And so I was very interested in exploring early on whether we could create truly isolated mountable applications in Padrino. And that's exactly what we ended up being able to do. So with Padrino, you can actually, when you generate an application, you're actually

generating a project, kind of like similar to the Python-esque idea. And in a project can contain any number of sub applications. Each application can have models, views, controllers, separated namespaces, different components, and they'll all be mounted separately on sub URIs. And this will all run from the single Padrino project. This is a great, this is very nice being able to stack applications. And then on top of that, if you take middleware, which we're big fans of, anytime we can, rather than building a Padrino extension, we'll look to build a rack middleware, because we're a big believer in sort of of creating agnostic things not tying people down to a particular component or framework so we're very interested in allowing you to stack middlewares

to create functionality and then on top of that uh mount applications so that you can really keep your applications lightweight and keep it sort of separate your concerns definitely keep it very clean too yeah so that was those are really important pieces of the thought process going into the beginnings of Padrino. We're really curious to see how difficult it would be to create true mountable apps rather than sort of pseudo apps, the way that Rails engines worked. And we came pretty close. I was actually fairly pleased with the progress we've made so far that we're going to continue to make towards 1.0. I think the average Ruby web developer probably doesn't leverage middleware as much as he

should or she should. Mention some of your favorite middleware rack applications that you like to use. I think, well, there's a Rack Recapture that I use at work right now. It just pretty much allows you to use Recapture inside your app. We actually have a few, actually. For 9.12, we have a

template feature that allows you to just easily generate plugins, and then we use a lot of Rack apps in there that just pretty much sets it all up for you into your Pagina application. So it just config much uh sets it all up for you into your pagina application so it just configures everything out of the box for you but in terms of your bracket yeah i mean there are a wide array of rack middlewares and i would actually really um like you were saying a lot of ruby developers right now don't take full advantage of these but you'd

actually be i mean people would really be surprised to see how many awesome pluggable middlewares there are that can really expand the functionality of your application in a great way that doesn't require any additional complexity in your own code. One example is this thing called, I found recently, RackBundle. And what RackBundle does is it's sort of like AssetBundler for Rails, but what it does is it's a middleware that'll actually take all your JavaScript and CSS files, and it'll minimize them, and it'll rewrite to have a single compressed JavaScript and a single compressed CSS. But it'll do that at the rack level.

And it doesn't require a single change in your application level code. So that's just one example. I mean, there's a lot of great middlewares. Another one I've been using recently that's pretty cool too is Rack OmniAuth. It allows you to do just authentication through either Facebook,

OAuth 2, and Twitter. And it makes it really clean and really easy just to implement it right into your application right away. And it also comes with

other features for Basecamp and other ones like Google. And they have a couple other ones that I can't list off the top of my head. But I mean, it's pretty great. I mean,

coderack.org is a great site to take a look at for a list of pretty comprehensive Rack apps they can use, and even GitHub itself. So, yeah, I mean, I encourage other developers to check it out. And as we mentioned, but I would like to restate because it's pretty interesting, is for 0.9.12, we're actually going to...

We recognize that a lot of people aren't familiar with middleware to the level that they should be, so we're actually going to create a plug-in system so people could, for instance, write Pedrino Gen plug-in HopToad, for instance, and we'll automatically download and configure the Rack HopToad middleware for people so they don't have to learn how to configure that themselves. And so we have this idea with Pedrino is we really want people to be able to use whatever they want, but we want to make it extremely easy and integrated for them to do it.

And so we have agnostic generators, which we haven't talked about too much yet, but we also are going to have these sort of cherry-pickable plugins. And they're not like Rails plugins. They just insert RackMiddlewares and sort of existing libraries into your app and configure them for you. Yeah, it's actually leveraged the store

a lot, so it just pretty much writes the code inside your app for you. If you guys want to take a look at it, it's actually leveraged the store a lot. So it just pretty much just writes the code inside your app for you. If you guys want to take a look at it, it's actually on GitHub. It's proginorecipes, proginodashrecipes. It's a list of a couple of plugins that we already made so far that allows you to just instantly just drop these plugins right into your project. Are these available on Edge or are these live today? They're on a branch right now on Edge.

Yeah, right now they're actually on a separate branch we're still sort of fine-tuning some of the the uh like tests and sort of fixing some of the bugs so we're actually not it's not going to be in our next release but it's going to be on the one after that but we've already started building a library we have like 15 or 20 almost already um different plugins for everything from hoptoad to Recaptcha to Carrier Wave. Rackbug. Yeah, it's a lot of Rack on Drive. So that's going to be a big feature

in, let's say, the next couple of releases. So let's back up a minute and talk about the agnosticism and the generator. So one of the cool selling points for Padrino was when you generate your project, you can specify your ORM layer. You can specify your JavaScript libraries, your style sheet and templating libraries.

What's the full gamut of support that you guys have in that area? Well, we support MOCs, scripts, testing frameworks, ORMs, and I think that's pretty much it. Style sheet engines. Oh, style sheet engines, also renderers as well. What we did when we first built Padrino is we took a look at all of the different things that you even can choose when you're building an application in Ruby. We basically made a list.

There's obviously the easy ones, persistence and mock, but there's also the more nuanced ones like Sass or less support for StyleSheets. And so we made a list of these, and we made a list of the components we had used that we actually thought were the most common, the most popular components. And so, and so what we did was we, yeah, we have generators that essentially support any of these popular components for anything from persistence engines, the test frameworks. And the best part of it is that we really worked hard on was that it's actually fully integrated with the rest of your generators. So for instance, let's say you choose Active Record for your ORM. We don't leave you hanging. We actually provide you all of the necessary tasks

to develop with Active Record. If you generate a model, it'll be generated with Active Record. If you generate a model test, it'll be done in the testing framework that you specified. So throughout the entire development cycle, we fully integrated each of the components so that you don't even have to, you know, you don't have to at any point copy and paste boilerplate code. We've done all that for you. It's built right into the generator. This was an important point when we were building Padrino because especially with Sinatra, everyone is opinionated and they're opinionated differently.

So one person is going to swear by S-E-Q-U-E-L, SQL, ORM. Some people are going to swear by data mapper. Some people are going to love Mongo ID. And we didn't want to go down the rails route of sort of being very strict on giving suggestions. We wanted to go almost the exact opposite route. We wanted to make using any of these extremely easy, but we wanted to give you the choice to use any of the ones that you wanted at your discretion, not ours. So that was important when we were building it.

Yeah, and also in most of the generation, we include a couple comments to show you extra little features that you can use with these different components that you like to choose. So we definitely make it very easy for users to come in and quickly see some of the basic commands you can use with these, either ORMs or maybe testing frameworks,

and just a basic setup for them to use. In addition, not just models, our admin gem as well is fully integrated with the generators. So if you made something with DataMapper, the admin sees that right away and just generates an account model based on the ORM you choose, and just pretty much all seamlessly work together. So what exactly is the sweet spot for this? I mean, you mentioned earlier how it's more like package-like projects.

And I know in Rails projects, you often want to throw out an application and you also have something else you want to put underneath it, but you run into problems with engines and subprojects and stuff like that. Why this versus doing that in Rails? Why did you choose the projects kind of route? And what's the sweet spot for it? Well, I would say we primarily chose the projects route because I'm a big believer,

and I think our team in general is a big believer in keeping things very separated and sort of focused. So rather than having one large app, I love this idea of building lots of smaller apps that are well-tested and work in isolation. It's the same modular philosophy that exists just in general in programming. And so rather than having, let's say,

one huge application that deals with authentication, authorization, pictures, uploading, blog, everything, we were very interested in allowing you to use middleware to do the authentication, authorization, pictures, uploading, blog, everything. We were very interested in allowing you to use middleware to do the authentication, middleware to do authorization, create an app for the blog, create an app for the forum, create an app for your primary application, keep things very, very separated, very easily testable, and isolated from each other. So there's not a lot of coupling. So that was our primary reason for doing that.

And also I've done some Python development myself, and I think also some of the other team members have. And personally, I just really enjoyed the sort of the setup that you get with Django, where you can easily, let's say someone builds a blog, and I want to use it. I can just take that blog app and stick it right into my existing project. No questions asked. I have all the assets, everything I need, all the models. And it's just, it's very nice to be able to have that type of separation and control over each individual application. So that's sort of where the original thought process for the project structure came from. So Padrino, Italian for godfather, correct? That's right.

So let's talk about Sinatra and the Sinatra heritage that Padrino shares. We've interviewed Aaron Quint from the Sammy J.S. Project that borrowed a lot of ideas from Sinatra. How, I guess, revolutionary has Sinatra been to web development? Well, I guess especially in Ruby development, it's definitely brought the learning curve down a lot. For most people that just started getting into Ruby and definitely into Rails, there's always that big curve to just understand how to just develop in Rails.

And with Sinatra, it makes it pretty much plain and simple. You just have an HTTP verb and a block, and it just makes it really clear for you to see what's going on. And whereas Rails, you need to understand a lot of the magic behind it, like how the generators work, where everything belongs, and just a lot of nitty-gritty details that most people, when they start, can't pick up right away. And that's why I really appreciate Sinatra. It's really simple. One.rb file, and you can already have a little tiny web app going right off the bat. Yeah. I'm a big believer also just in a print in principle and sort of graduated complexity. The idea that when you start out building an app,

it should be really dead simple. If I want to create an app that just says, hello world, I should be able to do that in five lines of code. There's no need to have, you know, 80 files, a routes file, generate a controller. If all I want to do is print, you know, hello world or some basic JSON to the screen. And the reason I like graduated complexity in particular is I think as Arthur touched on, the learning curve is extremely important when you're doing web development. Whenever I try to teach people Rails or Ruby application development, they always run into all these hurdles because they have to learn like 30 sort of mental models at once in a sense. And so I love Sinatra. Even though I was already fairly proficient at Rails, when I went to Sinatra, it was like a breath of fresh air for me,

personally. I mean, you know, the DSL was extremely simple. You know, five lines of code could generate a web server. The whole philosophy was agnostic and very lightweight. It was extremely fast as far as performance numbers when I benchmarked. There was just something very, very right about the foundation with Sinatra. And so I just fell in love with it right from the get-go. And I would have Rails apps and I would be working on consulting jobs and I would need to build an app. And I knew I should have used Rails because it was a much better fit, but I would find myself trying to find a way to use Sinatra because for some reason it just felt more fun. It felt more natural. And so, yeah, for me,

the graduated complexity is huge. I mean, I love this idea with Sinatra and now Padrino. You can come in with no Ruby experience whatsoever. You read the Sinatra book, and you could be building basic web applications within a couple days. I mean, within a day, you can build Hello World. But within three, four days, you could probably build a basic web service. And then with Padrino now being a natural extension of Sinatra, you can take all that Sinatra knowledge, and you can start cherry-picking Padrino knowledge, and you can continue to build on a very, very sort of gradual process towards building arbitrarily large applications. And that's something that just isn't really possible with Rails. I mean, you could learn, let's say, Rack, then learn Sinatra,

then learn Rails. But each time, you have to sort of discard existing knowledge and start again. Whereas with this, you can build everything from Hello World to the most complex e-commerce site, and you're still using the same foundation with Sinatra and then on top of that, Padrino. So for me, that's the most revolutionary part of Sinatra. So what are you guys building with Padrino? For the time being, I mean, we're kind of both working for different companies, building different things. Do you want to start off? Yeah, actually, I think for me, I'm actually building a couple of sites for this company called Stockpixel.

They do mobile app development. So I'm actually converting a lot of their mobile apps on the iPhone and Android into websites. So that's what I'm currently doing with Katrina right now. Yeah, so I work for a company, as I said, it's a small company. And I have a main application which is actually still in Rails because it's very large and I haven't had time to convert it yet but I have a lot of web services that I'm building

on the side to interact with various components, JSON, XML components just you know and those I've all built in Padrino I have contract work that I do on the side too, freelancing, I build all of those sites in Padrino, David who's in Italy, he actually runs his own consulting firm called Lipsy Soft. And they have, he has a

team, I think of something like 10 or 15 people from what I understand. And they build, they run a few e-commerce sites. They actually run, I think they built already 15, 20 apps in Padrino for their clients. So we all do different things with it. But honestly, I mean, it's pretty – between Sinatra and Padrino, you can pretty much build any web application that you need. So, yeah, I mean, I have yet to run into anything that I was building where I was like, oh, Padrino isn't going to work for that. Because, like I said, it's very, very modular, but it extends all the way up to an arbitrary level of complexity. So I've actually really been enjoying sort of the conversion from using Rails for my apps to using Padrino for my apps. Yeah, I'd have to agree with that. So at one point, Adam and I were kicking around the idea of using

Graham Ashton's Nesta CMS that's built on top of Sinatra. For the ChangeLog blog, we've since decided to stay on Tumblr, but I wanted to give it a go for my own personal blog. And just to extend a Sinatra app that's kind of outgrown the one-file architecture is kind of painful. So just as an intellectual exercise, I ported Nesta over to Padrino, called it Presto, and I'm actually loving it. I mean, it's one of those things where it's a joy, again, to dive down into a web application and just have it be that

configurable and that extensible. Yeah, I mean, an example of eating our own dog food, we have a Padrino website, padrinorb.com, and obviously right from the get-go, we knew we were going to use Padrino to build that, but I was actually, to be honest, even surprised as I was building it because we were building it during some of the earlier stages of Padrino, how actually fun and easy it was to build this site, because it's actually fairly complex. I mean, we have, it's actually a full CMS, and it's a full blog, and it has tags, and you know, it has a full backend for managing the content and everything. And it was actually really a pleasure to build. You know, me, Arthur, and David worked on that for a long time. And it was actually really a pleasure to build. Me, Arthur, and David worked on that for a long time

and it was actually one of the first ways that we really stress tested and polished Padrino was through our own Padrino website. And that's actually open source. It's actually available through the Padrino GitHub account right now, Padrino website. And so you can actually download that and modify it if people are interested in seeing a real Padrino app. But yeah, I found during building that, I mean, at the time,

we found things we needed to add, obviously. But, you know, during the process of building that website, now that it's relatively complete, you know, Padrino has been rounded out. And I really, I had a lot of fun building it. And that was actually part of the reason why I was so committed to continuing development of Padrino was because there was something qualitatively different the experience that I had developing that website from some of the Rails apps I'd done before. It was just something about

it was just a little more fun, a little more relaxed and yeah so it was just for me personally it's great. Exactly just like Ruby. Awesome. So this is about the point where we ask our radar questions. So what's on your open source radar? What's out there that you're just dying to play with,

I guess, inside or outside the Padrino world? There's actually a lot of interesting things out there that I'm looking to play with right now. There's one, Node.js Express.js, I think. That's the one that Sinatra, like a Sinatra clone for Node.js. That looks pretty interesting. Definitely want to try that out sometime. Yeah, that's really interesting.

Another one I'm really interested in is that the framework Bowline, which is, it's pretty amazing, actually. I'm very interested in starting to play with it. It allows you to use HTML and CSS to develop desktop applications. But they look native. It uses WX widgets under the covers. And so that was very interesting to me because I've actually always had sort of a pet project, sort of a hobby of doing desktop applications in various languages. And I play with WX Ruby. I play with Shoes. I do mostly web development professionally, but it's always been fun to play around with these things.

And now that I can use Bowline to develop desktop applications that look native, but I can write them in HTML and CSS, that opens up a whole new world of possibilities there. So that's been really interesting to me. And in particular, in the Padrino-related world, I'm very, very interested in – we've been playing a lot with MongoDB, which is, I guess, that new now. But it's starting to get more established, I guess, in a sense. but it's still kind of a newcomer as far as the database world goes. And I've been having a lot of fun doing most of my new sites in MongoDB and then MongoID for the ORM layer. And that's actually fully supported by Padrino. And that's been really interesting to me, too.

You guys also support MongoMapper out of the box, right? That's right. Yeah, we support a pretty good array now of different things. And we're actually working on support for various other ones, Cassandra, Reek. And just to add on to that, I mean, we also have a page on our Padrino site that shows how to make or add components onto Padrino itself. So it's fairly easy. So people out there that want to contribute like maybe an ORM or a script or some other component that they would like that they don't see in Padrino, we make it fairly easy for them to edit themselves and then, you know, just send a pull request and we'll definitely pull it

in. Yeah. I mean, we have essentially step-by-step guides for how to build in anything from the ORM layer to a new testing framework. Or even just translations too. Right. So yeah, there's, it's a very open-ended question. There's a lot of awesome open-source stuff out there. Unfortunately, I wish there was more time in the day to play with them all. Where are you guys going to be where folks can catch up with you in person? What about the Padrino Roadshow?

What talks are you guys going to be giving on the framework? Recently, me and Nathan went out to OCRuby. We're probably going to check out LA Ruby. And I think June 22nd, I'm going to be going to LA WebDev. It's somewhere in LA. Yeah. So we're starting, we're staying local right now for us. And I believe that there's, we're hoping to get some of the other core team members to be able to do sort of

their local ones as well and i'm hoping once we hit 1.0 or you know next you know maybe next year for let's say rails conference next year's ruby comp i don't know where padrino will be hopefully um in a really good state at that point i would love to to like start to consider to be you know start to present at a sort of larger venues that would be really interesting to me but if i remember correctly i mean you guys could probably cut to Josh going to Lone Star, I think. I'm not too sure about that.

Yeah, we'll definitely be there. We're media sponsors for Lone Star since it's in our backyard. Yeah, so I think Josh submitted a talk, but I'm not actually sure if he ended up committing to doing that. But yeah, we're definitely interested in getting Padrino out in any way that we can. Hopefully we can start speaking at more conferences in the future. Well, nice work.

It's definitely a fun framework with all the buzz around Rails 3. Rails 3 does not equal the Ruby web development community, and Padrino is definitely worth a look. Well, thanks, guys. Appreciate it. I know it's late. Actually, it's early for you. It's late for us.

Normally we're talking to Europe that's right well thanks for joining us this evening of course it's been great to be on thanks for having us thank you for listening to this edition of the changelog point your browser to tail.thechangelog.com to find out what's going on right now in open source.

Also be sure to head to github.com forward slash explore to catch up on trending and feature repos as well as the latest episodes of the ChangeLog. Safe in your arms As the dark passions show Who was mine alone I'm out, I'm out Morals to try Bring it back, bring it back to Outro Music