02:53: Guest Introductions

• Nathan Esquenazi
  • twitter
  • github
  • Padrino
  • @padrinorb
  • CodePath
• Arthur Chiu
  • twitter
  • blog
  • GitHub
• Dario Cravero
  • twitter
  • github
  • blog
  • Content Kingdom 03:47 - Start of Padrino
• “The Godfather”
• Sinatra
  • sinatra_more
  • Standalone Usage in Sinatra 05:59 - Features 07:08 -Writing Apps in Padrino
• persistence.js
• Bootstrap
• Slim 10:14 - Default Stacks
• jQuery
• rstack
• Arabis 12:22 - Crossing Over - Simple to Complex
• Monolithic App
• Django
• RubyGems 17:38 - Sinatra vs. Padrino
• Dev BootCamp
• Rails BootCamp - San Francisco 23:47 - Tradeoffs Between Larger Frameworks
• Rails Asset Pipeline 25:28 - Stacking Gems 27:46 - Applications and Modules 31:23 - Architectural Problems 38:07 - Embedding URL’s 39:37 - Tutorials for Padrino
• PadrinoBook
• Projects Using Padrino
• machinima
• Padrino Timeline 41:31 - Future of Padrino
• namusyaka
• pendragon
• JRuby 44:09- Padrino 1.0 46:07- Front-End Framework Support
• Angular
• Backbone
• Bower
• Rabl
  • JSON
  • XML
  • MessagePack
• JBuilder 51:25 - Sinatra with Padrino Projects
• Sinatra Omniauth
• Devise
• tilt 54:45 - Auth Libraries
• Warden

See Also

• Press for blog posts and some tutorials

Book Club

Refactoring: Ruby Edition: Ruby Edition (Addison-Wesley Professional Ruby Series) by Jay Fields, Shane Harvie, Martin Fowler, and Kent Beck

Refactoring in Ruby by William C. Wake and Kevin Rutherford

Next Week

Rogues Only - Evaluating Yourself

Transcript

[Electronic buzzing sounds] AVDI:  Oh hey, there’s a real replicant. I tell you what Dave, I didn’t understand you but my microwave perked right up. [Laughter] DAVID:  Excellent. Is she free on Tuesday night?[This episode is sponsored by Rackspace. Are you looking for a place to host your latest creation? Want terrific support, high performance all backed by the largest open source cloud? What if you could try it for free? Try out Rackspace at RubyRogues.com/Rackspace and get a $300 credit over six months. That’s $50 per month at RubyRogues.com/Rackspace.]**[This episode is sponsored by Codeship.io. Don’t you wish you could simply deploy your code every time your tests pass? Wouldn’t it be nice if it were tied into a nice continuous integration system? That’s Codeship. They run your code. If all your tests pass, they deploy your code automatically. For fuss-free continuous delivery, check them out at Codeship.io, continuous delivery made simple.]**[This episode is sponsored by Hired.com. Every week on Hired, they run an auction where over a thousand tech companies in San Francisco, New York, and L.A. bid on Ruby developers, providing them with salary and equity upfront. The average Ruby developer gets an average of 5 to 15 introductory offers and an average salary offer of $130,000 a year. Users can either accept an offer and go right into interviewing with the company or deny them without any continuing obligations. It’s totally free for users. And when you’re hired, they also give you a $2,000 signing bonus as a thank you for using them. But if you use the Ruby Rogues link, you’ll get a $4,000 bonus instead. Finally, if you’re not looking for a job and know someone who is, you can refer them to Hired and get a $1,337 bonus if they accept a job. Go sign up at Hired.com/RubyRoguesPodcast.]**[Snap is a hosted CI and continuous delivery services that is simple and intuitive. Snap’s deployment pipelines deliver fast feedback and can push healthy builds to multiple environments automatically or on demand. Snap integrates deeply with GitHub and has great support for different languages, data stores, and testing frameworks. Snap deploys your application to cloud services like Heroku, Digital Ocean, AWS, and many more. Try Snap for free. Sign up at SnapCI.com/RubyRogues.] **CHUCK:  Hey everybody and welcome to episode 170 of the Ruby Rogues Podcast. This week on our panel, we have Avdi Grimm. AVDI:  I am not a replicant. CHUCK:  Saron Yitbarek. SARON:  Hey, everybody. CHUCK:  David Brady. DAVID:  Some medicines can change the effect of this podcast. Check with your doctor or pharmacist before taking any other podcasts. CHUCK:  I’m Charles Max Wood from DevChat.TV. And this week we have a few special guests. We have Arthur Chiu. ARTHUR:  Hey, what’s up? CHUCK:  Nathan Esquenazi. NATHAN:  Hey, everybody. CHUCK:  And Dario Cravero. DARIO:  Hey, everybody. CHUCK:  Do you guys want to introduce yourself really quickly? DARIO:  Nate, you want to go first? NATHAN:  Sure, yeah. So, yeah I’m Nathan. I was one of the original founders of Padrino with Arthur Chiu and Davide. And we create Padrino I think maybe five or six years ago now. And I’ve been watching its development ever since, helping maintain it. And we have a lot of new core contributors. But nowadays, I’m working on a company called CodePath which teaches mobile iOS and Android to senior engineers in the Bay Area. CHUCK:  Awesome. Arthur? ARTHUR:  I’m a Ruby developer. I work at GitHub. Yeah, so as Nathan said, we worked on Padrino a while back. So, that’s about it. CHUCK:  [Chuckles] DARIO:  Alright. That was quick. I am Dario and I’ve been in Padrino for a while now and using it since ages. And same thing as the guys, I’m working now at a company called Content Kingdom that was started a while ago. And just trying to contribute and make the best out of the framework. CHUCK:  Cool. So, Padrino means godfather, right? NATHAN:  Yeah. CHUCK:  And called the godfather because? ARTHUR:  That was initially Davide’s idea. And the idea was since we’re building on top of Sinatra, we would have all these extra modules you can put on top. So, he came up with the idea of, well we came up with the idea, the term godfather, since you can pretty much use Sinatra as base and have all these things working for  you. And then Davide suggests, well let’s use the Italian word, because godfather’s hard to do for a Ruby Library. But Padrino actually worked out pretty well. So, that’s how we ended up with that name. DAVID:  Are you going to follow the godfather convention and have Padrino be pretty good but Padrino 2 is going to be the defining classic? [Chuckles] ARTHUR:  We could definitely do that. DAVID:  Okay. CHUCK:  [Laughs] Nice. So, we brought you on the show mainly because we did an episode a while back, we were talking about the dichotomy between Rails and Sinatra. And we had a whole bunch of people come in and say, “Hey, wait a minute. What about Padrino?” And since I hadn’t really done a whole lot with Padrino, I’d heard of it, and the same across the board with the panel, nobody had done a whole lot with it, we thought we’d bring some folks in to talk about it. And tell us what this third option is. Where does it fit between Sinatra and Rails? AVDI:  Yes, why are you trying to make Sinatra more like Rails? [Chuckles] AVDI:  [Laughs] ARTHUR:  Or more like, “Why do we love Sinatra so much that we just want to bring some of the things from Rails back into Sinatra?” is more like it. CHUCK:  Oh, no. Every Sinatra project I’ve had, I’ve done that. ARTHUR:  Yeah, exactly. So, we obviously, we really enjoy working on Sinatra. And a while back, it actually started from something called sinatra_more that Nathan and I worked on. And it turned into this actual framework called Padrino. But it happens all the time. You want to start with a simple app with Sinatra. And then there are some features that you want from Rails and some you don’t, and then you ended up duplicating the effort. And then that’s where we are today. It’s this middle ground where I can still keep that Sinatra syntax, that opulent joy and the simplicity of it. Yet at the same time, if I need something more advanced like form helpers or caching or whatnot, I can just cherry pick it and put it into my app without having to full-blown Rails and abandoning my Sinatra app. CHUCK: Interesting. So, it just adds in a whole bunch of stuff that you would have gotten in Rails? I’m assuming there’s a little more to it than that. ARTHUR:  Yes. There is. There is stuff like it adds on to the routes to make it a lot more, I guess versatile for you to use. So, if you want some kind of controller namespaces, Padrino adds that to you as well. But another one of the big features too is our generators. So, with the Padrino generators, I can incorporate a lot of different setups. So, let’s say I wanted to pick a search ORM. Currently, we can integrate things like Sequel, Mongoid, Active Record, there’s a few more I can’t remember off the top of my head. But we also do the same thing with renderers. So, if you wanted Slim, Haml, or ERB you can choose it right off the initial command line command, ‘padrino g project’, and you can preselect that. And that will scaffold your project with all these different options that you want with that. DARIO:  Yeah, and the good thing especially with the components there is that you can swap them around once you start to use your application as well. They command line also helps you to do that, which is not that hard to do anyways. But in any other application, you would have to do that by hand. And we’ve also taken of that throughout the last releases. AVDI:  Ok, so I’m really curious about some of the details of those things. Lately I tend to write apps in Sinatra and then I usually find myself adding persistence using the Sequel library. And so, what does that look like in Padrino? How much are you adding in? ARTHUR:  So, when you use generators to generate Sequel [inaudible], it’s essentially just creating the template code for you. So, it’ll add a line to the gemfile for Sequel. And you can also [inaudible] that Postgres, MySQL, whatever. And then it will just put the code in for it to work in your app. So, that’s pretty much it. It’s not an extra library coming in. It’s just putting the Sequel library in and some of the code to make it work with the app. So, you’re talking about some, if you use Sequel… AVDI:  Like for Sequel, what kind of code is needed to make it work? ARTHUR:  So, you have the Sequel connection that you have to set up. And if you use the models, you can also do that. So, by using the Padrino generator, I can later on do something like ‘padrino g model’. It will generate a Sequel model for me and also migration, the Sequel migration. AVDI:  Okay. So, you’re also setting up the migrations conventions. ARTHUR:  Right. So, it’s all there for you. But if you don’t want to do it, you can also remove that as well. But it just makes it easier for people to just get going. NATHAN:  One thing I was going to add is that it actually has an intelligent understanding of the model systems. So, once you’ve picked a particular component, say you selected Sequel, and you generate your models, the model generators work with Sequel out of the box. So, it will properly include the modules. It will use the correct column syntax. It actually understands the component you selected. And every other choice you make from that point forward, whether you’re generating a model test or a model or other aspects, it will basically generate the standard templates for those for you automatically based on the components you picked. DARIO:  Yeah. And something else probably to add on to the model generator is that that integrates very well with the admin that we have as well. So, every model that you generate, we [8:59] have then, or could have [9:02] admin. And then you could manage it on the backend later. AVDI:  Oh, so you have some admin UI that you add? DARIO:  Yeah, we do, yeah. AVDI:  That’s super cool. DARIO:  Yeah, it’s been changing quite a lot through time. The first version was a little bit outdated [9:15]. And we moved it, I’ll say a year ago or something, to a Bootstrap version. And right now towards 1.0, we are planning to actually make it even better and include a bunch of things that people have been asking for, like say some either pagination or something like that. People even talked about say, relations between different models and all of that, just to make it I’d say slightly easier to keep on dealing with your data right out of the box. AVDI:  What about with the rendering helpers? If I want to add Slim to my project, what sort of things is it setting up? ARTHUR:  That’s just adding Slim into the gemfile. AVDI:  Oh, okay. So, it’s not adding new helpers or anything like that. ARTHUR:  There’s a render method that pretty much is smart and knows that you mean Slim, or whatever gems’ available. So, it will render the correct templates. DARIO:  Yeah, the good thing about that [10:08] when you use the helpers then they are renderer-agnostic. So, you can use them and swap them around and that should be fine. CHUCK:  So, one thing that I’m seeing with Padrino, because I did look into it. I installed it on my machine and started fiddling with it, is that it’s pretty agnostic as far as which ORM, which rendering engine, which whatever you put in there. Does it have a set of defaults? Because I know Rails is somewhat less flexible that way. You can still substitute a lot of those things, but you just include them in your gemfile and it does Rails type stuff and it makes it go in. But it has a default stack. Is there a default stack for Padrino? NATHAN:  There is actually. So, the way it works is that when you generate a project, you can set up flags. But every flag is actually optional. So for example, if I just set ‘padrino g project test’, then it would select certain defaults for everything. So, it would load in jQuery, it would load in a mocking framework default, it would load in RSpec for testing. So, there are defaults that were selected and if you want to change any of those defaults more than just adding something to the gemfile, you just set the flag on your project generator for any of those items. And then it will hook up everything accordingly based on that component switch. So, it’s basically, it’s fully agnostic but it supports all the popular components out of the box. And if you don’t care, let’s say you have no interest in thinking about those components, then you just don’t set the flags. So, it does have our favorite or the most common components out of the box without you having to actually tinker with if you don’t care to. ARTHUR:  Yeah. CHUCK:  What are those components? NATHAN:  I can actually, let me review the basic ones. I think the most common ones I remember of the top of my head are we have a generator for ORM. I think the default right now is basically Sequel. We have RSpec, jQuery for JavaScript, rendering, Erebus or ERB for rendering, for templates. I think we just use no style sheet library and no mocking library by default. So, those are the major things that are involved in choosing your project: ORM, test framework, JavaScript library, rendering engine, style sheet, and mocking framework. And some of them we just leave off if you don’t specify. CHUCK:  It seems like there are a couple of different ways that this cross-sections. So, Rails versus Sinatra, we’re talking about simplicity versus complexity. We’re also talking about opinionated versus non-opinionated. There are a few other ways that you can compare them. And I’m trying to figure out where Padrino really fits in there. Is it more complicated than Sinatra and less complicated than Rails? It seems like it’s a whole lot less opinionated than Rails. How do you zone in and target where Padrino fits? DARIO:  I wouldn’t say that it’s more complicated than Sinatra, really, because on that end what we really add on top of that is a bunch of helpers that just get you up and running quicker. On the other hand, as I said coming back to generators, I always say to people that it’s better if they actually look at the different options that they have and try to make an educated guess towards what they want to use in the project. And I guess that’s a decision that, on that sense you always do in Sinatra. And in Rails, most times you don’t. It’s there and that’s what you have to use. So, I’d say that the complexity is not really there from the kind of components you can choose and the like. But it forces you to understand those a bit better if you really want to know what your application is doing. NATHAN:  Yeah. I would add to that that I think it’s more than just, there are more dimensions than just simple to complex. There are also architectural decisions that you make with your app. So for example, one thing I think all of you have probably experienced is that when you’re building Rails apps, they often are not encouraged, but you tend to go down the path of one large app that does everything, the monolithic app. And so, if you look at frameworks like Django or Sinatra, they encourage multiple apps, multiple small micro-apps that are all relatively individual and independent and tested separately and modular. And so, beyond just simple to complex, there’s also the point of you can reduce complexity significantly by using a particular architecture which has a bunch of small, individually tested and maintained components. And so for example, there are three things about Padrino that I think make it a much better architecture, from an architectural perspective. One is it’s gradually complex. What that means is that when you’re working on Sinatra and all of a sudden I need a mailer, I just throw in the Padrino mailer and it works immediately. If I need the renderer, I throw in the renderer. If I need helpers, I can throw in helpers. So, Padrino can gradually scale up with your Sinatra app as needed. It actually works outside of a Padrino app. You can just have a Sinatra-based app and then include these modules. And if you want all of the modules or most of the modules, then you can adhere to the Padrino folder configuration. But as I mentioned, every single aspect of Padrino can be removed by just commenting out a single line of code, an include statement. So, it’s all very explicitly loaded into the Sinatra system. And so, because of that it’s a lot easier to understand, because you only get what you need. And there are defaults, but as soon as you don’t need that or if it’s too much for your app, you just remove it. And the other aspect which makes it I think somewhat unique is that we have the Django-style micro-app system where for each project, rather than the project being one monolithic app where you have all your controllers in one folder or in subfolders, or all your models in one folder, the way Padrino works is that it’s actually mountable applications out of the box. And the primary application is actually just one of many applications that you can build into a single project. And that’s actually built from the ground up. So, if you want to have four projects, one that’s an API for authentication, one that’s an API for your app, one that’s a frontend, one that’s the admin, maybe load a blog module, all of these things are mountable sub-applications from day one. And they’re all tested separately. They’re in separate namespaces. It’s all organized for you automatically. So, imagine taking Sinatra but adding the ability to combine all of these Sinatra applications together in a very specific way. And on top of that, we even make apps gemified automatically. So, if you generate a project and you flag --gem, what will happen is that it will actually package your project and your apps as fully-functional gems with runnable binaries properly configured with lib folder, test folder, the whole gem thing. And basically, you can push those gems to RubyGems and load them into your Padrino project with just a single line of code. So, the whole focus of Padrino isn’t just about making it easier to use Sinatra but also to encourage best practices, create more intelligent conventions for how to store your files within a Sinatra app, and essentially just help people avoid all of the pitfalls of the complexity that happens in Sinatra apps after a while. A lot of people joke that any sufficiently complex Sinatra app is either extremely messy or it’s reinventing Rails. And I actually think that you can avoid both of those things. It’s not about reinventing Rails. It’s about giving you the flexibility that Sinatra allows but also providing the support and the structure that you need to build better architected applications. And part of that is encouraging people to keep their apps small. So, you don’t want a monolithic Sinatra app. You do not want a monolithic Padrino app. And some of the functionality of Padrino helps you get there easier than you would have otherwise. SARON:  So, you’re making Padrino sound really, really good. And I’m wondering if I’ve decided that Rails is just too opinionated and too large and I’m picking between Padrino and Sinatra. Is there a situation where Sinatra would win? DARIO:  I would say on that end that you definitely want to use Sinatra if you are doing, say a presentation layer for a simple model or some very simple data layer, totally. And as Nathan said, the good thing is that you can build up on top of it and you don’t really need to have say, the full Padrino stack on that sense. But you know that you can [18:11 with] whatever models we have to enhance your app if you felt that it’s just too much as well. NATHAN:  And one nice thing is that from a benchmarking perspective, this is actually somewhat unique about Padrino, is that in benchmarks Padrino and Sinatra actually are almost always roughly the same. So, obviously take benchmarks for what they’re worth, but we find that a properly done Padrino app is only as slow as you choose for it to be. So, if you don’t use the helpers, obviously helpers are going to slow you down a little bit, if you don’t use those and everything else essentially maintains the same speed as Sinatra and it’s all 100% backwards compatible. What that means is that you could literally copy and paste your Sinatra routes into a Padrino app and it would just work. You don’t have to actually think about Sinatra and Padrino separately. Padrino is simply extensions to Sinatra. But every extension is fully backwards compatible. So, it’s actually nice. You could start with Sinatra and throw in modules with Padrino to experiment. You don’t have to be stuck to the entire stack. Say you do start with Sinatra and you want to migrate to Padrino, since the code is all backwards compatible, you can literally just replace the word Sinatra application in the extends for the class with Padrino application. And it will continue to work as it did before, but now you’re just given all of this extra functionality for free. AVDI:  Like I said, I like to build apps just starting with Sinatra and so I’ve definitely felt the pain that this addresses. I wonder though, is it a good idea, if you haven’t used any of these frameworks before, maybe if you’ve just used Rails, is it a good idea to start with just Sinatra and feel that pain before jumping into something like Padrino? Because I feel like if I hadn’t used Sinatra and started rebuilding some of these things from scratch, I wouldn’t have as good an understanding of when to apply them and where they fit in. And I might overuse some of those things when I don’t even really need them. NATHAN:  I think you bring up a great point there, actually. I do a lot of teaching. It’s my fulltime thing now. And one thing that I teach a lot is some web development stuff. And I always start with just plain Sinatra first. I used to do a lot of teaching at Rails workshops and I discovered that even at Rails boot camps, even fully-fledged boot camps like Dev Bootcamp in San Francisco that are teaching Rails, even they always start with Sinatra actually, surprisingly enough. And it makes sense. It’s because with Sinatra, in six lines I can show somebody the mapping between a URL and a website, a URL to an action. And it’s very, very cleanly mapped. And not only that, but you really get an understanding of what exists at the base level when you’re building web apps versus all of this extra stuff on top. And Rails is great. I love Rails. I’ve used Rails for quite a while now all the time. But one thing that it does is that it includes so many modules out of the box, so many folders, that if you take a beginner and you generate a Rails app, there are 97 files and folders that you have to explain, literally. So, that’s a lot to take in at first. So, I’m actually with you, curious to see what the others think, but I think starting with Sinatra first, experiencing how Sinatra works, playing around with the routing system, maybe getting a little frustrated with things that you’re missing, and then slowly loading in Padrino or including modules from Padrino as needed is a great way to get started with Padrino. Now, at the same time on the same token, if you’re coming to Ruby development from another language, I’ve had a number of people tell me that they found Padrino to be a great transition from say, Django. So, if you’re coming from Python and you want to jump into Ruby, Padrino is very, very, it adopts a lot of the patterns and philosophies from things like Django. It’s much more explicit. It’s very clear when things are being included. It’s very non-magical. Everything’s very specific so you understand how it all fits together. So yeah, and from that perspective I think starting with Sinatra makes sense. Starting with a basic Padrino app makes sense. In both cases, you get a lot more of a look under the hood of how web applications work. And I think that that’s really important. Padrino does not have a scaffold function. It does not have as scaffold function. That was not an oversight. That was an intentional choice. SARON:  That’s interesting, because when I learned Rails we started with Sinatra too. And I remember being very frustrated because Sinatra felt very magical. And then when we went from Sinatra to Rails, Rails felt exponentially more magical. [Chuckles] SARON:  And I wonder if the difference wouldn’t have felt as jarring if maybe we had done Padrino in the middle. And so, I’m wondering from a teaching perspective, do you think it makes sense to go from Sinatra and then Padrino and then Rails? NATHAN:  I’ve actually seen people try that and to some good success. Some of the coding camps I’ve talked with, that’s exactly what they do. They start with Sinatra base and then they present a problem, a use case, like, “Okay, I want to render this template and I want to add this form. How do I do that? Here’s how I do it in Sinatra. Okay, well now let’s do this in a slightly simpler way,” and then they add an include line for the helper. And then they do it the Padrino helper way. And then they say, “Okay, I want to send an email. How do I do that?” And so yeah, you can start with Sinatra, which is sort of like you said somewhat magical, although explicit enough to get what’s going on pretty quickly. And then you can layer in the use cases as they come up and actually demonstrate step by step what it looks like without these helpers and with these helpers, within the same context, until you’ve essentially rebuilt all of the helpers and magic that you need to build a complex application. And I think when you’re teaching, layered complexity is the key. This is something I’ve seen time and time again, is that gradually introducing layers upon layers and helping people understand how those layers fit together and how they’re related is really the only way for people to really understand web development. And so, Sinatra and the Padrino module system, it really makes it easy to do that layered approach to teaching, and that’s something I definitely advocate for a lot. CHUCK:  I am wondering. So, we talked a little bit about when you should just go with a Sinatra app as opposed to a Padrino app. I’m wondering. Are there cases where Rails really shines over Padrino? It seems like you’re trying to replace the case where you re-implement Rails on Sinatra to a certain degree. But I am wondering, what are the tradeoffs between the two larger frameworks? DARIO:  Personally on that, I don’t think there’s anything really that Padrino lacks not to be able to compete with Rails on that sense. Probably right now, it would be the whole Asset Pipeline integration that we are still debating, which way would be the best to integrate in Padrino. But you can also get around with Sprockets and that’s not a problem at all. So, I’d say that it’s really more a matter of how you decide to architect your application, but there is nothing there that would prevent you to build really big apps. Actually, as a matter of fact, we were asked that in Twitter before and they asked us to talk about our experiences building big applications with Padrino. We build quite a few in the different companies we’ve worked with. And we’ve never encountered any issues whatsoever when the application scaled. And I think most of it comes because we split it properly, separating these concerns into multiple applications. AVDI:  Does Padrino add any helpers for internationalization? DARIO:  We do, yeah. NATHAN:  It has full support for internationalization. So, if you render templates with Padrino, the smart renderer that we use, it will automatically consider your locale. It has full support for live stream translations and all the other things. It just uses… it leverages the existing internationalization libraries that you can plug in. And it gives you some helpers on top to make it really easy. AVDI:  Oh, very cool. DAVID:  So, we’ve talked about pluggability. And one of the questions I had before this show is that pluggable apps seem like a solution to a very heavyweight kind of problem. And since Padrino’s such a lightweight framework, how does pluggability fit? I think Nathan, I think you’ve addressed that a little bit, which is that the idea is to take a very heavyweight problem, break it into smaller problems, into smaller apps, and plug them in. And it sounds like Padrino makes it easier to plug things in to encourage that type of architecture. Correct me if I’m wrong on that, especially because the follow up question I have is you said that you can gemify your apps. Does Padrino make it so that I can write, say like an admin app or a payment transaction app and gemify it and then turn around and go to another application in another repository, plug that gem into that gemified app? Can I stack gems, is what I’m asking? NATHAN:  Yeah, I know. It’s a great question. And the answer to that is you actually can. So, it works like any gem, basically. DAVID:  Cool. NATHAN:  If you add them to the gem spec, literally it’s just like any other gem. So, adding an app to your project literally works exactly the same, or not exactly the same, but reasonably similarly to adding any other gem that you would add. So for example, just as one simple case, the Padrino admin functionality, which is the built-in admin panel for Padrino, is actually just a gemified basically sub-app that gets loaded into your project. And that could be done by anybody. So, if you want to build a reusable Padrino sub-app that can be loaded into an overall project, it’s literally as easy as just adding a line to your gemfile or even loading the source code for that app into the sup-app folder. So yeah, it’s pretty much built from the ground up to encourage that kind of behavior and to have you thinking about how to architect your project in a more modular and service-oriented way from day one. So for example, if you have an app so complex and so huge and so monolithic that you’re like, “Oh man, I really wish this was in Rails,” which I don’t think typically happens but say you did… [Chuckles] NATHAN:  I would actually argue that you didn’t actually think about your architecture properly. I’ve never had a complex app that couldn’t be broken up into discrete modules that are easier to test, easier to scale, et cetera. So, I think part of Padrino is forcing you down a more sensible path from an architectural perspective. AVDI:  Could you give us an example of an application that you broke down into modules? And just give us an idea of where you drew the lines? DAVID:  Yeah. NATHAN:  I think it depends on the application, obviously. One simple example is you could have an authentication layer, so you have a service which manages authentication across all of your different microservices. And that service is essentially an authentication API and an authorization API, which is separate from the rest of your app. And it only communicates using a specific set of integration points. So for example, imagine you have your own baked in Warden where you basically have your own authentication layer. And then all of your other apps are supported by it. And then you have your admin layer where you see your data. And this is where you and your team look at your data and all of the admin information. That can be its own application. And then you have your API layer. Say you have a RESTful API with your app. That can be its own application. And then say you have different stakeholders. You have shop owners who create information for their shops. Then, the shop creation side could be its own application and the consumption side, so the store fronts could be its own application. And they only share certain boundary points. So for example, maybe they share some models, or they say maybe some layouts. But in general, you try to minimize the amount of overlap and the amount of things, the amount of coupling between your individual sub-apps. Does that make sense? So, just different pieces of your application are extracted out into separate Padrino sub-modules that are all loaded and tested separately. AVDI:  You mentioned sharing layouts. Is that something that it makes pretty easy? NATHAN:  Yeah. It’s built in, basically. So, any app can depend on other apps, like gems. So, say that you have an app, like for example take a store front. The store front is going to require authentication, obviously. And it’s going to require some models from another app. So, you can have app dependencies. And then you can say, “This app requires this app to work,” and then you can say, “Load the layout from this app,” or, “Load the model from this app.” So, you can basically cross over when necessary between your sub-apps. Obviously, you want to minimize that as much as possible but there are cases where it makes sense to have shared models. And so, for example in a project, you can actually have shared layouts or shared models that are like a grab bag that any of the applications can pull from. Or, you can include those within the individual application and then declare dependencies between apps. So, it’s pretty flexible from that perspective. DARIO:  One good use case that I would add as well there would be probably to do API versioning. That is extremely handy and super to do with Padrino as well. And if you have say, multiple teams developing those, that’s not a problem at all. Gemifying the apps, it’s really easy to separate them and then just mount them wherever you need them. And as Nate said, you can also share your models there that are common. And the good thing as well is that whenever you see fit, you can always separate these apps into completely different apps, mounted in totally different places that are not sharing the same space. And that’s also not a problem at all for Padrino itself. NATHAN:  Yeah. Many times, we can talk about this a different time, but many times I’ve had a single project with five or six sub-apps. And then as our company scales, what I’ll do is I’ll actually move the individual sub-apps into their own projects and have them running separately. And so, I can scale my API layer horizontally, completely independently from my web frontend. And they won’t really bother each other. So, it just makes it really, really easy to start with a single project and multiple sub-apps and then eventually move those into fully-fledged services. DAVID:  There is a problem that I run into in that type of architecture and I wonder if you could speak to it, because I’m sure you’ve hit on it. You touched on one approach to it which was loading models from another app, which violates the service-oriented encapsulation, really. If you visualize, I’m an extremely visual person so I’m going to draw you a word picture here. If you visualize pluggable apps as this root system of a tree, basically, you’ve got this top-level node that’s your main Padrino app, and then underneath it it’s got these little sub-apps branching down. And it’s great when two branches of the root system have absolutely nothing to do with each other. Those absolutely should be isolated concerns, have nothing to do with each other. But all too often, branches start needing to talk to the same models. You’ve talked about having different stakeholders. So, you might have a person in a call center who is looking up customer information and placing orders. And this person can’t really get into too much trouble. They can’t get into a lot of the private information for that customer or that client. But then you have another stakeholder who is the accounting auditor. And they have to be able to get to all of the transaction data. So, these are two stakeholders that are looking at the same data. And I would make the argument that they’re actually looking at different models, because they can see different things and they can do different things. That’s the definition of a different class to me, even though they are the same database table in the database. Having preloaded the question a little bit like that, the visual root system starts to become diamond-shaped, right? You’ve got Padrino at the top. You’ve got a single database at the bottom. And then you’ve got this, as you come down from Padrino the roots widen out into all the different apps. And then they start to narrow back down to a common data backend type thing. How do you deal with a diamond-shaped hierarchy? AVDI:  And as any ex-C++ programmer knows, diamonds are bad. DAVID:  Diamonds are awesome. But that’s just me. I also love threads. [Chuckles] NATHAN:  So, it’s a great question. I think it’s a really, really good question and there are a couple of different ways to think about it. So, one thing is, there are different options you have when you’re in a service-oriented architecture. One thing you can do is that you have one core application that actually manages the database and then everybody else works through API layers. DAVID:  Oh, nice. NATHAN:  So, literally like a client for your own app. And imagine that you had, for example I’ve had this before, where you have an app which its sole responsibility is basically to act as a REST client that allows me to get and modify data on my database. And all of my other sub-apps simple leverage that documented client in order to access models and information. This especially works well for API-based apps. So, if you’re purely just, you have two stakeholders, or three stakeholders who are all acting on the same basic data with different roles, then there’s really no reason that those can’t be using a shared API. So, rather than having all of those apps all touching the models and touching the database which is kind of dirty in some ways, you could just have a single app focused on the database and then everybody else is simply leveraging APIs to get that data or to modify that data. So, that’s one approach you can take. Another approach you can take in the early days, keep in mind that you don’t have to do this approach overnight. Premature optimization is something that’s really unnecessary. So for example, you could start out where you have a Padrino project with four or five apps. And maybe they’re all just using shared models, because remember that if they’re all in the same project you actually have the flexibility to have shared models between all of the projects. And yeah, that is a little dirty, but when you’re first starting out it’s a lot better than not having separate apps at all, right? DAVID:  Yeah. NATHAN:  And then as you start to scale in complexity, say you want to remove some of the dirty aspects of having every app touching the same models, it’s like what you said. In some cases, you’re absolutely right. In some cases the models are actually entirely different even though the data is the same. And so, rather than using an API layer, the other option is to actually have each of the apps maintain its own models that are relevant for its particular domain and then they all just happen to share the same database table. So, you’re right. In some cases, you’re going to have the diamond structure with six apps and different models that are all leveraging the same table. In other cases, you’re going to have six apps that are all literally just sharing the same models within a single project. And in other cases, you’re going to have a true SOA or a service-oriented system where they’re not all touching the same models. It’s not so, they’re not putting their greedy fingers on every single data item. Instead, you just work through a shared API to manage and modify the data. I think it somewhat depends on the app or the project and the scale and other considerations. But the nice thing is that Sinatra and Padrino, Padrino in particular in this case, really gives you the opportunity to think about it early enough that it’s not an enormous pain once you do want to start splitting it up. And I will tell you that I’ve worked with a lot of different companies on contracts, I’ve done a lot of apps, and there does come a point where you deeply wish that you had a service-oriented architecture for a variety of different reasons. And so, [36:27 you can’t] really easy to get there by thinking about it upfront without a whole bunch of extra work. I think it affords you a lot of flexibility as you run into problems with your app and you want to scale or you want to optimize, or you want to split things out or have separate teams that all have ownership over different pieces of your project. So yeah, that’s how I look at it. DAVID:  That is interesting, because you just flipped the mental picture in my head where, if you’ve ever drawn out the database diagram for a has and belongs to many table, instead of viewing Padrino at the top and your database at the bottom, what if you rotate it 90 degrees? You’ve got Padrino at one side and then you’ve got your many-to-many join table in the middle which is all of your apps and your services. And then you’ve got this other service off to the right, which is your data access service. NATHAN:  That’s one way to think about it. And actually in many cases, that’s the most I would say architecturally clean way to think about it, because you want to have an API layer anyway. Who doesn’t want to have a clean, RESTful API layer these days? DAVID:  Yeah. NATHAN:  Most apps honestly are just clean API layers with a JavaScript and mobile frontend, right? And so, if you’re thinking about the world of that, then all of a sudden it starts to make a lot of sense. You have an authorization, an authentication module, API. You have an admin panel for your projects. You have API for this. You have an API for that. Maybe they’re even separate services if they’re totally different aspects of your app. And all of a sudden yeah, it’s a flipped diagram where all the aspects of your app are basically just leveraging shared APIs to communicate. And yeah, it works very well. It does add overhead obviously to simple apps. DAVID:  Sure. NATHAN:  So, it’s not for every app. But absolutely yeah, it’s a great option for things where you want to keep things nice and architecturally clean. DAVID:  Yeah. AVDI:  I’m curious about one detail of Padrino. Probably the first point at which I find myself thinking, “Hmm, Sinatra is actually a little bit lightweight for my needs,” in any app that I do is the point where I realize that I need to embed URLs in my views. Obviously, you need links. And I realize I’m hardcoding URLs because, well not hardcoding but effectively hardcoding paths, because Sinatra makes it very easy to set up routes but it does not give you reverse mapping. It doesn’t give you a way to say, give me the logical route to this resource, and whatever URL that happens to turn out to be. Is that something that Padrino helps with? DARIO:  Yeah. Yeah, Padrino has a set of helpers that would let you pick up any URL that you have named somehow. So, when you define them, you can give them a name and then you can reference them anywhere else as well. NATHAN:  Yeah, and it uses namespaces as well. So basically, just as an example, say you have a simple blog. So, you’ll have a posts route namespace and then you will have named routes. So, you’d have index or show or whatever you want the names to be. And then you can simply reference any route at any time by simply asking the system for the URL for a particular namespace and a particular named route. So yeah, that’s actually one of the many things the router that we created affords. But absolutely, we’ve added a number of things on top of the standard Sinatra router. We still support Sinatra routes, but we’ve added a number of extensions that give you some of that power that you need when you’re building actual applications. CHUCK:  So, are there any good tutorials or videos or things like that out there for Padrino? ARTHUR:  Yeah. There’s a Padrino book that’s wiki, is it wikimatze, that’s been working on it. You could take a look at it. It’s PadrinoBook.com. And then also, our main site has a pretty good tutorial on how to use the Padrino framework. CHUCK:  Are there any large apps out there that are using Padrino? NATHAN:  I could speak from my side of things. So, I know that Davide, one of the other founders, he has a consulting company. It’s one of the larger ones in Italy and he actually generates, I think he generates something like over a hundred Padrino applications there, some of which are of varying sizes. I know that outside of us, a number of companies actually use Padrino. We actually have a projects page called Projects Using Padrino. And some of those projects are fairly large. We know that Adobe uses Padrino internally for a number of different tools. And there are hundreds of other projects at least that we know of, some of which are, like I said if done right, they’re actually not a single complex app but they are fairly substantial. We know there’s a startup in San Francisco called Zaarly that uses Padrino for their entire API and backend and frontend, or at least used to potentially. Maybe that’s changed. Arthur, do you have other examples? ARTHUR:  There’s Machinima. I think they’re still using Padrino. They’re a gaming company. I’m not sure if you guys are familiar. So, they’re using Padrino. Yeah, the list is pretty extensive. Machinima’s probably the biggest one I could think of and the one that Davide’s been working on. SARON:  How old is Padrino? ARTHUR:  200-, when did start working on this, 2009, 2008? NATHAN:  Yeah. I usually say five or six years. I have to actually look at the first commit, because as Arthur mentioned, we actually were working on a precursor to Padrino even a year or two before that called sinatra_more, actually when we were in college. So, it must have at least been yeah, probably something like six or seven years now that we’ve been working on these extensions in various ways. SARON:  Nice. So, what do you think is the future of Padrino? Where do you want it to go? NATHAN:  We’re at 0.12 now. So, we’re actually not even at a 1.0 release after all these years for various reasons. But we havea number of things on the roadmap to 1.0. So, we’ve always mentioned that at 1.0 the major things that we wanted to add was we really need to replace our router. So, for a number of reasons, right now the router is not thread-safe. There are some issues with it. So, namusyaka who’s one of the core contributors, he’s worked on a really awesome replacement which is called Pendragon, which is a lightning fast router which we’re going to replace into Padrino before 1.0. We’re also working on a better authentication module. So basically, we want to have a Padrino version of Devise. And it’s something we’re working on actively right now. We want to do full threading support and also asynchronous support. So, basically if you want to have a fully-threaded app, we want it to be no locks, as multithreaded on possible on frameworks like JRuby or runtimes like JRuby. And there are a couple of other things. For example, we want to do a complete refresh of our site as well as our docs and get the book underway. So, just basically improving the documentation, improving the site, improving the router, authentication, so a lot of these major modules. And then I think also there are a number of other things I think we’re discussing right now. Dario, do you have any other items that are coming to mind for the 1.0 release? DARIO:  Well, I’d say that one of those would be that we definitely [43:03] get to have every part of Padrino to be modular, fully modular. Right now, you can mount pretty much most of it in a Sinatra app or something. But for instance, the routes are not that flexible yet. Thus to be able to just port them around and use them in different scenarios, those are one of them I’d say. And one of the things we’d found as well was that the reloader needs a little bit of love there. So, we are also working on that towards making it a bit better and more reliable. And I guess that at least from my end, most of the focus is towards making it easy for developers to just scale quicker. And when I say that, I mean I don’t know with you guys, but most of our work comes towards RESTful APIs. And I think that that’s one of the biggest things where all these frameworks should be helping towards, either helping you generating your API documentation so different users can consume it, and just making it easy to scale them up with all the versioning and authentication, so on and so forth. So, I’ll say yeah, it’s along the lines of that. SARON:  So, once you get to 1.0, or how do you hope that Padrino is positioned compared to Sinatra and Rails at that point? At the point where you’ve finished up a lot of the things that you’re excited about? NATHAN:  From my perspective, I think the idea positioning for us is one thing we learned from Sinatra is that we don’t want to continually take on scope. So, we don’t want to be constantly just adding features for the sake of adding them, or adding more and more complexity into it. We actually want to keep Padrino pretty lean and really fast and have it be very aggressively scoped. Sinatra is just as well-known for what it says no to as for what it says yes to. And I like that philosophy. Basically, not trying to be everything, not trying to be the kitchen sink. Leave things to third-party libraries when it makes sense. Leave things up to the individual developer. So, I want to position Padrino as the framework of choice for people who are interested in building light microservices and service-oriented architecture. So, if you’re in Ruby and you want to build a series of web services or you want to build a light API or you want to build mountable Sinatra apps in a maintainable way, if you were going to grab for Sinatra, I would encourage you to look at including Padrino modules when needed and/or leveraging some of the flexibility that Padrino gives you gemifying your apps. So, I think that’s really the key of it, is for people who are power users, as well as people who are new to Ruby who are looking to build lightweight modular web apps and web services, I really want them to think about grabbing for Padrino really, in every case. I think that any time you’re going to use Sinatra, there’s often a number of those modules form Padrino that you will almost certainly be either plugging in or rebuilding from scratch pretty quickly. So, I don’t really think there’s any reason not to leverage some of those features. And I think some of the conventions and the setup that Padrino gives your around generators to make it a lot easier to hook up components and to follow best practices, I think it makes it a really, really solid choice for anybody looking to build basic web apps or APIs in Ruby. AVDI:  One of the things that Rails has been getting dinged for more and more lately is the lack of any real coherent intentional support for frontend frameworks like Angular. Is that something that you’re thinking about and targeting at all? NATHAN:  Yeah. We actually all use things like that very, very heavily. And in fact, I think Dario can speak to this, and so can Arthur, that we’re all big fans of Angular and Backbone. And many of our applications now are just API backends and multiple web services that are leveraged by these JavaScript frameworks. We have a Padrino plugin system which plugins are basically like generators but they’re more extensive. And we can link to them. But basically that way it works is we have generators for the core components in the Padrino library, in the framework. But we also have extended plugins as well. And some of the things that we’re working on right now is making it literally a single line to load in all of the plumbing for getting Angular set up or getting Bower set up so you can install your dependencies that way, or getting Backbone set up. So basically, it’s a huge advantage of ours I think to encourage that kind of separation between the client and server. And so, that’s a big focus I think moving into 1.0 and beyond, is really thinking about how to make Padrino the best way of writing APIs and also making it really, really easy to plug in and use JavaScript client frameworks. So, it’s something that we already have support for but we’re going to be documenting better and even making it significantly improved in the next couple of versions. DARIO:  One thing that we really strive for is let the best tool do the job. And in that case, particular when we’re talking about JavaScript and frontend related tools, I think that Bower definitely wins. And we are using it extensively to create and pool all the dependencies. And then we just start building an app on top of that. I guess one of the things that we could probably work on would be some sort of integration with a frontend reloader and the like so that it would just make it easier. But there are already tools that solve that issue like library load. But most people just don’t really want to be dealing with yet another tool when they are setting up their workflow. So, I guess that we may explore that path as well. NATHAN:  Yeah. We’re really excited by the prospect of even cleaner backends and removing a lot of the templating from the backend. And I think that that’s where things are heading right now. And pretty clearly, I think in a lot of cases. But not every case. We want to support both. So, there are plenty of people who are successfully not using JavaScript frameworks on the frontend for loading templates. And we want to support all those cases. And if you don’t want to deal with backend templates, then just remove the Padrino helpers module and you don’t need to think about it. So yeah, we just like to keep it agnostic. Let developers make their own informed decisions, basically. DARIO:  And one little tip there when building APIs, one thing that works really well is use RABL to render your views so you can easily render JSON, XML, whatever you need. And then you abstract that from your model layer and you can swap it around as well and it just works really, really well. AVDI:  Use what to generate views? CHUCK: RABL, R-A-B-L. DARIO:  R-A-B-L, yeah. NATHAN:  Yeah. We built RABL to be pretty much focused on Sinatra and Padrino. It works with Rails as well. But basically, what RABL is it’s an agnostic platform for describing APIs. And so, you can describe your API in Ruby and then you can have it output in JSON, XML, MessagePack, all the other output formats, automatically based on that singular description of the representation of the model. So, it’s just a really simple way of generating the API responses for your codebase. CHUCK:  I’m actually using it on DevChat.TV. DARIO:  Really? NATHAN:  Yeah, I actually built it out of a pretty big pain point that I was having with Rails at the time. I had a big Rails app and I was using to_json for everything. This was a long time ago. I know there are a number of solutions today that are pretty good, like Active Model serializers and those. But when I was doing Rails on Rails 2, the to_json approach was just breaking for me all the time as I was building real API responses. And it was really, really frustrating. And so, yeah, it just came organically out of that frustration. And nowadays, there are a number of great solutions out there which I encourage you to check out for yourself: JBuilder, Active Model serializers, RABL, there are a number of others that have sprung up out of that pain point. So, it’s a much better world to be living in today writing APIs than it was just even four or five years ago, which is great. And yeah, Sinatra really just can’t be beat for basic APIs. If you just want to write a simple, fast, lightweight API, Sinatra and Padrino is just significantly easier. Many people who’ve done Rails APIs, they know that it’s a pain especially around the fact that you can’t see your routes and your verbs inside the controller. So, you’re in the controller and you have no idea what the URLs or the verbs that you’re mapping to are unless you go to the routes file or if you just assume that it’s following conventions. But with Sinatra, the verbs, the URLs, and the actions are all in one place. And it might seem like a simple distinction but it makes a significant difference when you’re writing complex APIs. So, I definitely people to check out, especially for APIs, I cannot encourage you more to check out RABL and Sinatra for things that are just simple, RESTful backends. DAVID:  I have a workflow-esque question. We’ve talked about how Padrino extends Sinatra and it’s seamlessly backwards compatible. And when I first started looking at Padrino, what I was thinking was, “Man, what I really want is Sinatra but I want to be able to just plug in OAuth and an image uploader and be done.” So, I sat down and I went, and of course some of these gems do exist for Sinatra. You can get Sinatra Omniauth and that sort of thing. Is this a really, I’m hoping the answer is yes, but is this a perfect use case for Padrino? Where I sit down and like just now, I did a gem search for ‘auth’. Well, I did a gem search ‘padrino’ and then I grepped for auth. And I came back with two gems that are out there that do, one does authorization and one does authorization and authentication. And we talked about Devise earlier in the show and that sort of thing. If I don’t see what I need in Padrino, in the Padrino namespace of gems, is it totally cool for me, my workflow, just to immediately go to the Sinatra gem space and say, “Oh look, there’s Sinatra Omniauth. I can just grab that and plug that into my Padrino project and I’m good to go”? NATHAN:  Yeah. You’re on the right track there, absolutely. DAVID:  Cool. NATHAN:  So, Padrino is basically fundamentally Sinatra-compatible in every way. So, what that means is you’re absolutely right. With Padrino apps, you have full access to the entire Sinatra ecosystem. DAVID:  Awesome. NATHAN:  So, whether you [inaudible] the Sinatra middleware, you want to load Sinatra libraries, or any other Sinatra things, all of those work, I wouldn’t say all, but 80 to 90%of them work just as easily in Padrino. So, that’s a great point. When we first started working on Padrino, it was one of the biggest reasons why we chose Sinatra rather than building our own framework. We could have easily written our own framework. DAVID:  Right. NATHAN:  But the reason we didn’t do that was because there is this beautiful Sinatra community and community of plugins and documentation and all these things. And it was great. It wasn’t broken. I love Sinatra. I think the community for it and the plugins available and the Rack middleware that you can wrap easily in Sinatra helpers is a really, really great approach. And we don’t want to break that. We didn’t want to change it. We just wanted to make it even easier and even more maintainable than it was. So yeah, that’s a great point to bring up actually, is the backwards compatibility. DAVID:  That totally opens up, like you say, the Sinatra ecosystem reduces my fear of going into Padrino and suddenly discovering that, “Oh no, now I’m trapped somewhere between Sinatra and Rails.” And the answer is, “No, you can always fall back to Sinatra.” That is cool. NATHAN:  Yeah, we really enjoy that. And what it also means for us is we don’t have to reinvent the wheel every five seconds. DAVID:  Right. NATHAN:  One thing with Padrino that we really took very seriously is if you look at the Padrino codebase, as much as possible we tried to avoid reinventing the wheel, as much as possible. So for example, for rendering we just used Tilt. Tilt’s a great rendering engine. It works for Sinatra. It works for us. For a long time, for auth, we just left it up to the Sinatra auth or the Omniauth Rack middlewares for Sinatra. So yeah, it’s part of our philosophy, is we really want to avoid trying to think that we can do things better than things that already work really well from the perspective of light, modular services. So, if we see a library for Sinatra that works well, we often just encourage people to use that rather than try to rebuild our own version unless we have something to add. So, if we don’t see ourselves as a value add, we try to stay out of your business, so to speak. [Chuckles] DAVID:  Right. So, what is the best auth library to use with Padrino? NATHAN:  Well, we’re actually working on our own auth, which is actually going to be… DAVID:  [Laughs] NATHAN:  Built in. Padrino [inaudible] auth. SARON:  [Chuckles] NATHAN:  I know it’s funny, but the reason that we’re working on our own one is because we’re actually going  to be building on top of Warden and essentially trying to… there’s nothing as good, to be honest, as Devise for Sinatra and Padrino. If you look into it, there’s nothing as robust and comprehensive as Devise for Sinatra or Padrino. So, we want to create not exactly Devise, because Devise is very Rails-esque. But we want to create the equivalent for Sinatra and Padrino. And in fact if possible, we want that auth to work for Sinatra just as easily as it works for Padrino itself. So, it may end up actually being a Sinatra library, rather than a Padrino library. We’re still figuring out some of that. But yeah, right now I would say Padrino Warden is pretty good, padrino-warden. It gets the job done. It’s simple but I like Warden. It’s rock solid. It does everything you need. And also, the Padrino admin actually has a built-in auth system as well. So, I think between Sinatra auth, padrino-warden, and/or the Padrino admin user authentication system, I think most people’s needs are met. But I think we can do better. So, it’s something we’re still working on. DAVID:  That is very cool. CHUCK:  Alright, well let’s go ahead and do the picks. Avdi, do you want to start us off with the picks? AVDI:  I don’t have a lot to pick today. I think I’ll just pick a program that I’ve actually been fiddling with while we were recording this episode. I’ve been having some trouble with my arm lately. Some kind of nerve issue, which is probably related to sitting at a keyboard all day. And so, I’ve been attacking that in various ways. But one of the things I’ve been doing is I did get an ergonomic keyboard. And there’s sort of a yak-shave related to that, which is that now that I’m messing with various different configurations of keyboard, I’m having to finally learn how to touch type. I know, shock, shock, horror, I don’t touch type. But some of these fancier ergonomic keyboards, they really have the assumption that you can type without looking at your hands. So, I’m having to do that. And so, I’ve been using various touch typing tutors. And one of the ones that was recommended to me I think on Parley is a little program called Type Fu, which you can actually get on the Chrome Web Store. It’s a Chrome App for $5. And it’s really nice. It’s pretty simple, but it’s really put together very nicely and I’ve been liking it a lot. So, I was actually doing typing drills during this episode. So yeah, Type Fu. And I think I’ll just leave it at that for now. DAVID:  Have you checked out Typing.io? AVDI:  Yeah. To be honest, I think it’s a cool idea. So, Typing.io, that’s the one where you type in code. DAVID:  Yeah. AVDI:  They give you code to type. It just seems like a gimmick to me. DAVID:  [Laughs] AVDI:  No offense to the people behind it. But I’ve messed around with it. But if I’m going to be typing code, I’m going to be typing code for my job, or for fun. DAVID:  [Laughs] Yeah. AVDI:  I’m going to be typing my own new code. I don’t really feel the need to practice typing by typing somebody else’s code. DAVID:  Why would I ever what to practice doing the thing that I actually have to do? AVDI:  Exactly. DAVID:  I totally get it, yeah. [Chuckles] AVDI:  I like, the program I’m working with now, it’s doing one of those scaled things where as I get faster with a certain set of exercises, it adds a new key into the mix. DAVID:  That’s cool. AVDI:  Step by step. And that’s working pretty well for me. That reminded me of another one. There’s another one whose name escapes me but I’ll put it in the show notes. It’s just a bit goofier as a typing tutor program. But there’s this HTML5 video game where you basically have to type words in order to shoot space ships. SARON:  That sounds awesome. AVDI:  And it’s kind of fun. CHUCK:  [Laughs] AVDI:  I’ll find the name of that and I’ll put that in the show notes, too. CHUCK:  That sounds way fun. Alright, Saron, what are your picks? SARON:  Sure. I have two. One is a site that I found out about yesterday, actually, on the CodeNewbie Twitter chat called CanIUse.com. And it’s mostly for frontend stuff, but you get to pick different things like SVG fonts and gradients. And it has a really nice display of what browsers, whether on mobile or desktop, support the feature that you are trying to use on your front end. And it’s really pretty and it’s really nice. The second one that I also found out about recently is Source Graph. And it’s an app that allows you to essentially look up any functions, packages, any really code stuff that you want more information on. And when you type it in, it pulls up open source libraries and examples of how people are using either that package or that function or that whatever it is. So, it’s great. The other day, I type in just .inspect and it gave me a bunch of different examples of how it’s used. Because I feel like a huge problem with learning, especially as a beginner tool, is you look at a method and you look at a definition of how people use it, but it’s very different from seeing an example of it actually being used. So, I really, really love the app. It’s called Source Graph. And those are my two picks. CHUCK:  Awesome. David, have we heard your picks yet? DAVID:  We’ve not. I have two picks for today. The first one is, I’ve got a technical pick and then just a brain-dead silly fun pick. The tech pick is I’ve been shooting a lot of slow-motion action type stuff. And I finally broke down and bought the GoPro camera. These are freaking awesome. I’ve got the GoPro HERO3+ which is the current edition of it. This thing will shoot, at 720p it will shoot 120 frames a second. And in WVGA which is wide VGA so it’s 848 pixels by 480, it’s 16 by 9 but it’s 480pixels tall, it will do 240 frames a second. So, you can actually go out and go shooting and you can actually see the bullet moving through the air. You don’t get very many frames of the bullet, because 240 frames a second, you only get three frames. But you can actually see it. It will actually stop motion and it does really, really great stuff. And I’ve been having a lot of fun with it. And that’s really all I can say about it, is it’s a heck of a lot of fun. And you do want to pay attention to when you buy one, you want the 3+ not the 3 because the 3+ has a bunch of extra features. And I don’t know why they decided to do this. These guys need to… these guys have no clue what semantic versioning is like, because you can get the GoPro HERO3+ in white, black, or silver. And they’re all the same color. But the black has way more, it’s the latest version, or the best version. And the white is the simplest and the silver is the in between. So literally, the white can’t do the high frame rate and the silver can only do 720 at 120fps and the black can do wide VGA at 240fps. So, that’s some amazing anti-semantic versioning there. So yeah, GoPro HERO3+ Black Edition is my first pick, tech pick. And then just for brain-dead silliness, Harlock Space Pirate. And this is an anime. It’s the same kind of rendering quality as the Final Fantasy movies. So, just beautifully luscious rendering. It’s got a great storyline. The ending is a little bit quizzical and weird. So, if you liked the Final Fantasy movies where not everything is perfectly resolved but some things kind of are, it’s a lot of fun. That thing that you… I have to love this movie because I just wanted to stand up and cheer, is that it’s a pirate movie. So, there’s a pirate ship. So, there are ships shooting broadsides at each other as they circle each other. There are boarding parties. There are pirates swinging across on ropes from one ship to another. But it’s all in space. So, the pirates are wearing spacesuits when they jump from one ship to another. And the cannons are laser cannons. And it’s just ridiculous. Your suspension of disbelief has to be rated at not less than 500 metric tons. If you can’t suspend that much disbelief, don’t even bother with this movie. But if you want a whimsical, silly, outrageous bit of anime, Harlock Space Pirate will do it for you. I absolutely loved it. And those are my picks. CHUCK:  Awesome. I’m going to go ahead and just do one pick. It is called LootCrate.com. I don’t know if you guys have heard of this. But basically what it is, is it’s a subscription service and every month you get a box of cool stuff. So, the last month was villains. And so, I got a couple of smaller posters of Batman villains. I got a Darth Vader keychain. I got a couple of comic books. And it comes in this nifty box and it’s way cool. I liked it. I also got a t-shirt that had just some artist’s rendering of a mix of Joker and Loki. And he called it Joki. And anyway, I thought it was a cool shirt. So anyway, I thought it was really cool. So, I’ll put my referral code for Loot Crate in there. But I think it’s great. This month, they’re doing heroes. So, I’m really curious to see what they come up with. Apparently they have licensing deals with Star Wars and most of the comic book stuff. And so, you just get a whole bunch of really awesome stuff. So, I’m excited to get my box this month. Yeah, that’s my pick. Nathan, what are your picks? NATHAN:  I think I’ll stick with less exciting picks for today. Just some new Ruby libraries that I think are interesting. So, basically I’ll just mention three that I think are fun. So, shout-outs to Scorched.rb, which is another take at building a better maintainable Ruby framework. Pakyow, which is an interesting take on like I said, doing Ruby web development in a totally different way. And Lotus.rb, which is the newest. Lotus.rb is built by Luca, Luca Guidi. And I was looking at it recently and I thought it was a very, very interesting approach as well. So, I always like to keep on the forefront of what’s the latest in terms of the web development paradigms for Ruby. And I just encourage people to check out Pakyow, lotus, and scorched. CHUCK:  Awesome. Dario, what are your picks? DARIO:  I could point [1:04:57] as well on the technical side and say on the Ruby land, I would encourage you to have a look at spider-gazelle, which is a new application server [1:05:08] a while ago. And it’s based on Libuv, so it’s extremely fast. It has a really low footprint. And it just handles web socket connections like crazy. So, it’s really, really good to look at. In the frontend probably, I would say that you should definitely look at Flux and a pattern that Facebook presented not a long while ago. We’ve been using it since pretty much since it came out. And I must say that it definitely helps you get your UI and the interactions between data and the like very well [1:05:39]. Then one last one that is a more personal thing is this site called olife.com. It’s kind of handy because you write an email. It sends you an email every day and you just reply with something, whatever you feel like. And then it brings back things that you did in the past. And it’s nice to help you keep track of what you’re up to and what you’ve been doing, which is quite easy to forget. So, that’s it. CHUCK: Awesome. Arthur, what are your picks? ARTHUR:  I’ll go with a vim one, something called unite.vim. So, if you guys use vim it allows you to create user interfaces. A lot of times you have Control + P that allows you to search files and also you might want to do stuff like regex for [1:06:16] text files. So, unite actually creates a unified way. So, I don’t need to have three or four separate plugins. So, with one plugin I can have these custom commands that allow me to see everything within one buffer. So, it’s pretty handy. And a fun one, or useful one I think, is something called omw.im, on my way. It’s an iPhone app. I’ve been using it and it allows you to tell your friends or your family, I’m going to arrive at a certain time. And it tracks you as you’re on your way there. And then when you get there, it stops tracking. CHUCK:   Awesome. Alright. Well, thanks for coming, guys. And thanks for helping us figure out what this Padrino thing is all about. DAVID:  I’m excited. CHUCK:  Yeah, I think there are some folks out there that are really going to be able to take advantage of this and it’s definitely on my list now. NATHAN:  Yeah. Thanks for having us. It’s always fun to chat about web development frameworks and why we built Padrino. And thanks again for having us on. I appreciate it. DARIO:  And on that sense, one note there. You can always find us on IRC, Twitter, anywhere. Just go on the GitHub issues and I’m happy to help. CHUCK:  Great. What’s your IRC channel? DARIO:  It’s #padrino in irc.freenode.net. CHUCK:  Okay, cool. And just a reminder, we are still working on reading the ‘Refactoring: Ruby Edition’ book, so go pick that up. We’re going to be talking to Martin Fowler about it in October. So, look forward to that as well. Thanks for listening and we’ll catch you all next week.[A special thanks to Honeybadger.io for sponsoring Ruby Rogues. They do exception monitoring, uptime, and performance metrics and are an active part of the Ruby community.]**[Working and learning from designers at Amazon and Quora, developers at SoundCloud and Heroku, and entrepreneurs like Patrick Ambron from BrandYourself, you can level up your design, dev, and promotion skills at Level Up Con taking place October 8 **^th and 9** ^th ** in downtown Saratoga Springs, New York. Only two hours by train from New York City, this is the perfect place to enjoy early fall and Oktoberfest while you mingle with industry pioneers in a resort town in upstate New York. Get your ticket today at LevelUpCon.com. Space is extremely limited for this premium conference experience. Don’t delay. Check out LevelUpCon.com now.]**[This episode is sponsored by MadGlory. You’ve been building software for a long time and sometimes it’s get a little overwhelming. Work piles up, hiring sucks, and it’s hard to get projects out the door. Check out MadGlory. They’re a small shop with experience shipping big products. They’re smart, dedicated, will augment your team and work as hard as you do. Find them online at MadGlory.com or on Twitter at MadGlory.]**[Hosting and bandwidth provided by the Blue Box Group. Check them out at Bluebox.net.] **[Bandwidth for this segment is provided by CacheFly, the world’s fastest CDN. Deliver your content fast with CacheFly. Visit CacheFly.com to learn more.]**[Would you like to join a conversation with the Rogues and their guests? Want to support the show? We have a forum that allows you to join the conversation and support the show at the same time. You can sign up at RubyRogues.com/Parley.]