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

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
      42
    end
  end
end

Here we define a module that contains a refinement (

refine

class TheAnswerToLifeTheUniverseAndEverything
  def self.answer(the_question)
    the_question.length
  end
end

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)
    the_question.length
  end
end

If we ask for

TheAnswerToLifeTheUniverseAndEverything.answer("I want the answer to everything!!! NOOOOOW")

String#length

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?

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!

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!"
    end

    on root do
      res.redirect "/hello"
    end
  end
end

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
end

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

module Tent::Views
  def index
    @tarpaulins.each do |tarpaulin|
      h1 tarpaulin.size
      div { tarpaulin.color }
    end
  end
end

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"
    finish
  end
end

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!

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() {
	alert(greeter.greet())
}

document.body.appendChild(button)

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

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!

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)
  end

  def find_uas
    raise 'Open the file first' unless @file
    # read file etc.
  end
end

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)
  end

  def find_uas
    raise 'Open the file first' unless @file
    # read file etc.
  end
end

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
end

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

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)

def initialize(body = Child.new) ... end

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!

given

when

then

given

when

then

given

when

then

This makes it easier to see what is just a test helper, which code is actually under test and what should happen to the different moving parts. Go read the readme in the rspec-given repository, Jim does a way more thorough job at explaining the semantics. Or if you know Cucumber, you can just continue! For the rest, I will be waiting, right here.

Back already? Good! Let’s continue!

A Primer on RSpec Given

So, if we want to write a Math library that uses a very strange notation, a spec could look like this:

describe "Math" do
	describe "#+" do
		it "adds two values" do
			let(:value_one) { 2 }
			let(:value_two) { 3 }

			Math.+ value_one, value_two

			Math.result.should == 5
		end
	end
end

I know, I know, it’s a very contrived example, sorry…

But what are we testing now?

Math.+

Math.result

With rspec-given, we could specify intent a lot clearer:

describe "Math" do
	describe "#+" do
		context "adds two values" do
			Given(:value_one) {2}
			Given(:value_two) {3}

			When { Math.+ value_one, value_two }

			Then { Math.result.should == 5 }
		end
	end
end

So we have two preconditions (setting

value_one

value_two

Math.+

Math.result

Math.+

then

it

I guess we all can agree that the second example is way more specific which code is there for what purpose. Which I like.

But that got me to ask one question: How do you extend the DSL? Let’s see:

Extending DSLs

First things first (because it wouldn’t make sense to mention the first thing at the end I guess? That saying has never made sense to me, sorry…), I’m looking at rspec-given-2.0.0.beta3. This way, Jim can’t ninja change things in there and then tell me I’m totally wrong.

Second things second (that doesn’t exist, does it?): Let’s have a look at the first file: rspec/given.rb. If we ignore RSpec 1 (someones still using that?), we include different files. One of the interesting files is configure.rb. Here the important lines (actually, all lines in this file except the includes):

RSpec.configure do |c|
  c.extend(RSpec::Given::ClassExtensions)
  c.include(RSpec::Given::InstanceExtensions)
  c.include(RSpec::Given::HaveFailed)
end

(On Github)

He uses RSpec.configure to extend and include a few extensions. If we take a look at RSpecs rubydocs, we can find RSpec.configure. Even more important, the Configuration object has two methods:

extend

include

These two are really similar. #extend is used to add methods to example groups (but not the examples itself). It is added to the

describe

it

Now guess what #include does. Right! It adds methods to the example itself, but not to the example group!

Now we know how we can add custom stuff to RSpec examples and example groups! Which is exactly what rspec-given does!

The class and instance extensions can be seen in extensions.rb.

That’s How You Extend a DSL

RSpec nicely enough provided everything we need to extend it’s syntax with our own methods. Of course this isn’t just handy for rspec-given. Everyone can extend RSpec with its own syntax, which might come in handy once in a while.

I suggest you have a look at the RSpec Configuration object, because it can actually do a lot. Did you know that it can show you the 10 slowest examples, automatically? Or that RSpec has before, after, and around hooks?

So not only have we learned what rspec-given is, how it works, but also how we can extend RSpec ourselves! Thanks Jim!

If you liked this post, you should consider hiring me freelance, part-time or full-time!

The Expert’s Dilemma?

Yes, the expert’s dilemma. What is it, you might ask. In fact, if you don’t ask yourself this question right now, why are you even reading? Maybe this piece then isn’t for you. If you are, however, wondering what that is and why you most likely also fall into this trap, read on.

The expert’s dilemma is quite simple: We try to emulate experts as well as we can. We try to listen to their opinions, follow them, and carry out everything they say. The problem with that? If you are not an expert, most of the things they say don’t matter to you!

Yes, seriously!

Let me illustrate through two examples: Fitness and Starcraft II. I know, I know, both of those have nothing to do with programming (except that progamer looks almost like programmer), but bear with me. Just a moment now.

Let’s talk about Starcraft II

Starcraft II is a really simple game. You have so-called harvesters, that gather resources. With these resources you can build more gatherers, units to attack or defend, or new structures and research to make everything stronger. Simple as that.

Now of course the pros are talking about balance, and that this unit might be a bit better if it had one attack power more than it has now. Or that if you delay action X, you can do action Y Z seconds faster. And other such fun things. If you follow all this advice, you fall into the trap of the expert’s dilemma.

When I started playing Starcraft II, it worked something like this:

Andreas: “Wohoo, I play Starcraft II. Let’s just try to play so I have fun!”
The Pro: “But Andreas, what are you doing? You should have a plan, you should scout your opponent!”

One week later
Andreas: “Whohoo, I play Starcraft II. I even scout!”
The Pro: “But Andreas, what are you doing? You should control each unit into his last detail!”

One week later
Andreas: “Wohoo, I have a lot of free time!”

Why did that happen? Because I tried to follow all the experts advice, I forgot that I first need to learn the basics: Gathering resources! So I started to lose a lot and I quit.

So all the questions about balance and all that don’t play a role for people like me, because other things play a much bigger role. For the pros who play all in the same percentile, they do. But for me?

Let’s talk about fitness

Ah, fitness. Where everyone has an opinion. And everyone has a different opinion. It sucks! It makes it hard to start. So let’s take the journey for a normal beginner (like me!):

Andreas: “Wohoo, I started with a fitness routine! So I run a few times per week and do some bodyweight exercises.”
The Pro: “But Andreas, what are you doing? Running hurts your muscle gain, so stop that!”

One week later
Andreas: “Wohoo, I started to do a lot of bodyweight exercises!”
The Pro: “But Andreas, what are you doing? If you would vary them more, you could get better results! Also, start doing them on 5 days instead of 3.”

One week later
Andreas: “Wohoo, I’m playing Starcraft II!”

Queue a rage comic here…

Result: Instead of following what I was doing and enjoying, I stopped doing anything. Instead of getting 80% of the results, I now get 0%!

This Is A Blog About Programming, Right?

Yes, absolutely. Now let me tie it back to programming.

TDD, BDD, refactoring, SOLID, performance, method to line ration, line per class ratio, test coverage, newest trends, etc. etc. etc. Sounds familiar? Do you get it now? No?

Damn it!

That was the point of the whole post.

Let me try again: There are a lot of buzzwords and other things to follow, which can choke a beginner. A beginner should be doing. (Careful: Controversial statement following!) If it isn’t perfect, who cares? It is more important to do than to do it perfectly!

Experts Are Nice, But…

I know the experts just mean well. But a beginner or intermediate can’t possibly follow all advice! It will confuse her or him more than actually following through with it!

So don’t blindly follow experts advice, just keep being awesome and improving along the way!

Don’t get bogged down, don’t try to do it all perfectly from the beginning. Add stuff slowly and concentrate on the basics. Because like in Starcraft II and in fitness, it is better to do the basics right than butchering all the experts advice.

Did you fall into this trap yet? Share your (horror?) stories!

If you liked this post, you should consider hiring me freelance, part-time or full-time!

I don’t know about you, but my Gemfile tends to have a lot of stuff in the group

:development, :test

group :development, :test do
  gem 'rspec-rails'
  gem 'cucumber-rails', :require => false
  gem 'database_cleaner'
  gem 'capybara'
  gem 'launchy'
  gem 'rr'
  gem 'awesome_print'
  gem 'jasminerice'
  gem 'guard-jasmine'
  gem 'poltergeist'
end

Holy crap that’s big! Of course, it also has some helpers only for development:

group :development do
  gem 'guard'
  gem 'libnotify'
  gem 'guard-spork'
  gem 'guard-cucumber'
  gem 'guard-rspec'
  gem 'guard-livereload'
  gem 'spork'
  gem 'pry-rails'
  gem 'pry-stack_explorer'
  gem 'pry-debugger'
end

Not too shaby, huh? So let me get into the details for each of those.

Guard

Guard is an amazing tool to automate nearly everything. Don’t believe me? Take a look at all the possible Guard extensions on Github! So what does Guard do?

It basically is a system that runs in the background and can watch files. Extensions tell it (through a Guardfile) that it should do something if a specific file pattern changes. For example, the Cucumber guard checks for this:

guard 'cucumber', :cli => "--drb" do
  watch(%r{^features/.+\.feature$})
  watch(%r{^features/support/.+$})          { 'features' }
  watch(%r{^features/step_definitions/(.+)_steps\.rb$}) { |m| Dir[File.join("**/#{m[1]}.feature")][0] || 'features' }
end

It looks at all features in the features directory, and Guard will call the Cucumber guard if one of these files changes. In term, guard-cucumber will call Cucumber and show it to you on the console. Neat, isn’t it?

Of course, this isn’t just for Cucumber! I also use the RSpec guard (for RSpec tests, duh!), Spork and livereload.

Spork is a DRb (Distributed Ruby) server that preloads the Rails environment so the tests run faster. Adding this guard makes Guard start the DRb server for Cucumber and RSpec automatically when starting Guard itself.

Another very neat guard is guard-livereload. Thanks to an extension in Chrome, this guard will automatically reload the page I have open when I change the ERb or the CSS files. Makes fiddling with CSS a lot easier!

You Have To PRY It From My Cold Dead Hands

PRY is one of those tools that you just have to know (and love). It is an alternative to IRB, and way better! Just add a

binding.pry

Some additions I added to Pry (and there are a few Pry plugins) are pry-debugger, so I can step through code and see what it really does. To complement Pry Debugger, I also use pry-stack_explorer. This plugin allows us to move up the stack and see the state of the code there.

Of course, in a perfect world, we never have to use one of these tools, but yeah… Real world and these things…

Testing tools

You might now say: “Hey! You said you will talk about testing tools, not support tools!” And you are right! (Though these support tools are amazing for testing!)

Yes, testing tools. For my testing needs I use the standard combo RSpec, Cucumber, database_cleaner, Capybara and rr stack. I don’t think I have to explain these (Do I? If I do, you should tell me so in the comments!)

Additionally I use launchy to launch a browser window with the current state of the page to debug Cucumber steps.

I also make copious use of awesome_print, because it is, well, awesome! awesome_print can be used instead of

puts

pp

Last But Not Least: JavaScript Testing

Something I struggled with for a bit, but found a good solution for, is JavaScript testing. There are two aspects here: One is Cucumbers Javascript support. For some acceptance tests, I needed Javascript to run. Per default, Cucumber uses Selenium (with a real browser), which is slow and not awesome at all! And then there are the Javascript unit tests, that also need to run.

For the unit tests I settled on Jasmine. Why? Because it seems it even tries to be as close to RSpec as possible, so I don’t have to learn yet another testing system. To run them, I of course, use a guard: guard-jasmine (Who’s surprised?)

guard-jasmine uses PhantomJS to run the Javascript tests in a headless mode (without a user interface), which makes them fast (not incredibly fast, but at least fast).

Of course we also want to integrate the Jasmine unit tests with the asset pipeline so we can use CoffeeScript. Luckily, Brad Phelan solved that problem and released JasmineRice.

Now, this doesn’t yet solve the Cucumber problem. For that, we can use Poltergeist. Poltergeist is a PhantomJS driver for Capybara. Do you see how this neatly matches up with guard-jasmine? Nice, isn’t it? I just configured Capybara to use Poltergeist instead of Selenium, and now the tests run at an acceptable rate.

So, What’s Your stack?

Yes, that is my “standard” Rails testing stack. I think this covers about everything I need. One thing that’s not included (because I currently don’t need it) is something like VCR. VCR records HTTP interactions, so that during testing the HTTP calls don’t have to be made, but can be replayed by VCR. Which makes things even quicker.

Have I missed something? Added something superfluous? What do you use for your testing stack?

If you liked this post, you should follow me on Twitter and sign up for the RSS feed!

And, like the monkey that I was, I thought statically typed languages were the best! Why? IDEs have a really easy time to refactor a lot of code. Everything was clear. Well, you know, the standard arguments you probably also here when we talk about statically typed languages.

But this post has nothing to do with statically typed languages, with me having seen the light at the of the tunnel and all that. And since you are reading this, I guess you did the same!

But, fun fact, here, for free, no sign-up needed: Ruby can do a lot more. A lot! And it has it warts, and it has its way of doing things. This isn’t easy to understand when you are knew, or even when you are experienced.

So here are 3 tips on what you could learn from reading Eloquent Ruby by Russ Olsen:

Strings In Ruby Are Awesome! Literally!

Ever had to write a string in Java? I feel sorry for you, because I have written way too many back in the days. Remember

"This is a \"String\""

"\\..*"

The first string problem is easy to solve in Ruby: Just use a single quote! But even better, if you mix single and double quotes in a sentence (“And here shall “REST” Java. It’s done.”) we can solve this with a string literal:

%q{And here shall "REST" Java. It's done.}

The Regex (or Regexp?) we could write as

/\..*/

There is a lot more that can be done with string literals, so you should check that out in the book!

Ruby Has Hooks For A Lot Of Things

Ever written a module? Imagine that you are that module. This is carry stuff! Just think about it: You have to blindly stumble around, never knowing which class carries you around!

Luckily, Ruby offers us hooks that we can use to alleviate these problems. Each module has a

self.included

This way you can build up a list of all classes that have this module included. Doesn’t sound very handy? But maybe, when the module is included, you also want to extend that class. Maybe you have a method that should not be on the class, but on the object!

With

self.included

How To Build Your Own DSL

DSLs. How much we all love these little things, and how much we use them each and every day. Thank you, dynamic typing!

Probably you have at least seen some RSpec code. Yes, all that

let

describe

Even better, he also mentions how to build an external DSL. An external DSL is not written in Ruby, and has to be parsed “by hand” with Ruby (without the Ruby interpreter helping). Which does have its pros and cons, as you might imagine.

Conclusion

All in all, a very good book that opened my eyes (and still does, on my second reading of it!). One of the really nice features about the book is its structure. Russ gives us first an introduction why we want to do this, then tells us how. So far so good.

But then he continues: He also tells us how you can get in trouble with it. To top it off, he shows some examples of the described concept in the wild.

If you are a Rubyist and you haven’t yet read Eloquent Ruby, I highly suggest you do. Because Ruby can do a lot more than you might image!

If you liked this post, you should follow me on Twitter and sign up for the RSS feed!

Though for this post we will concentrate on Deflate. Deflate is not only used in gzip and zip, but is also a fan favorite to compress web assets when sent to the browser.

The Basic Building Blocks

Underneath Deflate uses LZ77 combined with a Huffman encoding.

LZ77 is used to detect duplicate strings and insert a so-called back reference (more on this later). Huffman Encoding is similar to ASCII, but instead of always using 8 bits, it stores the most used characters in 3 bits, and the least used ones, with, well, more bits. More on this also later.

Come On, Deflate Already!

First, Deflate chops up all parts into blocks to make processing easier. Then it decides in which mode it should encode that block:

1. Store raw stream
2. Store with a static Huffman encoding
3. Store with a dynamic Huffman Encoding

Now, it still doesn’t deflate. But lets see.

First mode is raw mode. In raw mode, Deflate decides that the data is already compressed and it can’t do a better job. So it just inserts its header to say “I can’t do anything with that, this is already compressed, dummy!”. That’s why, the next time a coworker shouts at you why you didn’t ZIP these files, you can shout back: “D’oh, mode 1, man!”.

Second mode is static Huffman mode. This just means that Deflate decides that the data is standard enough that the standard Huffman Encoding table should be used. For example useful for English text. This way Deflate doesn’t have to add a table as overhead to the compressed content.

Third is dynamic Huffman mode. With dynamic Huffman mode, the content gets compressed with a Huffman Encoding, but the encoding table is generated based on the input. So for example, in Finish, the shortest code would probably be “ö”, or something like that. In @zedshaw‘s recent tweets it could be “C”, “F”, “K” and “U”, who knows!

But that leaves us with two question: Huffman Encoding, wut? And LZ77?

Huffman Encoding

Huffman Encoding is something that a guy called Huffman developed while getting a Ph.D from MTI MIT. Nothing surprising until now! The paper on it is actually from 1952. Damn it! That’s double my age! That paper should feel old!

What it basically says: Tally up all individual characters. The most used one gets the shortest code (at 3 bits). Then continue down until you arrived at the end. Actually, Wikipedia does a better job at that than I ever could, so here’s a picture:

Huffman Coding Tree

So that one sounded scary, turned out to be really easy!

So What About That LZ77

The next part in this tour around compression algorithms leads us right back into history. Can’t we get something new going in the compression world?

LZ77 was introduced in a paper in, well, 1977 by Lempel and Ziv. LZ77 is a so-called sliding window compressor. At least they came up with impressive names back then. Why sliding window? It checks the last 2, 4 or 32 kB for repeating strings. Simple as that.

Should it find one such repeating string, instead of adding that string to the output stream, it puts a back marker in that basically says: If you want to finish reading that sentence, go back to page 32, line 17, and read from character 17 to character 34. That lazy bastard!

Now I See How They Tie Together

Well I hope you do! Else I failed and you should shame in the comments. Or of course I can try again:

First, Deflate splits up the document into blocks to make working with it easier. Then (lets assume the input isn’t already compressed) it runs each block through LZ77 to get all the obvious double strings out of the way. Then it sends it through a Huffman Encoding to make it even shorter.

So yes, that’s deflate.

What About The Others (BZIP2 Anyone?)

Not all of them use this simple approach, because simple apparently isn’t good enough. BZIP2 goes through 9 different stages.

1. Replacing all 4 or more repeating characters with just 4 characters. (There you see, a geek had to make this algorithm for comic books! “AAAAAAAAAA!” is so much longer than “AAA\7!”) So called Comic Book Encoding… Unfortunately not, it’s simply called Run Length Encoding. How boring!
2. Next they wheel around the characters. Which basically means a fancy way to sort the same letters after each other so compression is easier. The so called Burrows-Wheeler Transform.
3. Replace all repeating characters with 0, so we have as many 0 as possible. Could also be any other character. The Move-to-Front Transform (Yes, I hate these people too at concerts).
4. And again, after sorting everything possible, we do a Run-length Encoding.
5. Then a Huffman Encoding. Don’t tell me now I have to explain what that is!
6. Then again we see Huffmaaa\7n! This time with multiple tables per block to make the output even shorter.
7. 8. and 9. Add some binary trickery.

So yes, you can use a lot of other things, but it all comes back to making the output even shorter. Surprising, hu?

So That’s Compression

Yes, that’s compression. Use a bit of special encoding, remove duplicates, and you are halfway there. Of course, this is just for Deflate. We saw that BZIP2 is already a lot more complicated and uses a lot of different tricks to make the output even smaller, but then again, it is also slower!

If you liked this post, you should follow me on Twitter and sign up for the RSS feed!

B58P3MMWCDTH