A good office sometimes...

...or sort of: it's all relative, n'est-ce pas ?

Not since Novell have I enjoyed a view like this one. Of course, there I had a hard-walled office all to myself whereas here I live in cubicle hell. Here you see I-15, the cities of American Fork and Pleasant Grove as well as Mount Timpanogos.

In the dark foreground is my visitor chair and a couch. As my manager shares this cube with me, we have our (small) team meetings here.

PBS Fund-raisers...

I see PBS has gone back into fund-raising mode again.

Is there anything in the universe more incongruous than a PBS fund-raising drive?

What's on PBS during fund-raisers? Shows that are never part of normal programming. Cheap, popular psychology by two-bit therapists. How-to-get-rich pitches by speakers whose fortunes come from writing books and giving pitches on how to get rich. Opinionated, anti-fat nazis who just want to tell you how you should eat food that no one else eats. Chefs that can't cook their way out of a paper bag that's been soaking in warm water for 24 hours.

Really? PBS fund-raisers drive die-hard PBS fans such as myself to discover "normal" television or turn away to put more time into books (where more of my time is deserved anyway). While I'm gone, save for maybe a few quarters tossed over my shoulder on the way, I'm not there contributing. In fact, most of the time I confess I don't contribute out of disgust with what they're doing.

In years past, I was lured into giving by the broadcast of a few great Jeremy Brett's Sherlock Holmes portrayals, a marathon run of Fawlty Towers, the promise of a mug embellished with PBS Mystery, Masterpiece Theatre or The MacNeal-Lehrer Newshour.

Fund-raisers used to be a time where the local PBS station's personnel made a connection with the local populace. Now it's all robotic broadcasts done by paid, D-rank speakers and actors nobody knows.

There must be an audience for the utter rubbish PBS puts on now, but it clearly isn't the people who watch PBS. I can imagine that someone unaware, for PBS fund-raisers aren't publicized, discovers this programming, likes it, contributes his bit resolving to adopt PBS only to find a few days later that PBS doesn't continue to broadcast this sort of thing. Which means that the next time this person sees it, he simply keeps on surfing.

Randomly firing smoke detectors

This has been happening to me. I don't mean the beep every couple of minutes indicating the need for battery replacement, but the whole (linked) system going off. I did some research and found some interesting points that likely explain my problem.

How do smoke detectors work?

There is a source of beta particle radiation (yes, smoke detectors are weakly radioactive) that continually releases particles across a small space to be picked up by a detector. As soon as the stream of particles or even part of the stream is interrupted, the alarm goes off.

Systems that meet modern codes are interconnected both to 120v power and also linked by an additional electrical wire such that when once detector finds reason to go off, every detector in the system goes off in sympathy. This results in a whole house protection that is very effective.

Even though a modern smoke-detection system is wired to sector current and powered by it, each detector has a back-up battery much as radio alarm clocks and other devices for the "convenience" that this provides during power outages. The convenience of this in the case of a smoke detector is simply that if the power's off or out and your house begins to burn, one or more detectors will presumably sense it and sound the alarm.

What can set off smoke detectors?

1. Low battery.
2. Condensation.
3. Change in temperature, especially from warm to cold, probably because of condensation.
4. Cooking smoke or vapors.
5. Dust particles.
6. Tiny insects and arachnids.*

* This appears to have been my case because of the randomness of occurrence coupled with the random length, but short duration of the alarm. My guess is that the vibration of the alarm is annoying enough to chase the little beasties out of the hole in the detector sensor mechanism.

Is it possible to diagnose the exact cause?

If the alarm duration permits it, running around examining each detector will reveal, for most brands, that the offending detector is showing a red LED light instead of the usual, continual green one. This is the detector causing the rest to fire off.

When should I change smoke detector batteries?

Other than the obvious need to do this when the detector begins to complain by beeping every few minutes, many advise spending an hour each New Year's Day or the evening before your locale goes on or off Daylight Savings Time. Detector batteries usually last a good year making this a good policy.

I personally do not replace the batteries until I hear the detector beep. I find that my batteries are lasting several years.

Do smoke detectors go bad?

Yes. However, people frequently replace them unnecessarily with new ones after 1) a family member or acquaintance experiences a catastrophic fire, 2) unexplained failure creates mistrust. Still, better safe than sorry.

Why is the need to replace batteries only detected at night?

This probably lies in the realm of urban lore. No one seems to know why, but it is widely reported. Many also report that it drives them nuts while other inhabitants of the household seem to be able to sleep through the beeping.

Page numbers in electronic media

Despite what I said recently to my mother about there being no page number handling in Kindle, there is a Menu function on Kindle, Go to Page, that suggests that if you know the paperspace number of a book's page, you can get there. This has very obvious limited utility and I've never done it.

It's just that while you're reading, you don't see page numbers and to figure out what page you're on is probably (I think completely) impossible. All you have is the percent indication of how far you are through the text. I have two Kindles myself and when I synchronize the one to the web, then pick up the other and synchronize to the last page read, it doesn't say what page or anything.

Perhaps we'll lose our "page number centricity" in favor of percent as electronic media becomes more widespread and dominant.

(Does this not establish "chapter and verse" as a superior system of organization for books? Perhaps that's a little too stuffy for novels, eh?)

An aside...

For instance, I noticed that the precursor indications that Asher (in My Name Is Asher Lev, one of the greatest English novels ever written that I've just read for the third time) would paint the three-way conflict between his mother, father and himself came more overtly predicted at 73%, 80% and 87%. I'll forget these numbers within a few days, I'm sure. Why was I watching for this? Because the dénouement at the end of this book is one of the most poignant in literature.

Even further aside...

And, I'm back in paperspace now as I can't justify spending money on a book for Kindle I already own in paper. Thus I'm reading (again after having read it 20 years ago when it appeared) the sequel The Gift of Asher Lev. I've had a couple of paper copies of My Name..., but the last copy I had, I loaned to someone in a hospital who, when I later attempted to retrieve it, clearly had the impression that I'd given it to him so, I made no issue of it.

Back to the farm...

If you think a lack of page numbers is somehow hampering, imaging reading Atlas Shrugged which is 1200 pages. On the other hand, maybe I read it (last spring) precisely because on the Kindle, I had no idea it was anywhere near that long (although I totally knew it was on the same order as War and Peace which can be in excess of 1400 pages).

Now, I can see that this post has completely deviated from the original subject. Could that be for any other reason than that there's precious little more important than reading? Music and literature: nothing can dethrone these which reign supreme over leisure (and beyond). 

Test first, code later...

Another day, more proof that the first stroke of your finger in vim or whatever your favorite editor is, should begin with public class ...Test.

I prove this to myself altogether too often.

Whatever, I've never been on a project, even one with which I have so much to do as the present, for which there are myriad tests missing almost from day one.

Today, I went to tackle some "clean-up tasks" postulated in a distant sprint planning as something we'd need to get around to. Circumstances made it so that I needed to pitch in to help an area that's not ordinarily mine. So, I immediately set about adding tests for the little details I figured a couple of months back might need particular attention.

As the French say, Ben, voyons ! And how! Handling of nearly every one of the little details was either absent or seriously compromised. The test bits, which I wrote in JUnit using Mockito to eliminate any connection to wire, database or stuff that would defeat total automatization, were tiny, but they did the trick. In the space of probably two hours, I had the tests written and the implementation fixed.

For this, I can only thank my old friends from Brisbane, Dean Povey and David Leonard, for teaching me the maxim that is the title of this post. I'm only a deacon in this church of writing tests first, coding afterward, but I hope to become an ordained priest before much longer.

Patriotism in an era of repression

When I think, as I often do, about what distinguishes modern Americans from those who were willing to take up arms in defense of their personal and political liberties all those generations ago, I don't see many parallels remaining.

Two major distinctions exist in my mind.

First, it's not an us-them sort of thing. I realize that many colonists saw themselves as English subjects, but it's obvious that the British parliament's and King's unfeeling arrogance alienated enough thinking people to spark a nascent nation (no pleonasm intended here, but...). And, you had to be a thinking, indeed radical person for the most part even to find yourself in colonial America in the first place.

It's hard to raise up opposition against tyranny when the tyrants are you.

Second, today so many just aren't citizens anymore.

I think a couple of hundred years of assumptions largely fulfilled along with a Zeitgeist of democracy people have bought into whereby nations are becoming increasingly democratic (not sure this is even really, deeply true, but it's a different debate) have put Americans to sleep about what it means to be a citizen and the real threat that any government at all poses to liberty. In short, people assume that governments are legitimate to the point that individual freedoms are purely secondary considerations. Worse still, Americans now believe as long have their French counterparts, that it's government and not Nature or God that grants rights and liberty.

Immigrating peoples, especially Hispanics, come from a backdrop of appalling political servitude and a Crô Magnon-era understanding of themselves in the face of government, and do not expect liberty in the way our Founding Fathers thought both natural and crucial. I mean no slight: many immigrants come here for economic prosperity and personal safety for their families. I'm down with that as a totally honorable reason to come. Our distant ancestors, however, came because to stay home would have meant death or at least sore persecution for their religious beliefs. Those are reasons for creating an America of the Declaration of Independence, the Constitution and the Bill of Rights.

In summary, I don't see America irrigating the roots of the tree of Liberty with its citizens' blood ever again. Instead, what I see coming is strife and bloodshed unassociated with the lofty goal of "putting things aright" in a proper revolution.

The best laid plans...

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.

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.

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).

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.