It was a long talk, so I couldn’t cover all the topics I wanted to cover. I talked about ubiquitous language, bounded contexts, core and support domains, and showed some ways to do this in Ruby, using modules. Basically, I concentrated on techniques to organize essential complexity, while keeping an eye on practical usage with Ruby and Rails.

When you talk about Domain Driven Design, you hardly cannot do that without mentioning the three types of objects that Eric Evans discusses in his book. It’s Entity objects, Value objects and Service objects. Still I managed to do just that. Time to fix it; here is what I failed to mention.

Entities

Entity objects are objects that represent something in the real world and can be referenced as such. Translated into Rails terms these would be instances of (most of) your models. You can reference a post instance by getting it via its id from the database.

These objects are prime candidates for using plugins like friendly_id, making the fact that these objects have a real identity in real life clearer. This is because you can now reference them by name, instead of some database id. To use friendly_id with Rails 3, point your gemfile to the ‘edge’ branch on github.

Value Objects

Objects that don’t have any real identity are called “Value objects”. Any object that is a value object has no real identity, nor is it important to know its identity.

Addresses are a good example. The value of the address (e.g. street, house number, city, country) is important. But it’s less obvious to store this in a database and reference it by an id. This id would be purely superficial and have no meaning in the domain you are designing.

A pure Ruby way to do this with Structs, which I have mentioned before on this blog. If you’re using a document based database, like MongoDB, these would obviously be embedded documents. With ActiveRecord you can use the composed_of-method. Allow me to demonstrate that:

# Attributes of Person include:
# 
# * first_name  string
# * name_infix  string
# * last_name   string
# * male        boolean
#
class Person < ActiveRecord::Base
  composed_of :name,   :mapping => Name.members
  composed_of :gender, :mapping => Gender.members
end

class Name < Struct.new(:first_name, :name_infix, :last_name, :gender)

  def to_s
    [ first_name, name_infix, last_name ].select(&:present?).join(' ')
  end

  def first_name
    super.presence || title
  end

  def title
    I18n.t(gender.key, :scope => :titles)
  end

end

class Gender < Struct.new(:male)

  def to_s
    I18n.t(key, :scope => :genders)
  end

  def key
    male ? :male : :female
  end

end

By defining to_s on these structs you can output their gender or name in views without doing anything special:

%dl[@person]
  %dt= Person.human_attribute_name(:name)
  %dd= @person.name
  
  %dt= Person.human_attribute_name(:gender)
  %dd= @person.gender

In this example, Person is actually an aggregate of the entity Person and two value objects, called Name and Gender. Although all attributes are flattened out in your persistence layer (in this case, your database table); they do have a deeper structure in your code. And it’s easier to test too!

Services

Things that aren’t really a ‘thing’ in the domain you’re designing are usually services. They are not really part of any entity or value object, but do something with them.

In Rails, these would be observers or plain Ruby objects lying around. Maybe it’s time to call them what they are and place them in app/services.

Every Rails developer knows the pattern “Fat Model, Skinny Controller”. This is a pattern to remember that you shouldn’t put model logic in your controller but in your model. But this pattern is often taken too far. There are people that give the params-object, or worse, the entire controller-instance, to the model and do their shit there. This is not right. Use a service for that.

Pagination and searching are good candidates for a service. But this blog post is on the long side, so I’ll save an example implementation of that for another time. No post is complete without a promise to a follow-up that never comes, right?

Conclusion

It’s the same as I said during my talk: Rails helps you by keeping accidental complexity at a minimum. You can use the techniques described in Domain Driven Design to organize essential complexity and make your application more maintainable. Just be careful not to over-engineer it, that would defeat the purpose. Always be critical of your own code and continue to ask yourself the same question: “Does this make my code better?”

Customizing my work environment is a nerdish hobby of mine. I spend far to much time tweaking my terminal. While I’ll save my terminal customizations for another time, I’ll show you my IRB tweaks in this post.

There are several tools to improve your IRB, and some of them have been around for ages. But the arrival of Bundler makes it difficult to use them. Bundler creates a bubble in which you have to specify your dependencies explicitly. Furthermore, with project specific gemsets, provided by the ever so awesome RVM, we need to install these IRB extensions for every project.

This means that you cannot be sure that extensions like Wirble are available in your new and shiny Rails console. There is only one way around that: add them to your Gemfile. This is what I usually add:

group :development do 
  gem "wirble" 
  gem "hirb" 
  gem "awesome_print", :require => "ap" 
  gem "interactive_editor" 
end

Extension Loading

To load the IRB extensions without blowing up in your face when they’re not available, I gently try to load them, and configure them only when that is successful. You can download my .irbrc on github. Here is what it looks like:

When you start IRB, it shows a line with the extensions loaded. If it’s gray, it’s not appropriate (like rails2 in this example), loaded extensions are green and extensions that are not available are in red.

Showing Queries in ActiveRecord 3

As you can see, the queries done by ActiveRecord are displayed in the same way as they are displayed in your log files. In Rails 2, you would’ve done this by redirecting the log output to STDOUT. In Rails 3 you need to subscribe to the ‘sql.active_record‘-notifications.

This could in theory also be done for other Rails 3 compatible ORMs like Mongoid, but I haven’t looked into that yet.

Hirb

Hirb formats objects into pretty tables, as you can see in the picture above. It also provides some scrolling possibilities like the command line tools less and more. Very handy!

Wirble

The first IRB extension anyone uses. Wirble provides you with history and syntax highlighting.

Awesome Print

While Wirble colorizes the output to improve readability, it can get cluttered really fast, especially when you’re dealing with nested hashes and arrays. AwesomePrint helps to untangle your object mess:

Print Methods

The ‘pm‘-extension I found on the intertubes some time ago, lists the methods and what arguments they take on any given object. You can filter it, by providing a regex. This is what it looks like:

It’s not a gem, but a snippet pasted directly into my irbrc, so it’s always available.

Interactive Editor

Open vim (or any other editor) from IRB, edit your code, save it, close your editor and the code gets executed. Open vim again and your code is visible and editable again. Very awesome! Check it out!

More

Yeah, there more. There’s bond, which makes autocompletion better, and utility belt, and more. I can’t remember to use them all, so I haven’t included them into my irbrc. They certainly are cool enough for you to check out! Also, a lot of great tips are here on Stack Overflow.

If you have any good tips, please share them! Oh, and the other OSX tweaks I use are on github.

PS. For those that don’t know how to load this: put the .irbrc file in your home directory and it will load automatically.

The jQuery UI framework contains some nice styles and some nice javascript to accompany it. But the class names you’re ought to be using are awkward. Nobody wants to add “ui-widget-header” to their classes. We have standards; we want semantical html and css, even if we don’t want to be doing much styling ourselves.

Editing the css file that jQuery UI gives you is not an option; that would be a hideous mess even before we get started. Luckily, Sass can help us. Sass introduced the “@extend” method since version 3, which we can (ab)use.

We need to convert the css file jQuery gave us to Sass. I’m a big fan of sass, not scss, so I’ll be using that:

sass-convert --from css --to sass \
  path/to/jquery-ui-1.8.2.custom.css > app/stylesheets/_jquery_ui.sass

I’ve included an underscore so it won’t be compiled to a real css file when I run my application. I’ve also configured Sass to load my sass files from app/stylesheets.

Next, create your own sass/scss file and use @extend:

@import jquery_ui

.project-header 
  @extend .ui-widget 
  @extend .ui-widget-header 
  @extend .ui-corner-all 

@import "jquery_ui";

.project-header {
  @extend .ui-widget;
  @extend .ui-widget-header;
  @extend .ui-corner-all;
}

Now you just need to add the class “project-header” to the appropriate HTML element, include the compiled “screen.css” tag in your layout and you’re done!

Be sure to use the javascript too, for nice interactions. The javascript will add classes dynamically to certain elements. They will still work.

So what really happens? Well, @extend appends your own selector to the jQuery selector you specified. So the compiled jQuery css would’ve looked like this before:

.ui-widget-header {
  border: 1px solid #aaaaaa;
  /* more... */
}

But after doing our @extend-trick, it will now compile to:

.ui-widget-header, .project-title {
  border: 1px solid #aaaaaa;
  /* more... */
}

Sass parsing is incredibly smart. Really smart. The original jQuery css will be changed automatically. Awesome! And without hardly any effort from my side!

For more awesomeness in styling: Have a look at compass. It will be worth your time!

class FooBar
  attr_initializer :foo, :bar
  def to_s
    "your #{foo} is #{bar}"
  end
end

FooBar.new('foo', 'bar')

But there is a way of doing it without a monkey patch. Use the Struct.

FooBar = Struct.new(:foo, :bar) do
  def to_s
    "your #{foo} is #{bar}"
  end
end

FooBar.new('foo', 'bar')

Pretty cool.

Update

As was pointed out in my comments by Radoslav Stankov (which you can’t see anymore, because I switched to Disqus), you can also do this:

class FooBar < Struct.new(:foo, :bar)
  def to_s
    "your #{foo} is #{bar}"
  end
end

FooBar.new('foo', 'bar')

I use this one more often, actually.

One final note: the parameters here aren’t stored as instance variables, they can only be accessed through their accessor methods.

Imagine you add a class to the menu item that is active, like this:

<nav id="menu">
  <ul>
    <li><a href="foo.html">Foo</a></li>
    <li class="active"><a href="bar.html">Bar</a></li>
    <li><a href="baz.html">Baz</a></li>
  </ul>
</nav>

Then all you would need to do is something like this with jQuery:

$(function() {
  $('nav#menu a').click(function(){
    $('nav#menu li').removeClass('active');
    $(this).blur().parents('li').addClass('active');
  });
});

I’ve added a blur()-command in between, so the dotted lines disappear earlier.

Try it out, you can really notice the difference. It works best when the menu items don’t move, but only change appearance.

Update

Because I switched to Disqus, some nice comments have gone. Stefan Borsje, of Pressdoc fame, replied with this concern:

To be honest, I don’t like it very much. It really changes a basic way the web works; you click on something, the page loads (and optionally shows an activity indicator) and you get to see the result. With this method you already get see part of the result even before the actual loading fase, which could easily confuse users by letting them think the page is already done but nothing has changed.

I agree that you should be careful applying this technique. But the clicking of the link is done instantly, so the user would see the page loading immediately, thus he/she wouldn’t think the page is done. This technique works best if your pages are speedy enough, but can use just a bit more oomph.

Rails gives you a helper module for every controller. The problem with modules is that they don’t contain state and are usually used to just put a lot of methods in. But this can grow quickly out of hand when the stuff that you’re building is a little more complex.

Never forget to run tools like Reek on your helpers as well. What do they say? Are your methods too long? Do your methods require too many arguments? Is the complexity too high? Do your methods have feature envy?

I’ve seen quite a lot of Rails projects and helpers are almost always the forgotten parts of the application. Every Rails developer knows about the “Skinny Controller, Fat Model”-principle. Better teams also make skinny models, by using modules and creating macro’s. But helpers are usually ugly. And they shouldn’t!

Helpers are code too! They want your love and dedication!

There are a couple of ways to keep it clean. Sometimes they are called “Presenter Objects” or something similar. It doesn’t matter how you call them, and you don’t have to use any complicated gems or libraries. Regular classes suffice.

Here’s an example of a typical helper:

module PostsHelper

  def post_title(post)
    header_class = post.published? ? "published" : "normal"
    header = content_tag(:h2, post.title, :class => header_class)
    content_tag(:div, :class => "post header") do
      if post.user == current_user
        [ header, edit_post(post), destroy_post(post) ].compact.join(' ')
      else
        header
      end
    end
  end

  def edit_post(post)
    link_to('edit', edit_post_path(post))
  end

  def destroy_post(post)
    link_to('delete', post, :method => :delete, :confirm => "are you sure?")
  end

end

You might choose a different route, like putting the if-statement in the view. But that’s beside the point. The point is that this is what usually happens when you don’t use objects as they are supposed to be used. Look at the post argument for example. It’s on every frickin’ method! That’s not DRY!

And what if you need to extend it? What if you need approve and reject links as well? What if the destroy link needs to only show when the post has been approved? It’s becoming more and more messy. Time to refactor!

This is an example of how I would do it:

module PostsHelper

  def post_title(post)
    PostTitle.new(self, post).to_html
  end

  class PostTitle

    attr_initializer :template, :post
    delegate :content_tag, :link_to, :current_user, :to => :template

    def to_html
      content_tag(:div, elements, :class => "post header")
    end

    def elements
      [ header, edit, delete, approve, reject ].compact.join(' ')
    end

    def header
      content_tag(:h2, post.title, :class => header_class)
    end

    def header_class
      post.published? ? "published" : "normal"
    end

    def edit
      link_to('edit', edit_post_path(post)) if my_post?
    end

    def my_post?
      post.user == current_user
    end

    # etc... (you get the drift)

  end

end

Nice! Small testable methods! Readable code! Less repetition. Run Reek on that!

If you’re wondering what the attr_initializer is, it’s a monkey patch, that I’ve described here. The delegate-method is something ActiveSupport offers you. Use it, it’s super effective!

Wait a minute. Did I say “testable”? Yes, I most certainly did! As with any code, this needs to be tested. But it’s not that hard anymore! If you’re using Rspec, you can use the helper specs it provides. But you don’t need to!

The PostTitle-class is a regular Ruby class, and so every test framework can test with it without much effort. You might want to use stubs and mocks for the other helper methods you call. Or subclass PostTitle, define the used helper methods and use this to subclass in your tests. The delegate specifies which other helper methods are used.

Remember that what you program is entirely up to you. You, and only you, have to decide when a simple method is enough, or whether you need to add a class, or something similar. You can also consider using Builder for some parts, if the HTML generation becomes too hard.

The main point is that any part of your application needs to receive the same attention to detail. Don’t hide your dead bodies (of code) in helpers, or anywhere! Be critical everywhere and all the time! Run Reek regularly. It’s a depressing tool and you don’t need to fix every message every time. Use it wisely and pay attention. There is no excuse for ugly code!

In this example, I would use a partial, but when the view logic increases, you should be thinking about extracting it.

Programmers humor dictates me that from time to time I say things like “In Ruby, that’s only one line!” or “In Ruby, that would cost me just one minute!”. Putting money where my mouth is, I wrote the entire application in just one line of Ruby.

So here it is. It looks more like Perl than Ruby. But it works!

String.class_eval{define_method(:to_grid){(self =~ /\A(\d+)x(\d+)\z/ ? 
(0...split('x').last.to_i).map{|_| (0...split('x').first.to_i).map{|_| rand > 0.5 } } : 
split("\n").map{|row| row.split(//).map{|cell_string| cell_string == "o" } }
).tap{|grid| grid.class.class_eval{define_method(:next){each{|row| 
row.each{|cell| cell.class.class_eval{define_method(:next?){|neighbours| 
(self && (2..3).include?(neighbours.select{|me| me }.size)) || 
(!self && neighbours.select{|me| me }.size == 3)}}}} && 
enum_for(:each_with_index).map{|row, row_num| row.enum_for(:each_with_index).map{|cell, col_num| 
cell.next?([ at(row_num - 1).at(col_num - 1), at(row_num - 1).at(col_num), 
at(row_num - 1).at((col_num + 1) % row.size), row.at((col_num + 1) % row.size), 
row.at(col_num - 1), at((row_num + 1) % size).at(col_num - 1), 
at((row_num + 1) % size).at(col_num), at((row_num + 1) % size).at((col_num + 1) % row.size) ]) 
} }} && define_method(:to_s){map{|row| row.map{|cell| cell ? "o" : "." }.join }.join("\n")}}}}}

I didn’t cheat! No semicolons where harmed during the making of the spaghetti code. I did enter some newlines in the code shown above to prevent wild scrollbars from appearing.

You can use it like this:

# generate a random grid
grid = "100x30".to_grid
# show the grid:
puts grid.to_s
# get the next generation of the grid
new_grid = grid.next
# convert a drawn out grid to a grid
new_grid.to_s.to_grid == new_grid # returns true

If you want to know how it works, or make an animation of it, it’s all here.

This is what it looks like:

It was a fun exercise, but I don’t think I’ll be writing all my code like this in the future :)

In views you can automatically scope translations to the view you’re working in.

So this HAML code (in the users#index view):

= t('.foo')

It’s the same as:

= t(:foo, :scope => [:users, :index])

I use this technique a lot.

Anyway, we could clean up it even more, by making a dynamic dispatcher. It would look something like this:

module ViewTranslatorHelper

  def vt
    @view_translator ||= ViewTranslator.new(self)
  end

  class ViewTranslator < ActiveSupport::BasicObject

    def initialize(template)
      @template = template
    end

    def method_missing(method, options = {})
      ViewTranslator.class_eval <<-RUBY
        def #{method}(options = {})
          @template.t(".#{method}", options)
        end
      RUBY
      __send__(method, options)
    end

  end

end

And now you can write:

= vt.foo

How does this work?

The vt method returns ViewTranslator instance. It is cached inside an instance variable. The ViewTranslator object inherits from BasicObject (ActiveSupport‘s BasicObject uses Ruby 1.9 if it is on Ruby 1.9, and constructs it’s own when on a lower Ruby version). BasicObject is an object that knows no methods, except methods like __id__ and __send__. This makes it ideal for using dynamic dispatchers.

When we define method_missing every single method we call on it will be passed to there. We could call @template.t directly from here, but we don’t. To know why, we must know how method_missing works. When you call a method on an object, it looks to see if the object knows the method. When it doesn’t know it, it looks to it’s superclass and tries again. This happens all the way until it reaches the top of the chain. In Ruby 1.8 that is Object, because every object inherits from Object. Ruby 1.9 goes one step further and goes to BasicObject. If a method is not found anywhere, it will go to the original object you called the method on and it calls method_missing. Since that usually isn’t there, it goes up the superclass chain until it comes to (Basic)Object. There it exists. It will raise the exception we all know and hate: NoMethodError. You can do this yourself too:

> "any object".method_missing(:to_s)
NoMethodError: undefined method `to_s' for "any object":String

You see, even though the method to_s does exist on the string, we stepped halfway in the process of a method call. The error message is a bit confusing, but the we just called a method on the superclass of String. Anyway, by defining method_missing on our own object, it cuts this chain short. To cut it even shorter, I define the method itself, so it doesn’t need to go through this process at all. After it’s defined I call the freshly created method.

Now, to be honest. This is not at all that expensive to use method_missing in this case. The chain is only classes long, so it’s hardly putting a dent in your performance. There are cases were this is very important though. One such case is ActiveRecord. When you call a method on a new ActiveRecord-object for the first time, you reach method_missing. It needs to look at the database to find out if it is an attribute. Looking inside the database is very expensive, so method_missing creates methods for all attributes. If the attribute exists, it will be called, and it’ll be a normal method call from then on.

Thanks for reading. If you found it informative: I love feedback ;)

I recently gave a presentation at my company Finalist IT Group about the philosophy behind Ruby. Code written with this philosophy in mind is called ‘Rubyesque’. It’s not hard science, so we had plenty ingredients for a discussion.

The reason behind the presentation was because we’re in need of more Ruby developers and looked inside our own company for Java developers that want to learn Ruby. Because Java and the philosophy behind it are so radically different from Ruby, we organized a discussion to explore those differences.

About programming and the ‘flow’

The Rubyesque mindset is all about opinions. Opinions tend to vary from person to person. By reading a lot of blogs and code I do see some sort of consensus. This opinion is not always explicitly mentioned, so I don’t pretend to speak in absolute truths or be complete.

Programming is usually compared with other professions to give an idea what it’s like to do it. Ruby programmers tend to compare programming with craftsmanship. I even go one step further. I think programming Ruby is a form of art of playing an instrument. Programming is a creative process. You’re programming to express meaning and intent. The only way to achieve this, is if you know your instrument so intensely that it’s not compromising you’re ability to express yourself.

Every programming language has its own style. You can call it its ‘flow’. It’s wise to go with the flow. It’s easier to use the language as it’s intended to be used than to go against it. For example, don’t try to force inheritance in a language that is intended to be prototype based. Program according to the flow and other programmers can understand and maintain your code better.

About Ruby

Everything in Ruby is aimed towards making the programmer happy. A happy programmer is better motivated to deliver great code and will feel responsible to do so. And better code makes everyone happy.

It’s the machine that is supposed to do the heavy lifting, not the programmer. This means that Ruby isn’t particularly fast, but since machine power is cheaper than man power, it’s not that big of a deal.

Ruby has a couple of traits that make it a joy to work with:

• Dynamic and open to bend it to your liking
• Few rules, so easy to learn
• There are ‘shortcuts’ for common tasks
• Many ways to reuse code, such as mixins
• Optional punctuation to improve readability
• Methods like attr_accessor to become more DRY

Dynamic

In a dynamic language it’s not important to know which type of object you’re dealing with, but it’s more important to know what it can do for you. This is called duck typing. This isn’t only handy in making mock object, but also means that you don’t have to abuse inheritance to comply to some method you’d like to call.

A nice example is the Rack specification. The header object you’re supposed to return needs to have the method each. It doesn’t say that it needs to be a hash. You could use a hash, but if it makes more in your sense to have some other object, it’s fine. You don’t have to inherit from hash, just to implement the each method.

The flow in Ruby is not to perform any check of the objects. If you’re explicitly want an integer, just call to_i inside the method. Any code that checks the type is usually considered to be distracting from the real meaning of the code. It’s the programmer that uses the gem/library responsibility to use the right objects, and not the responsibility of the gem-maker. The naming of methods and variables need to be obvious enough, so that it shouldn’t be a guessing game.

Open

In Ruby, nothing is final. This allows for the ability to add and change anything in any object, including core classes. This is called Monkey Patching or duck punching. This results in even nicer and more readable code, like:

15.minutes.ago

Nobody needs to explain this. Nobody needs to look up any documents to understand what is going on here. Monkey patching can improve the readability of the code immensely.

I understand that this technique may be considered extreme by some people. It doesn’t comply to the strict rules that govern most other languages. Still, these kinds of techniques are very handy and addicting.

Monkey patching is dangerous. It’s your own responsibility to use it responsible. Use tests to ensure that you don’t break anything unintentionally.

Punctuation

Some of Ruby’s punctuation is optional. Ruby programmers love to leave them out. It’s mostly a matter of taste. Readability is key here.

Rubyists rather write this:

class Post
  belongs_to :author, :dependent => :destroy
end

Than the same code with all punctuation visible:

class Post
  belongs_to(:author, {:dependent => :destroy})
end

It’s not important that {:dependent => :destroy} is a hash. Nor is it important that belong_to is a method, and that it takes two arguments. It’s much more important that the post belongs to an author and that the post will be destroyed when the author is being destroyed.

By not using all the possible punctuation, it becomes easier for our brains to focus on what is actually written, rather that which objects might be used to express it.

Few rules, many shortcuts

There are only a few genuine language constructs. There are just three elements in the language that have any real meaning. Those are objects, methods and blocks/closures. The only way in which classes and modules are special is by their implementation, but they are still regular objects. There are just a few other constructs, most notably if, while and the logic operators like && and ||.

The rest of the keywords you see are just shortcuts, you can type to perform common tasks. Like defining a class:

class Car < Vehicle
  # ...
end

The Ruby interpreter reads this as:

Car = Class.new(Vehicle) do
  # ...
end

Defining a class is actually just a method called on an object. The first argument is another object (the class to inherit from) and the second argument is a block. You can write it like this if you want to and play with it too, like dynamically making many different classes.

Some other examples:

counter += 1                   # this is a shortcut
counter = counter + 1          # without the shortcut, but also without punctuation
counter = counter.+(1)         # without the shortcut and with all punctuation (yes, + is just a method)

@user ||= User.new             # this is called a 'teapot'-operator or 'or-or-equals'
@user = @user || User.new      # assign @user to @user if it exists, otherwise create a new user

exit unless busy or cancelled  # 'unless' is a shortcut for 'if !()'
exit if !(busy or cancelled)   # 'if' at the end of a sentence is also a shortcut
if !(busy or cancelled)        # for a regular if
  exit
end

There are many more shortcuts. But why? Why are there so many ways to do the same thing? It’s not just readability, but also the ease in which you can translate the ideas in your head to code.

The smaller the difference between your thoughts and your code, the easier it is to program. Ruby gives you full freedom to express yourself how you feel fit. That doesn’t mean it always works out. If you have an unclear image of the problem you’re trying to solve, the code you write will be unclear too. Nothing stops you to write bad code. Ruby doesn’t force you in any way. These things cut both ways.

Exposing intention

Code needs to expose its intent. Ruby code is Rubyesque if it uses the above mentioned techniques to expose its intent. Because Ruby has such clean syntax, most DSLs (Domain Specific Languages) will be written in Ruby. These kinds of DSLs are called internal.

The naming of variables and methods is extremely important. The meaning of the code must be clear the first time you read it.

A fantastic example is Rspec, my favorite test framework.

describe Post do

  context "when it's not approved" do
    subject { Post.new(:approved => false) }
    it { should_not be_publishable }
  end

  context "when it's approved" do
    subject { Post.new(:approved => true) }
    it { should be_publishable }
  end

end

The entire Ruby bag of tricks is being used to make it as natural as possible to write down your specifications. This example doesn’t like like regular Ruby code, but it still is. It’s nothing more than objects, methods and blocks.

This is very Rubyesque. There is almost no distraction from the meaning of the code. I can plainly read if my code still does what my customer wants and I can run the specs to see if my code does what I specified it to do. And even nicer: it’s incredibly easy! Rspec makes Test Driven Development very easy.

If you’re interested in the code to implement this example, take a look at this gist.

Succinct and Concise

Rubyesque code is succinct. That doesn’t just mean short lines (I try to limit myself to about 80 or 100 characters per line), but also about short methods. The code smell detector Reek will raise a warning if your method is longer than 6 lines. Does this means you are not allowed to write longer methods? Of course not. Is it a good idea? No.

People are better at understanding short sentences. And it’s the people that need to understand the code and maintain. And we’re back to the philosophy behind Ruby. It’s meant to be understandable for people. It’s less important if the computer needs to do some extra work.

Conclusion

Ruby is a free language. You can bend the rules. The goal is to make you happy. Ruby was made to make you happy, to close the gap between human and computer language. Try to do that in the code you write too, it works!

I found that most people coming from languages like Java or PHP find Ruby a weird or magical language. That is only the appearance. Ruby is very easy to learn. It has few rules. Ruby programmers don’t code using rigid rules and dogmas, but experiment solving the same problem in different ways.

I hope you got some idea of what it means to program Rubyesque. I advise everybody to look at the different languages and their philosophies. See what philosophy suits you. If the Ruby philosophy suits you and you have the discipline needed to write Ruby, give it a try! Ruby transformed the way I feel about my job and never regretted learning it one bit.

Common Squirrel Monkey (from Wikipedia)

I often find myself writing code like this:

class Foo
  attr_reader :bar, :baz
  def initialize(bar, baz)
    @bar, @baz = bar, baz
  end
end

This can be very annoying to maintain. The variable names are repeated four times, within three lines of code!

Ideally, I’d want to write something like this:

class Foo
  attr_initializer :bar, :baz
end

Much better, if you ask me. Here is one example of how to do this.

class Class
  def attr_initializer(*attributes)
    attr_reader *attributes
    class_eval <<-RUBY
      def initialize(#{attributes.join(', ')})
        #{attributes.map{ |attribute| "@#{attribute}" }.join(', ')} = #{attributes.join(', ')}
      end
    RUBY
  end
end

No piece of code is complete without tests, so this is it:

class AttrInitializerTests < Test::Unit::TestCase

  def test_attr_initializer
    klass = Class.new do
      attr_initializer :foo, :bar
    end
    object = klass.new(1, 'b')
    assert_equal 1, object.foo
    assert_equal 'b', object.bar
  end
 
end