Tag Archives: tools

This week, I switched our systems-level monitoring from Cacti to Munin.

I was dissatisfied with Cacti’s interactive-only configuration and limited OOTB charts, and its reluctance to correctly display the processor %U of my multicore servers. I tried the oft-cited suggestion of cloning the existing %U graph into a new template and bumping the maximum to 1,200% (for a 12-core server); no good.

I have a, “I have bigger fish to fry” mindset lately, and I want something that does (mostly) the right thing OOTB without having to delve into the source code.

Read More


When writing tests, mock out a subsystem if and only if it’s prohibitive to test against the real thing.


Our product uses Redis. It’s an awesome technology.

We’ve avoided needing Redis in our unit tests. But when I added a product feature that made deep use of Redis, I wrote its unit tests to use it, and changed our development fabfile to instantiate a test Redis server when running the unit tests locally.

(A QA purest might argue that unit tests should never touch major system components outside of the unit under test. I prefer to do as much testing as possible in unit tests, provided they don’t take too long to run, and setup and teardown aren’t too much of a PITA.)

This was a contributory reason for our builds now failing on our Hudson CI server. Redis wasn’t installed on it!

Why didn’t I immediately install Redis on our CI server?

  1. Our CI server had other problems
  2. I intended to nuke it and re-create it with the latest version of Jenkins. I just needed to first clear some things off my plate
  3. Our dev team had shrunk down to just two people
  4. We were both strict about running unit tests before checking code into the pool
  5. We were up to our necks in other alligators

From a test-quality perspective, if code uses X in production, it’s better for tests to run with X than with a simulation of X.

One of the many joys of working with Ryan is that he challenges my assumptions and makes me consider alternatives. Because of a perceived lack of elegance in needing Redis on our CI server, and because his work had been temporarily blocked by my code changes, he challenged me to replace my unit tests’ use of Redis with a mock.

I walked into work yesterday and it was quiet. All our critical bugs blocking Saturday’s release were closed. I thought, why not? I’ll give it a go. Today’s a good day to see what’s involved with replacing Redis with a mock!

Read More

My new Bamboo Stylus arrived today! It’s just long enough so that the upper inch or so rests in the space between my index finger and thumb, and hefty enough so that I feel it there. I don’t have the specifications handy, but I’d say it weighs slightly more than a typical rollerball pen, but less than a typical fountain pen.

Read More

I’m playing more with Noteshelf and thinking about how I use a whiteboard. And I’m noticing aspects of my sketching for the first time…

My drawings mutate a lot as I create them:

  • I’ll start out leaving space for objects (e.g., server boxes, database symbols), and then decide the objects need more space. (For practical or esthetic reasons.)
  • I’ll assign colors to different entities, and later change the color assignments.
  • I’ll start recording attributes A, B, and C for state transitions, and then decide to drop B and add attributes D and E.
  • It’s very rare that nothing has to change. But even then, I’ll wish I could move the whole diagram on the whiteboard or page in toto, because it’s grown in a direction or to an extent that I didn’t anticipate.

I often wish I could do a diagram twice — once as a dry run, once “for real.”

These alterations happen more often to my drawings than they do for others. At least, it seems that way to me.

I often need to diagram things at work. It’s usually something like a system block diagram, a gnarly code problem, or client-server interactions. Sometimes it’s just a list of things I’m comparing.

Whatever the diagram is, I need to the keep it around for a while. And refer to it, scribble on it, and update it. And sometimes share it.

Since “back in the day,” I’ve used a whiteboard for this. Or sometimes pages from a pad of graph paper. I’ll noodle around, sketch things out, and leave it up.

For sharing, I’ve resorted to snapping a photograph of the whiteboard with my iPhone. (Or a couple of photographs, which I then stitch together with AutoStitch.) If the photo’s not adequately square, I straighten it out with Genius Scan. And then e-mail it. The mail message can get pretty large, so this can be a nuisance.

Eventually the whiteboard needs to be erased, or is accidentally erased. Or I lose the graphing paper doodles, or decide to throw out the diagrams.

In December, I received an iPad 2 as a gift. And I’ve gotten around to thinking, why not step up my game and use the iPad for this? (Yeah, I’m being dramatic and rhetorical. Sorry. I’ll re-phrase: “I’ve decided to use the iPad for diagrams and simple drawings.”)

I haven’t completely figured out how I’ll do this. I’ll write about my experience here as I go down the learning curve, mistakes and all.
Read More

I protected my tweets on Twitter.

When you protect your tweets, you have to approve any new follower request.

This is easy if you use a desktop or laptop browser. But if you use a Twitter client application, or a mobile browser on Android or iPhone, you can’t approve new followers. In fact, you won’t even know about them. You’ll see new follower requests only if you view Twitter with a desktop browser. (I’m crawling slightly out on a limb here. I’ve tried a few iPhone apps, and none have let me approve follower requests. I can’t find references to Android apps that let you do this, either.)

This irks me.

Read More

I bought “Python Testing Cookbook” by Greg L. Turnquist, published by Packt.

The good. I liked the cookbook recipe approach. Each recipe has the same headers: Its name, “How to do it,” “How it works,” and “There’s more.” This may not sound fancy, and it isn’t, but it works.

The writing’s good (albeit sometimes elementary — see below) and the example code is well laid out (except when it isn’t — see below). The book starts with the simplest form of unit testing, and goes all the way to measuring test coverage, and load testing. That’s a lot for one book to cover, which is both good and bad. Your first line of defense can be one book, but unless the book is very well written, it may leave every reader scratching their head over one section or another.

I learned a couple of new tricks.

Read More


Get every new post delivered to your Inbox.

Join 9,493 other followers