The U.S. Product Product Safety Commision is now recommending that you not use a laptop on your lap.
Archive for September, 2006
Onward, battery technology
Friday, September 29th, 2006The Law of Demeter, briefly revisited
Sunday, September 24th, 2006If you find yourself getting into arguments at dinner parties about the correct application of the Law of Demeter (LoD), Brad Appleton has a post on the eXtreme Programming mailing list that’s worth a read. Brad points out that LoD, as popularly (mis)stated, conflates classes that encapsulate functional behavior and classes that encapsulate structural behavior. The LoD isn’t violated by invoking the public interface of a purely structural class (e.g., a collection class such as Array or Hash) to obtain a contained object and then invoking behavior on that object.
This makes intuitive sense. The usual fix for an LoD violation is to add indirection, in the form of a new behavior that delegates to the behavior in object that you’re trying to invoke. But extending generic collection classes in this way seems silly, even if some languages make it possible.
Paging Dr. Jung
Sunday, September 24th, 2006If I go to sleep with a problem in mind, I’ll often wake up with an answer, or at least with fresh ideas. But I’m usually pretty groggy early in the morning, and those first thoughts often go *poof* by the time I’m out the shower, so I keep a pen and some index cards on the nightstand. (There’s also a small diver’s slate in the shower for those occassions when overnight ideas have been delayed in transit.)
The waking idea this morning was “this holiday season, maybe I should give fruitcake another chance.”
I have no memory of going to sleep with a problem in mind that this idea solves.
Dependency Injection and the elusive forest
Sunday, September 10th, 2006I’ve been using various forms of Dependency Injection (DI) for a while now, mostly as a technique for structuring code so that the pieces are easily testable. Using a mock object (or some other flavor of stub) in place of an object that accesses some slow external resource can keep unit tests fast, which is a Very Good Thing when you have lots of tests.
The problem I have is when trying to get my arms around a legacy system that uses DI. (Where legacy means “one I didn’t help write”.) Building up a mental model of what the system looks like when assembled can be difficult–a lot more difficult than when dealing with a system that is explicit about its dependencies. This is particularly frustrating when tracking down problems in legacy code. When the patient presents with an exception and stack trace, diagnosing the problem often requires starting up the app the debugger and working forward, not just to re-create the right internal state, but also to build up the mental picture of what the assembled application actually looks like on the inside.
So there’s my quandry. DI can lead to trees that are easy to understand in isolation, but the forest can be hard to grasp. And the trees no longer know enough to help.
In darker moments, it feels like DI is a form of stealth obfuscation.
Team sizes that maximize pairing
Monday, September 4th, 2006Let’s say that you’re a manager who is convinced that pair programming is a good thing, and that you’re growing an existing small team or staffing a new one. How many developers do you add to the team to maximize pairing? (Let’s assume that the developers are all pairing-positive. Maximizing pairing when the team isn’t entirely pairing friendly is a question for another day. We’ll also duck the question of when a team gets too large.)
A team of one is a non-starter, even if the sole team member mummbles to himself while working.
A team of two works.
A team of three doesn’t work. At least one person will be solo at any given time. You’re better off skipping three and going right to four.
The obvious answer is to keep the team an even size.
But people take vacations. And sometimes get sick, or have car problems. Or a tree limb falls on a house. Or there’s an inconveniently timed meeting at school with a kid’s teacher. Life happens.
The larger a team gets, the greater the chance that at least one person will be out at any given time. At some scale, the obvious answer of maximizing pairing by keeping the team an even size breaks down. The “50% chance of exactly one absense” points depends a lot on context (team mix, vacation policies, local weather patterns).
A quick after-the-fact, back-of-the-envelope calculation for an XP team I worked with a while back suggests that after six developers, moving to seven, and then nine, would maximize pairing opportunities. At least for that team, in those circumstances. Your context, and hence your numbers, may vary.
If you are growing an existing team that practices pair programming, count the number of days that one developer is working solo because a pairing partner isn’t available. If it’s more than half of working days, (and all other things being equal, which they never are, so of course you’re going to consider other factors), lean toward adding one developer. Otherwise, you might consider holding off on growing the team until you have budget for adding two developers.
Resolution matters
Monday, September 4th, 2006When the price for a Samsung 20″ LCD dipped below $300 USD, I snagged one, only to find that the onboard video on my desktop, which had been driving a smaller 1280×1024 LCD, wouldn’t handle 1600×1200. Oops. Fortunately, the two resolutions are both a 4:3 ratio, and the Samsung scales down to the lower resolution. Text isn’t crisp, but isn’t fuzzy, either.
Swapping in a spare low-end ATI card didn’t help. I still only got 1280×1024, but now windows jerked around the screen when I dragged them. The card went back into inventory.
This morning I bought up a low-end nVidia card. On first try, it only yielded 1024×768. Oops. Digging through the Ubuntu forums yielded the “well, duh” clue: I needed to install nvidia drivers and do a minor bit of configuration. Now I had crisp 1600×1200. Woo hoo!
That’s when I found that I actually prefer running the 20″ at a lower resolution. Leaning back in my chair with my feet on the corner of desk and the keyboard in my lap, the display is about three feet away. At that distance, text on the screen at a lower resolution is readable. But at 1600×1200, I either have to kick the font size up, or lean forward and squint.
Leaning back this way isn’t doing my posture any good, but as I look a bit to the right, out the window, I see the evening sky turning dark pink and blue behind a large oak tree. And to my left, a cup of tea is within reach. Life, at least momentarily, is good.