Another Tuesday Morning Zen Moment

Wrangling an older dog and a new puppy has brought a certain form of enlightenment to me. I can express it best as a koan.

Student: Master, what is the sound of one dog barking?
Master: Nothing like the sound of two dogs barking.

Rails, Prototype, Ajax and Forms Walk into a Bar...

Rails is my friend. Prototype is my friend's foreign friend. Ajax is my child-prodigy friend. Forms is my long-time blue-collar friend. Submit buttons are pieces of currency, among many other Internet coins and bills. Recently my friends and I got together at the local web bar to have a beer.

Rails, Prototype and Ajax had been hanging out together lately, and while it seems they knew Forms fairly well, he was kind of old. The other three were younger and getting rich, and so they'd started paying for everyone's drinks. Forms had been buying me beer for a long time, but hadn't had to pull out Submit Buttons very often in their presence since we met the other three. The other day, I asked Forms for a few Submit Buttons to get a beer, but Rails, Prototype and Ajax said they'd take care of it. Forms smiled and said "Fine. Thanks."

I took the Submit Buttons up to the web's bartender, and to my surprise he said they were no good! They were skilled forgeries! They looked like the real thing, but the serial numbers were all the same!

I went back to the table and told my friends. It turns out Rails had suspected they might not be good enough to pass before a scrupulous eye for a few years. Apparently Prototype had been giving them to Rails to help Ajax for a while. Forms pulled out a real Submit Button so I could hold it and the forgery up to the light and compare them.

The deal is that if you use Rails to generate multiple submit buttons on a remote form (ie. for Ajax), regardless of which button is clicked, only the value of the first button is set in the parameters coming into the controller. The issue was documented by Ticket #5031 on Rails-Trac over two years ago. While there was a partial fix put into prototype in 2007, it didn't go far enough to fix the problem.

I played with the prototype code a bit and roughed in a solution, but had an older Firefox on the machine I was using that was incompatible with the latest Firebug. My tests passed, but I was sure they weren't exhaustive. Since I couldn't see what was getting generated under the covers, I didn't trust it enough to use my fix and went back to the web to see what others had done.

I found the solution that I decided to use on Harry's Blog, basically to tuck the value of the submit button that was pressed on an Ajax form into a hidden field. This is done by assigning the onclick of each submit button to some field-setting javascript code. Since this was essentially what I was doing under the covers in the prototype, I was happy.

I sat down and changed the Submit Buttons Rails had given me out of the view of the web bartender. I then gave them to our server who brought me back a nice tall beer. Good times ensued.

I haven't done any wholesale changing on either of my friends Rails' or Prototype's Submit Buttons yet and I hope to avoid it, preferring getting together with my friends in the more comfortable setting of my neighborhood web bar instead of submitting my changes to official scrutiny. For now I'll keep fixing the Submit Buttons locally and just let the officials get to it in their own time.

Time for another beer, eh guys?

Future Science: Augmented Wetware Processor

During a recent hallway conversation a friend and I were considering heads up displays in aircraft and automobiles, and the difficulties in doing the same things with spectacles. A lot of work has already been done in these areas and some remarkable things have been built that add information to the optical channel. Since the signal-processing bandwidth of the eyes is the highest of our senses, projecting information onto the retinas (either indirectly by annotating the "window" we look through or directly by imaging into the eye) seems like the best way to push more immediate knowledge into the brain.

But is it really? I suspect we'll bypass the eyes completely in the future, instead augmenting the brain's wetware directly. After gaining a much deeper understanding of our neural networks and the parallel processing algorithms in our brain, we ought to be able to determine what has our attention moment to moment. Using that as the driving input and factoring in enough context, we should be able to add information to what we are conscious of in real time by stimulating the brain artificially - from within using processors and a wetware interface device. Imagine that whenever you looked at, heard, tasted, smelled, or touched something, you would immediately just "know" all sorts of extra information about the experience as if it was just "there" already, without having had to learn it the hard way, by integrating it a priori through the senses and reasoning.

Abuse by malevolent powers aside, a virtually-connected, immediate-access Wetipedia could extend perception far beyond what any one person would be capable of by themself. There are lots of issues, and science has a long way to go before any of this is possible at the lowest level. But I think it'd be pretty cool.

Mulling and Pondering...

It's happening again.

I'm turning another corner in my software development life only to find myself revisiting some of the same issues I've resolved before. Whenever this happens I learn again that though my instincts were good, the solutions I came up with need to be cleansed of my habits from that time. Interestingly, what comes out of this process is something a little simpler, a little more robust, and a little more consistent. Crisper and cleaner. Which is good, I suppose.

I guess I'm just older and crankier now, and as I look over the things I've built I feel the need to streamline the whole mess and make it hook together better. I guess I just want a more holistic software world when things seem to be getting more disconnected in real life.

Why do things feel more disconnected? Tax day? The price of gas? Stiffness in the joints? Perhaps it's just because I'm older and crankier, and the little pleasures have paled a bit. Or maybe I need a warm sandy beach somewhere for a week or two. I just don't know. But I'm tired of disconnectedness.

So I find myself thinking about simplifying again - hiding details through progressive disclosure and creating seemingly invisible interfaces. But this time I'm thinking harder than I have before. I feel like I need to get this right once and for all. I need that layer of infrastructure that I can live with and not second guess again in seven years.

Damn.

Such is my life, as always.

Cleverness

In some recent writing, I once again was thinking about how I'd get something done. I realized that in this instance it was time for a clever solution rather than something more rigorous or systematic. So I popped out some code that did the job quickly, with a dash of elegance and bravado.

Afterwards, it got me thinking that one of the greatest compliments I've gotten when I've done this sort of thing is that I'd been clever.

• Clever makes me feel good - a very positive rush.
  
  
• Clever is a little added oomph that makes a good solution into a cool solution.
  
  
• Clever has a feeling of fun and wit to it that is missing from it's more boring cousins capable, organized, or methodical.
  
  
• Clever pushes against the ordinary and admits that there's more to life than following a procedure.
  
  
• Clever adds fun to the journey.

There are some who see clever as a negative - it reeks of non-reproducibility and heroic-effort rather than the more dependable repeatable-process and committee-based decision. Yikes! Quite boorish folks if you ask me! Give me the adroit and courageous over that hesitant ilk any day!

Clever Rocks!

TechnoSmiles

Suddenly, from the depths of your mind, up bubbles a childhood memory... a snippet of a song lyric - just a few words and a fragment of a tune. An online search, a glance at few entries to get the name of the song, a buzz over to a music repository, and a double click. Thirty-five years melt away as you listen.

We live in the best of times: we still have the mysteries of the past, but now we have the means to solve them at our fingertips.

Life is good.

MetaThought

Curiously, I find myself being driven to devise common ways to abstract context in my infrastructures. Initially it was an afterthough, but now it's become a metathought, becoming an approach rather than an artifact. I'm wondering now if it has more to do with the problems I'm working on or the way I'm going about coding their solutions. How far can abstracting context go?

From a practical perspective, I've been busy lately building infrastructural facilities to support other efforts. At night, when I work on my own stuff, I'm metaprogramming at subterranean levels while juggling multiple contextual onions. I contrast that with the day job where the focus is always on end-product - add a feature here, a page there, connect to a database and do choreographed crud. Both are satisfying, but the depth, issues and complexity are entirely different.

Perhaps what I'm seeing now is just a sort of transcendence of style. Instead of writing context-free code in a specific domain, I'm writing context-abstracted code for use in multiple domains. Pushing away from specific problems, I find context can be wrapped up in a small packages and examined or re-established as needed. It's like I'm stepping outside, standing away and looking in. But it's more than a simple inversion. I really am thinking of context as an abstraction, as though from the point of view of an infrastructural component. And I'm finding that this perspective has tremendous simplifying power.

It's still fuzzy. I haven't yet stood far enough away. I think I've only glimpsed at what a generalized context object needs to contain and do. But I really want it.

Understands and Groks in Ruby

When I fashioned an approximately_equals method for Numeric in Ruby, I missed something. I want to not get epsilon (the maximum difference to still be considered equal) from Numeric if a different epsilon can be found in a derived class closer to the instance on the inheritence chain. While I'm probably going to do this through an include, it did turn me on to a chain of mail that was talking about the use of include at the instance versus the class level in Ruby.

The main point of the discussion wasn't centered around it's value - it is clear that it would be great to be able to mixin at the class level as well as the at instance level. The main point is what to call it. I'll go on the record - I don't like "include", the method name that mixes a Module's instance methods into the includer. And though there were many suggestions for class-and-instance-level inclusion, most didn't connote the intention or were syntactically cryptic.

What I already have done with "include" is this: in a centrally required class, I alias it to "understands". My rationale is, if Module Foo is included in Class Bar, the instances of Bar understand Foo - they can do what Foo has defined. In my 3D classes, for instance, I now say:

class Point3
  understands ThreeDimensions
end

and it knows all sorts of things about the 3D world.

Once I finally really need it and take the time to do a little metaprogramming (or if it finally comes out as a Ruby 2 feature and I get it for free) I'm going to do the same thing for the class level. But I'll call it "groks", which connotes a deeper understanding than "understands". When Class Foo groks Module Bar, The Foo Class can do what Bar defines.

Grok belongs to Robert A. Heinlein, from his book "Stranger in a Strange Land". Its a made-up word that means "to drink". The usage goes further though, to the concept of "more than understanding", a capture of essence, a blending into identity - which is exactly what mixing in at the class level is all about to me.

Closer to Yottabytes!

In "Digital Data will Increase Sixfold by 2010" (http://www.channelregister.co.uk/2007/03/08/digital_data_explosion), O'Brien claims that it is suggested 988 Billion Megabytes - almost one Zettabyte - will be in play by the end of the decade. Of course, much of this data won't be unique, but that's still an awful lot of ones and zeros.

I'm wondering how long it'll be before we have a million times the 2010 amount - a thousand Yottabytes. Yotta is currently as far as the prefix numbering system officially goes...

More People Everyday...

Wow. When I was back in grade school, the population statistics I remember were that the US population was 250 million, and the world population was 4 billion. Big numbers, and I thought, if I could just get everyone to send me a dollar...

Ah, the dreams of youth.

A quick trip to the population clocks at http://www.census.gov/main/www/popclock.html took me by surprise. The US population has just recently climbed over 300 million and the world population is up to over 6.5 billion. Simply amazing. 20% and 60% growth respectively.

I suppose that it's good to keep track of this stuff, if just for the sake of scale. There really are quite a lot of people out there.

Moment of Artificial Wonder

Nature keeps time, but doesn't bother about counting. People do like to count however. Especially us math geeks.

A close friend of mine (who's also fascinated by numbers) pointed out to me yesterday that early this morning, at one hour, two minutes and three seconds after midnight - and noon if you go by a twelve-hour clock - the time and date was officially

  01:02:03 4/5/06

Perhaps an uneventful moment, but one that only happens once (or twice on the 12-hour clock) each century. Of course there are some other notable moments upcoming,

  02:03:04 5/6/07
  03:04:05 6/7/08
  04:05:06 7/8/09
  05:06:07 8/9/10
  06:07:08 9/10/11
  07:08:09 10/11/12
  08:09:10 11/12/13
  09:10:11 12/13/14

which is as far as that goes if you're on a 12 month calendar. But the biggest one will be coming soon...

  12:34:56 7/8/09

That'll be two (or four) magic moments on July 8, 2009. Sounds to me like another good reason to have a drink with a math friend. Thanks Ann!

... name of my dog

When I got married for the second time, I inherited a dog. A good fellow named Mickey, with a keen nose and ear, keeping us safe from all the things that go bump in the night with a bark that can wake one from even the soundest sleep. He marks his spacious territory that is my yard with considerable regularity and consistency, something that, because of polite society, requires my out-of-doors janitorial efforts with commensurate regularity and consistency. However, his greatest skill is his never-ending search for sustenance - if even a tiny morsel is dropped onto the floor, it is swallowed up in moments. He gives us no time at all to exercise the five-second rule.

If I had to rename him thirty years ago, I'd have gone with Hoover. Today, I think he'd be called Dyson. Times clearly do change.

Realized Calling

I don't remember when it started, but for more than thirty-five years I've been an author. Whether it's software, articles, fiction, commentary, music, painting, sculpture, documentation, woodworking, architecture, drawing, email, or even blog entries, I've spent the majority of my waking hours authoring in different mediums. The purpose of what I author are myriad. I've spent a lot of time with my head in books, going to conferences and lectures, and since the web appeared, researching by browse and search. I constantly cross-fertilize original ideas with what I learn from others and put down my thoughts, relentlessly. I don't know why, but upon introspection, that is what I do.

Looking back over more than three-quarters of my life, I see now that what I produce is all the same type of stuff. Sure, the engineer in me does math, the artist in me draws and sculpts, the writer in me types, but it's all effectively authoring. Some of the work I do for others, some for myself, but all with the passion of starting with a clean sheet and making something new. Though I've never really put myself in the category of an author, examining what I've really been doing has now defined me.

As I sit in front of my keyboard and look around at bookcases full of other's works, listening to music others have composed, being drawn into the painings other have made, and photographs others have taken, I'm humbled. I'm certainly not a great author, but I do feel a kinship of sorts with these folks.

I've truly become what I've eaten, and my appetite has grown more ravenous through the years. For better or for worse, I am what I am. The revelation is exciting and it stirs me. Though I don't know what's next, I am happy to have finally lifted the edge of the veil and seen more about myself. I am Dave, an author.

MetaThought

Missing-Method Exception Handling in Dynamic Object-Oriented Systems

or...

Can Good Congruence Processing Work Outside of an Intelligent Mind?

It's funny. You're talking with someone and they throw things out at you, and you've never heard about what they're saying, but it all starts to seem like something else you have experience with. It fits into familiar patterns - it seems close to something you know about - it is congruent to a known. As you consider everything more closely, you think about it within the familiar context. You're able to make conjectures and draw conclusions. Though they might be right or wrong, your brain didn't crash when it encountered the unknown - like most software would. It dynamically came up with a way to recover.

In a statically-compiled object-oriented system, a target object's methods are called by other objects. The target usually responds to the method by doing some work, possibly changing its state or calling methods on other objects, and then possibly returning a value. If the method being called doesn't exist in the target, this is caught by the compiler and an error is signalled. Typically, an executable program will not be generated until this problem has been corrected. The system is relatively brittle, with little room for processing the unknown.

In a dynamic object-oriented system, any method can be called on any object - a much less brittle mechanism. The fun starts when the method being called on a target object doesn't exist and a runtime exception is raised that the program can try to handle and recover from. This missing-method exception handling can do whatever it needs to do to try to take corrective action, or fail in trying and stop the processing of the method, or perhaps halt the entire program.

While it is simplistic to equate the brain's forgiving wetware processing with the step-by-step execution of a dynamic program on silicon, perhaps a parallel to the missing-method exception can be drawn between them. The brain seems to try to integrate the questionable through congruence and analogy, recovering from missing information by trying to transform it into something known. This seems to be able to happen at many levels at once. Of course, if a fit can't be found you might get a "What the heck are you talking about?" (or its equivalent). But experienced, intelligent minds tend to be very fluid, able to map unknowns onto knowns with ease, even with only a partial fit. And thinking continues.

Pulling back to dynamic object-oriented systems, when a missing-method exception occurs, can something similar be done? Is it possible to use congruence to build good recovery into these systems with just a small amount of programming, and still get reasonable results? How can congruence mapping be done to help recover from a missing-method exception? What clues can be added to a system that could be used to form congruences? How can the the system determine that a congruence doesn't fit well enough and it's time to try another, or just give up?

I don't know... yet. But I'm thinking congruently about it.

Not as much as I wanted, but better than nothing...

Well, these days I keep asking for an extra few hours a day as a Christmas present. The extra time would let me get ahead of all the extra stuff that seems to appear out of nowhere onto my schedule.

I guess Santa was listening a little. A leap second was added to the calendar yesterday - the first in the new millenium. I thought things had started to feel just a tad out of sync for the last few years.

Anyway, though it's not much, I'll take all I can get.

Upcoming Blue Moons

While not an officially recognized star-gazer or anything, I have always been enamored by celestial events. I enjoy being humbled by the unceasing regularity of the heavens. It reminds me not to take things so seriously, since there are some things out there that won't change no matter how great my successes, how frustrated I get or how badly I screw up. Anytime is a good time for us to have a laugh when we know that there are larger systems that continue to work irrespective of the success or failure of our most intense plans. It doesn't mean you should stop striving for greatness, but it does mean that the weight of the world is not ever solely on your own shoulders.

This all is especially apparent when our artificial systems, such as the calendar in this case, bump up against nature's own grand clockwork. Take the Blue Moon for instance. When two full moons occur in the same month, the second is called a Blue Moon. It's really nothing special astronomically, but we take note because its a rarity when measured against our all-important life-driving wall clocks.

The Blue Moon dates for the next 25 years are:

June 30, 2007		December 31, 2009
August 31, 2012		July 31, 2015
January 31, 2018		March 31, 2018
October 31, 2020		August 31,2023
May 31, 2026		December 31, 2028

I recommend that especially on these Blue Moon days, we all pause, step back, and take a good look at what we're doing. We should smile, remembering that whatever vitally important things we do, while incredibly relevant to us, are of no real consequence to the universe at large.

Sometimes true happiness can be all in how you look at things.

A Question of Balance

As I write more Ruby, thoughts of what should go where have occurred to me. While having monolithic packages take the load off package users, the question of performance penalties arise. If everything is loaded up front when a simple require is done, a full package monolithm may take more time to load than that required when just a simple piece of functionality is needed.

I'm thinking that a nice runtime feature to develop would be to include a "require-manifest" array (or tree perhaps) in a package base class that would be used in case missing methods were encountered. If a method was missing, the manifest could be used and additional requires would be sent, and then the offending method could be resent. If the method was still missing, additional action could be taken.

This strategy would effectively lazy-load class extentions automatically as needed, removing startup performance penalties for applications, time-shifting the load to when a set of advanced features is used. For simple applications that do not use the extended features, the time could be eliminated completely. It does require a bit of planning ahead, building and maintaining the require-manifest structure, but perhaps this could be done by a packaging script...

Of course, this would not prohibit the direct loading of a specific package nor calling the method to load entire manifest at startup, if desired.