Photo: Geraint Otis Warlow

For quite a few years now, I've used Microsoft's HTA setup for doing quick, standalone applications in HTML and Javascript. Most of those have been for my own use, in large part due to the fact that changes in the Windows security policies mean that if you distribute them, you don't really have a great chance of them working on other people's machines.

Along the way, a few other solutions in this vein have shown up as well. Webrunner is based on the Mozilla platform and works particularly well if your application will reside on a web server and you just want to provide a custom client for it. Webrunner is cross-platform (which HTA's aren't), but doesn't provide much access to the local machine. The "sandbox" that it is able to operate in is pretty much exactly the same as a regular browser.

However, when I saw Adobe AIR (with Linux support planned) being reannounced after the recent renaming from Apollo, I gave it a closer look. Adobe's AIR gives you that same build-it-in-JS-and-HTML approach, with installable final applications. Further, it provides some additional API's to things like the local filesystem.

That feature leverages both sides of the technology. You've got all of the web and the best of the desktop all in one. If you look at the samples page, you'll see a variety of stuff that just doesn't work in a regular browser. I'm messing with ScreenPlay for use in screencasts to do that play-by-play highlighting of what's going on on the screen.

Now, when Apollo was announced, one of the reasons I didn't do much with it was the same reason I have a love/hate relationship with XUL: creating projects was a major pain. I'm perfectly OK with writing code by hand (it's usually what I prefer), but I hate having to stub in dozens of files just to get a "Hello World" project up and running.

So, Aptana's, recent addition of AIR support in their IDE caught my attention and I gave it a spin.

I have to say, I'm impressed so far. It was really easy to set up a basic project, run it from the IDE and build an installable AIR file. In short, their support for this framework lets you focus on writing your application instead of setting up the project and environment. Very nice.

This offers some real possibilities for some of my project ideas, particularly where the client side of the client-server equation needs to be a bit richer or should really be a dedicated client instead of sharing the web browser.

For instance, I really prefer to use a dedicated application to do the writing on this site. All too often, something can go wrong when you just type into a web browser's text box and you lose a bunch of content. However, a nice desktop application, with local saving of drafts fixes that. If I can whip something up that also uses SVN to version and share those drafts, I think I'll have my writing environment. And, AIR with Aptana looks like it might make that easy.

Photo: Danny Hope

I just got an email from someone complaining about an email they got from me. Well, actually, they got it from this site on my behalf. At their request.

It was an updated comment from a post. The only way you get one of those emails from this site is if you post a comment AND check the box that says to send you an email when someone else comments.

Now, it happens that people forget that they clicked that check box (unchecked by default, by the way) or clicked it accidentally. And, people don't always see the link at the bottom, indicating how to unsubscribe.

As a result, I have no problem with people asking how to unsubscribe. However, this morning's email highlighted something I've noticed over the last few years: the definition of spam has shifted.

This person's email complained, in decidedly unfriendly terms, about their intent to report the "spam" if I didn't unsubscribe them immediately.

Originally, "spam" referred to:

1. Unsolicited. The recipient didn't ask for the email.
2. Commercial. Though not part of every definition, the commercial nature of the message was a large part of what made a message spam.
3. Email

However, I've gotten this "stop sending me spam" complaint about individual, personal emails, about mailing lists (with double opt-in subscriptions), and even product receipts.

Over the last few years, though, I've watched as nearly every non-techie out there has apparently decided that "spam" actually means:

Any email I wasn't expecting and am not happy about receiving.

How exactly did that happen?

Photo: lui

[[FYI, this has been sitting in my writing queue for a while. I took a quick look at it and am shoving it out the door. Let me know if it's deficient and I'll fix it. Consider this version 1.0 of the article.]]

Ever since I spent my time in the technical writing trenches right out of college, I've been interested in doing my writing in a single format, generating whatever target formats from that.

At different points over the ensuing years, I've been drawn to Docbook as that single format. It's SGML/XML, first of all, which makes it relatively easy to write in a text editor. It uses XSLT to transform to other formats. It has pre-built toolchains for outputting HTML, PDF, etc. Also, it is easily versioned using Subversion.

As an additional vote of confidence for using Docbook is the fact that O'Reilly has been using it for many of their recent books. They're actually also storing their content in an Atom Publishing Protocol repository. That's another vote for where my intuition about a personal publishing stack has been leading. When written content is stored in a robust container (DocBook or Atom, etc.), you can repurpose it.

Technical documentation doesn't always work in every format (which is why many of the single source experiments in that space failed). However, for things that *do* work in multiple formats, the technology for producing those formats gets in the way. Not so with DocBook.

Now, while I've looked into it at several different points, I've never really dug into it well enough to get much done with it. I set out over the last couple of weeks to actually get completely up and running with Docbook. This time I powered through and got it working. I suspect that the motivations were more concrete this time

Along the way, I discovered that there wasn't a tutorial that matched what I was looking for. I also found tutorials that had non-functional code. However, despite that, I was able to get a basic Docbook book up and running and figured out a much simpler way to get started with Docbook, so I figured I'd share.
Read the rest of this entry »

I love movies. After technology and computers, movies are probably my 2nd favorite hobby. Between the theater a few times a month, Netflix and my own collection of 500+ DVDs in my home theater, I watch more than my fair share of movies.

Quite a few years ago, I started watching a variety of movie reviews in order to better choose which movies to watch. I quickly came down to Roger Ebert and the various co-hosts he's had for his TV show. Now, I rarely bother with anyone else's opinion.

Now, that's not because I always agree with Ebert. Far from it. However, after all of these years, I can tell fairly accurately, based on Ebert's opinion and Roeper's counterpoint or agreement, whether I will like a movie or not. I've never been too concerned with their "thumbs" rating system, as it's mostly a gimmick to get you to read or watch the more in depth reviews.

That explanation of *why* they gave it a thumbs up or thumbs down is usually exactly what I need to determine whether I'm willing to see a movie or not. Heck, some of his most enthusiastic reviews have been for movies I absolutely hated, but I wasn't surprised when I hated them because of why he was enthusiastic.

Unfortunately, I'm often looking at a DVD on Netflix or in the store or on Amazon, wondering what his review was, 6 months or 2 years ago or whatever, when the movie was released. The current episodes of his TV show are great for deciding which movie to see in the theater this weekend, but don't help so much for a movie released last year that is for sale for $12 at Amazon.

That's why I think it's very cool that they've put up pretty much every one of those TV reviews since 1985 and a bunch of stuff that goes back as far as the beginning of that TV show, in 1975. With that archive, I can now pull up those older reviews easily.

Very cool and puts value on that huge repository of video footage that isn't easily monetized in any of the traditional ways. It's not like we're going to buy DVD box sets of 30+ years of movie reviews. Nor are we going to tune in for old re-runs of reviews from 1991. However, to look up a movie you've never heard of or to see if that DVD on the discount rack might be a hidden gem, it's definitely useful.

For the past few years, I've been making a concerted effort to question my own assumptions and the assumptions that our culture makes and presents to me. In so many places in life, when you directly examine the "conventional wisdom" about a given subject, it just doesn't stand up to scrutiny.

Over the last couple of weeks, this particular theme has been popping up (which is to say that I've just been noticing it where I've been looking) a lot. In many places, we seem to rely on what we *think* is true rather than actually investigating and determining what actually *is* true.

In many cases, this is because the conventional wisdom is something we're attached to. Take for instance, the idea of creativity. This old article on the myths of creativity (linked from Lifehack.org a couple of weeks ago) lists as #3 in their list the idea that creativity thrives under pressure.

I've heard that hundreds of times from all sorts of people, that they just do "better" work when their scrambling at the last minute. Heck, for a long time, I believed this one myself. The thing is that when you actually study creative output, it just isn't true.

Similarly, Marc Andreessen pointed out an analysis of the concept of "brainstorming" as a group. Again, if you analyze it rationally, having everyone in separate rooms coming up with ideas results in not only more ideas, but better ones as well than having everyone in a room.

On this one, I suspect that the "feeling" of brainstorming as a group gives the impression of higher productivity. It's probably also linked to the fact that in most offices, if you ask people to go to their desks and come up with ideas, they usually get bogged down in unrelated work. That doesn't change the facts, though. It just points to needing to handle brainstorming sessions in a more intelligent way.

Have everyone spend half of the meeting spread out coming up with their own ideas and then bringing them all together later. Don't send them back to their desks to get distracted. Just keep them on task, but brainstorming as individuals.

Some other conventional wisdom comes out and becomes pervasive because it's what we want to believe. A recent book, Myths of Innovation looks at one such area. We all (especially the press and blogs) want to believe in the idea of all innovation coming in that garage-in-the-wild-west, burning-the-midnight-oil, eureka-moment version of innovation. The truth is much less sexy. I'm not done reading this book yet, and have only been able to listen to a few minutes of this podcast interview with the author. However, all of it keeps resonating this same chord with me.

I'm definitely digging this trend, even if it's just that I'm finally noticing it. This stuff is striking me the way that Stumbling on Happiness did. It gets me in a mindset to think through my habits and the things that I take for granted. It makes me question my beliefs about practical matters like happiness, creativity, productivity, morality, work, etc. I like that.

It all feeds into the general approach to life that I've been taking lately which is that many of these issues require that you quit relying on the lower/older portions of your brain to make decisions and plan, instead using the top. That's mostly a debate between snap judgments and rationally examining a situation. It's clear to me how much of life comes down to the battle between the top and bottom of my brain.