Testing everything is a good thing - or call it TATFT if you have to. While most programming languages already feature great testing frameworks, the ones available for JavaScript have just recently achieved a level of functionality that I would call nice to work with. First I've discovered blue-ridge, which is great if you use it within a Ruby on Rails project. And to be honest, I've gotten pretty much excited about it. Unfortunately though, it has some trouble running on several JavaScript engines, including Google's V8. Another caveat is that the only way to run tests in background with blue-ridge out of the box is with Rhino, which basically cancels out JavaScript code that makes use of arguments.callee.caller. It's too bad, that I haven't heard about JSpec earlier.

The list of JSpec's features is incredible, the DSL is beautiful (pretty close to RSpec's syntax), Ajax mocking works like charm (which you have to figure out with blue-ridge, or well, the included Screw.Unit and Smoke Mock combination more or less by yourself). And it is also great to use outside of Ruby on Rails projects. Something that is possible with blue-ridge as well, however, it leads to a quite of a hack if you want it to work well. And even though blue-ridge has received quite of a hype recently, I definitely recommend to check JSpec out. The spec runner opens all requested browsers for you, runs your tests in Rhino if you want to and runs your tests in all your browsers in background. And if you like BDD as much as I do, you will like its ability to do continuous integration, just like autotest.

Just one thing: While JSpec's installation is easy, it doesn't install Rhino for you. That should not be a problem though. Here's how you would do that on Mac OS X:

curl ftp://ftp.mozilla.org/pub/mozilla.org/js/rhino1_7R2.zip > rhino.zip
unzip rhino.zip
mkdir ~/Library/Java
mkdir ~/Library/Java/Extensions
mv rhino1_7R2/js.jar ~/Library/Java/Extensions/

That should do it. Happy Testing!

Labels: JavaScript

It has been a while since the last post of this blog series. Though, it is not over and today's post will definitely not be the last one. Previous participants have mainly been people working on the more theoretical side of computing. However, if you have followed this blog for a while you might have realized that I try to cover both, theory and practice. Therefore, today's open question is from: David Heinemeier Hansson.

Unless you have spent the largest past of your life hiding underneath a rock in the Chihuahuan Desert, you have probably already heard of dhh. Anyways, as I introduce every questioner, I won't make an exception today.

David Heinemeier Hansson is one of the partners of 37signals and most of his frame probably comes from the creation of the incredibly popular Ruby on Rails framework. He is a common speaker at Ruby, Ruby on Rails and open source conferences. But it doesn't stop there. He is also the co-author of one of the standard texts of Ruby on Rails development, Agile Web Development with Rails (together with Sam Ruby and Dave Thomas, now available in its third edition) and of many of the 37signals books, including the soon to be released book Rework. Well, it is more than likely that you already know all of this, so here is his question (short but well thought):

How can make programming less work and more fun and by extension attract people outside the traditional circles?

Ideas anyone?

Labels: Rails, Ruby, TOSOTT

Often, I do not feel like agreeing with Linus Torvalds. This is not because he is not right, but because of the very opinionated, sometimes even stubborn way he brings his message(s) across. To me one of his most interesting exploits comes from one of the messages he posted to the Linux kernel mailing list back in 2001 (which is archived on KernelTrap).

The topic of discussions was coding style and the ways of how Linux was (or was not) designed.

You know what the most complex piece of engineering known to man in the whole solar system is?

Guess what - it's not Linux, it's not Solaris, and it's not your car.

It's you. And me.

And think about how you and me actually came about - not through any complex design.

Right. "sheer luck".

Well, sheer luck, AND:
- free availability and _crosspollination_ through sharing of "source code", although biologists call it DNA.
- a rather unforgiving user environment, that happily replaces bad versions of us with better working versions and thus culls the herd (biologists often call this "survival of the fittest")
- massive undirected parallel development ("trial and error")

I'm deadly serious: we humans have _never_ been able to replicate something more complicated than what we ourselves are, yet natural selection did it without even thinking.

Don't underestimate the power of survival of the fittest.

And don't EVER make the mistake that you can design something better than what you get from ruthless massively parallel trial-and-error with a feedback cycle. That's giving your intelligence _much_ too much credit.

Many of us spend quite a vast amount of our precious time on design issues upfront. This is to make sure that our code is more maintainable, free of errors that could be avoided with a more thought through design, or just to increase our confidence in our piece of software. Every time I write a piece of code that only seems to work out of sheer luck, I very quickly loose confidence in it. I tend to read through it endlessly, refactor to see how much I can clean it up. Eventually though, I will delete it and rewrite it with what I have learned and most often I will find a way to implement the same functionality with a cleaner design. There is a mental block that disallows me from just giving it a show and trying it out in the wild. However, Linus, the maintainer of one of the largest and more successful open source projects known, seems not to have a different point of view.

What are your thoughts?

Labels: Programming

While I was refactoring a hand full of commonly used methods from a few controllers into a superclass, I was looking for a way to test that these controllers are actually inheriting from the new superclass and I won't mess up something in the future. Ruby's Class provides a superclass method which returns the superclass of the class the method is called on (obviously). Now while it is easy to simply add an assertion to each of the tests, I believe this is not very DRY, and well, doesn't look very good. I really like Shoulda macros, so I decided to write one for this particular case. Here we go:

# test/shoulda_macros/superclass.rb

class Test::Unit::TestCase
  def self.should_have_superclass(superclass)
    klass = self.name.gsub(/Test$/, '').constantize
    
    should "have superclass #{superclass}" do
      assert_equal klass.superclass, superclass
    end
  end
end

I inherited from Test::Unit::TestCase, so this should work in both, unit and functional tests. Now you can simply use it like this:

class CommentsControllerTest < ActionController::TestCase
  should_have_superclass MessageContextController
end

Labels: Rails, Ruby, Shoulda

This post in the The other side of the table series is one week late. Sorry for that. As I have mentioned earlier, it is a quite busy time for me at the moment. Anyways, this week we will hear what Lawrence C. Paulson's questions are.

Lawrence Charles Paulson is a professor at the University of Cambridge Computer Laboratory where he works on mechanical theorem proving and its applications. One of the widely known results is the Isabelle system, a generic theorem prover developed together with Tobias Nipkow from the Technische Universität München. He has used this system for his best-known work on verifying cryptographic protocols using an inductive model. Last year, Lawrence has been elected as an ACM Fellow for his contributions to theorem provers and verification techniques. Before that he has earned the Pilkington Teaching Prize. He is also the author of one of the standard books on the programming language ML, ML for the Working Programmer, and also Logic and Computation: Interactive Proof with Cambridge LCF, Isabelle: A Generic Theorem Prover, and Isabelle/HOL: A Proof Assistant for Higher-Order Logic.

I would like to know when the software industry will start taking quality seriously, with the ultimate objective of providing consumer warranties for software. Software is unique in giving the purchaser no remedies whatever; if the product won't launch, the purchaser cannot even resell it on eBay.

I don't forget the Morris Worm of 1988, a huge event that told the computing community of the destructive power of buffer overruns. Despite this early warning, the software industry continued to use unsafe APIs that made buffer overruns inevitable, writing literally billions of lines of unsafe code. Like the bankers, they pretended they were taking risks, but the only people they put in danger were their own customers.

Labels: TOSOTT