If programming is like gardening, then weeding has much to teach us about debugging.
Friday, August 6, 2004
Laptops need power. Fuel cells generate power. Fuel cells burn organic fuels. Many developers have excess body mass. Seems like a perfect fit…
Sometimes ideas come together so naturally, and in such a balanced way, that it’s clear that they were just meant to work together. Apparently unrelated concepts and problems fuse into a single tidy solution so perfect that, when looked at in hindsight, the only possible reaction is “well, of course, it’s obvious.” Two problems that share a single solution: a fusing technology. The technology that solves one of your problems serendipitously solves the other (apparently unrelated) issue.
Tuesday, August 3, 2004
I love the output produced by TeX, and I love the flexibility I get typesetting from plain text input. However, TeX isn’t trivial. The new edition of The Latex Companion is a godsend.
I love type. Ever since I got into computers, back when high resolution was a 132 column printer, I’ve tried to find ways to play with typesetting and fonts. I wrote a basic layout system in OMSI Pascal that drove daisywheel printers. I got to be quite an expert at nroff and troff. I used to hunt (without success) for a free copy of Scribe. I played with Lout, and a dozen other packages. But nothing, ever, helds a candle to TeX when it comes to the quality of the output it produces.
Ignore for the moment some of the uglier fonts than some TeX users employ, and look instead at the pages. Hold them up at a distance and admire the uniformity of the gray: no rivers of white to be seen. Look at the bottoms of the page: if the typesetter didn’t totally goof off, they’ll be vertically balanced: an open spread is the same height on both pages (TeX’ll add tiny amounts of leading to make it happen). Dig into the line-breaking, and you’ll find optimization algorithms, which shuffle words back and forth trying to minimize the badness of the appearance.
The output of TeX gives me a lot of pleasure.
Unfortunately, the same cannot be said for its input. Don Knuth is clearly a genius, but as with all wizards, his creations can be tricky. In the case of TeX, we have a typesetting engine driven by a macro processor whose interpretation of syntax can be changed while it is in the middle of processing individual commands. Raw TeX is scary to deal with, so people don’t deal with it. Instead, they use its power to write macro packages, abstracting the low level commands into something more palatable (and tractable). The most widely used of these is Leslie Lamport’s LaTeX. LaTeX is at its heart a logical mark up system, documented in an admirably short and lucid book, LaTeX: A Document Preparation System.
But when you want to use LaTeX to do serious work, you need more than this small book. When you want to set complex tables, or handle floating material a certain way, or get your index looking just right, you need the real scoop. And you turn to just one book.
The original LaTeX Companion was one of those books that never got returned to my bookshelf. I used it almost every day for 4 years during the typesetting of five books. Thanks to its wealth of detail, I was able to create press-ready files straight from my computer to the exacting specification of the production departments of three separate printers.
But now, the bible has been retired. Mittlebach and Goossens have produced a second edition of The LaTeX Companion, and it’s better in every possible way. In the ten years since the first was published, a lot has changed, and the book captures it all. New packages, improvements in encodings, font handling, xindy: the book describes it all. My copy arrived a couple of weeks before Mike Clark’s Automation book was due to go to the printers. I devoured it, and immediately used its advice to improve the appearance of ragged-right text, fix up some font issues in the code listings, and improve the handling of included graphics. Since then, it’s been a true companion as I’ve worked with the typesetting of the new edition of Programming Ruby.
I don’t often gush, but if you use LaTeX, or if you’d just like to produce great looking typeset output, you owe it to yourself to get this book.
Tuesday, July 13, 2004
Monday, June 28, 2004
Tuesday, June 8, 2004
I just checked some local bookstores—the Pragmatic Starter kit books are now available in some Borders! That’s pretty neat: in a way the loop is now closed. If you’ve been waiting to thumb through a book before buying, now’s your chance.
So, next time you’re in a Borders, check to see if we’re there. (And next time you’re in Barnes and Noble, ask ‘em why they take so long to place orders :)
Thursday, May 27, 2004
Mike Clark’s been hunkered down for a number of months now writing the third volume of the Starter Kit, Pragmatic Project Automation. On Monday this week he finished the draft, and it went out to 20 or so lucky folks for a first review. The feedback so far has been marvelous: people really like both the content and the style (after all, lava lamps are this year’s essential project accessory).
I’m really pleased about all this for a number of reasons. First, I’m pleased for us. This really is a great book—practical, timely, and fun to read. We couldn’t have asked for a better way to round out the starter kit. I’m also pleased because automation is near and dear to my heart, and with Mike’s book we finally have something to show people to say “this is what we mean.” And, of course, I’m please for Mike. Writing a book is a lot of work, and it requires a bunch of dedication. In Mike’s case, that was tested even more, as he was the first person to use our new typesetting toolchain.
It’s looking like the book will be available sometime in July, and I for one can’t wait.
Wednesday, May 26, 2004
Monday, May 17, 2004
Monday, April 26, 2004
Monday, April 12, 2004
I came across (yet another) example of real-life broken windows last night.
I went to the supermarket about 6:30pm to buy some lettuce. Big mistake. At that time of night it’s crowded, full of folks on their way home. All the checkout lanes were four people deep, and every employee was working a register. It was chaotic, and a high pressure environment for those who worked there. Customers picked up on the tension: everyone was a little on edge.
Then, three people ahead of me in line, a women dropped a box of raspberries out of her cart. They spread out in a patch maybe 18” across. The woman was embarrassed, and pointed out the spill to the guy running the checkout. He craned his head to look, then looked at the length of the line and the expression on the face of the person he was serving. “I’m too busy to deal with that now,” he said. But he did call out to the floor manager. She was on her way to start up a new checkout, clearly harried. “No time” she called. So the raspberries lay there. As the line moved forward, the woman tried to move the raspberries out of the way, but she wasn’t too successful. In fact she managed to squash a few of them. The next person in line also tried to be careful, but his trolley ran over some, and got raspberry juice on the wheels. And so it went. By the time I checked out, the raspberries were a purple-red mess on the floor. The mess had spread from a small, contained spot to a large stain, and there were red tracks leading from the checkout to the two doors. The stains were already drying. It was going to take someone a while to clean it all up.
On the way home, I thought “that’s another great ‘broken windows’ story.” Fail to fix something early, and reap a whole lot of extra work later. Had the assistant said to the line: “Let me clean these up before they get all over your shoes” and spent 30 seconds with a broom, the problem would have gone away, and no one would have complained. In fact, the customers would have left the store glad that someone actually cleaned things up. Instead, we walked away with a bad impression and red-stained shoes.
It’s the same on software projects. Even when (especially when) things are chaotic and pressured, make the time to fix the small stuff. Otherwise it’ll just become big stuff, and your customers will end up seeing red.
Tuesday, March 16, 2004
Tim Bray has just joined Sun (congratulations, Sun). One of the interesting snippets in the middle of the article was:
In fact I personally believe that Java’s share of enterprise software will decline, but not in favor of anything from Redmond. I think that dynamic languages (Python and friends), particularly in conjunction with Test-Driven Development, are looking more like winners all the time. They generally are cheaper to program in, run just as fast, and have fewer bugs; what’s not to like?
I wonder if Tim’s in a position to help Sun see that the drive to make J2EE heavier and heavier will ultimately hurt them? There’s a definite groundswell out there of folks pushing back against the monster that is modern enterprise development (just look at the spread of the Groovy meme, and things like Spring). Will companies like Sun and BEA listen, or will they simply become less relevant? I’m hoping that Sun at least listens, but I’m not holding my breath: they’ve got an awful lot invested in the J2EE, and seem to think that the only way to move into the future is to add even more features.
The best thing that they could do for themselves and for the development community would be to scrap at least half of J2EE, and move back to a more lightweight, declarative style of applications development. Perhaps the 1.5 metadata stuff is a Trojan horse to let them do that, but I suspect not.
Sue Spielman just called. Apparently the Pragmatic Starter Kit just won a Jolt Productivity Award. I’m blown away: we had some stiff competition, and the books haven’t been out that long. I’m thinking that the judges were probably thinking what we’re thinking: these kinds of basic skills are becoming crucially important if we’re to keep software development competitive in this country.
Anyway, a big “thank you!” to everyone involved, and congratulations to the winners.
Thursday, March 11, 2004
My Powerbook’s hard drive came to a sticky end yesterday. Almost literally. Starting in the morning, it seemed to “stick” every now and then, and applications would hang until it came back. The sticking got worse and worse until eventually everything just died.
Down to the Apple store, and Tony in the Genius Bar said “before we wipe it, why not take an full disk copy to be on the safe side. It’ll probably cool down enough overnight that you’ll be able to get to the disk.” And he recommended Carbon Copy Clone as a way of getting a hard drive copied onto and external firewire drive.
And it all worked. I downloaded the software, booted up in the morning, and copied 40Gb onto an external LaCie drive. My hard drive resisted a few times, but judicious tapping of the case seemed to bring it back to life. When it finished, I rebooted off the firewire drive, and was able to create a book PDF to send to the printers before the weekend.
Along the way, I came to admire the Carbon Copy Clone interface. It’s trivial: it basically asks you where to copy from and to, and gives you a “start” button. But what makes it great is the log window. You see, underneath the covers, CCC simply uses BSD commands to do its work (things like ditto and bless). And in the log window, it shows you these commands as it executes them. First, that means that as the backup is happening, you can track the progress. I had a couple of terminal windows open to I could see directories being created in response to the commands that CCC was issuing. That made it easy to tell when the hard drive had stalled.
But it’s also a great interface because it taught me two or three new commands: things I hadn’t tried before. After I’d got a new loaner Powerbook powered up, I found myself using ditto a lot to install particular applications and directory trees.
So, for me at least, CCC is a really good example of a mixed-mode interface. It’s a GUI when I needed it (I have to admit to being panicky when the drive failed, and the idea of pressing a single “start” button to make an archive was appealling). At the same time, it also encouraged me to understand what wasreally happening under the covers, knowledge I put to good use later in the day.
And now I’m thinking about the applications I write. Do I perhaps hide too much of what’s going on from my users? If I made it more explicit, would it help them become more proficient?
Anyway, kudos to Mike Bombich for Carbon Copy Clone. (And thanks to Tony at the Willow Bend Apple Store for the loaner machine).
Saturday, March 6, 2004
If I’ve been distracted recently, it’s because Andy and I’ve been heads-down getting our third book finalized. When we first started Pragmatic Unit Testing in C# with NUnit, we though it would be a fairly light rework of the JUnit book. We were wrong. Instead, we’ve found that we’ve rewritten entire chapters, and heavily modified much of the rest.
The good news is that with this book we’re absolutely at the leading edge. We were tracking the NUnit team as they added whole new sets of features (check out categories as a great way of grouping tests), and Andy’s been working closely with Charlie Poole (thanks, Charlie!) to make sure we’ve been capturing the spirit of what they’re releasing.
We’ve also decided to try an experiment: this time we’re releasing the PDF version while the paper book is going into production. Folks who buy the PDF now will be able to get the standard combo discount ($12.50) on the paper book when it arrives from the printers.