“We have achieved peace for our time”

The Honorable Neville Chamberlain

It is often the case that when you look at things a certain way, they become filtered over time, and you see what you expected to see. This happens to everyone, and while a wonderful adaptation to help handle all of the various inputs in our lives, has caused just about everyone to jump to conclusions because they think they know what they see. Neville Chamberlain did that. He (and his advisors) was certain that Hitler would keep the peace after he was given what the German people wanted. He saw Hitler as the same as other European leaders, and that was definitely not what Hitler was. There is no definitive proof that things would have gone differently had the allied powers put their foot down on Czechoslovakia. But the Munich accords, and the statement quoted above, definitively did put an end to Chamberlain’s career.

Thankfully, for most of us, our misapprehensions rarely result in the type of drastic results Chamberlain encountered. In fact, for most tech bloggers, unless you say something that gets your employer into hot water, the worst you can expect is some snarky commentary on your blog. Not so long ago, I wrote a post decrying the failure to do anything truly new in recent years. As often goes with such posts, this seemed rather obvious to me. NoSQL databases were significantly different, but everything else I was hearing were new ways to do the same things, without a major shift in paradigm.

And therefore as a stranger give it welcome.
There are more things in heaven and earth, Horatio,
Than are dreamt of in your philosophy.

Hamlet, William Shakespeare

I’ve been at this long enough to know better than to go off on a longish rambling post making hasty generalizations. So I deserve it, go right ahead, give a laugh. I’ll wait.

…

Really? Still laughing?

…

Okay, now that you’ve gotten that out of your system, I’ll stop being self-deprecating and propose a possible pattern that I find pretty interesting… And ask what you think.

You see, while I was ranting about nothing being different, Android’s “never stop execution” model of execute the routine until it exits, with no way to stop execution and await an event was giving me terrible headaches. Normally that model is rock-solid, saves CPU time, and only takes a short amount of time for most developers to adjust to. But when doing something that requires user input before it can complete, it actually makes the coding more complex, or in the worst case, makes the code run a ton slower. My case was asking a user if they should allow a connection to a site with a mis-matched certificate (host name different than the host the certificate was issued to). You simply cannot ask that question and then have the code continue on. The result would be connection before the user had a chance to hit “Okay”. That’s not just bad coding, it’s dangerous. And likely to result in consequences as dire as Mr. Chamberlains were. But the alternative is to throw an exception (stopping the connection) then in the calling code catch the exception and start the entire connection process over. Thankfully for my Android project, I could ask the user when they added the server if they were okay with server name mismatches, but for most scenarios (going out to a site the user entered the URL for), that’s not an option.

And then I developed an interest in Node.js. Guess what type of model Node.js uses? Non-blocking. Now I’m seeing an interesting pattern that is perhaps more fundamental than it appears at first blush. You see, in the old world, 99% of code was written to wait for whatever resources they needed to become available. Yes, J2EE and Perl, PHP, basically all of the web app dev tools did run beginning to end and then exit, but on the backend, they waited. They blocked on database I/O, they blocked on SOA calls, you name it, there were a bunch of reasons that during execution, they blocked.

Not these two environments. When you tell Node to do something, you give it a routine to call back when it’s done, then continue doing what you were doing without waiting. And when the callback occurs, then you can use the resource you would have blocked for. Android is the same. Create a background thread to handle database, or SOA, or file I/O, and continue what you’re doing. It’ll notify you (assuming you wrote the notification code ;-)) when it’s done. Send an intent to another app, and wait for it to notify you, same scenario, different mechanism. Even services are just a massively evolved form of background thread, and as such, notify you when they’re done processing in your stead.

Modal dialogs? Android core devs will happily tell you '”Yes, they’re just different”, which is true as far as it goes. But modal as in “can stop execution while the user tells me what to do” is not possible. Execution continues, you move your “waiting for a response” to a separate routine.

There is a seismic shift here, and I was missing it in that older post. Both of these environments maximize CPU utilization by not blocking, and both are pretty high performance environments. Android does a lot on a few resources, and Node.js outperforms LAMP – at least one inaccuracy in the article, but not in the testing or discussion of it.

But for me, the key is that devs will be thinking differently. In my experience, stretching outside the normal functionality fits the very innovation I was thinking of, and between the two, most of us will end up developing for one or the other at some point in our career. Or for their descendants, same difference.

So I’m overall stoked, different thinking leads to different solutions, which means more options for doing what needs to get done, which inevitably makes IT stronger, simply because the better fitting solution can be adopted for entire problem domains, industries, whatever.

I am looking forward to playing more with the non-blocking paradigm, should prove to make us all better developers. Almost makes me want to do some timings to check how much wasted blocking time we’re saving. Almost. I’ll content myself with getting better at these two tools, and someone with more free time can do averaging on blocking times, I’ll read it avidly.

I still stand by the general gist of the article, that AppDev is somewhat stagnant in relation to the rest of high-tech, but there is some fun stuff out there that’s starting to make its way onto your AppDev team, and will make a shift in development mentality.

And for those of you still laughing, well I never. :-)