I'm taking cooking classes from Gloria Bonfanti this month.
Observations: I made some really good pizza yesterday, I chose to make a Margherita I believe it's called. When I opened the huge bag of basil leaves, it was like walking into an opium den. I almost passed out from a drug-induced stupor. I'd be making this again today if it weren't that it's my granddaughter's birthday and she's asked for feijoada.
We made risotto e funghi. Gloria likes a lot of salt in the food. When we tasted the risotto, she asked if we liked the taste. I said I did, but that it was too salty by far. She said, "Ah, now that's the French for you."
Then we made a penne with broccoli and sausage dish. It was fun using her kitchen for this: the broccoli blanched and the pasta cooked in little compartments that fit a rack then plunged into a deep fat fryer except filled with boiling water. When she asked how I thought it tasted, I said it was perfect. She said, "Hmmm... there's not nearly enough salt in it."
Next week is pollo con funghi, meatballs in tomato sauce and a section on how to marinate meat and potatoes.
The week after that is tiramisu and crostata al cioccolato.
It's very instructive to see how a practicing chef works. I'm now totally bummed by my own kitchen. I need a real cooktop and real ovens. I'm already starting to think seriously about the ovens because I've got room to do something about it if I want (because of how I redesigned my kitchen when we bought the house).
Technical debt is a recent metaphor in my industry concocted to refer to the phenomenon that as we write and modify computer program code, its increased complexity costs us more.
The idea is that as programs age, they cost a company more money in terms of developer time and expertise to maintain or enhance them. Debt can also be a function of resources the application consumes, stuff like computer power, database size, increased disk space, memory and network bandwidth requirements.
This debt metaphor applies especially to the accumulation of code that's duplicated, tightly coupled, untested or doesn't fall under paths of known test coverage—all creating the situation where a developer goes in to add a feature and finds either that he cannot do it without breaking something else because of unforeseen dependencies between existing components or must do a great deal more work because there are considerably more points in the source base that demand his attention than might be estimated.
Obviously, reducing existing debt is thought to be important; limiting it in the first place is a pretty big goal.
And yet, this metaphor can be abused.
One might postulate that an application's debt can be seen like a mortgage at a certain interest rate. If the company considers "paying it off," the exercise quickly becomes daunting. A great deal of effort must be expended to make that happen.
Of course, the tools used to measure technical debt are suspicious in and of themselves. Their use and configuration cannot be taken lightly.
In the end, technical debt isn't really like a mortgage because one needn't always pay it down. One particularly nasty component may, in the wisdom of a measuring tool, constitute a huge debt in terms of its complexity. But, tools don't measure the fact that maybe there aren't bugs in it or that there is little or no need to go into that component to do anything. Whatever its cost may be estimated at, if no developer's ever going to have to touch it, the imaginary cost is not important.
Other code that must be touched frequently, such as a user interface, would be an important undertaking full of potential pitfalls. It would be more important to concentrate on doing it right, maybe choosing a widely understood framework, ensuring freater much test coverage, etc. than other components.
Beyond these considerations is the longevity of an application. If an application is soon to be replaced by a new version or by another application altogether, it's not important to spend any more money on it. It's like spending money on janitors to clean up a building that will fall to the wrecking ball.
Nevertheless, this metaphor is apt. And it underlines the need for software development to be agile, invested in test- or behavior-driven development techniques so that no code is written that's not covered by tests.
Test first; then code. State behavior by means of a test first, then code to solve the challenge.
When young, we fixed stuff ourselves. No big deal; poverty, semi-poverty or just frugality meant that we did it instead of paying someone else to do it.
Somewhere along the way, they figured it out. Auto makers began colluding with dealerships to produce cars that would need a modicum of repairs over their service life. Guys like me who used to know what every last thing under the hood did and what to do when it broke, long ago stopped recognizing much. Television sets, washers, ovens, refrigerators and other electric appliances became unserviceable at the component or subcomponent levels. Too, we get better jobs and better pay wimping out and allowing our manhood to drip away.
Well, today, I cheated the system. I fixed my two-oven stack, saving myself hundreds of dollars.
It used to be that when an oven stopped working, you replaced the heating element that no longer fired.
This is almost never the problem today. Last year, in my old house I kept for (usually related) college students. I lost an oven for want of a magic board to keep it running. Oven manufacturers discontinue component-level replacements after a few years and what was an dream oven I bought brand, spanking new in the late 1990s, an upscale one to boot, was reduced to worthless and I had to replace it.
That unit needed not only the circuit card that ran the oven elements, it also need the logic module—what ran the digit read-out, touch pad, etc.
I learned a few years ago, at the same time that I was first disabused of the out-dated notion that you can simply replace an element when it stops working, that modern ovens turn on and off the elements. This is the clicking sound you're hearing. In this way, they also use less power and need far less current. It cost me something like $350 to learn this lesson, about $200 of it was for a new circuit board.
When I installed my oven in the old house and the stack in my new one, I always ran 8-3 or at least 10-3 with ground to supply them. But I noticed that the ovens' factory cabling wasn't anything like that heavy. This can be because they now cycle on and off making it unnecessary to handle such huge current loads (30 or 40 amps back in the day) for so long a time. (Or, so I theorize.)
What this means is that when the oven goes out (excepting for the logic board), it's likely a relay/solenoid, the thing that goes clickity-click.
Having kept a board I needed to replace in my oven stack a few years back, I reached a conclusion based on inspecting it: the built-in obsolescence relies on the circuit board heating up and slowly letting its solder melt and/or dissipate. You replace the board because it stops functioning. It might have been a relay, but likely it wasn't. It was the board.
I just proved this to myself. I kept that old board and resoldered two relay lugs that were obviously "unsoldered" over the few years I'd had it thinking that if the board ever failed again, I'd at least try the old one now repaired. It was the upper oven.
The lower oven lost its broiler a year ago or so, but I've just been using the upper one. (Besides, everything I put under a broiler is reduced to ash anyway, so I generally avoid using it.) Last week, I lost the whole bottom oven for baking as well—just in time for Christmas dinner.
I'm about to embark on my traditional New Year's Eve dinner. Pulling it off with a single oven isn't pleasant to think about.
Today, I pulled it out, photographed the boards, recognized the new board (which was for the upper oven) and pulled the one for the bottom instead (after also noting all the colored cabling in case my photos weren't sufficient).
Sure enough, the dysfunction was identical to the old board for the top oven. Excited to prove my theory, I dug out my old Weller and applied new solder to two points underneath the board. I reassembled and fired up the lower oven.
Success!!!
I am finally a man again.
When you can get them, every time you can get them.
Today I polished off a new Apache ant custom task I wrote by publishing it along with some Eclipse projects that illustrate one of the tutorials I used to figure out how to write a custom task. Then I went back in and tested a feature I'd put in, but had forgot to use (it worked). Subsequently, my continuous build (via Jenkins) stopped breaking, well, only after fixing a few things in some SQL scripts that suddenly became visible because of the cool ant task I added to the build.
Yesterday, someone wrote to thank me for that Eclipse, Tomcat, JSP and servlets tutorial I wrote way back in 2008.
Things have wound seriously down at work for the next release of things. I can sigh in relief and look forward to more "planned" (read: non panic-motivated) work.
As I say, cheap thrills.
Sometime last spring, my van's heating and cooling system failed in the sense that I could no longer direct the air anywhere in particular. It was stuck on the floor, which wasn't particularly helpful for refrigeration.
No matter; I ride a motorcycle almost exclusively in the spring, summer and fall. Still, there are those times...
...and, after all, winter is coming: I can't operate this vehicle without a defroster.
Well, I knew that, because this happened before, there was some nasty work in the offing. Julene remembered that the last time, the mechanic reattached some hose to the engine. Yeah, back when I was a child, the manifold vacuum was used to operate many things—using amply large-gauge rubber tubing. Not everything is electric even today.
Well, for the Chevy Astro van, there's a "doghouse" that encloses the back end of the engine compartment isolating it from the cab. The operating manual has instructions and illustrations on how to do that. This doghouse cover must be removed because the hose connects underneath it. It also connects up in a place accessible from the front mixed in a bit with large aluminum tubes that appear related to refrigeration. (I'm not verifying all I'm saying 'cause I'm way past interested in auto mechanics at this point in my life, but most of this is accurate I think.)
At first, I couldn't find any tube likely to the one in question. And the doghouse wouldn't come completely out of the van without removing one of the seats. As (bad) luck would have it, my brother has the same vehicle (a little newer) and the same problem at the same time. If that weren't convenient, his second son married the daughter of the guy who, Julene thinks, fixed this thing the first time. So, a little networking and a visit from my brother after calling the mechanic and he found the broken tube exactly where he learned it would be.
The problem is this tiny gauge (1/8") tube is cooked by the engine over the top of which it's routed, become brittle and ultimately breaks. Mine broke next to the repair splice from the first time. The splice was still good; much of the rest of the tube was brittle.
We went to get a replacement from AutoZone, but they only had ¼" gauge tubing and some tubing connectors, none of which really was the answer, but we were in hard way, night was falling, etc.
We clipped off the tiny hose from its nice factory ends (rubber elbows that mated with a T connector in front and a nipple on a connector at the back under the doghouse) leaving short stubs of that tubing, still not brittle, and cleaned the latter up. We force-fitted these good bits of the remaining skinny tubing into nylon connectors from an $8 box of a million different size tubing connectors purchased from AutoZone, and heated up the ¼" tubing ends to go over the other end of the connector.
This, plus hooking it back up did the trick. My brother did his this morning and reports that it all went much faster as he'd been in on most of the job at my house.
Here are the puzzling bits I learned performing this repair. I'm hoping that after the search engines crawl my post, these points and my account will help someone else.
1. You need a large-gauge star drive to remove the two upper screws holding the console to the frame over the doghouse.
2. In order to remove the upper, passenger-side screw holding the doghouse to the firewall, you must have a flat-blade screwdriver at least 18" long. Nothing else will reach in there because there's precious little room left between a duct and the doghouse.
3. The tubing is tiny and the end under the doghouse is on the driver's side very near the throttle body.
The rest of what's going on is fairly obvious.
Twenty-seven years ago today, about the time I'm writing this (between three and four in the afternoon), my wife and I got on our motorcycle and headed up to a specially scheduled venue for a party we'd been planning for some time. We were a little tight on space in our tiny car, and we needed to get a few things ready anyway, so we planned for her mother to follow a little later with our three children aged seven, six and four.
Everything was already set up and waiting for us. There were treats including a cake as I remember (no, really) and drinks and even staff to wait on us, hand and foot. The children and their grandmother arrived in plenty of time for the party to start. The only one missing was a special invitee, whom we'd not really met before.
He arrived a little later.
One could accuse him of arriving "late," and certainly he didn't arrive until after all the other guests, but maybe just a little like a wizard, he didn't arrive early or late, but precisely when he meant to.
A great time was had by everyone and we all got along with him so well that we invited our honored and newly met guest to come home with us.
And so he did.
And we've all been delighted by him ever since.
Happy birthday, Thierry Daniel Bateman.
As announced yesterday, the Provo Tabernacle is no more. The outside walls will be restored, but the interior, the seating, the gallery, the choir seats and organ will never see the light of day again.
This edifice burned down last December. See story here.
The Church has decided to turn it into a temple. Understandably, the Church is not in the business of rebuilding community centers for secular benefit. However, failing to restore it to its original purpose makes for a very sad loss in that this building has stood for over 120 years as part of the community not only in terms of its spiritual usage, but it has, just as the Salt Lake City Tabernacle, served a local community's other needs. In Provo's case, this has meant hosting concerts (including an appearance by none other than Sergei Rachmaninoff) and community musical programs, school commencement exercises, university student piano, organ and other recitals, and it has served as home now and then to organizations such as the now defunct Utah Valley Choral Society. It has seen many performances of Handel's Messiah.
From a more conventional viewpoint, it long served as the site for stake conferences of various local stakes of the Church of Jesus Christ of Latter-day Saints. And it served the Roman Catholic community at least once or twice for Christmas Eve mass.
One of the more delightful aspects of this beautiful old building was that it hosted ecclesiastical meetings in a comfortable context and secular events in a cozy, inviting atmosphere appreciated by many Utah Valley residents be they Mormon or not.
And, there is really nothing in terms of a venue that comes close to replacing it.
On the plus side, most if not all of the block immediately south will include considerable green space that the City is hoping will attract people, and therefore shoppers, to central Provo which has for decades defied all efforts at reinvigoration.
Over the years, many Utah communities have learned the lesson that their tabernacles are similarly doomed as they no longer fit a growing Church's agenda or purposes. One by one, these historic structures have either fallen to the wrecking ball or, as in the case of Vernal and Provo, been converted to other purposes, temples in these two cases, a museum in another. Sadly, it's a rich legacy we're losing.