May 2006 Archives
"Sure, test automation is a good thing. But we can't, and shouldn't, automate them all. Why then, ask people to 'automate all tests'?"
Very Cool: The YAGNI Development Assistant.
Mising in both Visual Studio 2003 & Xcode 2.3.
(Via Jeremy D. Miller)
Jeff Atwood elaborates on Programmers and Chefs inspired by the Ron Jeffries's quote I posted a few days ago.
As always, Jeff's thoughts are a great read. Plus, to kind of push the kitchen analogy even further, it's always great to come up with some vague idea for a meal and someone else is doing the hard work of actually cooking the meal (and cleaning the kitchen afterwards, of course).
"The only time not to automate a test ought to be if we are never going to want to run it again. But it isn't. The more common time we don't automate a test is because it would be 'too hard' to automate it. That is, however, not really a property of the test, though we like to put it that way. It's really a property of our own test automation capability and tools."
...Uncle Bob.
Of course, you're lucky because you don't have one of those MacBook Pro emitting whining noises, featuring an LCD panel with brightness issues and having general excessive heat issues. But still, even with those issues, it's still way better than anything else out there.
Der ist wirklich gut.
An excellent collection of Code Smells by Coding Horror.
Ron Jeffries (taken from an interview with Bruce Eckel):
"The reason the kitchen is a mess is not because the kitchen is poorly designed, it is because we did not do the dishes after every meal."
Hallmarks Of A Great Tester - Great presentation by The Braidy Tester.
I also like the subtitle of his blog: Making developers cry since 1995.
Jason on what the software industry is missing.
Excellent.
Nice overview of code smells and what to do about them: Smell to Refactoring Cheat Sheet.
(Via William C. Wake)
Here's a good one: Coercing Your Developer.
Andy Dent on Object Master & the classic beauty of the Smalltalk Browser.
That's something I crave: Having a Smalltalk 3-pane browser to edit C++ code - like Object Master. Occasionally, I spent some time googling for one, but it looks like there's nothing like that out there.
Here's an excellent post by Jonathan Pickup on the need for a solid foundation to successfully complete advanced projects.
I would like to add that you will need to work on your foundation, the basic skill set of your profession every day. It's one of most important things you can do.
If Christoph blogs, you can count on him blogging something deeply relevant: Martin Luther King, Jr.: I Have a Dream.
Even though the speech was delivered more than 40 years ago, it's still relevant today.
Back to our regular scheduled programming.
Another excellent post from Creating Passionate Users.
Why wrap a (procedural) API of a third-party library / host application - instead of using the API straight away? Here are some reasons plus some simple techniques to accomplish just that:
- Wrapping the API makes unit testing much easier because you can mock your own classes instead of mocking the API itself (which tends to have more dependencies)
- Creating your wrapper may actually deepen your understanding of the API
- You may be able to tie up a few loose ends in the API (e.g. mix of deprecated and new API functions to accomplish a task)
- Creating your wrapper may simplify the API (witness the change from AddPopupItem() to AppendPopupItem() in the sample provided below
Here are some simple techniques for wrapping:
- Save on parameters - Instead of using AddPopupItem(..., long dialogID, short popupID, short insertAfterEntry, String entry) you could use MyAppendPopupItem(long dialogID, short popupID, String entry) - not a substantial improvement, but if combined with the next techniques quite powerful...
- Transmogrify the API into an object-oriented API - Use myDialog.AppendPopupItem(short popupID, String entry) instead
- Make it even more object-oriented - Use myPopup.Append(String entry) instead
There are a number of arguments against wrapping an API - but at the end of the day, I'm quite firmly in the "Wrap it" camp.
Here's a great one from the 37signals blog: Illusion of agreement.
...just because all the fields (of a class) are final and there are no setters, this doesn't mean that the object is immutable.
