Money (the desire for money), we might naively think, is the great unifier. We all want it, as much of it as we can get, at the lowest level of effort. Incorporated Individuals tend to thirst for it a little more than their non-incorporated peers. Only a few elites have come to realize that something greater than money exists; while the rest of us waste our effort in the acquisition of valued assets, this enlightened Select seeks out the superior resource: power. The company of these persons understands that power achieved is little without frequent demonstrations of power wielded.

APIs are hellish things: inconstant moons, inconsistent interfaces, intolerable incompatibility. If you have not watched Bret Victor's latest epic, I do recommend it. As he channels the spirit of innovation from the 1970s, he notes that it would be horrible if, 40 years from then, the only way two systems could communicate were through predefined and agreed upon interfaces. Indeed. What a terrible thing that would be it is.

As I continue to build out my prototype for OJ's qDb component (trying to fulfill my promise to IndexedDb), I have done a few of the obvious things. I automated the database connection in the constructor as +Kyaw Tun recommended. I looked at +Taylor Buley's own library and make some tweaks accordingly. I have tested inserting up to a million records and selecting from the resulting object stores. There are some memory leaks to address and a few other performance issues before I'd recommend qDb on very, very large datasets--but it is in an OK state.

Yet, as pleased as I am with the abstraction layer that I built, I feel a growing sense of frustration in this class of problem solving.

Last year, I saw +Paul Irish's introduction to Yeoman in the Google I/O 2012 session, and I instantly knew that I was fundamentally doing something wrong. Yeoman did not exist yet; but it was easy to find Grunt, which was already close to being well baked. However. All of the documentation for Grunt, its cousin Brunch, and the now available Yeoman seems to be geared toward starting new projects.

Not yet grokking how the whole system worked, I wanted a simple, straightforward explanation for migrating an existing project into Grunt. I have not yet found one, and a search for "import existing project into Grunt" still returns my SO question for the same in the top 10. So, this is my guide to taking a project and making it grunt.

I ask the question, because I assume it must be (considered evil)--on the subsequent assumption that if it were not (considered evil) that someone, somewhere, somehow would have made it easy. I had a simple vision: take JsDocs from my project, convert them to an API document, publish that document to my Github pages place.

Quite a bit of my free time in the last 8 months has slipped away into OJ, my solution to the hell of dynamic form creation (based on arbitrary data inputs and accordingly arbitrary data outputs). Folks at WuFoo and Bootsnip have some nice prototypes of runtime manipulatable engines; while each looks like excellent work, neither solves my problem of generating entire workflows based on data. I want the data to drive the UI; the UI should simply read the data and generate the necessary rich form content necessary to provide slick, intuitive, addictive user experiences.

In the pursuit of this heffalump, I had recently been working on decomposing Martin Orth's query builder into classes in the OJ framework (see it on Github, in NPM, and collaborate with me in Cloud9). This body of work depends upon ExtJs, which is a powerful but extraordinarily inscrutable framework. I spend a frustrating amout of time comparing the inputs into Ext from OJ vs the inputs in Sencha's examples or their documentation. It's tedious and fragile as seeming minor changes can produce difficult to track bugs which go unobserved across several commits.

I wanted to be able to instrument my code in such a way that I could flip a switch and start logging every input into Ext. I had a few requirements: the objects logged needed to be in as close a state as possible to their values at the time of logging (logging to the console sends the object by reference, so you'll usually get the last known value of the object by the time you see it). The objects needed to persist across page loads. There would be a lot of data (more than would fit in localStorage). Finally, the data needed to be queryable.

IndexedDb seemed like a potentially good fit. Unfortunately, like so many "HTML5" standards, the API is terrible. If the consumers of this API were just vendors, like Chrome and Firefox, it would be hard to identify any specific contract as "wrong"; but as a developer consuming this API, I cannot easily point to any component and say, "this is right." But it is what it is, and it is all we've got.