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.