So, in the following, I will give my impressions of Sass, CoffeeScript and Hogan.js.

Sass

As its name implies, this CSS extension is AWESOME and makes CSS easier to write and read, and I haven’t even used yet half the features (it’s not like I required those).

It eases the writing of a hierarchy of rules and eliminates the redundancy of the rules when applying styles to deep elements. Obviously, mixins and variables allow to keep most repetition of things like colors or fonts down to the minimum.

One can compare the new improved stylesheet compared to the old version.

CoffeeScript

Using CoffeeScript is really a matter of taste. It enhances the Javascript experience, but it has some quirks, especially with a ruby environment in mind. For example, for a method call, if you have parameters you can omit parentheses (à la ruby), but without any you need them since it would otherwise think you’re using the function reference (à la javascript). And some shortcuts are not available (an empty jQuery object is not a false value). But having proper class support and automatic variable scope management is helpful.

Hogan.js

I had one big chunk of my javascript code which was building a HTML component from JSON data and I found it sometimes a bit hard to edit and modify. I had recently seen mention of a templating framework used by LinkedIn, dust.js and I noted this in a corner of my mind. More recently I stumbled on Twitter’s Hogan.js templating engine. And what’s more, I also found a asset integration for rails. So I jumped in. And the result is pleasing enough to use.

• Parseexcel: Not sure if it is still maintained. Reads data sort of ok while looping rows with an iterator but not in random-access mode;
• Roo: More pain than anything just to get is installed. Didn’t even bothered to try to make it work to access the data;

• Jruby-poi: Apparently, the formulas that I need are not correctly (if at all) handled by this one.

Ok, thanks everyone, I think I’ll go back to CSV parsing.

I rewrote entirely the javascript and display to look (and somehow act) like Google’s API explorer, with the main difference with the previous version being the ability to switch between APIs (for example, the bikes/alerts API) and versions. It also display the raw response (currently only JSON) (and the HTTP result code, but it’s not like it would help much anyway, heh!).

But it is still work in progress: the listed API are not complete, it does not handle parameters of parameters (but only a single level of parameters, which can be confusing at times), it would be nice to have a user-friendly key storage mechanism and the overall display could be better.

Rennes OpenData API explorer

First, you need to create a connection to the web services, by passing credentials to the constructor:

storage = Fog::Storage.new( :provider => 'AWS',
                        :aws_access_key_id => your_key_id, 
                        :aws_secret_access_key => your_secret_key,
                        :region => your_region )

The region is not mandatory but may help performances (and keeping warnings away).
Once you’re connected, you need to get the directories stored in your bucket:

directory = storage.directories.get( your_bucket )

If the bucket does not exist of for some other reason the directory might be nil, so obviously you have to check for that. Now, you have to get a reference to the file in the directories and then you will be able to destroy it:

remote_file = directory.files.get( your_path )
remote_file.destroy

Be aware that the path must not include a leading slash (as one could get by splitting a S3 URL and using the path component).

In early december, I decide to scrap my existing webapp to use those official data. I had soon a new working web app that I was able to share with others as Carte et horaires des bus de Rennes. It did a few enhancements and features that look and feel nice, but I was still not reaching my three year old goal. So, instead of J2ME I settled on ObjC and I targeted my iPod Touch as device of choice, with the additional difficulty that not being a mobile phone, I could not rely on an Internet access.

By mid-december, I had a small application reading a SQLite database and displaying the name of lines, that I wrote while traveling by train. On the 28th, I had a semi-working application that I could hint in a youtube video, and one day later, I stole the grid display from another bus schedule application OpenMBTA and I was submitting my application on Apple’s appstore (“Release early, release often…”) and it was published Yesterday as Bus de Rennes en poche. Look, Ma’, I’m an iPhone developer! Sure, it is just a really basic version, but I’ll soon release an enhanced version, and so on.

Of course, both the web and iPhone application are Open Source.

Think about it. What is the main example of Git usage? The Linux kernel. What is the role of Linus Torvalds? Build Manager. He doesn’t code a line (almost) but just get patches from others to integrate them in the official tree. What is the other main usage of Git? Github: You can create (or fork) a project, have people develop features and create pull requests that you integrate if you wish to, picking whatever suits you.

Git (and other DCVS probably) is the best Build/Integration Manager tool: Developers can work however they want on their own repository and be empowered by fast versioning tools while a central role can coordinate and pick whatever features are available, in order to have the best resulting software (and eliminating the risk of a developer committing and pushing everything (for backup reasons) to the master server on a friday night, including unfinished and/or broken features).

Having a central repository where everybody pushes features without any control is just a bastardized (un) distributed revision control.

Compared to my real life usage of SVN in an enterprisey usage, the main selling point of Git (and probably other DCVS) is the ability to have local branches at a nearly zero cost (for either creation or switching), not only for a feature-branching workflow but simply to have at hand the various points of the life of a software (development version, latest/current release, maintenance releases…).

Add to that his stance regarding the DevOps movement and against system administrators, and people knowing me will understand why I hardly agree with him.

First, care has to be taken of what code generators may produce. It is especially important if using controllers in modules. To test views with RSpec 2, the top most describe must use the path of the file. Unfortunately, some generators with modules will generate a rspec path of module_controller/view.html.erb instead of the correct module/controller/view.html.erb.

Before rendering a view, one can set the values it uses by using assign as either a function call or a hash. The rendering itself is done by simply calling render and the tests of the view can be applied, not on a response object as it is the case for the controller (or as it was the case I think with RSpec 1?) but on rendered. There, the main matcher to use is have_selector which takes a xpath expression and can use a block to do further testing on an inner DOM node.

it "should have some tag" do
  render
  rendered.should have_selector( "a[class='foobar']" ) do |node|
    node.first.text.should == "quux"
  end
end

But XPath is not really the most friendly syntax and using blocks can become tiresome. There are shortcuts for testing the text content and one can in fact use CSS expressions as a selector:

it "should have some tag" do
  render
  rendered.should have_selector( "a.foobar", :content => "quux" )
end

And one can obviously use more complex CSS expression (div.foobar #quux a).