- Hold an expensive wine tasting … at McDonald’s
- Hold a Yankees rally … at the Cask & Flagon
- Hold a cloud computing seminar … at 8 A.M.
Month: January 2010
All time favorite television characters
- Jimmy James, News Radio (Stephen Root)
- Al Swearengen, Deadwood (Ian McShane)
- Omar Little, The Wire (Michael K. Williams)
Yours?
P.S. Tubalcain
Buying a car
I won’t say I’m some kind of genius buyer or that I have a bulletproof system, but I think I’ve done pretty well when I’ve gone shopping for a car, and this article backs up some of my ideas. I don’t think any tricks or deceptions are really going to help you, your opponent in this game is likely to be much more experienced than you. My rules:
- Make it clear to the dealer that under no circumstances, no matter what, will you be making any decision today, and that you need real numbers, in writing. This is not a trick, you really do need to walk away and sleep on it. The pressure will mount when he realizes you’re serious, and it’s hard to resist, but it’s well worth it. You’ll have real numbers to review, show someone else, fit in your budget. If you get the “I can’t hold this car for you for any longer” line, ignore it. Either he’s bluffing or he’s going to sell the car to someone else. Either way it’s no big loss for you, there are always other ones out there.
- Say as little as possible (not difficult for me). The article mentions not talking about credit or how you’re going to pay for your car, which seems obvious to me. Don’t talk about trade-in (if pressed, be indecisive, “my sister might buy it off me”) or how long you’ve waited for this model to come out, or anything like that, until you get the numbers from #1. Do your research, but don’t go in with a bunch of stuff you found online about invoice cost and think you’re going to get the guy to sell the car and not make a profit, you’re not.
Other tips: If you’re leasing, buy early in the model year. If you’re buying, buy later. And try to take something off the lot, you lose alot of wiggle room when you need to order it.
Contrary Opinion: Code coverage by checked exceptions
This is the first in what will hopefully be a series of statements that I may not entirely believe, but to put out there to see if they are viable…
Conventional Wisdom: Unit tests are great, you should have lots of them. More code coverage is better.
Conventional Sentiment: Checked exceptions are a hassle, more trouble than thier worse, promote sloppy coding, etc.
Contrary Opinion: Checked exceptions are a better way to address code coverage than unit tests.
On a scale of 1-10 of using and advocating for checked exceptions, I’m probably an 11. I completely disagree with pretty much all of the conventional complaints against them. They do not promote spaghetti code, they actually clean up your normal logic and neatly compartmentalize your error handling. They do not promote sloppy behaviors like exception swallowing, that’s entirely the programmer’s fault. Adding or removing exceptions breaks client code. Yes, it does, why is this a problem? You added additional error conditions, meaning you changed your contract with the clients, and they should be revisited. If you didn’t have this obvious way to signal a change, chances are that the client would handle things incorrectly. Even some of the major voices in computer science have fallen out of love with them, but usually the reasoning is based on people using them wrong (or being too hard to use right).
On a scale of 1-10 of using and advocating for unit tests, I’m probably a 2. They absolutely have their uses. A straight-up algorithm, especially things like math and parsing, should be unit tested for various input values to assure they’re returning the proper value. However in most modern business/consumer software these represent a very small portion of your code. There are far more lines of code dealing with things like authentication, user inputs, file loading, database and network operations, etc. These are complex activities. Even simple CRUD applications can end up invoking hundreds of functions across dozens of libraries for every operation.
The crux of my argument is that if you use exceptions properly, you don’t need to test if an operation completed properly. If the operation completes, it did so properly, all other conditions would fail to complete. Since you want to be using exceptions properly anyways for cleaner code, unit testing this code is redundant but a waste of time and energy to write and maintain. Not only that but exceptions give you code coverage at compile time AND error handling at run time, which unit tests cannot do.
If you disagree, please tell me why!