. This book is not just for programmers. Most of the content applies to testers, UI designers and other people who also participate in creating software just as much as programmers. And the bits that are specifically about programmers are still worth reading, because understanding how programmers function can be very useful when you work with them all day.--------
Then we got weathered-in (the ice was more a problem than the snow) for three days last week. My home machine wasn't really set up for testing stuff, so I picked up another tangent time project: procmail. I check email on 4 machines. Only 2 of them can run Mail filtering rules, so my inbox often filled up with subversion commit messages when I was away from my desk. And every time I wanted to tweak my rules, I had to remember to sync the changes from my work machine to my personal laptop (or vice-versa). My work mail filtering really needed to be handled further up-stream. Thus, procmail.
I learned the danger of reference material written for a context that doesn't match my own. And the importance of escaping square brackets in regular expressions. And I did everything very cautiously, because I've heard horror stories of buggy procmail rules bringing down mail servers. And I already used up my one 'kill the mail server' forgiveness card last year.
--------
Today I propped open Brian Marick's Everyday Scripting with Ruby
and worked my way through Part I. Yes, it was all familiar material. But if I was going to have problems with incompatible Ruby versions, or accessing the supplemental files, I wanted to have them while I wasn't also trying to debug some fancy meta-programming code I barely understood, or something like that. I've skimmed the book before, but this time I made myself actually write the code for all the exercises. I learned a little, but mostly I set myself up well to jump into Part II next week.
