The blog of a thinkerer.
By @featureenvy

All rights reserved.

Ruby 2.0 Reaches Feature Freeze: What Will Change?

Yes, you read right: Ruby 2.0 is in feature freeze! This doesn't mean it will be released in the next month. But it introduces us the most important changes that will come with version 2.0. The timing is actually pretty impressive, since this feature freeze was announcement by Yusuke Endoh one year ago! Ruby seems to be on track (pun totally intended)! Want more details? Read on!

The Release Plan

Right now, there are two important milestones left: Code freeze and release. Code freeze is planned at the end of the year. So all the bugs should be more or less ironed out by then. And then, on February 02, 2013, 20 years after Ruby became part of this world, Ruby 2.0 should be released!

The New Features

There isn't yet an official list out with all the new features, but the source code, commit history and discussions are open to the public, so it is no secret! This isn't a big release as the change from 1.9 to 2.0 would suggest, there are only a handful of new features:


Refinements are one of the more interesting changes that could actually change the way Ruby code is written. It allows you to monkey patch a class, but only where you want to, and not in the global scope. Monkey patching could actually become an accepted thing to do! Some code? Sure:
module StringExt
  refine String
    def length
Here we define a module that contains a refinement (refine) for String. Because length should always be 42 (for whatever reason...). Let's define a class that could use it:
class TheAnswerToLifeTheUniverseAndEverything
  def self.answer(the_question)
But that is wrong! And that's right. No, wait, I mean, the answer is wrong, but the rest is right. That's because we didn't use the refinement yet, we just defined it. Let's use it then:
class TheAnswerToLifeTheUniverseAndEverything
  using StringExt

  def self.answer(the_question)
If we ask for TheAnswerToLifeTheUniverseAndEverything.answer("I want the answer to everything!!! NOOOOOW") it will tell us 42. Exactly what we want. But the behavior of String#length outside of our class hasn't changed. At all! Only when we use it inside class that is using this refinement is the behavior changed. Which could be really handy!

Named Arguments

Another one that we might end seeing a lot is named arguments. Named arguments could replace the options hash that is so prevalent in todays Ruby code. Use def namedParameters?(yes: true, no: false) [...] end. Then there are some internal changes and some speed improvements for MRI. Nothing exciting, but definitely good changes.

Will It Break Stuff?

Most likely? No. The most likely candidate to break stuff? respond_to?. The behavior of respond_to? in regards to protected methods has changed. By default, in 2.0, it doesn't search for private or protected methods, in Ruby 1.9 it only excludes private methods. The amazing Tenderlove has a great writeup about this. Apart from that, it seems like there is nothing else that will break with Ruby 2.0, so the upgrade should be easier then going from 1.8 to 1.9. Even though the roadmap is actually pretty big!

Yay! Exciting Stuff!

I'm looking forward to Ruby 2.0. I'm especially interested in what kind of clever hacks people will come up with now that we have refinements. What are you looking forward to? What is still missing in your opinion? If you liked this post, you should consider hiring me freelance, part-time or full-time!

Does Rails Still Deserve To Be The Default Web Framework In Ruby?

To answer the question directly (aka a TLDR here for the impatient): I don't know. Read on! (HA! Tricked you there!) Let's take a dive through some Ruby web frameworks. There is one or two around, even if we don't count Rails. I promise!

But First, Let's Take The Rails

You know, I'm from Switzerland. We love the Railway here. We take it everywhere. It's our go to solution. Why? It offers everything we need, it is on time, and we can precisely plan when we will be at the destination. Like Rails! It is the go to solution, exactly because it offers so much stuff. Want migrations? It's right there! Want an asset pipeline? It's right there! Want to use SASS? It's right there! Architecture? Done. Validations? Done. ORM? Done. Security? Done. This is really nice! And we know that it might not be the quickest way to get somewhere, but it will surely get us there in a hell of a good time and still can continue from there. There are no dead ends! If you are American, I'm sorry. I know you probably don't get why calling Rails after the Railway is a good and apt metaphor. So come visit Switzerland, get a good local beer with me and I will show you why!

Onwards, To Cuba!

Cuba! Where you can really do whatever you want. Welcome to the island of simpler times. The island where everything still seems easy. Cuba doesn't have too many complicated processes. Everything can be done, as long as you do it yourself. Welcome to Cuba, the Ruby microframework. Using Cuba is real easy:
require "cuba"

Cuba.use Rack::Session::Cookie

Cuba.define do
  on get do
    on "hello" do
      res.write "Hello world!"

    on root do
      res.redirect "/hello"
Yes, that's it! Inspired by Sinatra? Maybe. It offers a few other things, like security or template handling through Tilt. A very simple, and laid back framework. Very fitting for Cuba.

Lets Go Camping

But of course, now that we are in Cuba, let's go camping! This way, we can see the landscape. We can see the world like it really is, unfiltered. And it is healthy, too! Don't know how to set up your tent? No problem, maybe the Camping framework can help:
Camping.goes :Tent

module Tent::Models
  class Tarpaulin < Base; end

module Tent::Controllers
  class Index
    def get
      @tarpaulins = Tarpaulin.all
      render :index

module Tent::Views
  def index
    @tarpaulins.each do |tarpaulin|
      h1 tarpaulin.size
      div { tarpaulin.color }
Yep, that's it. Very Rails inspired, isn't it? But it makes sense, because going camping with the train makes a lot more sense! And yes, it is all in one file. Including MVC, including routes, including everything! But will it replace Rails? I don't think so.

All That Traveling Gives Me A Cramp

Already? A cramp? We just traveled a bit around Cuba and you have already a cramp? I guess it was time to get you out of your comfort zone! Ah, that damn cramp. This is something special. But lucky for us, we don't have to wait until your cramp recedes, we can just continue. Nice, isn't it? Don't know why we can continue even while you have a Cramp? See for yourself:
require 'cramp'

class GoHomeAction < Cramp::Action
  def start
    render "Let's Go Home"
Yup, that's it. The cool thing about Cramp? It is designed for asynchronous requests right out of the box. It is very simple, but powerful, if used the right way. But, since walking around with a cramp isn't fun, maybe it's time that we head home.

Home Sweet Home

Welcome back! I hope you enjoyed this tour around the (Ruby) world. I know I did! So to answer the question that the title was asking all along: Probably not, since all these other frameworks target another niche. Will something replace Rails? I don't know. Rails has a lot of convenience built it that it just a burden to lose. And I don't think we will see a new full featured web framework soon. But these micro frameworks are really nice for the small niche that they chose to fill. So for very small apps, maybe Rails isn't the right choice. For bigger ones? I still think the convenience of Rails can't be topped by these small frameworks. If you liked this post, you should consider hiring me freelance, part-time or full-time!

Why Microsoft, Why? (aka Introducing TypeScript)

Interesting. Microsoft recently released their own version of JavaScript, TypeScript! Now, some people might want to mock Microsoft for that. Maybe they just couldn't make Visual Studio play nice with JavaScript, so they made TypeScript. Oh wait! I am one of those people! Naah, let's be serious here. TypeScript is something like CoffeeScript. It does less and more. It offers "proper" type support and a class system. They don't touch any syntax however. At first I simply wanted to introduce TypeScript, but it turned out in fact I just wanted to rant about how wrong Microsoft is once again in trying to introduce their own standards.

An Example, Please!

Sure, judge for yourself:
class Greeter {
	greeting: string;
	constructor (message: string) {
		this.greeting = message;
	greet() {
		return "Hello, " + this.greeting;

var greeter = new Greeter("world");

var button = document.createElement('button')
button.innerText = "Say Hello"
button.onclick = function() {

(Taken straight from their documentation) So this is basically JavaScript syntax. All braces are kept intact. Except it introduces classes and types, that will be checked during compilation.

So, Why?

Apparently, some people working for Microsoft had problems with JavaScript. Which is fair, since I guess we all have problems with JavaScript sometimes. Microsoft solution? Make our own JavaScript! Because, let's be honest, this worked so well with a lot of stuff they did, like, oh, ActiveX... or OOXML.

Why Does Microsoft Need Its Own Stuff Again?

I honestly have no idea. No idea whatsoever! It doesn't make any sense. We have CoffeeScript. If they wanted to back a JavaScript replacement with types, why not back Google's Dart? It would make a lot more sense. But no, Microsoft had to introduce its own stuff again. Why will remain a mystery, probably forever.

Will This Succeed?

Probably. Why? Simply because in Microsoft world, people love Microsoft stuff. Nothing wrong with that, it is convenient. And if Microsoft backs something, this means people will probably pick it up. The integration into Visual Studio, the IDE of choice for Microsoft programmers, will probably have superb support for TypeScript, including refactoring and all the other goodies that people expect from IDEs these days. So yes, I think a few people will pick it up, just because it is bundled. The same way that a lot of Rubyists picked up SASS, or CoffeeScript, simply because it comes bundles with Rails. And yes, I know, not every Rubyist uses Rails, sorry 'bout that!

You Don't Like It, Right?

Well, no. It doesn't offer enough new stuff that we could consider this a new awesome thing that could change the landscape of web programming. In fact, I don't think it offers anything new. So no, I don't like it. I don't like it when companies waste good, sparse programming talent. Why couldn't Microsoft back Dart? Than that language would suddenly be huge! If Chrome and Internet Explorer come with proper Dart support, Mozilla would have no choice but to back it too! But no, this way we, again, have multiple "standards" that aren't interoperable. We will have another fight on our hands with Google pushing for Dart, Microsoft for TypeScript, and Mozilla (maybe) for CoffeeScript. Does this remind anyone else of web codecs? No, no, and no. I do not agree with that decision by Microsoft. I think its wrong, bad, and it definitely won't help move the web forward. In fact, it pushes it backwards. So sorry. No.

Is The Time of The Big Languages Coming To An End?

Go, Rust, Erlang, R, Closure and what all the new(er) languages around the block are all called. But one thing is certain: They are all niche languages. Why is that? Why don't we have another C or Java? One language to rule them all? If you have ever chosen a new language to program in, you know the steps: Look at whats available, dabble in them, find out what other people think about it. Or you might do it like I did. Chose a framework, and then learn the language that this framework is written in. This way I got started in Ruby.

Big Languages Are The Past, Right?

But is the time for big languages, ones that we use for everything, coming to an end? Maybe. The last "big" language is C#, and just because it got a lot of promotion from Microsoft. Before that? Java. C. Cobol. Let's not go further into the past please! And while no new all purpose language has come out, we get more and more niche languages. R for data processing. Rust for systems programing. ClosureScript for writing web applications in a LISP dialect.

Programming Languages Have A Short Lifespan

Is the time of the all purpose programming language coming to an end? I think so. There was a time when a company would use one language. One framework. One database. One operation system. But today? Employees chose their operation system. Databases are mix and matched freely for whatever purpose they serve best. And programming languages are intermingled in huge systems.

The Programming Language Lifecycle

Programming languages seem to have a limited lifetime. They take a few years to mature, are then picked up, and a few more years later, replaced by something new. And I think we should all embrace this change. Because we learn a lot about language design, programming. CPUs get faster and faster, so the language designers can get away with even more every year. Is this cycle inevitable? Yes. It is. There are some languages which try to dump every new thing into it (hello Java, hello C#!). But look at what happens when you just put everything in your fridge in a pan and let it cook for an hour. You get crap! The same thing happens to languages as well. The only fix is to do something new, which takes full advantage of that new paradigm.

No Good Programmer Knows Just One Language

Programmers who can just use one language are becoming a rarity. Does who do will soon be obsolete. So don't think just because you use Ruby you are save. Ruby is quite popular right now, so according to the language life cycle, it will soon be made obsolete by something better. Will everyone switch to the new thing? Of course not, there is a good reason why big companies still search for Cobol programmers. But those of us who want to stay ahead, who want to belong the circle of not just good programmers, but great programmers. We can't look the other way. We can't ignore all new languages and stay too comfy with our current languages.
Don't have a holy cow that you aren't ready to slaughter!
If you liked this post, you should consider hiring me freelance, part-time or full-time!

Are Your Abusing Constructors, Too?

Ah, constructors. The little, forgotten, and often abused thing. No one really thinks about it for long, no one really knows what it does. Everyone tends to ignore it until they think they need it and throws things into it with no care whatsoever. Yes, the constructor might be the best equivalent to a homeless child. And yet, recently, I started thinking more and more about homeless children constructors. They are a defining character of all object-oriented programming languages. And they do fulfill an important role! So let's learn a bit more about the homeless constructor.

Do's in a Constructor

Ever had a class that felt awkward to use? Where you, in practically ever method, first checked if some precondition was fulfilled? That might mean you have forgotten to put something in a constructor. The simple rule is: Everything the class needs in order to work goes into the constructor. For example, recently I wrote a small proxy to Nokogiri. The class looked something like this:
class XmlHelper
  def open(file)
    @file = Nokogiri::XML(file)

  def find_uas
    raise 'Open the file first' unless @file
    # read file etc.
With one method, that might work. But how would I add a second method here? I would have to do the same check if the file is actually opened again. Which means the class isn't ready for operation after the constructor is called! So I fixed this the easy (but hey, stylish!) way:
class XmlHelper
  def initialize(file)
    @file = Nokogiri::XML(file)

  def find_uas
    raise 'Open the file first' unless @file
    # read file etc.
Yes, one small change. From now on, when someone wants to make an instance of XmlHelper, he has to provide a file to read. Which means the class is ready to be used.
Put things into the constructor if the class can't feasibly be used without it.
Another great use of constructors? Dependencies! Of course, you could add a dependency like that:
class Limb
  @child = Child.new
We have two problems with this:
  1. The Limb class knows too much about its surroundings. Maybe it just needs to tell the child that it is tired. But what if we suddenly want to use the Limb class with an Adult? A dog? We can't do that with this implementation!
  2. Another problem is testing. We can't, in a unit test, easily replace Child with a mock or a stub. Maybe instantiation of a child is difficult (it takes 9 months for gods sake!) Or we simply want to test the interaction between Limb and Child, which is difficult if we don't know to which Child this Limb is talking to. (Remember: A constructor shouldn't do real work!)
The better way to do it?
class Limb
  def initialize(body)
    @body = body
Ah, now it's obvious, right? We can simply add a new body that this Limb belongs to. And the Limb doesn't care anymore if it is a child or not. For the lazy who don't want to type Limb.new(child) all the time, we can also change the initialize call to def initialize(body = Child.new) ... end so the Child is automatically added if we don't specify something else.

But Don't Put These Things Into the Constructor!

So now that we have a usable object after construction, what doesn't belong in there? Should we just throw everything into there? Now that we know what to throw into a constructor, it is easy what not to throw into a constructor. In short: Everything else. If not every method in the class needs this property, if the class doesn't need this information to work correctly, then don't add it to the constructor! If some methods need a property, and the others don't, you probably should split the class up into two. They deal with different things. One special thing though: If the initialization logic is very complex, it might be better to put it into a builder. A builder is a separate object that can be used to build up an object. It can even build objects of different classes (that have the same method, of course) given different input.

Ah, So That's Constructors!

Yes, so it is. So please stop abusing the little homeless kid on the block and treat it with the kindness it deserves. It shouldn't be dropped all responsibilities, but don't forget that it is there and you can use it. To summarize: Pass a constructor all the information the class needs to work properly, but nothing more. Have I forgotten some use case for constructors? Do you know some other constructor abuse cases? Then drop a line either here in the comments or on Twitter! If you liked this post, you should consider hiring me freelance, part-time or full-time!