It's good that the market corrected. Otherwise it was saying something pretty horrific. That the economy will just sail along with huge unemployment, hunger, disease and death.#Lakoff says "defund the police" is a terrible slogan. As I've said myself. Black Lives Matter is brilliant. Impossible to disagree with. But even if you endorse defund the police, you have to immediately explain that isn't literally what it means. #
On Twitter, a question. Name something that your mother cooked that was your favorite. At first I was going to reply my mother wasn't a very great cook, but then I remembered. She sent us, my brother and I, cookies at summer camp. They were the best things ever.#
One of my servers was down at least since midnight. Sorry if you've had trouble reaching LO2 and many of the static sites. Operator error. #
I found the patio lounge chairs I want. Reasonably priced. Sturdy. Attractive. Only problem is they take a long time to get here. 8 weeks. By that time summer will almost be over. (Update: My friend Peter Politi found the chairs on the Lowe's website at a good price for delivery in 8 days. Problem solved.)#
- Continuing the example from the previous case study. The routine, pad, takes three parameters, a string or something that can be coerced to a string, a character to pad with, and the number of places to pad to. So pad (8, "0", 4) returns a string whose value is 0008. It's useful for neat tabular displays. #
- In an app I'm working on, I call pad a lot. Then, while testing it in a new environment, I got an error message from the JavaScript runtime:#
- TypeError: Cannot read property 'toString' of undefined.#
- Looking at the stack, the error was in the first line of pad. #
- var s = val.toString ();#
- I conclude that val is undefined in one of the many calls. #
- The question -- should I find the place I called it with undefined and add logic to not call pad in that case, or should I add the test in pad, and return something reasonable when val is undefined?#
- Now we get to the point of this case study.#
- Changing a core routine like pad is tricky. If you change its functionality, you potentially break code that calls it. If it's been around a while, who knows all the places it has been called. However in this case, that's not an issue, because any call that has undefined as the value of the first parameter is going to fail. So it's already broken, therefore you can't break it and therefore it's okay to fix it. 🚀#
- Then the question is if it's desirable to fix it in pad, or in the place that calls it that causes the app to fail. For me that's a no-brainer. It would clutter up every call if we don't put it in the function. The whole point of factoring like this is to trade off a tiny bit of time for space and reduced complexity. Factoring is a good thing, and you should do it whenever it's responsible. Remember what Einstein said. Basically factoring is good, but don't do too much. #
- I call this coding technique defensive driving. It's something you do in case the other driver (the caller) screws up. You want to prevent the accident. Most of the time it won't accomplish anything, but when it does, it saves you from a crash. One less thing to worry about.#
- So here's the new version of pad, with the defensive driving code added:#
- function pad (val, withchar, ctplaces) {#
- It makes pad a little more complicated -- a fact of life. Production code is rarely as simple as demo code because it has to deal with all the crap that gets thrown at it. Defensive driving is how you deal with that, the same as in driving a car or riding a bike in traffic. You never know what the other idiot is going to do. 😄#