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.

Comments

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...

Rails 3.2, MiniTest Spec and Capybara

What do you do when you love your spec testing with Capybara but you want to veer off the beaten path of Rspec and forge ahead into MiniTest waters? Follow along, and you'll have not one, but two working solutions. The setup Quickly now, let's throw together an app to test this out. I'm on rails 3.2.9. $ rails new minicap Edit the Gemfile to include a test and development block group :development, :test do gem 'capybara' gem 'database_cleaner' end Note the inclusion of database_cleaner as per the capybara documentation And bundle: $ bundle We will, of course, need something to test against, so for the sake of it, lets throw together a scaffold, migrate our database and prepare our test database all in one big lump. If you are unclear on any of this, go read the guides . $ rails g scaffold Book name:string author:string $ rake db:migrate $ rake db:test:prepare Make it minitest To make rails use minitest , we simply add a require ...

Poor person's guide to managing Ruby versions

Understanding the guts of Ruby Version Management by rolling your own I've been tinkering with a fresh install of Ubuntu 12.10, setting up a nice clean development environment. One of the first things to do, of course, is implement some sort of Ruby version management. RVM and rbenv seem to be the clear winners in this arena, though there are a lot of tools out there that do a similar job . Writing your own version management for your Rubies isn't actually all that difficult. At it's core, we need need two things: A way to segregate the executables of the various versions A way to call the versions at will Segregating versions is trivial - working with files and folders, we can put the various versions into named directories. Actually executing our different versions is not all that difficult either. One way would be to create aliases with version numbers and explicitly call those when we want to use them. The more popular way, however, is to manipulate our PATH ...