Skip to main content

Ruby frameworks, Rails and Padrino

Some thoughts on the Padrino and Rails. For the past few weeks, I've been working on a small project that is using Padrino rather than Rails. The interesting thing was that the decision for the technology was based on the idea that the project was only going to have a few objects; at most five or six and as such, didn't need something as large, complex or weighty as Rails. However, something as barebones as Sinatra would not allow for some of the more rapid application development that you get from some of the baked in goodness of Rails - things like Sessions, Flash, Form helpers and generators all speed up development fairly considerably. With that in mind, Padrino was the framework of choice.

Now Padrino is interesting. It's a great little framework, but, the temptation is to look at it's relative light-weightedness in comparison to Rails and think it will require less learning time or up-front knowledge for someone with little experience of the framework or of something like Rails. This is really a false economy. I would, in fact, say that for a beginner, Rails, not Padrino, is the sensible choice. Rails has excellent documentation right out of the gate, Padrino - well the documentation is just okay. It's enough for a seasoned developer to use, but unless you are already familiar with Rails, you might find yourself floundering a bit trying to figure out how to do something relatively simple.

The other area in which Rails really excells is in the sensible defaults - Padrino, in a way, requires you to really know your technology up front. Padrino is less opinionated than Rails and allows you to plug in various different components to pretty much any part of the system, even coding your own if you fancy. However, this kind of flexibility comes at a price - you need to know what you're going to use up front - Datamapper? ActiveRecord? Sequel? With Rails, the decision has been made for you - ActiveRecord. No faffing about with analysis paralysis. On the other hand, this kind of agnostic framework is good for those with specific requirements to use the non-defaults.

Where Padrino really shines in my opinion, is in the admin support. Generating an admin backend to your app is so simple. Granted with Rails you can use ActiveAdmin or something, but really, having this kind of CRUD baked in to a framework is awesome - one of the things, incidentally, that I love about Django.

So, when should you use Padrino? Well, my advice is, when you already know Rails and you want a framework that's a little bit smaller. But, heed this will if you are new to Ruby based web frameworks - learn Rails first.


Popular posts from this blog

Getting started with Ruby on Rails 3.2 and MiniTest - a Tutorial

For fun, I thought I would start a new Ruby on Rails project and use MiniTest instead of Test::Unit. Why? Well MiniTest is Ruby 1.9s testing framework dejour, and I suspect we will see more and more new projects adopt it. It has a built in mocking framework and RSpec like contextual syntax. You can probably get away with fewer gems in your Gemfile because of that.Getting started is always the hardest part - let's jump in with a new rails project rails new tddforme --skip-test-unit Standard stuff. MiniTest sits nicely next to Test::Unit, so you can leave it in if you prefer. I've left it out just to keep things neat and tidy for now. Now we update the old Gemfile: group :development, :test do gem "minitest" end and of course, bundle it all up.....from the command line: $ bundle Note that if you start experiencing strange errors when we get in to the generators later on, make sure you read about rails not finding a JavaScript runtime. Fire up your rails server…

Add css class to your label form helpers

Say, for example, you are using Twitter Bootstrap to style up a quick rails app and you want to throw in a label tag with the class set to "control-label" just like the bootstrap guys do you do it? And more importantly, since you don't want to specify the text of the label, how do you accomplish that? Fear not intrepid young but soon to be rails guru, behold the truth:

Overriding equality and Test Driven Development

Ruby has, at its root, an Object. Methods available in Object are available to every class because every class in Ruby inherits from Object somewhere in its own class hierarchy. Of course, you can override methods in subclasses, changing the functionality of a root method.You might stumble on to this idea if you work through Test Driven Development By Example by Kent Beck, translating the Java code into Ruby as you go. At some point pretty early on, he overrides the equality method on the Currency class to better test if two instances are equal. I'm going to do the same here, working with Instruments instead of Currency.EqualityEquality in Ruby can be expressed using any of the following three methods object == other equal?(other) eql?(other) These methods are defined on the base Object. The default implementation of equality will only return true if both objects are exactly the same. The interesting thing is that although these three methods start out functioning the same, the do…