Happy Things: spending the holiday with friends

Yesterday was a bit too out-and-about (with msmemory and I searching in vain for an open gourmet shop to pick up soup mix from), so I didn't get around to posting, so consider this a make-up post. It was a good New Year's.

Because of Wednesday's snow, we ran a bit slow on New Year's Eve, and decided not to do our usual party-hopping. Instead, we grabbed a quick dinner, and headed over to Camelot for the annual Lochleven/Camelot/bunch of other things New Year's Eve party. They hadn't managed to secure a Certificate of Occupancy for the (huge and gorgeous) Camelot Commons, but they just moved the party next door into one of the legal but not yet occupied houses. We were cozy, but since there was no furniture yet everybody fit, and it made for a boisterous good time.

My toast for this year is worth remembering for the diary: "2008 was a learning experience. Somewhere, I have a button that reads, 'Okay, that was a bit *too* educational', and that sums up the year nicely. Learning is good, but for 2009: Success!"

New Year's Day started, as always, with brunch at Joan and Ed's, with ladysprite and a gaggle of friends. It's become one of those traditions I very much look forward to: beginning the year with good people, freewheeling conversation and fine pancakes really seems like the right way to do it...

Happy Things: spending the holiday with friends

Yesterday was a bit too out-and-about (with msmemory and I searching in vain for an open gourmet shop to pick up soup mix from), so I didn't get around to posting, so consider this a make-up post. It was a good New Year's.

Because of Wednesday's snow, we ran a bit slow on New Year's Eve, and decided not to do our usual party-hopping. Instead, we grabbed a quick dinner, and headed over to Camelot for the annual Lochleven/Camelot/bunch of other things New Year's Eve party. They hadn't managed to secure a Certificate of Occupancy for the (huge and gorgeous) Camelot Commons, but they just moved the party next door into one of the legal but not yet occupied houses. We were cozy, but since there was no furniture yet everybody fit, and it made for a boisterous good time.

My toast for this year is worth remembering for the diary: "2008 was a learning experience. Somewhere, I have a button that reads, 'Okay, that was a bit *too* educational', and that sums up the year nicely. Learning is good, but for 2009: Success!"

New Year's Day started, as always, with brunch at Joan and Ed's, with ladysprite and a gaggle of friends. It's become one of those traditions I very much look forward to: beginning the year with good people, freewheeling conversation and fine pancakes really seems like the right way to do it...

Happy Things: a good firewall

It is oddly comforting to receive the daily emails of who has tried to break into commyou.com. While it's not great that the attempts are happening, it does show me that everything's up and running, and working hard to keep the system running on an even keel...

Happy Things: a good firewall

It is oddly comforting to receive the daily emails of who has tried to break into commyou.com. While it's not great that the attempts are happening, it does show me that everything's up and running, and working hard to keep the system running on an even keel...

Okay, *this* is a good argument for unit tests

By and large, I'm fonder of user-level scenario tests than I am of unit tests -- I think they give you far more bang for the effort buck.

That said, unit tests are often helpful and sometimes crucial. A really good example of such is the explanation for why 30GB Microsoft Zunes all failed on Wednesday. Summary: it was a very dumb code bug that turned into an infinite loop on the last day of any leap year, and just the sort of thing that a well-written unit test suite might well have caught.

Closely related to this: Microsoft is pushing automated testing tools rather hard right now, especially new tools that will automatically write many of the easy and obvious tests. I'd be curious to know whether the Zune was exposed to these tools, and whether they would have caught the bug if so. It's the sort of thing that a reasonably disciplined QE programmer might well consider fairly obvious (test the first, last and somewhere-in-the-middle days for a variety of years), but I could easily see an automated system not getting. It would be useful to know whether the automated tools are good enough to catch this kind of thing...

Okay, *this* is a good argument for unit tests

By and large, I'm fonder of user-level scenario tests than I am of unit tests -- I think they give you far more bang for the effort buck.

That said, unit tests are often helpful and sometimes crucial. A really good example of such is the explanation for why 30GB Microsoft Zunes all failed on Wednesday. Summary: it was a very dumb code bug that turned into an infinite loop on the last day of any leap year, and just the sort of thing that a well-written unit test suite might well have caught.

Closely related to this: Microsoft is pushing automated testing tools rather hard right now, especially new tools that will automatically write many of the easy and obvious tests. I'd be curious to know whether the Zune was exposed to these tools, and whether they would have caught the bug if so. It's the sort of thing that a reasonably disciplined QE programmer might well consider fairly obvious (test the first, last and somewhere-in-the-middle days for a variety of years), but I could easily see an automated system not getting. It would be useful to know whether the automated tools are good enough to catch this kind of thing...

Paring is difficult

Another of those disciplines of programming. It's hard for a good programmer to not write unnecessary code -- the temptation to gold-plate, and add extra functionality for completeness' sake, is very strong.

What's even harder is *removing* unnecessary code. Sometimes, you've built up a system that is complete, but you've found that you're no longer using all that functionality. It's painful, but the right thing to do is often to delete the no-longer-exercised code. Not only does it present danger (if it's not being tested enough, it may introduce bugs), but it can make refactoring harder in the long run. So it is often easier and better to re-create it later when and if it ever becomes relevant again, rather than keep it on the books without a clear use case.

(Yes, I'm doing exactly this right now. Some of the mechanisms from the old Facebook UI just aren't being used in the new UI, and should probably be restructured if they ever do come back. So the low-level support for them should be snipped...)

Paring is difficult

Another of those disciplines of programming. It's hard for a good programmer to not write unnecessary code -- the temptation to gold-plate, and add extra functionality for completeness' sake, is very strong.

What's even harder is *removing* unnecessary code. Sometimes, you've built up a system that is complete, but you've found that you're no longer using all that functionality. It's painful, but the right thing to do is often to delete the no-longer-exercised code. Not only does it present danger (if it's not being tested enough, it may introduce bugs), but it can make refactoring harder in the long run. So it is often easier and better to re-create it later when and if it ever becomes relevant again, rather than keep it on the books without a clear use case.

(Yes, I'm doing exactly this right now. Some of the mechanisms from the old Facebook UI just aren't being used in the new UI, and should probably be restructured if they ever do come back. So the low-level support for them should be snipped...)