There were so many little things to get done yesterday so that Monday could start with a crash and a bang to lead us to the point of priming at the duplex.
However, the fates had another destiny planned for me.
You may remember that a few weeks back my van died. We took it to a garage while I was in Palo Alto. Yesterday, Julene called me from a store parking lot. The van was dead again with the same symptom. Happily, Randy was just arriving at work not far away and I was able to borrow his van to pull mine. After a phone call to verify with a friend* that it was indeed going to be worth shelling out $160 to buy a new starter from AutoZone, and after many fun adventures like being pushed hard down from the top of my street so that I had enough momentum to land it in my garage, but not so much as not to be able to turn (without power steering) or brake to a halt (again, no running motor, right?), I changed out my starter.
Sam and I took the old one in to AutoZone to have it tested before putting the new one it. The tests were at first conclusive, but then we discovered a loose wire and had to retest it to make sure. The starter worked better, but the machine still failed it. Then I insisted the guy test the new starter I had just bought. The difference in performance, not to mention the machine bestowing a blue ribbon on it at the end, made me feel better about the expense and the time.
However, earlier, I discovered that the starter wasn't in the right place--just underneath the driver's side where all the starters in my life have ever been. I crawled deeper under to find it on the other side from which I didn't have access because I had beached my van carefully to expose the driver's side.
As I lay under the van, I began to have visions of the whole thing coming off my central hydraulic jack and it was obvious that death by crushing and suffocation would be painful and too long not to mention the disconcertment of those around me when it happened. So I "did the worm" to crawl back out from under and bought a pair of jack stands at Home Depot where I'd planned to be buying stuff like sheet rock and lumber that day.
For all my whining and moaning, I have to admit that a starter is a simple thing to replace on a very big vehicle like a van. I probably wasn't under the car longer than 20-30 minutes all told and there were no puzzlers of the sort that sometimes happen when working on a car.
Oh, and to finish the story, the van starts up just fine... for now.
* P.S. The article at the link above about this friend I've sung with for 20+ years now is well worth the read.
Sunday, May 27, 2012
Tuesday, March 20, 2012
REST-assured!
It's been a little while since my last post; I've been very busy professionally and personally.
For example, over the last month, I've weighed EasyMock and Mockito, then chosen the latter and cranked out a first draft of tests to cover a business logic layer already written.
This last week or so, however, I’ve been playing around with REST-assured in my spare time in an effort to leave no stone unturned on the way to covering every path in our restlet with a test. This is a very lightweight, open-source (Google-hosted) framework that allows you to test your JAX-RS implementation.
ReST testing is brittle
This sort of testing is a little brittle to say the least. It requires...
— Tomcat running the restlet.
— a database (in my case anyway) initialized with at least a modicum of test fodder.
In my case, I targeted one entity in my server that amounts to a collection of 172 guaranteed objects in my database. So, ...
— in order to test the HTTP POST, PUT and DELETE verbs, assumptions had to be made as to the existence of objects (being able to add rows to the database, some to update and some to delete for completeness).
The result is or can be somewhat destructive.
That's three strikes and the first two clearly mean this is not unit testing anyway, but something else (although, you code in JUnit).
I'm in the REST-assured community trying to find out how to solve the third problem. Still, it's a back-burner project as it's not super important and there aren't a tremendous number of code paths involved. These paths may turn out to be the 20% I don't cover.
But wait: There are advantages!
Still, it's pretty cool: the code reads wells, is simple and very self-documenting.
Second, it is a great formalism for stating exactly what URIs are implemented (handled by my ReSTful service) and how they should behave.
Last, it covers creating failure situations and explicit checking for particular HTTP status code returns.
Ooooo...
These last two points scratch (nay, gash deeply with long nails!) my TDD fascination and are the real reason I even walked this path.
Check out my notes and sample code here.
For example, over the last month, I've weighed EasyMock and Mockito, then chosen the latter and cranked out a first draft of tests to cover a business logic layer already written.
This last week or so, however, I’ve been playing around with REST-assured in my spare time in an effort to leave no stone unturned on the way to covering every path in our restlet with a test. This is a very lightweight, open-source (Google-hosted) framework that allows you to test your JAX-RS implementation.
ReST testing is brittle
This sort of testing is a little brittle to say the least. It requires...
— Tomcat running the restlet.
— a database (in my case anyway) initialized with at least a modicum of test fodder.
In my case, I targeted one entity in my server that amounts to a collection of 172 guaranteed objects in my database. So, ...
— in order to test the HTTP POST, PUT and DELETE verbs, assumptions had to be made as to the existence of objects (being able to add rows to the database, some to update and some to delete for completeness).
The result is or can be somewhat destructive.
That's three strikes and the first two clearly mean this is not unit testing anyway, but something else (although, you code in JUnit).
I'm in the REST-assured community trying to find out how to solve the third problem. Still, it's a back-burner project as it's not super important and there aren't a tremendous number of code paths involved. These paths may turn out to be the 20% I don't cover.
But wait: There are advantages!
Still, it's pretty cool: the code reads wells, is simple and very self-documenting.
Second, it is a great formalism for stating exactly what URIs are implemented (handled by my ReSTful service) and how they should behave.
Last, it covers creating failure situations and explicit checking for particular HTTP status code returns.
Ooooo...
These last two points scratch (nay, gash deeply with long nails!) my TDD fascination and are the real reason I even walked this path.
Check out my notes and sample code here.
Sunday, January 15, 2012
Gloria mi insegna a cucinare
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).
Thursday, January 12, 2012
Technical debt
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.
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.
Friday, December 30, 2011
Manly thrills and excitement!
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.
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.
Wednesday, November 2, 2011
Cheap thrills..
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.
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.
Tuesday, October 25, 2011
In the doghouse...
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.
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.
Subscribe to:
Posts (Atom)