30 October 2010

static file handling in Sinatra

I've been using Sinatra for a bit at Forward, here's what I like about Sinatra.
  • Its interface for http integration is a Rack. Sinatra#call(env) that returns [status, headers, body] How simple is that? It's hard to beat.
  • Any Rack based web app is so easy to test. Out of container test is baked in from the birth.
Then I found the default static file handling in Sinatra ignores before_filters and after_filters defined by its beutiful DSL.

How do I set Cache-Control headers for static files?
 
Enter Rack middleware which is essentially a filter. All I had to do was to write a simple CustomHeaderFilter riding on the same simple Rack interface, another happy day :)

15 May 2010

Visualising wave federation protocol

Keeping good readability of high level tests require a right level of abstraction that presents its intention clearly. When it's not right, it's either going to be too verbose or obscure.

While working on functional tests over wave federation protocol and eventually to be able to plug in third party wave provider and have a suite of functional tests to certify that it works with fedone implementation, I thought it might be interesting and helpful if all the packet transfers and its effect on wavelet state can be visualised.

My first attempt was with ProcessingJS, which I found hard due to textWidth not implemented yet.

My second attempt was with WebSequenceDiagram, which also had a limitation of its size on single line statement.

If anyone is interested to contribute, feel free to clone wave-protocol and have a look at WebSequenceDiagramTestSuite to generate visual for all scenarios covered in functional tests.

23 February 2010

Why being perfectionist when you can improve?

It's been quite a interesting week for me trying to get code reviews for a patch to an open source project.

I've decided to start with functional tests, because I've learnt that the best way to dive into foreign code is to write high level functional tests focusing on "what" it does rather than "how" or "why". I justified that it would probably help other new comer to the project too.

I knew from looking at the amount of time it took for the previous patches to get a green go ahead if any, it would take me a while if my patch was anywhere big or ambitious. It's been 6 days since my first submission. In the mean time, I've been just building up a backlog of patches. Following up the community feed, it does make me feel that most of the code is being developed in-house by co workers and then it's "open sourced" with regular dump from in-house development.

It is still a very early days, but I fear that the community being perfectionist would discourage communication of different ideas and frequency of patch submission.