I read a very fun book on my holiday in Manitoba this last few weeks. It's written by a biologist who has turned to fiction with an eye to producing some good hard core science based fiction. I would compare his work to William Gibson and Arthur C. Clarke.

As an added bonus (I discovered this after buying the book) the author has published it under a creative commons license and you can read the entire book online for free. How cool is that? (Read it here)

There is a lot to chew on in this book, but my post subject says it all. Seriously though, don't judge based on that, it's a good book. No really...

I had to blog this, and yeah I'm going to be the billionth person to do so, but that's ok because no one reads my blog and it's basically just my personal public archive. (ppa?)

This guy http://www.thomasfrank.se/sessionvars.html has managed to find a very clever place to store data within the browser without resorting to cookies, flash or anything beyond basic cross browser javascript. Apparently "window.name" which lost it's usefulness when the spammers started making popups obsolete can contain arbitrarily long strings that persist as long as that window is open (equivalent to a session cookie)

This is damn cool, and while a part of me twinges at the hack-ish nature of overloading a window property with a bunch of json strings, well this is javascript we're talking about here so what the hell. You're already standing out in the rain trying to build a fire with soggy sticks and no pants so why not use what you've been given.

This is just one of those things I know I'll want to come back to one day for one of my pet projects so I thought I'd blog it.

I'm currently working on moving a web application from using some ad-hoc javascript and iframes to a full fledged ASP.NET Ajax implementation based around Telerik's RadControls and a suite of our own controls. This is the third application we've given the ajax treatment to and each time we've taken a slightly different approach.

Approach 1 ... "Javascript + Web Services"

Full view manager/page controller implementation on the client side to handle events thrown by all the components on the page

Homegrown "ServiceManager" to handle brokering calls to the server

Centralized error handling

Shared message contract base class to allow "sub-messaging" for the server to send information to the view controller on the client

Blocking calls when things needed to be "modal" or serialized

... we had intentions of also building in grouping of calls

... we had intentions of canceling redundant calls when the user was asking for something that made a previous call unnecessary

Chatty - many calls, small amounts of data (largely json)

Javascript controls that render almost strictly client side based on data delivered over web services

Zero postbacks / Very fast

Expensive/Complex development and maintenance

Prone to memory leaks

More difficult to leverage third party controls

Approach 2 ... "Update Panels"

Traditional ASP.NET development with a sprinkling of update panels where it made sense

Chunky communication... partial postbacks, but still heavy

"Simple" development - UpdatePanels were spotty at the time, there were quite a few workarounds hacked in to this interface

Medium reliance on third party controls

Less performance than "Javascript + Webservices"

Less transparency and control to developers

Approach 3 ... "Javascript + Web Services + Update Panels"

A view controller/ page manager approach similar to Approach 1 except that in this iteration we are relying on the ScriptManager and it's events to handle a lot of what we were previously rolling on our own.

A heavy usage of Telerik's Prometheus suite of controls, which in turn is built against the Microsoft Ajax Framework

Webservice layer for a class of managed actions where we control the control flow via our view controller

Partial updates for more complex control interactions/workflows

These are sometimes triggered by the controls themselves in which case we are dealing with "chunky" transactions

Othertimes triggered by the page manager in which case we have small requests and potentially heavy responses

Good use of third party controls

Chunky or Chatty based on need

Medium development complexity

Less transparency/control for developers

High development complexity

Better performance than Approach 2) but less than 1)

Still prone to memory leaks

So you can see across these three different applications we're dealing with a swinging pendulum of ajax development methodologies and philosophies. My hope with our most recent approach was that we would have the strength of increased reliance on Microsoft's framework + Telerik's suite of controls combined with hooks and web services to eek out that extra level of performance whenever needed.

Of course in this latest iteration we also have the added complexity of having to port legacy controls on a very difficult timeline. So we have a collection of editors, some of which are doing chunky partial post-backs whereas some of our newer type editors are using a more... let's say finely tuned approach where only the necessary data is sent and only limited page updates are performed.

The third option still has some proving out to do. Rather then being the perfect blend of complexity vs performance vs reuse vs transparency is instead turning out to be not especially good at any of these. I'm frankly a bit frustrated by the whole exercise right now an am increasingly eyeing the glorious promises of Silverlight.

Really I don't see this stuff getting any easier until we're either seeing browsers that have equivalent capabilities in supporting Html 5 and all the exciting new javascript features of the future or a widespread installed base of Silverlight 2. haha... right.

In GEB Hofstadter mentions the complexity in building an isomorphism between two poems written in two languages.

"In ordinary language, the task of translation is more straightforward, since to each word or phrase in the original language, there can usually be found a corresponding word or phrase in the new language. By contrast, in a poem of this type, [Jabberwocky, Lewis Carroll] many "words" do not carry ordinary meaning, but act purely as exciters of nearby symbols. However what is nearby in one language may be remote in another."

Reading that acted as an exciter for my own interest in poetry. I immediately think about some of the poetry I have read which had the most impact for me and it did exactly this. The ability of a good poet to draw scenes by exciting patterns of shared experience and perception is really amazing. Choosing those "words that excite nearby symbols" is a bit of a game and for me what makes trying to write poetry enjoyable. It becomes almost technical or like solving a problem.

I am often cynical that poetry can be really widely appealing if only because the most poignant and effective poems I've read require a familiarity with the writer and a shared experience that allows compact transfer of imagery. Then again, some of the power in the compression and lossy nature of these poetic images is that there is room for interpretation in the eye of the beholder.

In a field at dusk, trees made short by distance, a line of black on blacker at a horizon pulled ever closer by night...

I just finished reading "The Dream Machine" and getting a very cool look at some early history of computing including the birth of Multics and it's spin off and almost more interesting the birth of tools like email and ftp as a way to actually do something with the ARPANET that was being built. A great read for anyone interested in how we collectively have arrived at where we are today in computing. And as it happens, I'm also currently challenging a course on Unix which as part of the challenge requires that I complete a project before I can write the final exam.

The project itself is great fun actually. I've been in the world of Microsoft for so long at work that I've completely forgotten about the old days of living in vi on Solaris as part of my 9-5 work. (CATI programming back then) More than anything about Unix I love the power and flexibility of combining these small well written tools like awk, sed, grep etc. These are incredible tools and it's easy to forget how powerful a fully text driven system really is.

I remember being completely stoked about Microsoft's powershell project a few years ago. On the surface it seemed to take everything exciting about a Unix environment and add a layer of object orientation across it so that not only could you fully embracing piping and redirection with the help of some impressive shell programming capabilities but you also had the full .net framework at your fingertips and the ability to use reflection to "discover" a system at run time. This discover-ability aspect is key, and the importance of "man" to rusty or newbie Unix users can let you appreciate the value in being able to query objects to ask what they can do. The simplest example of where powershell is so powerful is to just imagine good ole ls, but where each element output from ls was an actual file or directory object. If you do nothing then those are simply iterated by ls and essentially .FileName.ToString() gets called for each... but if you pipe that output to your own iterator you can all of a sudden do some really amazing things with very little effort.

Having said that though I never truly fell into powershell like I have unix in the past. In my opinion it's about the eco-system. The set of utilities in unix work because everything in unix plain old text, meaning the same tools can be strung together to do any countless numbers of tasks without additional support. Compare this to powershell which really loses it's value where .NET doesn't exist. True, there are some amazing providers that bridge gaps into SQL Server, WMI, etc etc. But just the fact that you are now talking about .NET development to create those new bridges means we're half a step behind the accessibility and simplicity of a text file. I do think that powershell will only get better with age, but for now unix as a whole is still king for me even if powershell is sexier.

Anyway, this project I'm working on is just a series of clever questions that force you to construct chains of tools to elegantly (or inelegantly) solve a problem. It's extremely fun and in the course of a couple weeks I've reinstalled cygwin at work, gotten ssh access to my mac at home and have had terminal open for pretty much a week straight on my iMac. It's hard to keep this up without an actual task - and considering I'm still doing 95% .NET development i don't expect this will continue for too long but it's a good reminder.