This may be the last article on building command line apps with Ruby you’ll ever have to read.
Okay, not literally! But I think you’ll know enough to accomplish quite a lot by the time you’re done reading this.
There are a lot of Ruby gems that help you build command line apps. Thor, Escort, CRI, GLI, Methadone, and executable, just to name some of the libraries out there. While results have varied, I’ve personally had my share of hangups with these gems:
- I get the whole kitchen sink. ASCII tables and ncurses support? I don’t need those things.
- Bugs. Real, show stopping bugs. Several of these libraries have a few dozen open Github issues that show no promise of getting fixed any time soon. Call me cynical, but if I’m going to tie this gem into my app as a dependency, I want to have faith it’s going to be maintained.
While building my latest command line app, I eventually gave up and decided to just roll my own with Ruby’s standard libraries. The results were surprising.
It turns out Ruby’s OptionParser library offers everything you need. It’s just not very well documented. For those of you that aren’t familiar with the library, OptionParser parses out option arguments from ARGV (text such as “–option value”). You can also set defaults and define help text. What you’re left with after you call the parse! method is an ARGV array of commands the user passed (i.e. “test units”).
I recently setup Cacti to gain more insight on some server performance issues we were facing at work. Previously we had been using NewRelic, but found it to be expensive and limited in the stats it gathered and presented. If you’ve never heard of Cacti, it’s a fantastic in-house solution for network graphing. The graphs are generated using RRDTool, and front-end web interface allows you to set up automated polling of servers using a number of different methods. It’s quite a bit of more work to setup than using a managed solution, but you can tailor the polling to what you’re interested in and gather more in-depth stats.
The most popular method of polling is using the Simple Network Management Protocol, or SNMP. It’s very standards-driven, which is great for network engineers because it means that any device running SNMP can report stats on the same stuff. It’s not so great for developers though, because working with it often involves consulting a type of database known as a management information base, and addressing the stats you’re interested in by OID. You have to know the exact OID you’re interested in (or use a tool like SNMP Walker to “walk” the MIB tree), and some systems differ slightly in the OIDs they implement. I can’t say that SNMP is bad. I’m not a network engineer, so I don’t think I have a place to criticize it. SNMP provides a standardized interface to talk to network devices and can even be used to configure devices remotely. It’s really powerful. However, if you’re like me and you’re interested in just gathering performance stats on some servers, it can take a lot of work to setup.
I thought it would be really cool if there were an API for server performance monitoring. Something that you could just run– securely of course– and would then tell you about the performance of whatever it was running on over HTTP. Then you could have consumers do different things like setup alerts, draw graphs, automatically scale a cluster, etc.I couldn’t find anything quite like what I had in mind, so I decided to start developing something myself. You can find the project here. I’ve named it sys.json, and at this point it’s a proof of concept more than anything. I’ve got it running on my own personal server and it has reported reliably so far. However it isn’t fully tested, nor is the codebase very mature yet, so I cannot recommend that you rely on it for anything mission critical.