I hope this next year will afford me more time to write, as I’ve enjoyed all the comments I’ve received from you readers. I have plans on documenting and devoting a page on this blog to two new Open Source projects I’ve written since starting this site; accepting suggestions, comments, and hopefully remarks that they were useful to you.

Thanks for reading.

I jumped ship to Eclipse for Java development several years ago. It was Free, independent of Sun, and had a plugin architecture. It wasn’t until some errant day that I fortuitously pressed Ctrl+Shift+c to toggle a line comment. I was floored! Oh, rational and easy keyboard shortcuts, where had you been all my life?! I remember, tied up in some “Ctrl+Alt+x-tcomment” command. No longer!

Then, after I began really customizing Eclipse, right around Ganymede, I started tweaking the keybindings to just-suit my likings. I bound Ctrl+Alt+s to Save All, Ctrl+Alt+q to Close All, and Ctrl+Alt+r to Run. It was glorious. My high-school typing teacher told us that two hands on the keyboard will always be faster than a mouse. I’d have to amend that statement and say that it certainly is, for particular tasks. The key is to bind the right tasks to easy-access shortcuts, and you’ll never be beaten in a speed-test by a mouse-driven GUI.

Recently, I’ve again changed loyalties and moved to Netbeans. (Aside: Eclipse was wonderful, and I still have a soft spot in my heart for it, but the explosive memory usage and frequent hangings made it unusable.) It was a tough switch, though. I had tried several years before, and ran into what I considered a major usability problem: lack of multi-key bindings. By the time I was ready to switch, I was almost ready for Emacs. The fact that I could nest actions into multi-key-multi-mask shortcuts was downright awesome! By then, I’d had intimate exposure to SVN and couldn’t live without my Ctrl+t-Ctrl+c check-in binding; (“t” for “team”, “c” for “check-in”). It wasn’t until recently that I gave it another shot and am so thankful for the effort. I’ve discovered an entirely new realm of happiness for an IDE. Assigning and navigating bookmarks takes less than ten seconds and jumping to the declaration of a function to see the actual code, then right back to where you were is easy as Ctrl+d-Alt+Left!

Custom keybindings will save your life, or at least make you twice as productive. Learn them, use them, enjoy them.

I suppose more than anything, I just needed to recharge the batteries, as it were. Being a digerati only allows for so much creative thought to be put into extracurricular activities before you owe it back to what you’re being paid to do. And, while I absolutely love putting my opinion and my works out to the public, (expect to see at least one post about GitHub and it’s glory soon), I just realized I didn’t have the content to keep up with this (or any other) blog. So rather than pollute what I strive to make otherwise a substantial addition to your Google Reader feeds, I’ve left this smolder.

But having a moment now, I’m finally in a rejuvenating mood that I believe is worth sharing with all my readers. If you’re mildly interested, I’ve had many starts to articles on various topics which I hope to finish: CSS syntax, Django bugs, and an expansive description of an open source project I hope to put on GitHub very soon regarding the new CANVAS HTML element.

In short, I’m back to writing in the techblogosphere, and I’m quite happy about it.

IE8 continues this misguided charge with Web Slices, a particular element of a page which the browser can selectively update asynchronous to the rest of your behavior. In lamens terms, consider it to be RSS on crack. The idea is kind of cool and interesting as a developer: Provide desktop and web apps a URI to a manageable piece of information that can be parsed relatively frequently for updates.

My issue is two fold: (1) the URI Microsoft defines is nonstandard and trivial; and (2), why should we learn another set of proprietary syntax for what should be defined elsewhere in the page or headers?

As for the URI, XPath is a much stronger and cleaner way to identify what is subscribable. Why should I be limited to just one element at a time? XPath would allot me several subscriptions all at once. A URI like http://blog.adventdigerati.com//*[@class="story"]:first would give you my the snippet to my latest blog post, and omitting :first would give you all the posts on the front page. Why is that so hard?

Secondly, most of Slices’ API is defined using bastardized (X)HTML elements and attributes. Even I learned that text content should not be used to define semantic meaning in a document; it’s a corruption of XML standard, one of the best directions in web standardization so far. How hard would it be to include a custom <meta> tag in the <head>? Namespacing a custom tag would be sufficient, and you could even achieve the same effects MS wants via these methods. <meta name="ms-slice-title" content="/absolute/path/from/slice/root/to/title/tag"/> would give a consistent way to retrieve the titles for each slice with one line of code! Or, if need be that the slices be drastically different, <meta name="ms-slice-ttl" content="//*[@class='entry-content']"/> would parse slower but achieve the same goals, and be standards-compliant.

In all, everything Microsoft wanted to get out of their new Web Slices feature could already be done using existing tools; let’s not clutter what could be an awesome new tool for developers with sub-par requisites that somehow shoehorn their way into standards by just being left to fester.

Then came O’Reilly and his onslaught of black and woodblocks of wonderfully foreign animals. After all, what business does a camel have learning Perl, anyway? Regardless, the new and fresh cover matched an epoch in programming/coding reference books. Gone were the days of black and gray boxes, laden with cross references and appendices; now, we have analogies and metaphors to spare. Reading up on honing your skills as a software engineer just got a whole lot more interesting.

But, you have to draw the line somewhere…and I’m very glad Dave Thomas, (the programmer, not Wendy’s uncle), did. Look at a humorous reworking of one of his past titles:

Using our previous example, we can already see how rapidly a RDb can gain entities and relationships as correctly storing information can require many additional entities. For our “intelligent SQL constructor,” the system will need to weed through the myriad of tables to get to find the fastest path from start to finish.

Now suppose we expand our example yet again and include a second path between Baby and Deceased: “A Baby can be born and soon after become Deceased.” This new relationship throws a monkey wrench in some interfaces, as the most direct path from Baby to Deceased is now a single hop. For some users, that we may abstract the fact a Person will become Deceased can lead to erroneous expectations either from the developer or the user; in either event, this is a discrepancy which will cost patrons and development costs in the end.

So how can we expose this fact? My personal inclination is to be explicit is possible. By describing to users what you, as the developer, were intending, harmful reactions should realistically be cut to a minimum. To do this, the system will need to be mathematically aware of how the RDb is structured and what the relationships imply. As proposed in the exposition, knowledge of existing information, its meaning, and a relation to other algorithms should help us greatly.

The first tool we’ll need is a mathematical expectation of how to go from Baby to Deceased. Because of the wonders of modern medicine, users expect that life for a Baby does not cease until having consumed a significant time on Earth. From the data-modeling standpoint, this is to trace the relationship from Baby to Deceased through the Person entity. However, some UIs may not account for this and choose the direct, 1-hop, relationship.

From a user’s standpoint, this is misleading. “I’m calculating social security checks for the elderly; why do the results include a dozen records which are extraneous?” The system’s presumption that it must follow the most direct path from Baby to Deceased seems flawed, though – for the criteria – its data may be perfectly correct. Shouldn’t we instead initially propose to follow the path with the highest probability of success?

In such an example, based on our knowledge of the use of the system, we estimate that there are ten times the number of records for paths between Baby to Deceased using the Person table as without. Taking this into account, we almost assuredly are retrieving the right result set for social security calculations. Then, for the remaining ten percent, we offer the option to “trim” the Person entity from our query.

Additionally, what the system hasn’t exposed here is the semantic relationship the surmised from the entities provided. Perhaps the results were appropriate for what was provided, just not what was expected. This is the second tool we must produce: a means of exposing to the user our presumption of the semantic meaning of their query. This is, admittedly, less for our system to act upon than to influence what the user will input next, or perhaps withdraw and try again.

By now it might sound familiar to problems faced in graph theory. At the moment, there are two that I can think of which aptly fit into this scenario: maximal flow and minimal cut. Both are incredibly annoying problems with surprisingly low-tech solutions. They also both make use of our mathematical model tool we prescribed earlier. An improvement to this theory which deserves its own article will be proposed at the end of the article.

Luckily, there are means to do all of these things when given a well thought-out framework. Semantic ties can be stored within the framework and the mathematical model can be derived quickly from the data via a few SQL queries. (I already anticipate the cries of outrage over additional SQL queries, but those drawbacks will be addressed in the conclusion; so please, save your flames until the end of the series.)

XOmB Logo

For everyone who hasn’t been following the Pitt Geeks forums, XOmB is a new middleware architecture, written as much as possible in the D programming language, lying between the HAL and the OS. The “XO” stands for “exo,” as in “exo-kernel.” MIT has written several exo-kernels, it’s main details page was last updated in 1998.

XOmB was written by several University of Pittsburgh CS students starting just after Y2K, and not a year after graduation is the kernel stable enough for LibOSes to be written and tested. It’s a great day for FOSS! (Oh, I didn’t mention it was free before? ;-P)

GIT XOmB

git://github.com/untwisted/xomb.git

This is not to say, however, that they are insurmountable. Often, in fact, when we stop trying to over-engineer our system and evaluate the situation as it is, we can make optimizations beyond our expectations. As a simple “for instance,” presuming we have a determinant for a conditional that is initially a free-text entry. According to this pretense, Boolean evaluation can take as little as the first byte in the string or as much as the full text of the string; thus, for sake of computation time, memory, and most of all maintainability, it should be avoided at high cost. Compare this with replacing this free-text with a numerically-indexed list of choices and the Boolean evaluation drops to a static value. (Even better, most implementations of bit-wise integer comparison are executed as close to machine code as possible.)

But, inevitably, there are cases which solutions such as these are not so prevalent or obvious. For instance, when implementing join-context SQL conditionals as PHP, it can take a tremendous amount of derived and out of band knowledge to perform the translation. Combine this with already complex logic, (nested XORs, negated string comparisons, and cross-table lookups), and the code can get slow and ugly very fast. So what do you do as an engineer with an email, the SQL, and a pat on the back? Get a game plan.

It’s more important to pencil in a strategy for defining your criteria than going off of pre-existing assumptions. For one measure, repeated calculations in the original may be consolidated as a single conditional whose value is stored and later addressed; the processing efficiency alone is worth the change when scaling up to enterprise-level datasets. Additionally, as I stated above, changing data types of pre-existing conditionals can be a great boon as well, and performing integer arithmetic is always faster than strcmp.

Once the parameters are defined, we zoom out to observe the algorithm. Keeping in mind the practice degrades maintainability, nesting some repeated conditionals can save processing power down the line. But don’t get nesting-happy; (especially with code you’re simply translating and didn’t have the mental inception for) you’ll forget why two conditionals had been nested or why their order mattered so much. This is where your formal logic class enters the picture. Class, what is {A, B, C, D} & {A, B, C}? Of course it’s {A, B, C}; it’s also ¬{D}. The optimization, however slight, of changing

if($var == A OR $var == B OR $var == C) { something_true(); }

to

if($var != D) { something_true(); }

may not increase performance by leaps and bounds, but if you’re deep in the code anyway why wouldn’t you shave off the time?

Now, after the code is written and tested, there is much rejoicing. The only thing we now have to contend with is if the translation needs to change. And while we may not, (and hopefully will not), go back to square-one with our evaluation, we should at least take the time to consider where we may have gone wrong in our previous implementations and where we can continue to go right.

Anyone can write something that uses a finite language to perform a task; they view programming as a science because the result is all-important. A subset of these people care about the means to that end, how to innovate and control or to clarify and enhance something that predates their intervention. It is these select programmers that see what they do differently from science; as Graham’s analogy goes, they are as painters.

It was a novel idea, one I hadn’t personally thought of. Coming out of the 80′s and taking computer classes in the 90′s, I learned that the old, original way to program was pencil-and-paper; you traced, retraced, and did it again until you were sure that all the pieces compiled and didn’t hang on an infinite-loop. Ka-chunk-ing the graphite into punch cards or translating the pseudo into real code seemed like a science; the very implementation of the scientific method.

Enter the 2000′s. As a Comp Sci student, there are classes everyone dreads. Algorithms are typically one of them. Learning the Complexities of Djikstra and A* meant sleepless nights reviewing code, compiling, and reading the textbook. Sounds like a science to me! But, at the end of it all, the reason so much pain was endured is quite clear: it makes us resilient, faster, and better “painters.” We see the loops, callbacks, and hash trees as strokes on the canvas or rhymes in a song; storing references instead of whole objects slides the slant rhyme into a perfect-pitch. I thought differently, even began speaking a different language in my head: a programeese that was based more in logic and absolutes than society’s compassionate relative truths.

Then again, this brings up its own interesting tangent. Maybe software engineers are closer to being writers than painters, but no one has written about the connection because the thought of mixing science and creativity was a noxious concoction. William Strunk wrote Elements of Style in 1918. He didn’t have a clue what Boolean logic or a vacuum tube was. But he did understand writing; and words were his symphony. He must have, I believe, painstakingly sat through the English Composition equivalent of our programming algorithms class. His grasp of what makes a good essay translates with only a little help into great programming practice.

An excerpt with noted emphasis:

Make the paragraph [function] the unit of composition: one paragraph [function] to each topic [task].

[…]Ordinarily, however, a subject [task] requires subdivision into topics [functions], each of which should be made the subject [task] of a paragraph [function]. The object of treating each topic [task] in a paragraph [function] by itself is, of course, to aid the reader [programmer]. The beginning [declaration] of each paragraph [function] is a signal to him [or her --Ed.] that a new step in the development of the subject [task] has been reached.[…]

~ Bartleby

That’s remarkably coherent for what was changed! And if you hadn’t thought about it before, beautiful code follows this advisory very closely. The function is the fundamental unit if any program, (if you bar the variable since they are in themselves stoic). Its purpose should be solid and rudimentary if internally complicated. But just as my 5th-grade teacher taught me when outlining my papers, that complication should not become so extensive that the intent is lost; in that scenario, the paragraph should be subdivided, and likewise the offending function should be dissected. The contexts are different, but the underlying principles are the same: K.I.S.S. — Keep It Simple, Stupid!

So, after all, maybe programmers are men and women of double duty; scientists who engineer excellent structures that do exactly as told, and yet makers who craft works that are intuitive and engaging to use. I guess that “programeese” I constructed my world around once I appreciated what I had learned was more than sounding crazy. It was learning how to fasten a dangling participle or paint a Douglas fir Bob Ross would be proud to put in the background of one of his paintings.

Buy The Elements of Style
Buy Hackers and Painters

I hope to fill this blog, (hopefully before Technorati.com gets upset, I just liked the name), with a few ideas, anecdotes, and insights from my aspect as a newfound professional software engineer in the professional world. Here in the U.S., it’s 2:30 AM on a Monday morning, and I know I’m going to have fires to fight come the work-week; so I’ll bid you (possible) readers a good night, or good morning, and try to update this with something meaningful by Wednesday.