Numerous issues kept me from moving it back to the original domain. First, of course, there was the fact that I didn’t have control of the domain at all for three months. When I did regain control in the summer of ’07 I was right in the middle of the Oregon move. By then I’d been posting away and it just never seemed like a good time to switch back.

If you know me, you know I’ve got lots of opinions about what’s good and bad about our various online communication tools such as blogs, email, Twitter, forums. What better way to test some of those ideas than to um, write a prototype and then uh, use that prototype. So as ’07 neared its end I made a little pact with myself that I wasn’t going to blog until I did so on my own stinking blogging platform (one I’d created).

Well what with the day job and design school and the family and all, that progress was slow. However in September, ’08 I did launch a first cut as part of the Thought Propulsion corporate site. If you look at the blog tab there is a beginning there. Not a lot of the functionality is exposed yet and my assessment is that to expose a whole lot more is gonna take a whole lot more work. Go figure.

While all this was going on, my WordPress installation at TextDrive (the one running meme-rocket.com) got upgraded about once and was in need of another upgrade. I kept putting it off because I loathe upgrading WordPress. It makes me crazy that “themes” are not isolated from the rest of the system. It’s crazy that a WordPress upgrade cannot be push-button.

So I decided to go ahead and kill a few birds with a big hammer and set up a shiny new wordpress.com blog on my original domain. That’s what you’re reading now. I’m feeling great about this decision so far since:

1. I was able to use my own domain—yay!
2. I was able to reclaim my original domain
3. I was able (using my DNS provider dnsmadeeasy.com) to HTTP (permanent) redirect meme-rocket.com to memerocket.com
4. I never again have to upgrade WordPress

A few minutes after upgrading I received a positive message from The Universe in the form of a wordpress.com alert on my dashboard. It said that the system was going to be upgraded to version 2.7 in 23 minutes. And guess what. I didn’t have to back up my files or my database. And I didn’t have to do anything but refresh my browser to enjoy the sweet new UI.

On the downside I’m sure I’ll miss some customization features. More on those as I run into them. For now though, I feel like I got my old megaphone back. Get ready for some blasts. Ahem! And what of that early ’08 pledge to roll my own. Well we’ll just have to see about that…

This thing uses Comatose 0.8.1. Unfortunately, Comatose 0.8.1 isn’t compatible with Rails 2.1. Fine, I’ll just upgrade to Comatose 2.0 (uber-alpha) and that’ll work. Oops, Comatose 2.0 uber-alpha breaks Rails migrations. Fixing that breakage requires a patch to Rails itself.

Oh and did I mention that this project of mine also requires a patch to Comatose proper (adds before_filters to the Comatose configuration object).

So I need a patched version of Comatose and a patched version of Rails. “OK” you say, just use Piston to manage those vendor branches. Not so fast. Piston only works with Subversion and the Rails project is no longer hosted on a Subversion repository. The old repository was deprecated after Rails 2.0.2. Rails is now hosted on Github. Oh and so is Comatose.

Never fear, Github support for Piston is coming Real Soon Now™. Until then I’m stuck in limbo. I suppose I’ll do the manual vendor branch thing—essentially manage my own private Subversion repositories for Rails and Comatose.

The fact that François Beausoleil is implementing Piston support for all-Git projects leads me to believe that there is no convenient alternative (to Piston) for vendor branches in Git. Hum, that’s hard to believe. Anyhow, I can’t migrate this project to Git yet so all-Git alternatives are sort of moot.

Crockford takes us through a brief history of computing reminding us, as we’ve been reminded before, that the Web interaction model is practically the same as the mainframe 3270 interaction model circa 1972.

The most potent moment in the talk however, is when he shows a shot of a mermaid rendered via a run of the mill nvidia subsystem and dryly points out “look, rounded corners”. The upshot: the 1984 Macintosh had rounded corners — browsers were obsolete from the git go and there is a huge and widening gap between what you do in a web app and what you do in a non-web one.

Oh and I’m making Crockford my Personal Hero of the Month for pointing out that not only are our web technologies based on eight-year-old standards (HTML 4.0.1, ECMAscript ed. 3, CSS 3) started in ’98 and still under development but that of those, CSS is the worst of the lot and should be replaced with urgent haste. Refreshing respite from the usual CSS love.

“Don’t take any crap.”

update: watch this space for my growing list of web standards revolutionaries:

A backlash is brewing against traditional thin-client web applications. Folks are tired of the beachball. Vendors of Web-based applications like Gmail, in which users spend a significant portion of their day, will respond by incorporating client-side persistence, offline operation and synchronization. In particular Gmail will add these features in 2007.

Well then a couple days ago (May 30, 2007), Google announced Google Gears , their toolkit for offline web apps (connection detection, offline operation, offline storage) and updated Reader with an offline mode. This thing is similar in purpose to Joyent’s Slingshot which went into Beta on the Mac on April 17, 2007.

It sure seems like the stage is set. Technology answers need. Only thing standing in the way might be competing priorities or strategic conflicts. Have to think about that a little bit.

How long will it be before a complete IDE is delivered as a web application? To varying degrees, Eclipse and IntelliJ IDEA are stuck on the same island that Smalltalk was. They’re all trying to be graphically rich and run on many platforms. They’re all expending lots of resources maintaining UI toolkits (think of Eclipse’s Rich Client Platform). And the resultant UI technology, while often innovative and sometimes pleasing, suffers a “credibility gap” when compared with platform-specific technology on the Mac or Windows. When will the IDE’s throw their weight behind the DHTML+AJAX crowd and embrace the “third platform”?

Well there is renewed hope – but it looks like Ruby and Rails may arrive before Squeak does. Gyre is an honest-to-goodness Ruby on Rails IDE delivered through the browser complete with source-level interactive debugging, project navigation, and an interesting syntax-aware text editor.

Seems like the next step is to get the Gyre folks working with the Firebug folks. Can you imagine it?

Anyway, google uses the “v” key to view an article in full. This comes up either in a new window or a new tab, depending on the firefox configuration. Sadly, if you want the article in a new window (and I do, seeing as I paid good money for a large amount of real estate), firefox’s popup blocker blocks it.

So, the technology progression was — Netscape invented the pop-up window, the various web standards bodies standardized it, the advertising people abused it, so pop-up blockers were invented to prevent it from working in most cases. I wonder at the aggregate amount of engineering it took to come full circle. In 1936, J.M. Keynes suggested that it would be economically useful to pay otherwise unemployed workers to simply dig up bottles filled with cash, which other workers had earlier buried for them. Seems like we’ve got a high-tech equivalent going on now.

The Unix Philosophy

The first reference I heard of to the Unix philosophy was in the seminal 1978 Bell Systems Technical Journal special edition on Unix. (Appropriately, if you go to the Bell Labs. Lucent, Alcatel (?) web site to subscribe to this journal, you’ll find it has literally gone 404). Again and again, this philosophy has been repeated. I’ve seen it most recently on Duncan Davidson’s Web is a pipe blog entry. Sadly, his otherwise insightful post has an example that does not demonstrate the value of pipes, but rather a Useless use of cat.
The Unix philosophy, is described quite well on wikipedia, attributed to Doug McIllroy:

This is the Unix philosophy:

Write programs that do one thing and do it well.

Write programs to work together.

Write programs to handle text streams, because that is a universal interface.

The Big Lie

This is the Motherhood and Apple Pie of programming. It sounds great in some idealized world, but we rarely see it in our world. Think of the Unix applications you spend the most time using every day. For me, it is something like compiler, editor, web browser, web server, database server. None of these are built from a large set of small tools hooked up with pipes transmitting ASCII data. Not one single application. Yes, I know about gcc and the -pipe option, but this doesn’t count — gcc doesn’t read standard input, and the five (or so) stages of the compiler hardly qualify as small, reusable components. Historical tidbit: In the 2BSD days, the C compiler’s optimizer was implemented as an awk script that ran over the assembler input. But now that we expect our compilers to do more than peephole optimizations, we don’t do this kind of thing anymore.

Now, I use the Unix command line every day, and frequently string together shell one-liners. I build histograms with
sort | uniq -c | sort -n

idiomatically. But I don’t build large applications this way. Almost no one does. Does this mean that the Unix philosophy only applies to interactive shell programming? Or perhaps to that and one level higher, smallish shell scripts (but certainly nothing the size of a C compiler)? Or was the intention of the Unix designers that their machines, tiny by today’s standards would mainly run small shell scripts? I would love to ask Thompson, Richie, or any of the other Bell Labs folks these questions. It is ironic that we are more concerned/obsessed with performance on today’s machines that are thousands of times faster and cheaper than the PDP-11s Unix was born on.

Solutions to the dilemma

One “solution” is to admit defeat, and say that the Unix Philosophy doesn’t really work, at least not on big programs or anything more complicated than a shell one-liner. After all, most Windows users, even power-users, never use command pipelines. Instead of the three command pipeline above to create a histogram, a Windows power user would probably load the data up in Excel, and go from there. Maybe that isn’t as elegant, but it gets the job done just as easily as the shell command. If this is your solution to this dilemma, I would ask you to at least be honest about your retreat — if you don’t build programs this way, stop proclaiming its superiority. Please. There are plenty of sucessful projects in the other camp, and they are up-front about violating all three tenets.

Another solution is to claim that the problem is that the unidirectional ASCII streams aren’t structured enough, and to add some more structure and state, and create a full-blown RPC mechanism. In terms of the Unix Philosophy quoted above, we remove the third leg of the tripod (Write programs to handle text streams, because that is a universal interface). Once this is done, the sin of premature optimization is inevitably commited, for there is the fear that bundling each component into a separate Unix process will lead to performance problems. So, the word “program” is struck out of the philosophy, and replaced with the word “component”, with convenient vagueness. Once these changes are made, we’ve pretty much given up on the validity or usefulness of the original philosophy.

This is the path that SunRPC, CORBA, DCOM, and XPCOMM take. While each of these have been successful within limited domains, we don’t see any of them used as toolkits to quickly build many, diverse applications by non-experts. Rather, they are used to glue together predefined puzzle pieces in predefined ways. For example, as Firefox is composed of many XPCOMM components, why can’t I break apart the components, and quickly build, say, an IM client out of those components? Ho-ho, I hear you say, what about Chatzilla? Chatzilla is built from over a dozen Javascript files by an expert javascript/XUL developer. I would categorize this as an exception that proves the rule — if it really were easy to build this up, there would be dozens of them. Especially the first three component techologies mentioned above, make it hard to connect up various components, especially those which haven’t been planned to interoperate a-priori. The Unix philosophy stresses easy of connectability.

Why not try?

A wise man once told me, “If there’s one thing I’ve learned in six years of graduate study in Computer Science, it is the value of a Unix process”. So, why not try it, and build real, large applications out of smaller unix processes connected by pipes? There’s even precedent — the applications that Dan Bernstein has written, like qmail and djbdns. These systems, primarily designed for security, are composed of many processes which communicate via ASCII stream over pipes. And guess what? qmail is secure, gives good performance, and there are many add-ons and replacements for its various components. Maybe, in this age when folks worry about how to effectively use quad-core CPUs, just maybe the graybeards knew a thing or two after all.

But hold the phone. If you look at the Seaside tools you see a demonstration of Seaside’s LiveWeb. LiveWeb is a lot like the traditional Smalltalk browser but rendered, well, in your browser. So you’re chunking along in your Seaside application and you decide you need to debug something, and rather than using Squeak’s browser, you hit the “toggle halos” link on the current page and ka-ching, the page view is transformed. Page components sprout frames and icons enabling you to switch between a rendered view, an HTML (source) view and a Smalltalk object view. There’s also access to a full-fledged Smalltalk object browser with live source editing.

Smalltalk’s browser paradigm will not be bound to an aesthetically-impaired user interface technology. Like Crichton’s Raptor, it has found a way out. It has broken free into the (web) browser. For now, this has resulted only in a marginal usability improvement — LiveWeb has about the same Aesthetics as Squeak’s browser. But how long will it be before LiveWeb gets its face lift? If Avi Bryant and friends can create a web application as visually striking as dabbledb, it’s only a matter of time before they, or someone else applies the same level of care to LiveWeb.

How long will it be before a complete IDE is delivered as a web application? To varying degrees, Eclipse and IntelliJ IDEA are stuck on the same island that Smalltalk was. They’re all trying to be graphically rich and run on many platforms. They’re all expending lots of resources maintaining UI toolkits (think of Eclipse’s Rich Client Platform). And the resultant UI technology, while often innovative and sometimes pleasing, suffers a “credibility gap” when compared with platform-specific technology on the Mac or Windows. When will the IDE’s throw their weight behind the DHTML+AJAX crowd and embrace the “third platform”?