Recently I've been working on some health issues but nothing really serious. My doctor asked me to collect some statistics for heart parameters (pressure, pulse) for review. Since I hate dead-tree versions of pretty much everything I decided that it's the best time to renew my friendship with Ruby and Sinatra.
The challenge
The challenge for me was to write the app in about an hour, with possible extensions at a later time, but to start collecting evidence as soon as possible. Although I'm a huge Grails fan (like you didn't know that) I think it is just too damn heavy for simple data collection applications like the one I have had in mind - thus the obvious dilemma between PHP and Ruby/Sinatra. I really like the embedded nature of PHP but to write anything in a sane way one needs to employ frameworks like CakePHP and the like. I hate that. I wanted to have as minimalistic as possible, with everything just working in a matter of minutes.
My sweet Ruby, Dear Sinatra,
You all know what Sinatra in the Ruby space is, right? If you don't - just go to http://www.sinatrarb.com and find out. Here's what I did with it:
1. All in one construct with everything in one place (configuration, controller, views, css, javascript)
2. All of it takes 210 lines of code (63 Ruby, 143 Erubis and a few while lines for convinience)
3. Deployed to Heroku in a matter of minutes
4. Using MySQL backend because it was just convenient.
Heroku provided the infrastructure for free (the one web worker that's always for free), a free database and Git repository. With all that in place I was ready with the first usable version in about 30 minutes (that's how quick Ruby and Sinatra and Heroku are).
Iterate iterate iterate
As with everything in software development there are going to be bugs, there are going to be new requirements and there are going to be "things that could be done better". One of them was for me to be able to input new measurements using my phone's web browser (the simplest thing that could possibly work). And it worked right out of the box but the default font size is just so small on my S3 that I've had to go through a number of zoom-ins to make out what's in there. Every navigation to another page returned me to that ugly small fonts. Changing the font size to like 40 did the trick :)
Then there was the matter of inputting numbers into the edit boxes. See, the default keyboard is an alpha-numeric-on-request type of keyboard which means that to enter numbers you have to either long-tap on the screen every number you'd like to enter or to switch to the numeric-special-characters-page on every input box which was just plain ugly. Changing the input types to "number" did the trick. Fortunately I'm not using Firefox on my Mobile where this type of inputs are just plain text inputs (as per some sophisticated page that knows all about browser compatibility).
And there was light! I have had enough measurements to actually display them on a chart. I wanted it to be an interactive graph, obviously, so my first choice was Google Charts. Even though beautiful and easy to use almost out of the box I felt kind of cheated because it used Flash underneath the skin. That obviously didn't work on S3 so I needed some alternative. Dygraph to the rescure (with GViz interface) and in a matter of 10 minutes (including research) I've had my charts up for display.
A small snag
As it turns out MySQL by default doesn't understand time the way it's supposed to. It just knows that 13:21:43 is almost half past one but with no particular interest for time zone. An obvious way to overcome this issue was to set all times to UTC and convert them when interacting with the user. Piece of cake. I'd like to point out that the author of mysql2 gem could finally extend the thing to allow something else than 'utc' or 'local' for the automated conversion and life whould be a lot simpler.
Closure
I always believe that software should be written according to high standards, with proper code coverage, proper planning, agile mindset and clean code in the end. Even though I tend to not do TDD in the case of such simple project such as this I still think it makes sense in other cases. I know I shouldn't talk like this since I'm the "Mr TDD" among friends but guys let's face it: throw-away software happens all the time and there's no reason to follow the routine blindly even in the case of spikes. Production code you write for someone else - TDD all the way; spikes no.
I'll probably use the app for another week or two, maybe even for a couple of months, who knows. I just hope it'll give my doctor enough information to get me back on track.
