Naming Conventions for Data Objects

January 25, 2009

One of the things that was at once striking to me about David H’s description of the Ruby on Rails recipe, in the book Agile Development with Rails, was his headfirst launch into the data object naming conventions. They were as follows (this is not complete. For a more complete list, see : http://rails.raaum.org/database-conventions.html ) :

1) Database table names are always to be plural – This reminds me of a project a number of years ago, when the database was being reorganized. Well, they had decided to name everything in the singular. Their thinking was, it is obvious that a table named USER would contain users, a table named ORDER would contain orders, and a table named LANGUAGE would contain languages. It was soon discovered, however, that all of these were reserved words in the RDBMS system we were switching to. The solution was to add a character at the end of the name. So, ORDER became ORDERR and USER became USERR, and so on. The simplicity of just using plural for the table names struck me as something to lean towards in most RDBMS environments.

2) Primary Identity Fields will be named id. I’ve seen many cases where the identity field is named like a foreign key would be. That has advantages, like when the field names are matched exactly, as some tools will do. But  there is nothing wrong with just “id” for the field name, and it is clear what this means.

3) Foreign Key fields will be named (singular table name ) + “_” + “id”

At a certain point, it becomes clear that the rules are in place to assist automatic generation of various pieces of the Rails framework. By simplifying the components and requiring them to adhere to strict naming rules, the framework is able to maximize its power while minimizing complexity. The human user of the framework is admonished to conform to strict guidelines, to enjoy the large benefit.

  These “strict guidelines” (there’s an oxymoron for you), are in support of the concept of favoring “convention over configuration.”  By clearly stating the assumptions and defaults of the underlying framework, the designers have eliminated the need for configuration files which would spell out the exact same details.  Most software development teams would opt to leave the defaults in the first place, making all of the configuration work basically wasted effort.  By adopting convention, and eliminating a large chunk of configuration time, a real quantifiable savings can be immediately realized.

Often, I am lamenting the lost opportunities in computing systems, for real accommodation of the user. I find myself in situations where I have to repeat my phone number to computer systems on the phone, when a network of connected systems should “remember” my phone number, and even pass it on to the agent at the destination of my call. All of that made even more laughable given the fact that we do not block caller id, so the called party has access to my phone number by default, and should not have to ask for it in the first place.  It should simply ask if the number I am calling from is the number associated with the account.

  I was installing a printer on my computer, and operating systems said it recognized a Networked HP 2610 and asked if I would like to use it. I said yes, or clicked yes, as the case may be. Then, on the next screen, I was asked to select a driver. And not just from HP drivers, but from a large assortment of possibilities. HP wasn’t even the default.

So, it leads me to think that perhaps, as I have seen before, there was simply not enough time to address all the issues at the end of the line. The software had to be shipped and besides, we have “online updates” now anyway, so it doesn’t have to be 100%. The engineers probably wanted to take care of these last details, but were pulled off onto another project, and a new team was brought in for support and post release development. Did they plan for this from the beginning? The project managers, I mean. Or did time escape them, as it does so many of us?

Is it possible that they spent a lot of time at the beginning of the project, trying to sort out naming conventions for their data objects, or untangling legacy integrations?  Or editing configuration files for frameworks?  Or, automating things a little bit, by generating the configuration files?  (Even with automation, these things take time to do).  Is it possible that the manager, not being able to read code, did not understand the significance of the efforts under the hood, and was anxious for results he/she could “see”, and cut these efforts short?  Is it possible that with some of the up front efforts out of the way, the underlying engine of the project basically together, that the focus could be returned to the customer, and better managing workflow related tasks?

I, for one, would join the chorus of those who point out the significance of the approach used by David H. in the Rails framework, rather than the specific language he utilized.  That said, isn’t the language itself a convention, and the act of using a different language, a sort of configuration?  Food for thought.

Advertisements

For Historical Reasons, Opcode Value 186 is not Used.

July 20, 2007

I run across obscure references from time to time, and they have a tendency to stick in my mind, like part of a pattern that needs to be matched.  As perfect as an abstraction as mathematics may appear to some, it carries its own set of special cases and exceptions.  We assume that these are naturally occurring and just accept them at face value.  It is not very useful to try to figure out why Pi is not a round number.  It is what it is.

  The domain of computer languages and software carries its own set of special cases and exceptions, but often these are the result of human conditions.  And in carrying out whatever pursuits we are engaged in, they are accepted and we say “it is what it is.”  Following is a brief catalog of numbers, mostly with a computer related historical description, but some with related cultural references:

186  (oxBA)-Java opcode which was not used in the first Java virtual machine, for historical reasons.

3:16 – Lecture and Book by Don Knuth, author of the Art of Computer Programming.

0xCAFEBABE – Magic number which appears at the start of every Java class file (bytecode).  Note the presence of 0xBA in 0xCAFEBABE, in the third byte position.

0xCAFEDEAD – Rumored to be the originally desired magic number for Java class files, as the developers were fans of the Grateful Dead. It had already been used for other things, so CafeBabe was used instead.  Note that Java 1.0 was released January 23, 1996, 167 days after the death of Grateful Dead guitarist Jerry Garcia.

0x504B – Magic number at the begining of every ZIP format file.  These are the hex codes for ASCII characters ‘PK’ initials of  Phil Katz, the author of the original zip compression program.

0x4D5A – Magic number at the beginnng of every DOS executable program.  These are the hex codes for ASCII characters ‘MZ’, initials of the developer of the file format, Mark Zbikowski.

8675309 – Seen in many, many more oscure contexts for computing.  From unlock codes for games, to causing a mode change for Microsoft’s WebTV, and various others.  This was Jenny’s Phone Number, in the hit song by Tommy Tutone.

420 – A cultural reference to cannibas. 

404 – Page Not Found Error Code in HTML

2600 – The frequency originally used by AT&T to signal a ready state for a long distance phone line.  Also the same frequency which was produced by a toy whistle which was given as a toy surprise in Captain Crunch Cereal in the mid 1960’s.  As an added curiosity, to no one except for myself, I happen to have the home printer, HP Photosmart 2600.

90125 – The original catalog number of the Yes album, by the same name.

9:15 – Time of the train referenced in The Who’s Quadraphenia in the song by the same name.

90210 – The zip code for a Bevery Hills neighborhood in which a popular 1990’s tv series was based.

The appearance of numbers and codes like those listed is frequent.  The presence of codes and oddities in the digital domain offer an endless supply of curiosities.  The crossing of domains has become more and more commonplace as computers and digital electronics settle into their place in our culture.  Phone numbers become song titles, and song titles become codes in computer file formats, and will continue to do so.  And most of the time, “they are what they are.”


Object Proxy (cont)

June 8, 2007

I ran across the topic again, and again this week, and I haven’t even been working in Flex.  It’s been all Java this week.  I was cruising through the blogs of the European Union, and found this comment:

“Yep already… I fixed the annoying “Lazy Loading”-issue. I found a little hack and it goes something this:

  1. Store openDuration and closeDuration;
  2. Set openDuration and closeDuration to 0;
  3. Call open and close methods;
  4. Restore openDuration and closeDuration;
  5. TADA… lazy loading be gone….. “

http://labs.flexcoders.nl/?cat=3

Is it possible that the standard use of Delayed Instantiation of Objects, is emerging as an Anti-Pattern, as programmers worldwide come up with various solutions and workarounds to make the objects behave as procedural Objects would?

And at the same time, other programmers are adding additional Proxy wrappers, to achieve the effect they need.  Utilizing the Double Proxy Pattern, the first access to the object would release the inner proxy, and fire off a request to fill in the proxy with “real” data.  Hopefully, by the next time the object is accessed, it will be populated.  This is related to the re-wrapping with ObjectProxy which I have seen.

——

  Earler this week, a colleague was putting together a dashboard application view, and had a coldfusion remote service all wired up in ColdSpring, and was at the point of getting the data back in the ResultEvent of the Service Delegate, and was getting strange results.  The ResultEvent.result was an ObjectProxy, or nothing.  He was not getting a list of data for his view to bind to.  He was returning an array of some type, but the remote object declared it was returning type “any”.  Well, when we fired up Charles, and looked at the AMF result coming from the Coldfusion server, the type was a custom coldfusion recordset.  So, he changed the declaration of the return type to “Array”, and lo and behold, while observing in Charles, we saw that the  AMF return type was ArrayCollection.  And the rest of his code worked, and the dashboard element filled up, because the data was in a format that Flex recognized.  I don’t know exactly what this tells me, except that the return type declaration in Coldfusion is important.  As is the RemoteObject type meta tag in the Flex Value Object declaration.

  He did not try another test, wrapping the result in ObjectProxy to see if that would have taken care of the problem.  I don’t know that it would *solve* it, but it would probably yield different results.

  And then I am reminded of this post:

“Accessing proxied object

Under some circumstances Flex wraps object with special mx.utils.ObjectProxy wrapper class. Documentation describes special object_proxy “object” property containing reference to real object. But accessing this property at runtime always returns “null”, althought this property is visible in debuger watch window with “package” icon. Code below demonstrates the problem, and shows “Real object: null” message:

 import mx.utils.ObjectProxy;
 import mx.controls.Alert;
 …
 var o1:Object = { f1:”aaa”, f2:123 };
 var o2:Object = new ObjectProxy(o1);
 var o3:Object = ObjectProxy(o2).object;
 Alert.show(“Real object: “+o3);
Matt Chotin pointed me to the solution. It’s special namespaced property and need in special code handling. So updated example listed below:

 import mx.utils.ObjectProxy;
 import mx.utils.object_proxy;
 import mx.controls.Alert;
 …
 var o1:Object = { f1:”aaa”, f2:123 };
 var o2:Object = new ObjectProxy(o1);
 var o3:Object = ObjectProxy(o2).object_proxy::object;
 Alert.show(“Real object: “+o3);”

from http://www.docsultant.com/site2/articles/flex_internals.html

(to be continued)


When to Use ColdSpring: one example

June 4, 2007

  I have conversations with people I work with, regarding the pros and cons of employing a framework like Coldspring.  Well, ColdSpring in particular, actually.  While explanations of its benefits have been present, there has lacked a concrete example that I could share with with my coworkers and comrades.  The benefits realized from loose coupling of objects have been demonstrated, and ColdSpring is a way of moving toward that end, but that is fairly abstract.  Also, as trends in OOP have moved away from inheritance and have leaned toward composition, the process of decorating or injecting the objects in this model, is also worthy as part of a prevalent approach, but it remains too abstract.  The notion of logging, or security, or changing the DSN does not get people too excited about putting ColdSpring into place.  Instead, Coldspring could be the source of a whole new batch of problems without even giving any benefits in return.  And the notion that everyone is doing it, brings requests for a new glass of Kool-Aid. 

A ColdSpring Example Transaction  A real example that can be seen by our organization comes with the wave of demand for Dashboard enabled applications with analytics, and metrics that could never be satisfied.  (I will lay aside for this writing, my thoughts and concerns on Dashboards, and the dangers of their overuse).  So, in this perhaps hypothetical situation, we have a customer who uses our eCommerce application, and decides that he wants some real time metrics, of things which do not neatly fall into one table or another, and might require some data consolidation, or something, to pull what he wants to see.  Let’s say he wants to know what aisle of the store people spend the most time in (category), and of those, how many buy product.  For people that hang out in category A, how often are their carts abandoned.  Do people get lost in aisle A?  Questions like that bubble through the storeowner’s head, and he pictures a dashboard, with a realtime visualization as solving the problem.  Now, it could have been anything.  We don’t track which aisle people are in, only what they put in their basket.  And we don’t pair that with the cross sells.  How can we get the data that he wants without making huge changes?

   The important thing to note is this:  The huge changes that need to be made to facilitate this customer’s desires do *not* benefit the shopping workflow at all.  They are a separate concern.  A possible solution, with ColdSpring, would be to introduce an AfterAdvice, which would feed the desired data into a log, which would be fed to the dashboard, and so on.  So, this could be done without any major impact on the workflow code itself.  This is huge.  This could have made the shopping cart code just a little bit more complicated.  Instead, it has left it alone.

  In some ways, having programming in database scripts, Oracle PL/SQL procedures and triggers, this dependency injection is not so different.  It is just happening at a different layer in the process.  In fact, I had thought of using database triggers, at first.  It took a little while to realize that this would be a decent situation for using ColdSpring, and realizing some tangible benefit from it.

  Now, with a concrete example in front of me, I can think of another situation, which again, could have been dealt with using database triggers, that could benefit from this architecture.  Stepping back, I think that will continue to be the case.  The immediate solution that jumps out in response to the problems that ColdSpring addresses could often be taken care of with the application.cfc (security), or by the RDMS (logging).  Caching goes in the middle there somewhere, in certain situations, but even that for some situations, has solutions easily employed at different layers.  So, part of the difficulty is beyond the abstraction, and in the realm of problems which we have already solved in one way or another.  And while that may be so, as customer demands shift, we must at least be prepared to shift our strategies and solutions to problems.


On the Taxenomy of Ducks

May 27, 2007

On the Taxenomy of Ducks:

Using Object Inrospection and Reflection to Manage Systems Integrity

          When I was 12, my brother and sister and I spent a week in Seatle, visiting my grandparents during winter breaker.  On the Tuesday of our visit, my grandmother had her bridge club over, and my grandfather was out taking care of some holiday shopping, so my siblings and I were left to entertain ourselves for a few hours.  It was was raining outside, so my sister decided she would read a book.  My brother wanted to play a game (I was hoping we would play chess).  So, he went to grandmothers game closet, and pulled out a box, handed it to me and asked me to set it up, so we could play a game.  The box was labelled Chess, and had pictures of a chess board and chess pieces on the outside, so I was excited to play a game of chess.  I opened up the box, and began to set up the board pieces, and I found that a few pawns were missing.  I could have just told my brother we could not play, as there were pieces missing.  I could have gone and interrupted grandmother’s bridge game, to ask her if she knew where the missing pieces were.  But I found some dice laying on the table, so I substituted the dice for the missing pawns, so we could play a game, and asked my brother “Okay, white or black?”
Rabbit Or Duck
           The roles and responsibilities and expectations of objects in software systems are subject to the requirements, methods and organization of the system architect, and the engineering team lead.  How objects handle their input objects is an age old problem, and with the introduction of distributed systems, the shapes and sizes of input objects can suffer from their own contraints.  An object needs to have a way of behaving when it is handed an object for processing, and the first thing it needs to do is inspect the input.  If the input is not what it requires, then it needs to either handle that somehow, or throw an error.  Or maybe he doesn’t want to deal with it at all and “fixes” it by making the error message go away….
try {
  functionthatgivesmeanerror();
} catch(e:Error)
{
  //do nothing - let someone else deal with it.
}

          This principle of software development has become topical because of the fairly recent adoption of a practice dubbed “Duck Typing” by some, popular in ColdFusion and Ruby development circles.  So, what is “Duck Typing” and why does it raise discussion around object behavior?         

          In software languages like C++ and Java, objects are classified by types, which define specifically what properties they have, and what methods are available.  When the C++ or Java code is compiled, the compiler checks to ensure that the inputs to object methods are of the expected types, and if not, a compiler error is thrown.  In interpreted systems, like Ruby, or JIT compiled systems like ColdFusion, the types are checked at runtime JIT compile time.  If the objects are strongly typed, an error is thrown.  This is much like my brother handing me the box from the game closet.  If the box was not labelled Chess, I could have objected and handed it back to my brother.

          The practice of “Duck Typing” is to abandon this practice, and let the called object deal with whatever object it is handed.  I have heard it told to me that "If it looks like a Duck, and it Quacks like a Duck, then it is probably a Duck"  So, in other words, if it is the object has a radius parameter, then it is probably a circle.  In practical terms, this is a shift of responsibilities from the caller, software environment or compiler, to the called object.  The objection to “Duck Typing” is that often this means a shift of responsibility to quality control, the bug tracking team, customer service and the project manager who is left explaining why their enterprise web system is crashing, and the development team is having difficulty tracking the bugs.  What has not been clarified in some team development environments, is that there has been a shift in responsibility.  Someone has to pick up the slack.  It is left to the called object to be more diligent in checking it’s input, and more flexible in how it handles the input.  Like, when I discovered there were pieces missing from the chess set, and I made a couple of pawns out of dice, the team needs to be clear on what the object has the authority to do, to perform its function.       Communication needs to be of the highest order in cases like this, where repsonsibility is shifted to the worker classes.  Once it is clear what the developers are being handed, there are a few strategies which need to be embraced when the protective tools of compile and runtime type checking are no longer there, because in the end, the software needs to work. There is ad hoc internal type checking, which can be set up with a simple tag, or an extra parameter on an object, which signifies the class.  There is an inventory process which an object can run on acceptance or rejection of a call.  The inventory is a matter of running through an object’s properties, like a checklist, to see if this is here, if that is there, etc., to make sure its properties match to what is expected.  The reflection API can accomodate this, as well.    If you are using Duck typing in a project, make sure to build type variance into your unit tests.  Better that the unit tests blow up than your codeline… or the customer.    What is the reason for this interest in a methodology?  Where’d the Ducks come from?  Well, when the girls start screaming, look for the rock star.  Quiz Time:  Is it David Hasselhoff or David Heinemeier Hannson?  Well, the DRY principal employeed in Ruby on Rails, says that the interface (required behavior) leads to repetition.  (DRY = Don’t repeat yourself… so repeating, bad).   Dave Thomas and Andy Hunt (Pragmatic Programmers)  These guys are incredible.  They advocate pushing Ruby on your business, with the tactics of Scientologists on a three day weekend.  Well, that was then.  Now, they are pushing Erlang (saying it’s today’s Ruby).  Give me a break.

     There is some merit, however, in the argument that the behavior of an object should in some cases define what it was, and so, having a type would be redundant.  And, given suffiently compelling context, I’d give it a whirl.  However, the situations a contractor is placed in are often a little less predictable than the cozy intellectual Oasis of Object Orient land.  There is a large installed base of non OO scripting methodologies, and relational databases, which aren’t going to step aside and make way for new practices.  Same goes for the installed base of employees.

     So, while not denouncing the practice of Duck Typing completely, I would question the argument for its adoption simply on the basis that it has one aspect of DRY, so it will lead to some future benefit.  In every single case, where a change is made, I have to ask myself How much is this going to cost? and What business benefit are we going to derive?  You *cannot* simply remove a solution from its context, and then advise for it.  If you remove it so far as to remove it from the problem, then the solution looks for a problem, any problem, to take its place.

     Sean Corfield expressed concern that people seemed to miss the point of his talk, when they talked only of the performance boost of using Duck Typing.  Removed from even a contrived context, how would anyone think any differently?  You can lead a duck to water but you can’t make him…. (okay, a metaphor mix in was called for)

   As a quick disclaimer, I should say that I am passionate about patterns, enthusiastic about object oriented methodologies and applications which can really drive efficiency and creativity.  While this is so, I witness many people who simply do not understand the underlying pricipals, but think they do.  It’s okay to not understand.   The concepts are not at all down to earth… they are abstract.  But for the people who think they understand the principals and try to drive an implementation with complete disregard to tried and true principals and practices of Unit testing, communication, and so on, … and without any support from a return on investment standpoint, let me say, these people are dangerous to software projects.

     I will continue this (rant?) and tell how the chess game turned out in a later post  (continued….)


ObjectProxy in Flex 2

May 18, 2007

ObjectProxy in Flex 2 (continued) I went over the problem of the null responder, and a solution, in the last discussion of Delayed Instantiation. This deserves a deeper look because it is a frequently misunderstood and misapplied area of the Flex framework. Fortunately, Adobe provides the source code for ObjectProxy, and it can be found in the Flex SDK under [Flex SDK Folder]’frameworks’source’mx’utils’ObjectProxy.as. I’ll dig into one particular area, the getter function, as that was what was in doubt in the example.



 
/** * Returns the specified property value of the proxied object. 
** @param name Typically a string containing the name of the property, 
* or possibly a QName where the property name is found by 
* inspecting the localName property. 
* * @return The value of the property. 
* In some instances this value may be an instance of 
* ObjectProxy. 
*/ 
override flash_proxy function getProperty(name:*):* { // if we have a data proxy for this then 
   var result:Object = null; 
   if (notifiers[name.toString()]) return notifiers[name]; 
    result = _item[name]; 
    if (result) { 
       if (_proxyLevel == 0 || ObjectUtil.isSimple(result)) 
           { return result; } 
             else 
           { result = object_proxy::getComplexProperty(name, result); } 
// if we are proxying } 
  return result; 
} 



In the traditional use of the Virtual Proxy, the caller is requesting the value of some property. The only way to access this property is through the accessor interface, or the getter, which is what is listed above. Now, the getter does not simply return the private value and be done with it. It can do several things. In this case, it does the following: 1) Check to see if we are waiting for a response on this item (from the notifiers). If so, pass back a reference to the notifier. 2) Get the indexed item, and if it is a simple object (a Number, say) or if the _proxyLevel is 0, just return the object 3) Otherwise, send back a proxy to the complex object The caller is never sure what he is going to get, and has to work with the interfaces presented to him. In the first use case, where the Notifier is returned, is this what we see when we are givge, en the null error, as in the last article? Or is this a different case altogether? Now, you think, it would be really handy if I could introspect the proxy to see if it is the real object, or if it is a notifier or proxy. But it would also be the exact opposite of what the design pattern was supposed to encourage, thus reducing the solution’s overall effectiveness, and lowering the measure of loose coupling between those layers. As soon as you start digging inside of the object to find out stuff (not during debug, I am talking about realtime deep uinstrospecting to gain knowledge about the state of an object when it was intended to be encapsulated. This is a good time to go ahead and trace through a test case with the debugger, to see what is going on. Why is there a delay in that object’s instantiation, and why do we get a null error? What are the mechanics of what is going on? What is the proper way to handle these objects with care, to avoid producing that error. And finally, if there is an inherent problem with the architecture, how could it be fixed, so that a deeper look would not be necessary? (continued) Here’s another solution I have seen applied, which eliminates the errors, but we still haven’t fully clarified the root cause yet.:

public function result( event : Object ) : void
{
   trace("myCairngormCommand.result()");
   var resultEvent:ResultEvent = ResultEvent(event); 

   var result:ArrayCollection = resultEvent.result as ArrayCollection;
    for (var i:String in result) 
    { result[i] = new ObjectProxy(result[i]);}
    ModelLocator.getInstance().myArray = result;
} 

This looks suspiciously like the code in the previous post, in the framework itself. So, this move compensates for something the framework is not handling for some reason. That is, the result is not being wrapped in a Proxy because of the type of variable the result is being assigned to. So, the return code is doing what the framework would have done, wrapping it in a Proxy, so the Proxy will handle peeking at the contents to see if it’s ready. More can be gleaned from the documentation on RemoteObject, and the ways to handle the results and bindings. The best results seem to come from letting the bindings do the hard work, and to not beat the framework into submission with multiple type casts, and extraneous events. But, sometimes, this seems to be all you can do to make it go… (to be continued)


Hooked on a Railing

May 15, 2007

David Heinemeier HanssonHooked on a Railing
Reviewing recent history (last three or four years) I acknowledge that David Heinemeier Hansson is a rock star, and not to be confused with David Hasselhoff. While Mr. Hasselhoff’s gifts to the world have included ending communism in Europe,and blessing us with this little musical gem (see video below), Heinemeier Hansson is no more hooked on a Railing, than he is focussed on the future, and helping to shape it in a very D.R.Y. way.  (For the uninitiated, David Heinemeier Hansson is the creator of the influential Ruby on Rails framework.  D.R.Y. is one of the motto’s of his Agile framework : Don’t repeat yourself).David (”The Hoff”) Hasselhoff
But the two David’s do share a common influence, inspiring thousands of would be, could’ve been, and other sufferers of a vague inferiority when in the presence, of one of the David’s. Once the malady has been diagnosed, it is far too late to help. When the 40 year old comes home with his shirt unbuttoned down to his beer belly, lifts his sunglasses to peek over the windshield of his GTO convertable, and sighs with satisfaction at a sideways glance into the rearview mirror, everyone knows to keep a solid distance, or to risk being assaulted by more manliness than you can fit in a can. Delivered with that sublime sensitivity only the Hoff could deliver (and right over the Iron Curtain, too!)

Night’s shadow does not draw a deep enough curtain to conceal the irrational exuberance of ambitious projects started on sourceforge, often with great promise, but lacking in that one key element which turns a brainstorm of well groomed linguistic marvels, into revision 1.01. The tabloid bloggers, eager to drop a name, or shout out the programming paradigm particular to patterns and practices in Python, Ruby, or OCaml, rush to lift up each new “framework” which is presented, and decree that it is adorned with those favorable qualities of the day. A sprinkling of buzz phrases in sketchbook of unfinished ideas, a mention of Scaffolding, or Lazy Evaluation, or principles of REST, or Object Relational Mapping, brought out and paraded before the willing, drive an embarrassed sigh, and a few muffled chortles, from gawkers and standers by. It was supposed to mean something at some point in its development, but was utterly lost in the circumstance, schedule and the sense that it lacked that Quality of David (QoD), that some would understand. Each vocal group after Ruby on Rails, Groovy on Grails, ColdFusion on Wheels, Gypsy Lispers on skateboards, thinks they’re bringing the Esperanto of computer languages to the table. But William Shatner never got the memo that he was to be your spokeperson.

2005, David was ordained Hacker of the Year, by Google. That carries more prestige than being knighted by the Queen of England, in some people’s books. And the rock star elite are vaguely aware that they have drawn onlookers, and groupees, and Iwasthere’s, and hopers for the startup which makes billions, and mostly curious people who wonder, what it might be like. Hacker of the Year, not Corporate Evangelist, which is more common than a PHP Programmer these days, the title worn and bruised, the position carrying as much weight as a marketing director, but it beats having to wear a funny hat.

Standing from up in the bleachers, I can see, a plethora of programming languages, frameworks, ontologies, most of them being a halfhearted attempt to imitate what their creators don’t understand. And so there is always so much rubbish, but it is so hard to tell while the game is on and the lights are bright. Once the game has been played, and the locker rooms have cleared, it will be the rubbish that is blown aimlessly over the field of dreams, and the self deluded who have wandered into another romance with their own image. It’s a distraction, an amusement, and a little sad, all at the same time. Occasionally, I feel like I should lean over a railing.

The burst of creativity, regardless of how misguided it is, in some cases, is reminescent of the old days of the late 1990’s. The winners and the successes and the shared glory of all of humankind will be the headlines we remember. Creativity and innovation can be messy, but it’s one of the key reasons why I am in this business.