July 2012 – Should Be Simple

Groovy, The Gateway Drug

Once upon a time, the only languages I trusted used static typing. This now seems silly, but is a fairly common attitude and for good reason. To a developer trained in C++ and Java formality, using Ruby or Python feels like anarchy. And there is that pejorative term “scripting language.”

At my first job after college I built Java Enterprise Web Services on the gruesome Servicemix platform. My task involved deploying the xml beasts and synchronizing our Cvs repository with the Devil’s own source control. Just maybe, this was a job for a scripting language. Just a taste couldn’t hurt…

So I found Groovy and got myself a copy of Groovy In Action.

At first, my Groovy scripts looked like Java, semicolons and all, since almost any Java program is also valid Groovy. An established codebase full of closures and duck types would have been alien, but to the programmer tiptoeing at the edge of dynamic language, Groovy felt very safe. After time, the same comforting safety eventually made Groovy feel like lugging Java baggage, but I highly recommend it for the programmer monogamous with Java. Just start renaming your Java files with Groovy extensions.

Next, drop a semicolon here and there and those ridiculous “throws Exception” clauses. Then, discover the “each” method; it seems like syntactic sugar, but explore. It involves some wacky thing called a closure. Write a function that takes a closure argument.

Every once in a while, try writing “def foo” instead of “String foo.” Surely dangerous, but promise yourself it will just be this one more time. The examples all do it; how bad could it be?

Ask yourself again, “What’s so great about closures?” Google says they sprout like weeds among the Ruby community. That’s still not a real language, but maybe Groovy is; it works with Java, after all.

Soon enough, you will realize Java feels stifling. “Dicing all this xml sure would be easier in Groovy,” you will think. You will notice and understand dynamic language zealots. The cool kids mostly run Ruby and Python. Java virtual machine startup delay is a drag for scripts, so try one of those.

No variable declarations at all? No damn curly brackets? You will be hooked.

Google Reader Squish

Remember when Google was minimalistic? This is Google Reader now:

At 1600 x 900 resolution, this relegates actual content to only about two thirds of the available screen space, part of a 2011 Google effort:

The way people use and experience the web is evolving, and our goal is to give you a more seamless and consistent online experience—one that works no matter which Google product you’re using or what device you’re using it on.

The “elastic” interface concept that Google intends to follow sounds like the idea of making a single page that works well on both a desktop and mobile device. It turns out that the mobile page is actually completely different, so the new desktop look must be more for styling than cross-device usability.

To be fair, the interface is minimal in that it displays only a few buttons, but I think Google went too far making the interface look touchable. Modern phone browsers render normal pages faithfully while handling the small screen size nicely, so a page that displays well on high and low zoom on a desktop will also likely display well with little or no modification in a mobile browser. Even if it were intended to work on widely varying screen sizes, I see no functionality reason for expanding incidental controls to consume almost a full third of the screen:

Links to unrelated Google services
Search box
11 buttons

So decided to experiment with customized style sheets using the Stylish Firefox Add-on. The Stylish site already lists plenty of compact Google Reader styles, but I did this for the practice and also because many of the minimal styles I tried removed functionality such as the logout link.

I called the style “Reader Squish” and published it on userstyles.org under the WTFPL.

Unicomp Customizer

I am writing this on my brand new Unicomp Customizer. Since first reading Have Keyboard, Will Program, I wondered whether buckling spring hype was really worth it, especially since I have long loved the near-perfect¹ Microsoft Natural 4000 layout.

Within an hour or two of receiving my keyboard and excitedly testing it on online typing tests and games like Qwerty Warriors, I realize this is the first keyboard that actually speeds up my typing. In that short time, my beloved Microsoft Natural has started to feel spongy and uncomfortable. [Update, March 2020: Flash is dead and Qwerty Warriors with it; my JavaScript version is at https://www.qwertywar.com/]

Finger exhaustion makes the difference. Five minutes full bore on another keyboard and my fingers feel tired. Tired fingers make more mistakes; I backspace more; I slow down. On the Unicomp, however, my fingers feel just as sprightly after the test as before. At test completion my fingers feel as if they have been jumping on a trampoline and their parents just spoiled their fun by telling them to come in for dinner.

Beside tantalizing finger pleasure, the Customizer adds visceral clattering spring charm. By practicing a soft touch, you can dull the sound a little, but passersby will always think a mini war zone surrounds your computer. And I thought even the Microsoft Natural’s space bar was a little loud in an office.

Regardless, those who regularly type long blocks of text might justifiably tell coworkers to suck it up. Even without an ergonomic layout, the reduced finger fatigue over just a five minute test makes up for every clicky keyboard comment. Sadly, the Customizer will probably not increase my overall work efficiency. My typing usually involves the typical programmer’s short bursts and frequent contortions for symbols.

So I probably will not use it in an office and I am unlikely to gain significant typing comfort or speed, but was it worth it? $80 to make typing fun again? I think so.

I have only two gripes with the Natural’s layout. First, six should be on the right, but the peculiar left-handed six position may not have been Microsoft’s decision; it infects most split layouts, including the original Natural’s contemporary IBM M15. The second mistake, F Lock does belong exclusively to Microsoft.