Fitnesse: executable specifications for the developers
Fitnesse is a framework that allows you to create HTML specification pages in a wiki. Those specifications can include any form of text, images and HTML links. But they can also include tables that specify acceptance tests for your system.
Then, provided that a developer (or better: a pair of developpers,...) has provided a "fixture", that is, a java class that will implement the table, the HTML page is executable! Once executed, the page shows the expected/actual results and uses the famous green/red colors to display those results.
I see many advantages to this approach:
- The HTML pages look like a classical specification to the analyst
- Having the analyst specifying very precisely expected values results in much better specifications
- This makes the analyst and developer discuss very precisely the requirements and their possible implementation (when creating the fixtures)
- This forces the analyst and the developer to think about the testability of their system, which usually results in better designed systems
- This is the start for a global Test-Driven approach to system development
- The wiki markup language itself is weak and would really benefit something like Confluence (if Atlassian guys hear me,...)
- The integration into a continuous build system is not standardized (with an ant task for instance)
- The implementation of some concepts is not first-class (try to add something like ${myVar} in a table,... Fitnesse will try to evaluate it, even if it is in fact part of your specification)
Rails: a bliss
It is hard not to come up with glorious adjectives when speaking about Rails. I have not been specifically a web application developer knowing all the nitty-gritty details of web application development: urls, sessions, security, html specifics, javascript,...
And Rails makes it so easy. Each time I asked myself: "how can I do that"? I found an elegant solution in the Rails framework. And when I dont find it, I think "I have to search harder,..."
Of course, part of the success of Rails is due to Ruby, enabling beautiful code with minimum of syntax. I have been, for instance, very easily refactoring some test code by intercepting calls to my tests methods to assert the same thing in several methods.
There are 3 other reasons in my mind:
- the famous "convention over configuration". Having nothing to do when implementing the default/most common behavior is productivity at its maximum
- the dynamic aspect of the language: you don't have to redeploy to see the changes
- the people that designed the framework really know about web application specifities. And they did their maximum to leverage Ruby and the DRY principle (Dont Repeat Yourself) to reuse this knowledge
I am really wondering what is going to be the success of Ruby and Rails in the next years. Certainly Java won't die (21st century cobol), but what I know for sure is that Ruby and Rails is really fun and productive to program with.
Those are 2 really strong arguments for people with squared fingertips !