Codegram Blog

Linting the hell out of your Ruby classes with Pelusa

2012-02-14T16:12:55Z

As you might know, yesterday morning we had Monday talks at the office! Oriol talked about Object Oriented Nirvana, inspired by an old post about how to improve Object Oriented skills by using certain constraints while you're coding.

Then I got immediately interested on how to automate this, and knowing how easy is dealing with the Rubinius' Abstract Syntax Tree, I decided to give it a try and develop a tool that statically analyzes Ruby code to gain insights from it.

But what does it mean "statical analysis"? It means that this tool won't run any of your code at all, it just inspects it like you would as a developer, by looking at it. Since code is nothing more than nodes inside nodes, you can easily identify certain patterns that you consider wrong or desirable (for example, having else clauses in ifs, nesting blocks, or just using the word "foo" in actual programs). By traversing the AST, you can analyze parts of the code that don't fit your particular style or code quality requirements (actually with a little more work you could programmatically change those parts, i.e. automatic refactoring). I find this really cool!

The tool I've been working for the last couple of days is something along these lines (excluding, for now, the automatic refactoring part).

Introducing Pelusa - a Ruby Lint to improve your OO skills

Pelusa (which is Spanish for the word lint) is a static analysis tool and framework to inspect your code style and notify you about possible red flags or missing best practices. Above all pelusa doesn't run your code -- it just analyzes it syntactically to gain superficial insights about it, and raise red flags when needed.

Although Pelusa needs Rubinius to run, due to how easy it is to work with a Ruby AST with it, it doesn't mean that you have to run your application or Ruby code on Rubinius. Since it's a static analysis tool, pelusa doesn't care what your code runs on, it just looks at it and tells you stuff.

If you're curious, it looks like this (running on it's own code base, oh inception):

Find the default lint checks too Taliban for your tastes?

These are just guides, so you're free to fork the project and add/remove lints as you like. The fact that I've started with those doesn't mean that any of us thinks these are the true and only practices of Object Orientation, it's just a set of constraints that are fun to follow to achieve a mindset shift in the long run, or just to explore new styles.

One of the next features will be easy composability of lints, so you can remove those you don't like and add custom ones that fit your team's style or quality standards :)

Pelusa as a static analysis framework

With Pelusa, writing your own lints becomes very easy. Check out some of the default lints under the lib/pelusa/lint/ directory in the Github repo. Rolling your own style has never been easier!

Conclusion

My point by doing this was mainly exploring static analysis with Ruby, since I've never done it before, but also proving a point: good development tools are not only for statically typed languages! With a little imagination we can leverage our skills to make life better, or at least more interesting, for Ruby developers as well.

What do you think? Would you use this kind of tooling in your everyday job?

This week's talks: "Creating basic Chrome extensions" and "Object Oriented Nirvana"

2012-02-13T10:46:44Z

Check out this week's internal talk slides at Codegram:

Basic Chrome Extensions: Marc Divins introduced us to the creation of some extensions. Warning: Intense trolling ahead!
Object Oriented Nirvana: Oriol Gual refactored some of our Spinach codebase by applying some Object Orientation's best practices taken from The ThoughtWorks Anthology

Introducing Monday Talks at Codegram

2012-02-06T12:16:29Z

We've been noticing an increasing knowledge specialization ever since we doubled our team earlier last year, going from the 3 cofounders to a team of 6 people. This is a natural process, but sharing knowledge has become a bit trickier. As a company we sell knowledge, thus it's our most valuable asset — and sharing it among the team (and outside it) is crucial to increase our value.

Although we do have a set of common places to share knowledge (from an internal Google Groups site to various link-sharing tools), achieving the same level of specialization in all the fields is a hard task.

Given this, we had an idea: why don't we prepare weekly talks about software and computer science in general, and expose them to our peers every Monday? So we did this: Monday Talks is about sharing knowledge with your peers, improving your public speaking skills, and most importantly — having fun while doing it!

We've set up a site where we publicly upload the slides for our talks.

Also, if you want us to give an extended version of any of this talks at your company or university, with more examples, bibliography and Q&A, contact us :)

This week's talks

Josep Jaume: Heroku Buildpacks: Heroku for everything
Txus: Building a VM in Ruby

Hack Friday (Xmas Special)

2011-12-19T15:57:25Z

If you're around Barcelona next Friday the 23rd, we're pleased to invite you to our very special

Our special edition will feature free cake, beers, nougat and champagne and will start at 16:00. We will hack stuff away, discuss about Backbone and other hot trends, CSS 7.0, and basically whatever you want.

Also, if we promised you a Programming Motherfucker T-shirt and you didn't get it yet, this is your chance peoples.

Just comment this post if you plan to come, so we can plan ahead and there's enough beer for everyone :)

Update: Forgot to say where we are!

DataMapper, an alternative to ActiveRecord

2011-11-04T00:00:00Z

A few days ago we started a new project at Codegram. The project (which is still in development and will be released as open-source soon) is a good challenge for us and a real motivator: we all were tired of using always the same technologies, so we decided to use some tools we hadn't had opportunity to use. One of them is DataMapper.

So what is DataMapper and why using it?

From DataMapper.org:

DataMapper is an Object Relational Mapper written in Ruby. The goal is to create an ORM which is fast, thread-safe and feature rich.

From Wikipedia article:

DataMapper is an object-relational mapper library written in Ruby and commonly used with Merb. It was developed to address perceived shortcomings in Ruby on Rails' ActiveRecord library.

So, as the Wikipedia article says, DataMapper is an alternative to ActiveRecord. So why using it instead of the default ActiveRecord?

No need to write structural migrations
Scoped relations
Lazy loading on certain attribute types
Strategic eager loading
Default support for composite and natural keys

As you can see, DataMapper has some really interesting features. This post will be a little introduction to this ORM, let's see some of them.

Using DataMapper with Rails 3.1

First of all, we have to add Datamapper to our Rails project. I haven't found any metagem to include Rails and DataMapper basic gems, so we'll have to use this in our Gemfile:

Gemfile

source :rubygems

gem 'actionmailer'
gem 'actionpack'
gem 'activemodel'
gem 'activeresource'
gem 'activesupport'
gem 'tzinfo'

%w{core constraints migrations transactions timestamps do-adapter rails active_model sqlite-adapter}.each do |dm-gem|
  gem "dm-#{dm-gem}"
end

Our first DataMapper model

No more config needed! What now? Just start coding! Don't forget to bundle install first! Everything right? OK, then, here comes the important part: our first DataMapper model.

A typical DataMapper model (app/models/book.rb)

class Book
  include DataMapper::Resource

  \# Attributes
  property :id, Serial
  property :title, String
  property :synopsis, String
  property :edition, Integer

end

Wow! Amazing! Yeah! Looks beautiful, right? If we check the model line by line, we find that:

The model no longer inherits from ActiveRecord::Base. Oh, wait, we are not using ActiveRecord anymore, so looks legit.
We include the Resource DataMapper module, which adds some basics methods and includes the Assertions module.
We define the id attribute, which will be a Serial. You can find more info about DataMapper data types in the docs.
We define three more attributes: title and synopsis (which are Strings) and edition, which is an Integer.

Now that we have our model written, we have to create the database before creating our first book. Once we enter rake -T on our shell to see all our Rake tasks, we find two new tasks:

rake db:automigrate will destroy all our data and update de database to the last version
rake db:autoupdate will update our database without destroying our data

So what happens with rake db:migrate? I don't want to lose everything every time I migrate! Don't worry, it's aliased to rake db:autoupgrade, so it won't hurt you if you're too used to rake db:migrate.

We can now create our database with rake db:create db:autoupgrade and we can create our first book in the database! Let's open our beautiful Rails console and create our first book. <spam>I'm using a real world example: a novel written by Patrick Rothfuss which all you fantasy-lovers should read. Oh, and people who just enjoy reading too :)</spam>

:001 > book = Book.create(title: "The Name of the Wind", synopsis: "A rare find these days, fit for lovers of fantasy and newcomers to the genre alike.", edition: 20)
 => #<Book @id=1 @title="The Name of the Wind" @synopsis="A rare find these days, fit for lovers of fantasy and newcomers to the genre alike." @edition=20>

Wohoo! OMG it looks so beautiful! As I know you liked this way of defining the model's attributes, let's take a look at migrations before we go to the controller.

Structural migrations and lazy-loading

Structural migrations? I don't know another way to call them, so I call them this way. Structural migrations are those that change a database table structure: the ones that add or remove a field, add or remove primary keys, change a field type or add or create a table. That is, all the migrations that define the current database structure. Those migrations don't exist with DataMapper.

Let's see the usual procedure with ActiveRecord (actually, the list order is not important):

Think about the model's attributes
Add validations to the model
Write a migration to create the model's table and add attributes

So we often create the migration at the last moment to ensure we don't forget any field. And I repeat, you won't need this last step with DataMapper. Let's take the example from above and suppose we want to modify some model attributes, so our Book model will now look like this:

Our DataMapper model (app/models/book.rb) after some changes

class Book
  include DataMapper::Resource

  \# Attributes
  property :id, Serial
  property :title, String
  property :synopsis, Text
  property :author, String
  property :publication_year, Integer

end

Notice we've added two new attributes, author and publication_year, and we have changed synopsis's type from String to Text. Let's update our database with rake db:migrate and see what has changed:

:001 > Book.first
 => #<Book @id=1 @title="The Name of the Wind" @synopsis=<not loaded> @author=nil @publication_year=nil>
 :002 > Book.first.synopsis
 => "A rare find these days, fit for lovers of fantasy and newcomers to the genre alike."

So what has happened here? the database has been successfully updated to our last version: the book doesn't have any edition number and now has an author and a publication year. And what about the synopsis? What does <not loaded> mean? DataMapper lazy-loads some data types to make database queries faster. This means that fields with a lot of data (like Text attributes) won't be loaded until they are required, like in this example.

Other migrations

What if I really need a migration? Well, that's a good point against DataMapper: this way of migrating and updating the database is really nice, but fails when we really need to change the data. There's a gem out there called dm-migrations which could help you on that, but I haven't tried it, so I can't tell you anything about it right now. Sorry about that :(

Beautiful scoped associations

Let's see another database-related feature from DataMapper: scoped associations. To see the point, we have to add two new models and modify our Book model a little bit:

app/models/author.rb

class Author
  include DataMapper::Resource

  \# Attributes
  property :id, Serial
  property :name, String

  \# Relations
  has n, :books

end

app/models/book.rb

class Book
  include DataMapper::Resource

  \# Attributes
  property :id, Serial
  property :title, String
  property :synopsis, Text
  property :publication_year, Integer

  \# Relations
  belongs_to :author, key: false
  has n, :topics, through: Resource

end

app/models/topic.rb

class Topic
  include DataMapper::Resource

  \# Attributes
  property :id, Serial
  property :name, String

  \# Relations
  has n, :books, through: Resource

end

Woah, not so fast! What does through: Resource mean? Another beautiful DataMapper feature! Stablishing relations through Resource makes DataMapper auto-create the table between books and topics, but that's not all! You want beautiful things? You'll have them. Open your rails console and enter the following after migrating the database:

:001 > book = Book.first
 => #<Book @id=1 @title="The Name of the Wind" @synopsis=<not loaded> @publication_year=nil @author_id=0>
 :002 > book.author = Author.create(name: "Patrick Rothfuss")
 => #<Author @id=2 @name="Patrick Rothfuss">
 :003 > book.topics
 => []
 :004 > book.topics << Topic.create(name: "fantasy")
 => [#<Topic @id=1 @name="fantasy">]
 :005 > book.topics
 => [#<Topic @id=1 @name="fantasy">]
 :006 > book.save
 => true
 :007 > BookTopic.all
 => [#<BookTopic @book_id=1 @topic_id=1>]

WAIT AGAIN! What's that?? Amazing, right? When defining a relation through Resource, DataMapper creates a class so that relation becomes an object! Let's try to destroy this one!

:008 > BookTopic.first.destroy
 => true
 :009 > Book.first.topics
 => []
 :010 > BookTopic.create(book: Book.first, topic: Topic.first)
 => #<BookTopic @book_id=1 @topic_id=1>
 :011 > Book.first.topics
 => [#<Topic @id=1 @name="fantasy">]

So you can play with relations modifying directly the relation object. Let's keep with the scoped associations we were talking about before and try this on our rails console again:

:012 > Author.first.books.topics
 => [#<Topic @id=1 @name="fantasy">]

That's how we get all the topics an author has written about without using dirty Arel Table relations, try this with ActiveRecord ;) Actually, associations are a really powerful resource with DataMapper. We could keep talking about them forever, but you can also take a look at the DataMapper associations docs page, which is pretty neat and clear about that. You can also take a look at the Finding docs page, where you'll find another amazing feature with associations: queries combination.

Rails controllers with DataMapper

Just to end the post, I wanted to show you how a Rails controler looks with Datamapper. I've uploaded a gist with my BooksController so you can have a look at it:

Rails Controllers with DataMapper

\# This class is responsible for the Books REST interface.
\#
class BooksController < ApplicationController

  \# Get a book by the id
  before_filter :get_book, only: [:edit, :update, :show, :destroy]

  \#  Renders the form to create a new Book.
  \#
  def new
    @book = Book.new
  end

  \# Creates a new Book from the params and redirects to edit view.
  \#
  def create
    @book = Book.create(params[:book])
    redirect_to book_path(@book)
  end

  \# Renders the form for a given book. 
  \#
  def edit
  end

  \# Updates a Book from the params and redirects to edit view.
  \#
  def update
    @book.update(params[:book])
    redirect_to edit_book_path(@book)
  end

  \# Renders all books
  \#
  def index
    @books = Book.all
  end

  \# Renders a Book
  \#
  def show
  end

  \# Destroys the Book object from database
  \#
  def destroy
    @book.destroy
    redirect_to action: :index
  end

  private

  def get_book
    @book = Book.get(params[:id])
  end
end

As you see, it's very similar to an ActiveRecord one, except for one thing: DataMapper doesn't have a find method. So use the get method, which works pretty similar to the first one :)

Final thoughts

I must say I love the DataMapper approach about the model, this way of clearly showing what attributes a model has and the clean way DataMapper migrates the database. I've been looking for a good way to have my models information properly sorted and easy to access, and I think I can achieve it with DataMapper and some design pattern like Single Responsibility Principle. I just wanted to introduce you to DataMapper, an ORM not as used as ActiveRecord in Rails world, but I really think you should give it a try.

As a final note, you can find a debate on using DataMapper or ActiveRecord here. You'll find some of the points explained in this post and some more to help you decide :)