Jason Madigan

[Placeholder]

While developing Runt over the past few months it became obvious mid-way through development that the integration of graphing was somewhat of an afterthought. That’s okay though because we’re agile, right?

Graphing SNMP data in Rails applications (or any other application for that matter) is difficult for a number of reasons:

• What the hell do I graph?
  • SNMP data is so varied in scope that we need to narrow our scope in order to graph something useful. We don’t want to graph sysName against sysDescr because that’s retarded and completely useless.
  • Graphs obviously need need be composed of numerical data, so any SNMP data composed of strings is likely going to be useless.

• Right, so what kind of data types should we be looking at (assuming we’re working with protocol version 2c)?
  • Integer32/Integer (Enumerated)/Unsigned32/Gauge32/Counter32/TimeTicks/Opaque/Bits

With these data types in mind, our scope is still way too vague for us to be able to graph any meaningful data. With a deadline looming, I made the decision to limit the scope of graphing in Runt to just bandwidth, something which most SNMP graphing applications out there focus on (MRTG for example). Having made my decision I was then faced with some interesting decisions regarding graphing. Initially I wanted graphing to be as sexy as that found in the Tomato firmware installed on my WRT54GL router:

Tomato generates its graphs in between AJAX requests and renders them to the user using SVG. Unfortunately, browser SVG support is patchy for Intel Mac users with Safari 2.0.4 (even though SVG support landed in WebKit landed over two years ago). Adobe have offered a plugin for SVG support in Safari (which is going to be unsupported next year), but only for users running Safari on PowerPC Macs. As an Intel user you could of course run Safari under Rosetta to enable the plugin to function but jesus don’t. Thankfully SVG support will finally find its way into Safari 3.0 in Leopard, but that’s several months away. IE6/7 users enjoy SVG support through the same Adobe plugin, while Gecko based browser users see SVG built-in.

With this in mind, and due to the fact I’m a selfish jerk who uses Safari, I decided against using SVG in Runt, at least for the time being. My options for graphing in Rails boiled down to three contenders:

• Gruff - pretty graphs that are rendered as PNGs. Rails plugin.
• Scruffy - pretty graphs, internally rendered using SVG and it can spit out your graphs in pretty much any format imaginable. Unfortunately it hasn’t been updated in over 9 months.
• ZiYa - pretty Flash graphs. Flash, ugh.

I eventually rolled with Gruff since I found it the easiest to get to grips with and because it somehow felt more Rails like than the others. I was seriously considering ZiYA for several weeks but considering how much I’ve come to hate almost all implementations of Flash – hay guys lets totally offload the rendering of this website to some proprietary plugin! This is a great idea, right guys! Guys?! – I decided it was best to roll with something I could stomach myself using. Unfortunately, this meant that interactivity with the graph was going to be seriously limited as Gruff was just going to throw rendered PNGs at a user with a rather horrible rendering delay between AJAX requests. This is something that has bothered me ever since I chose to use Gruff, but what’s done is done.

The next iteration of Runt will see me revisit the idea of using SVG rendering because it’s sexy as hell and because, for the time being at least, I’ve begun using Firefox 2.0 regularly once more.

[Placeholder]

I’m Jason Madigan, a jerk/web developer from Waterford, Ireland.

I like to think I specialise in developing clean, functional web sites & web applications. Currently, most of my web development centers around Ruby-On-Rails, but I’m currently in the midst of learning Python while experimenting with the Django web application framework. Currently I’m working for FeedHenry as a web developer, a spin off from the Telecommunications Software & Systems Group.

If you need to get in touch, feel free to email me: jason at jasonmadigan dot com

In the midst of some downtime, I finally got around to doing something I’d planned to do for 2 or 3 years; give autosystems.ie a complete rewrite/redesign. At the moment the homepage is a mess of static content and things don’t get much better when we look at the shopping cart system. The shopping cart as it stands right now is a pretty hacked up version of OSCommerce which has been slowly disintegrating over the past year. No less than 4 times in the past year I’ve had a call from my brother where it had broken unexpectedly, seemingly without any user interaction whatsoever.

So I decided to set about developing a really simple shopping cart system which would be a snap to maintain and which my brother would find easy to use. I also needed to implement a really lightweight CMS so that he could change some page elements on the homepage informing people of new offers and the like. 4 hours later and I’ve got a pretty nifty Ajax shopping cart system working. There’s still quite a bit to do (payment functionality with PayPal/Authorize.net for one) but on the whole I’m amazed at how quickly it came together. Well, maybe not that amazed, I have been using it to develop Runt over the past few months.

For the past few months at college I’ve been developing a web-based Rails application called Runt; Ruby Network Tool. It’s a small application which displays nicely formatted, up to the second SNMP data from pretty much any device attached to your network. If you’re after specific data from specific devices, you simply load a custom MIB for that device and Runt can get data from it. It features a sort of tacked on ability to graph interface traffic for a given device also, but it really doesn’t feel all that at home in the application itself at the moment for a variety of reasons. I’d like to expand upon this a lot with later releases, but I find myself hindered with current browser SVG support (at the moment RUNT uses Gruff to generate static PNG graphs each pass).

The response from the demonstrations I’ve done over the past few months has been encouraging but the codebase remains a bit too clumsy for my liking to release it to the general public, at least not yet anyway. It had been my first foray into the world of both Ruby and Rails so there’s a lot of cruft which needs reworking.

The version which I’ll release will be v0.1, and I have a lot of other functionality planned for v0.2. One of the biggest problems I encountered while developing the application was finding myself constantly hindered by the very nature of web-based applications - they sort of need interaction before they’ll do things. As a result, v0.2 will see a lot of functionality handled by a Ruby daemon (using BackgrounDRb) such as graphing and some cool alerting functionality through SMS should certain user specified conditions arise like a device fails to respond to SNMP requests.

One thing I will say about this learning experience is that I’m quickly understanding why so many developers are using both Rails and Ruby for development, regardless of of their rather sluggish performance in comparison to say Django and Python. There’s just something about blocks like

foo.collect {|bar| b.to_i/5*8}

which makes me consider how amazingly eloquent Ruby really is. I’m having a blast with this stuff.

Here’s some screenshots:

I never thought I’d actually have any use for a blog (and to be honest I’d always found myself struggling to see why other people needed them too), but I guess what with working on new projects and having finally completed college I could do with some place to organise my ramblings, so here we are.

I’d been meaning to put together an online portfolio with quite some time now, so I guess now is as good a time as any.