Darwin: Not Quite Fin
by admin
Well it is 2:40 AM my time on July 22nd and I am not where I would like to be in the project.
However, I do have something to show and will try to package some semblance of a useful application. Truthfully, this is a piece of junk. It collects CPU load and displays a graph for each particular IP entered into the database. Not to mention NONE of the http exchanges are secured and that you have to rely on HTTP in the first place.
As 3AM draws closer, I tell myself, “This is a learning experience,” as I said in my opening posts. Sometimes software development is frustrating, especially in a new language and development environment. NetBeans is loaded with lots of modern features and a clean interface that the developers at Delphi could pick up a few things from NetBeans and incorporate them.
That’s not to say that Delphi isn’t one of my favorite IDE’s. I use it very regularly, especially with IntraWeb for a few applications. One area that I particularly loved in NetBeans was find/search. The results of your searches are presented in a more logical manner than the standard Delphi dialogs and they behave in a manner that is familiar.
NetBeans did not start out with Ruby support, yet it functions as a wonderful platform for coding, testing, and learning Ruby or Ruby on Rails. The 6.1 version loads quickly and does not consume gobs of memory like its other Java relatives. I wish I could have tried CodeGears 3rdRail to compare the feel to Delphi. Any experiences with this?
Darwin RubyMonitor
The project consists of three parts.
- Agents – these are simple HTTP servers running on port 2000. They respond with YAML containing the CPU load, frequency, and quantity.
- TractorBeam – You would have one of these running on your network. All it does is sit and run through a loop every few seconds to poll “agents” you have added to your database for their average CPU load.
- Interpol – The front RoR application that simply renders a graphic right now with the statistics collected from TractorBeam.
I’ll give you all a little tour via screencast below.
There you have it. Here’s the graph after a few minutes displaying average CPU load:

Things I would change:
- The “Agents” should use a Restful API to communicate with “TractorBeam” instead of the other way around. This would allow one collection server to be running, and clients to connect on the fly. Ideally, you could use existing performance statistics available from the operating system and would not need any clients. Much easier for a sysadmin.
- The userinterface is awful.
- More testing. I have not run any unit tests on this. Use at your own risk–I don’t recall writing any code that formats drives, but it could happen by rookie mistake.
- Write the application in Ruby/Netbeans and Delphi/Intraweb. I think if I had used Intraweb I could’ve had a pretty slick application using NexusDB as the backend. However, I did like the productivity increase of Rails over the Intraweb GUI designer.
- Temperature. This one drove me nuts. Accessing temperature sensors from Ruby in Windows seemed to be on the same level of difficulty as traveling faster than the speed of light.
All in all I thought it came out pretty well given my ability (or lack thereof!). Now to try and submit to the contest… I hope I can!
Edit: I’ve tried and have come to learn that SQLite3 does not support one of the functions I use. I’m not sure what time the deadline officially is, but I’d like to get it finished before so you all can play with it and maybe I’ll win!
We shall see…
Cheers,
Steve
