Archives for category: meta

In my last entry I mentioned that I was starting a journal, where I would write about things I was learning. In the few days since I started it, I’ve already written five entries. I feel liberated by feeling free to write about half-formed ideas (of which I have many) vs. well-formed arguments (of which I have few).

So if you’re at all interested in my writing and don’t mind reading half-formed thoughts, I suggest you subscribe to the feed for my journal. I will probably write here only rarely, when I think I really understand something and want to share it.

Here are the entries so far, to give you a sense of what I’m writing about:

Last Friday I did an RIA weekly podcast (mp3) with Michael Coté of Redmonk and Ryan Stewart of Adobe. This was a fun and interesting experience. Fun because I like Coté and Ryan a great deal and enjoy talking to them and interesting because of the subject matter and also because it was the first podcast I’ve ever done.

There were a few things I said in the podcast for which I’d like to provide a bit of extra context, because it’s difficult in the podcast format to provide a great deal of context.

Network Transparency and Latency

At one point in the podcast, I talk about Jazz‘s early RPC-style web services and say something along the lines of “This is great for the Java client developers because they essentially get network transparency, which is awesome except for the latency.” This is sort of like saying “Not paying income tax is great, except for the eventual fines and imprisonment.” RPC-style interfaces that strive to provide network transparency have the unusual problem that they make remote connectivity too easy for developers. The result, which is almost a cliché, is that developers design applications which are way too chatty and which work fine on local area networks (the environment in which they are developed) but fall apart in wide area networks (the environments in which they are deployed). Later, in the clichéd scenario, the developers learn about explicitly designing the “stuff” that travels over the wire to provide a good balance between the needs of the application and the realities of the network.

Sometimes you just shouldn’t make things too easy. Like you shouldn’t put the car’s ejector seat button where the toddlers can reach it :-)

Why We Didn’t Consider Flash as the Basis for the Jazz Web UI Infrastructure

At another point, Ryan asked me if we ever considered Flash and I said something along the lines of “Well we didn’t select Flash because it wasn’t as ubiquitous as the standalone browser” but after saying this I remember Pat Mueller telling me recently that Flash is the most widely deployed web client technology when you compare it against particular browsers (i.e. browsers in general are more widely deployed than Flash, but Flash is more widely deployed than any particular browser like Internet Explorer or Firefox). So though my memory is a little fuzzy, I believe the reason was that just as a general principle, we didn’t want any core Web UI application functionality depedning on a particular plug-in; for instance, the user shouldn’t require Flash to create a bug report. Another factor was that this was early 2006 so Flash was probably not as ubiquitous as it is today. Yet another factor was our later principle that “look like a normal web page” and some examples of Flash violate this (i.e. the big box of Flash in the middle of the page, or overly ambitious site welcome screens). But I have to say, my thoughts on Flash have really changed over the past two years, because I’ve seen some incredibly useful, subtle applications of it. I can’t think of a particular example, but I know a couple of times some page on Amazon.com had a really cool little visual effect and sure enough when I right-clicked it turned out to be a little Flash app seamlessly embedded in the page. So using Flash in tactical ways where it can provide a powerful but non-jarring user experience is something I would like to explore in the future.

Meeting with the WebSphere Application Server Folks

At one point early in the interview Coté mentions that we hung out and got drinks in Austin one night and I mentioned that I was down for a meeting with some WebSphere Application Server folks and it was also a good opportunity to meet with Coté which is why I accepted the meeting. Listening to the podcast, I feel bad about how this came out because in reality the WebSphere App Server folks were doing us a favor by taking a day off to review the security architecture of Jazz.net and indeed they pointed out both important security and scalability issues. The missing context is that I hate work travel (I repeat hate) because I have two toddlers and they just grow too much and we miss each other too much when I travel without them. So the only time I travel for work is if I really need to be there in person (like if I’m speaking at a conference) or if I can accomplish more than one goal with a single trip. If not for the chance to both do the Jazz.net review and meet Coté, who in my opinion (don’t blush Coté) is both a cool guy and important industry analyst, I would have probably called in.

Innovation vs. Standardization

At another point in the podcast, I mention a blog post by Alex Russell of Dojo where he talks about standards not saving us and encourages browser vendors to provide non-standard innovative features. I think in the podcast I may have come across as “standards don’t matter”. In fact I think standardization is important to build the applications of today but agree with Alex and that the future won’t be invented by standards bodies.

Finally…

Otherwise I agree with everything I said :-)

After some prodding from Pat Mueller and James Governor, I signed up for a Twitter account about a week ago. It’s surprisingly fun.

If for some reason you wish to follow my daily activities, you can do so via the following two links:

Don’t know what Twitter is? Ask Wikipedia.

I noticed on Coté’s blog a few week’s ago that he was using a very big font size.  At first I thought it looked goofy, but after I while I thought to myself “damn if this isn’t easy to read!”  I played follow-the-leader and changed the default font size setting of my WordPress blog from the default 75% (normal letters approximately 10px high) to 120% (normal letters approximately 22px high).  Since then, I’ve gotten a number of compliments from friends and family who can now read the blog easier (and aren’t familiar with the browsers’ font scaling controls).

So unless you’ve got a really good reason to keep your font tiny, why not follow Coté’s lead and make your blog’s font real big?

Based on guidance from James Snell and a WordPress plug-in from Ben Smedberg, I’ve removed the RSS feeds from this blog and replaced them with Atom 1.0 feeds.

Thanks James and Ben.

I’ve had a blog on IBM developerWorks since October 2004. But, I think I’ll do a personal web site and blog to experiment with new technologies that I don’t use at work and also so I have a place to post stuff that’s got nothing to do with my job.