My kids sometimes wonder what it is about history that fascinates me so much, and I have almost no ability to provide an answer that satisfies. So instead I turn to demonstration. Every now and then I learn something that, once it sinks in, nearly takes my breath away, and my next thought is usually to communicate it to them so that I might prompt some flowering of interest. But it hasn’t worked yet. Today’s New York Times provided me with such a piece of information, which I may email them. It’s always worth another try.
The story concerns one of the earliest musical instruments ever discovered intact: a flute carved from a piece of bone nearly 35,000 years ago. Go ahead and click on the link. There’s a picture. The instrument in question is thin, graceful, gently curved, and bears every resemblance to a modern woodwind in form and function. It was created in a past so distant that all of recorded history could have occured in the interrim seven times over. Everything we know about civilized humanity spans a mere 5000 years or so, and yet seven times that long ago humans were carving instruments and playing music. If the very idea doesn’t awaken in you an appreciation for ancient history then I think we can safely assume nothing will.
You may have been in a situation like this, or you may have known of a situation like this. A child is performing poorly in school. He or she misses assignments, pays little attention in class, and doesn’t do well on quizzes and tests. Naturally the quarterly grades reflect this. In between report cards the parents are kept informed through scrawled notes on progress reports, emails, and perhaps even the occasional phone call. The messages may be depressingly consistent: “Missed two assignments.” “Not putting forth effort.” “Project turned in late.” In the worst cases of this sort, the child may even be receiving actual failing grades in one or more classes.
The parents, of course, do their best to intervene. When asked about homework assignments the child always has an answer. The assignment was made up. It was turned in but the teacher missed it. Everybody was late on that one, etc. These excuses generate more messages back and forth between parents and teachers. Everyone is involved, which is what we’re all supposed to be these days. Everyone is talking, and yet the student’s performance doesn’t improve. Why? Wasn’t all of our caring supposed to ensure success? How is it that in the face of all this virtuous involvement the child is still screwing off 75% of the time?
One question that is worth asking is: what are the consequences of screwing off? The answer, depressingly, is that there aren’t any. Will a child who fails to pass a grade be held back from the next grade? No. Will a child who fails to turn in an assignment get detention, or have to write 500 times on the blackboard “I will do my homework,” or even clean up the classroom at the end of the day? No, they won’t. What about discipline? Surely a child who misbehaves will get sent down to the principle’s office for a stern talking to? Yes, that might happen, but unlike in my day there sure as hell won’t be any paddling involved, or any other material consequences, and a stern message delivered to any given teenager has about as much effect as you would expect it to have. But there will be another note home to the parents, who are expected to cure all these problems somehow.
What does the child ultimately learn from this, about the nature of obligations to the institutions that govern our lives, and with which we voluntarily affiliate ourselves over our adult careers? What they learn is that institutions are impotent. The school can assign work. The school can make rules. But the school is utterly unable or unwilling to enforce any of its rules, or hold students accountable for discharging their assigned duties. Later in life the little dears will find out that other institutions are very capable of doing these things, and I suppose it will come as quite a shock to them. Parents naturally want to do what they can to respond to teacher concerns, but the parents are a third party to the relationship. If the institution cannot hold its charges accountable, how should the third party do so?
They cannot, and the impotency of this triangular relationship ultimately encourages the students to do whatever they feel like, secure in the knowlege that nothing bad will happen to them at the hands of the people whose rules and requirements they are disregarding. Of course, bad things will happen, but they will happen much later, in adulthood, long after the administrators of the schools have added another number to their count of children not left behind. Unfortunately, by then it is far too late, and there is no safety net of helicopter parents to descend from the skies and fix the problem. All of which prompts the question: how can a child learn discipline and studiousness and the virtues of hard work from an impotent institution that can do no more than make friendly suggestions? The answer is that they can’t, and many don’t.
County route 517 leaves Hackettstown, NJ as High Street, heading north. Not far past the huge Mars candy plant on the outskirts of town the road lifts itself up and over the shoulder of Allamuchy Mt., and then it is just 517, the road to Andover and Sparta. As you drive northward past the little crossroads town of Allamuchy,sheltering in the shadow of two highways and what is really a large hill, a broad valley opens up on your left. It is typical northern New Jersey farmland, rolling and rich, stitched into quilted patterns by old stone walls, bits of forest, and wandering streams. This is the valley of the Pequest River, which has its start in Stickles Pond high on the slopes of Wawayanda, where they call it a creek. Down here in Warren County it is a river, whatever those Sussexers might say.
As you continue north past Lake Tranquility, another of those quirky little resort towns that grew up around New Jersey lakes before there was such a thing as subdivisions and suburbia, you can’t help but notice that the gentle progress of the valley seems to be interrupted by something very high, very straight, and very flat. As you get close it seems almost as if someone has thrown a massive earthwork across the valley from mountain to mountain, and then let nature have its way. This is what Hadrian would have built, with a million more men and fifty more years, because this damn well would have kept the Scots out. Not far from where you gaze up in wonder 517 punches under this massive edifice in a narrow tunnel and continues ascending the valley.
Instead of following it you take a left on Kennedy Road and rumble northwestward, parallel to the earthwork that reaches heights of 110 feet not far to the right, until you reach the town of Greendell. Greendell is a quiet little burg hugging a country crossroads, with little left of whatever bustle and prosperity it may once have had, and although you may not know it yet, the coming and going of that prosperity, like the rise and fall of many another little milltown in the Highlands, had a lot to do with that impossibly big mound of dirt you’ve been tracking. Taking a right on Wolf Corner Road you spot a thin, gray line on the GPS, crossing the road at nearly a right angle, and then suddenly you’ve come to a wider spot next to a chain link fence, with room to park. You hop out and pretend not to notice the sign that says “State Property – No Trespassing.” Around the end of the fence and over a mudhole between two bushes and you’re looking at a little concrete railway station with a green roof.
This is the Greendell station of the Delaware, Lackawanna, and Western Railroad, opened in 1911, closed in 1934, and never of much use to anyone since. A muddy, cinder-black trail leads eastward past a concrete ramp and platform where cars were loaded during the brief time that the DL&W tried to serve Greendell. Bits of railroading history begin to appear here and there: concrete tower mounts, chair plates, old bolts and ties, lots of ties. Not very far along the muddy and undulating trail you see the remains of the Greendell Tower, its reinforced concrete shell as completely durable as every other structure the DL&W built when they made this line in 1911. It, and the station, stand as lonely sentinels on the western approaches to one of the most audacious, and remarkable feats of railroad engineering ever undertaken: the Pequest Fill.
Consider the following scenario: a rich client communicates over the Internet with an ASP.NET service that does not use forms authentication, and also sends requests to a content site that does use forms auth. Initial user authentication is performed by the client and service using a proprietary protocol. The service then creates an authentication ticket for the user that will permit access to the content site. The ticket is created using the FormsAuthentication.GetAuthCookie method, and passed back to the client to be used in later requests. On the content site the web.config file specifies that the authentication ticket timeout is 120 minutes on a sliding reset, however the ticket consistently expires in 30 minutes. What’s wrong?
My colleagues and I recently faced this exact problem on a current development project. In researching the issue we first made sure that our web.config settings were correct. Using the IIS service manager we verified that the values for the timeout, sliding expiration, cookie name, and machine keys were being picked up and used by the server. The timeout was clearly being set to 120 minutes, and everything else was correct, but still the ticket was expiring at 30 minutes. Obviously our config files weren’t at fault.
Configuration can be a tricky thing in ASP.NET, however, and sometimes the properties that end up driving your system are not the ones you thought were at the wheel. Further research led us to a Microsoft support article on forms auth tickets and cookies. The last paragraph in the article contained the following statement:
“If the forms authentication ticket is manually generated, the time-out property of the ticket will override the value that is set in the configuration file.”
Aha! Surely we had the culprit in hand. Someone had set an explicit timeout in the code that generated the cookie, and that timeout was overriding the values set in web.config. It made perfect sense, except for the fact that when we opened up the code the line in question did not set a timeout. In fact we could see no way of specifying a timeout in the call to GetAuthCookie. Lacking an explicit timeout the value in web.config should be used. We were prepared to head back to the drawing board, or at least Google, when one of my smarter coworkers wondered if, in fact, some default timeout was being set during the call to GetAuthCookie? With the help of a friend who had a copy of .NET Reflector handy we peeled System.Web.Security. Ultimately the public versions of FormsAuthentication.GetAuthCookie call a private overload. The disassembly of that method looks like this:
The part that caught our eye right away was the constructor call to create the FormsAuthenticationTicket. Specifically the fourth argument to the call, which is calculated from DateTime.Now.AddMinutes((double) _Timeout). Hmm, _Timeout, a private field, and obviously relevant to our issue. But where was it getting a value? The first line of GetAuthCookie is a call to FormsAuthentication.Initialize, and so we disassembled that, too. In it we found the following line:
So the timeout value being passed to the constructor was coming from the forms element of the authentication section in our web.config! But we had already verified the web.config was correct… errrm… actually, we had only verified that the web.config values on the content site were correct. The cookie was being created in the service implementation, a different site altogether, and one with its own configuration. When we looked in that web.config we saw that the forms element did not specify a timeout for the ticket. Since it didn’t the value that was ultimately assigned to _Timeout and passed to the constructor for the ticket was the default, and that is… you guessed it, 30 minutes.
Ultimately the solution that worked was to specify the same timeout value in web.config both on the content site where the ticket would be used, and in the service implementation where it was created. And while having a dependency between those two was less than satisfying, getting this vexing bug to go away more than made up for it.
I struck out three times at the library this week. One was a Ben Bova novel about two brothers on opposite sides of the stem cell/cloning/immortality issue. It started pretty well, but then kept switching between first person protagonists in the first three chapters. I like the first person perspective, but I guess I don’t like to get into a new head with every chapter. I might give this one another try because Bova is a fine writer whose work I have enjoyed in the past.
The other two looked like good stories too, and the one I began reading started well. However, what I had missed in both cases, and what was not advertised anywhere on the books’ jackets, was that both were buried in the middle of an -ilogy. One was a second book, and the other a third. This fact was not made clear in the frontispieces or title pages either. You really couldn’t figure it out until you read the back cover testimonials carefully. I took both back to the library and made a desultory effort to find the beginnings of each story in the catalog, but our small library either never had the earlier novels, or doesn’t have them anymore. Perhaps the buyers for the library were deceived as easily as I was.
I don’t like to jump into the middle of a multivolume story. In fact, I’m almost to the point where I just disdain -ilogies alltogether. I was introduced to them by Tolkien at the age of 10 or 11, and ruined for them by Jordan at the age of 45, when, after fifteen years of rambling through eleven increasingly incoherent and plodding volumes in the Wheel of Time series, the author departed the mortal plane without finishing it. I think WoT would have made a really great trilogy.
These days it seems more than half the new volumes at the library are part of a series. If I see “Fifth Volume in the Dreams of Balthazar Chronicles” I just put the damn thing back on the shelf, only slightly more quickly than I would if it were the first volume. My aversion is selective. I’ve been known to go out of my way to get complete sets of O’Brien, Gemmell, and Cornwell, not to mention Mary Stewart. In O’Brien’s case the Aubrey-Maturin books actually stand pretty well on their own, and as for Gemmell, Cornwell, and Stewart they are just worth it, and how. But my weariness of the -ilogy marketing approach just makes it a lot harder to win me over. I’d like to see more really good single volume stories. I’ll be fifty years old in a year and a half or so; I can’t even be sure of living through another Robert Jordan.
And while I am on the subject of books it would be remiss of me not to mention the most lamentable trend of all, which is neatly encapsulated by the title of a book I was looking at in the library last night: “Robert Ludlum’s The Bourne Sanction by Eric van Lustbader.” Robert Ludlum cannot write any more Bourne novels, because he is dead, and van Lustbader shouldn’t be writing them either. “Tom Clancy” is another one. He’s still alive as far as I know, but 95% of the stuff I see with his name on it was written by someone else. Hopefully, the publishing industry has been learning along with the rest of us that pursuit of money for it’s own sake isn’t the point. I’d just like to see good books. The rest of the business will take care of itself.
I’ve been thinking a little bit lately about the notion of completeness in programming. I think it’s a valuable concept because those of us who write software have a hard time defining what the word “done” means with respect to our product. The old saw about model railroads is that they are never finished, and I think a lot of us feel the same way about the code we write.
A similarly ephemeral concept is that of correctness. When is a body of code “correct?” Can a given piece of software be “correct” without being “complete”? The problem with correctness is that software is too complex to support any but the narrowest definitions of the term. We could define correctness as the state of development at which a piece of code produces correct outputs for all possible inputs. But it’s difficult to assert that any non-trivial system meets even that fairly specific definition, and that definition leaves out a lot of possibilities for things to go wrong due to external factors.
In practical terms software is perceived to be complete when it does all the big things we asked for it to do. This idea is reinforced by methods of requirements definition such as Use Cases, which focus on large-grained behaviors of actors in the system. I think it’s safe to say that we can get all that stuff right, and yet not have “complete” code.
So what is complete code? I’ll take a stab at a definition: Code is complete when it produces the correct outputs for all possible inputs, and fails safely and gracefully in all possible situations where a correct output cannot be produced. In my experience it’s often that second part of the definition that gets short shrift in the development process. Time and again I run up against code that takes the straightest possible path between input and output, and ignores a slew of potential boundary conditions and failure points along the way.
Putting the blinders on and dashing straight for the finish line is usually defended as pragmatism and a “get ‘er done” attitude, and there are times when it is absolutely a virtue. If you ever do a technology start-up you’ll encounter many of those occasions, often strangely correspondent to meetings with potential investors. But for just about any system that has to actually run reliably and do important stuff in a production context completeness is a more important quality than brevity. Brevity will make you feel good now, but it will cost you in the long run.
Unfortunately completeness is hard to see, doesn’t provide any immediate benefit in the eyes of users, and is therefore something they hate to pay for. Buying an incomplete piece of software is like buying an old, worn out car with a new paint job and refurbished interior. It feels great, and it’s fun to show it to your friends, but step on the gas and the wheels fall off. I’ve seen the wheels fall of a few software systems when the throttle was opened. I guess it’s a lot easier to place a value on completeness when the lack of it means you have to walk.
The New York Times had a little technology piece today about the waning popularity of voice mail, and it struck a chord with me. If voice mail isn’t the 8-track tape of the early 21st century communications industry then I don’t know why not. It should be. Voice mail is one of those strange devolving products that has gotten to be more of a pain in the ass over the years, rather than less.
You could probably say that the home answering machine was the first widely available voice mail technology. By and large they were easy to use. You plugged it in, pushed record, said a few words, played them back, pushed record again, realized ten minutes later that you would never sound better than that, and finally gave up and watched Johnny Carson before going to bed. Later when you returned from some extended absence you would know you had messages because the machine was blinking. You pushed play. You listened. You erased.
Which was all too easy for voice mail marketing people to stomach, so they started to add features. Multiple boxes, separate greetings, calling number storage; the slow climb of voice mail up the Rectal Scale of annoyance had begun. Voice mail had become a pain in the ass.
The growth of the cell phone business only made it worse, because along with new features we got lots more prompting. Apparently the explosion of tiny hand held cell phones gave lots of stupid people access to voice mail for the first time in history. I make this admittedly offensive suggestion only because I can think of no other reason why the nice lady insists on repeating 20 seconds of instructions every time I dial in to retrieve my voice mail. Yes, yes, dammit, I recall something about entering my four-digit pin and pressing ‘pound”. How about you shut up now?
Voice mail is a pain in the ass. Email is not a pain in the ass. See how simple technology market prognosticating can be? Skype is also not a pain in the ass, at all. I work for a small software company that has several offices around the country knit together using email and Skype. We have a virtual PBX, with an 800-ish number and assigned extensions for everyone, and last week the owner of the company admitted to me that he couldn’t remember them half the time. When we want to get ahold of each other we email or, far more often, Skype. In fact, I am at my desk so often working on projects that if you call my aging Embarq (Sprint, with a coat of paint over the rust) landline and get voice mail, it’s because I’m on Skype.
Voice mail: it’s as relevant as a cathode ray rube, and as fun to use as a mimeograph. What’s not to love?
If you use Foxit Reader, an excellent lightweight PDF file viewer from Foxit Software, then this tip might be of value to you sometime. I’ve been using the software for years as an alternative to Adobe’s bloated offering. It has always worked well for me, and continued to work well after I migrated my home office to Windows Vista. However, I recently installed an update to version 3.0.1301 of the program, and suddenly found that every time I tried to open a PDF Vista’s User Account Control kicked in and requested elevation. It was annoying. If this happens to you, here’s how to make it go away.
The reader program is located in c:\Program Files\Foxit Software\Foxit Reader\. The file is called Foxit Reader.exe. Navigate to this folder in Windows Explorer, and right click the filename. On the context menu that appears click “Properties,” and then click the “Compatibility” tab in the dialog. First, look at the bottom and see if “Run this program as an administrator” is checked. If it is, uncheck it. That might be the whole problem for you, but in my case the checkbox was clear, and I was still getting UAC prompts from Vista. The next thing to do is click the button at the bottom of the dialog labeled “Show settings for all users.” This brings up another dialog. Look for the same checkbox in that dialog and clear it if it’s checked. Click “ok” to accept the two open dialogs. Foxit should now launch without requesting elevation.
In the process of debugging some stored procedures the other day a colleague and I happened on an input parameter that had been given the type smalldatetime. We noticed it because we were using the maximum and minimum values for System.DateTime to set boundaries in some validation code. The maximum value for the System.DateTime structure is a number of ticks equivalent to the date December 31, 9999. That’s sufficient to cover the expected remainder of Robert Byrd’s time in the Senate.
A datetime SQL type has the same upper bound. However, a smalldatetime is only good through June 6, 2079. That’s why our validation code caused errors in the database. I admit it’s been many moons since I used a smalldatetime, and I was surprised to see that they expire so “soon” in relative terms. So if, seven decades from now, you’re around and hearing about the Y2.079K crisis and how it will cause flying cars to fall from the sky, bullet trains to collide at 350 KPH, and Senator Byrd to miscalculate his next earmark, remember that you read it here first. Probably.
If you have any interest in intelligent algorithms Ari Schulman has an article worth reading in the Winter 2009 volume of The new Atlantis. I am not particularly fascinated with what some think of as Artificial Intelligence; I can’t stand the term, to be frank, and hold the acronym in no higher esteem. But I am very fond of algorithms which occasionally seem to be intelligent, particularly as they apply to gaming and game theory. And seeming to be intelligent is, as Schulman reminds us, all the Turing Test requires. Having written a fairly popular backgammon game for Windows back in the early 90’s I have some direct experience of how much easier it is to opine on the idea of decomposing complex thought processes into rules and procedures than to actually do it. In a cogent and well-written tour of the last thirty years of thinking in the field of intelligent programs, Schulman applies his insights about the nature of mind and machine, and comes up with some convincing reasons why a layered, modular, procedural description of intelligence continues to be an ellusive goal.
Mark is a professional programmer and system architect with twenty years of experience in the industry. He works with C, C++, C#, Java, php and other tools to develop complex web-based and client-side applications for Windows and Linux platforms... (more)
