Chris Hubbard

I wrote my first Rails web application last night.  My work at my job has to do with managing configuration of SIP endpoints.  Our products are related to providing a IP PBX to call centers and enterprises.   

The SIP endpoints (most of the time a hard SIP phone) has its own configuration that has to be synchronized with configuration in our system.  This can be a huge pain point for our customers. 

My latest project at work has been managing the SIP endpoint configuration completely from our system’s configuration store.  This has include new configuration that used to be only needed for the phone.  There is also shared configuration that needs to be known by the phone and the server.

One of the simplifying assumptions was that a phone is only connected to one server.  In fact the phone can be connected to many servers (which show up a separate line keys) but that does not happen often in the field.  However it happens a lot in our office.  We may have a phone connected to our production server and several different test servers. 

This has been bugging me that I have made it much easier for our customers and at the same time made it difficult for our internal developers.  I have made some extensions that allow overrides to configuration to be done during development and out in the field (where there will inevitably be something that I messed up and some poor System Engineer has pull out some bubble gum and bailing wire to work around the problem until the next service update).

All the configuration for the phone is requested via HTTP.  I have been wanting to write a web application that aggregates complete configuration from multiple servers or just tacks on a few SIP registrations onto a current phone.  The problem is that I don’t write web applications.  I am a system level developer.  Writing any user interface code, especially admin interface, give me the hebejebees.

So I gave Ruby on Rails a try.  I have done some Ruby development in the past to the language was somewhat familiar.  I was very impressed by two key concepts of Rails: DRY and convention over configuration.  DRY stands for Don’t Repeat Yourself?every piece of knowledge in a system should be expressed in just one place.  And with convention over configuration, Rails has sensible default for just about every aspect of knitting together your application.  So there is dramatically less code to get this going.

To help me get going, I borrowed a copy of Agile Web Development with Rails and just looked around for examples.  It took me about 3 or 4 hours and I had a web application that was functional with an admin interface and a RESTful interface that returned XML in the format required by the phone.  The admin interface was one line of code which was very cool.  It was rudimentary but it got the job done (and it was going to be used by developers anyway).

In the end, the code didn’t smell right.  I showed it to one of my customers and he gave me some really good feedback that should help.  The neat thing about rails is that I have no qualm about just ditching what I did and start over from scratch since I didn’t have that much invested.  I can really see the benefit in Agile Development.

So tonight I bought my own copy of the book (you can buy the print and the PDF of the book together) and I am going through the PDF so that I can better understand how I should have put my app together.  This is going to be a nice tool to have in the toolbox.