[caption id="attachment_317" align="alignleft" width="626" caption="Output from OOMA call log service"][/caption]

So far, I have been using OOMA (premier) for a little more than three months which means, based on my prior AT&T bills that it has just about paid for itself. It also means that every month from now on without a phone bill is money in my pocket free-is-good.

I've been busy over the last few days on a small Ruby programming project. I'm somewhat new to Ruby, but not to programming. I was looking for a project to help me bring some of the Ruby concepts together - while there are some great Ruby tutorials and books available you can't really learn to program in a language until you actually start to write code.

OOMA provides a web page where your call log information is made available in a (boring) HTML table so this seemed like a natural for a non-trivial Ruby exercise. I figured I would get to work with HTML, Web authentication, Web scraping, string manipulation, web services (using Sinatra) and maybe a database. I ended up using Mechanize and Nokogiri to convert the HTML table data (using Xpath) to an XML document and parsing the XML document to obtain call log statistics. I used googlecharts to provide the graphics (via the super simple gchartrb gem). I dropped the database idea because I ultimately want to make this a service,  I didn't want to permanently store anything, the dataset size (I'm limiting it to 1000 records right now) is small enough to keep everything in memory. I also used Sinatra which is a much smaller and easier to use Ruby web application framework than Rails.

I ran across and created workarounds for a couple of problems that came up - for example, I was using the Nokogiri gem to scrape the page (which I had initially saved as a document for development testing) but then had to use Mechanize, which is built on top of Nokogiri, to handle the authentication. I also had several problems getting the Sinatra 'routes' to produce the expected results page until I relaized that there were a couple of bugs in ERB that I had to work around.

This was a pretty interesting and successful exercise as you can see from the opening screen shot. I only pulled the OOMA default first page of data for the screenshot but I can get up to at least 1000 records for the statistics. Next step is to look into cleaning  up the code a little bit and then deploying and testing it on Heroku. I'm going to have to figure out how to get the code deployed and accessible via SSL on Heroku since I envisioned this working as a web service initially.

Currently  the credentials (userid and password for the OOMA account) has to be provided because the application logs in to retrieve the OOMA call log data. I'm going to post a query on OOMA about this to see if there is a possibility that OOMA may allow OAUTH access to the data because I already have that coded and working for a twitter app that I created.

If OOMA doesn't allow OAUTH access then this may have limited use as a general/public web service because while I am not storing anything permanently (userid, password or call log data) I wouldn't trust giving my credentials to some unknown third party site so I definitely understand why someone wouldn't want to use this tool to graph their OOMA data . I guess we'll see, but as a learning project - this was pretty good.

Part 2 of this article will be released when I have this publicly available on  Heroku.