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.
Lately, I have a, “I have bigger fish to fry” mindset, and I want something that does (mostly) the right thing OOTB without having to delve into the source code.
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?
- Our CI server had other problems
- 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
- Our dev team had shrunk down to just two people
- We were both strict about running unit tests before checking code into the pool
- 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!
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.
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.
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.
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.
I recently questioned whether Bitbucket was suffering from neglect. My conclusion was, “yes”…
Jesper Noehr, a (the?) Bitbucket developer, replied to the post. He said Bitbucket’s development was “quite active.”
But… Bitbucket’s newsfeed has been “temporarily” disabled for over a week:
At my new job, we’re selecting a hosted “revision control + wiki + issue tracker + document repository” service.
My first recommendation was Bitbucket. I’ve used it for a while, and have always been satisfied. (I even have a paying account plan!) But after a day of use, we bumped into odd problems. Like, Windows users couldn’t upload documents, and errors when we used HTTP Secure protocol. And then I found many issues in Bitbucket’s issue tracker (i.e., issues about Bitbucket) that were (open && non-trivial && had no activity for many weeks).
How do we confidently assess the health of a hosted service? Large enterprises can meet the other company’s management and get privileged information about its finances, staffing, etc. But individuals or start-ups getting at that kind of information is impossible, or at least will need way more back-and-forth e-mails than they have time for.
In Becoming a Craftsman, Rock Hymas writes about Mercurial vs. Subversion. It’s an excellent exposition of the tools and their underlying philosophies, and how his own development style changed from working on a Mercurial-based project. It’s slightly marred by his conclusion that using Mercurial makes you a better developer; he seems to believe it does this partly through its own weaknesses, which I find odd reasoning. But putting that aside, it’s an excellent read.
He tasks me for my July 2008 article on Mercurial vs. Subversion:
“Additionally, I think distributed SCMs like Mercurial have a not-yet-fully-appreciated problem in making it too easy to not [ever] check code back into the main pool. With a local repository, a developer can feel protected from accidents and continue working happily for quite a long time. And then, say a year down the road, he/she does a massive check-in and discovers an integration problem. Branches, or a local repository that is effectively a private branch, should be easy to make — but not too easy.”
Let me explain why I don’t buy it. First, “a year down the road”?! Seriously? It says something that you have to imagine a scenario so horrible and unlikely in order to envision easy branching as a bad thing. I think that the author likely didn’t realize how easy merging usually is with a DVCS like Mercurial. And he must have totally forgotten that this lone maverick developer could have been merging the main development line into her own repository every day or week. The right solution to this imagined (and barely imaginable) scenario is not to eliminate easy branching, since without it the lone developer will do the same thing, but be much more likely to lose her work because it won’t be stored in a repository. The right solution is to fix a broken culture that enables someone to go a full year with no accountability for their work.