Who says there are no memorable theme songs anymore?
(March 28th, 2006 - 10:44PM)
Richard wrote a theme song for Steve Kwan dot com. I am at a loss for words. This is the funniest thing I've ever heard.
Correction: this is the second funniest thing I've ever heard. The funniest thing I've ever heard is still the time I was asked how well Yahoo! can index the second page of a paper document.
I know I already linked to his site once in this post, but I'll do it again because he's earned it. See Richard's site: I, Dickolas Wang!
I've gone through the tedious process of tagging the three years worth of postings on Steve Kwan dot com with subjects, and I've written a PHP script that lets you browse these postings by subject.
Right now, the script isn't very intelligent. It just displays all the postings by subject. I want to add some features, such as the ability to view a single subject only, and the ability to cache the output so it doesn't need to be generated every time it's requested. But for the time being, it's certainly a more convenient way to browse my archives.
I've been putting three months of blog postings on a single page. I'm going to change this to one month per page so that my readers won't have to download gigantic text files when they come to the site. If you actually know what I'm talking about, I hope you agree that this is a good idea.
I've decided I like Ajax, and here's why: it's a JavaScript methodology that lets you minimize your use of JavaScript. (For those of you unfamiliar with Ajax, read Jesse James Garrett's article, "Ajax: A New Approach to Web Applications.")
I'm not going to pull any punches here: I hate JavaScript. It's a lousy technology that's difficult to work with and difficult to get right. Applications with large portions of JavaScript tend to bloat out of control and become difficult to maintain. Unfortunately, there are some tasks that are best done through JavaScript, so it's difficult to avoid it. Until now.
Ajax (or Asynchronous JavaScript + XML) allows you to render specific areas of your page on the fly with server-side content. I won't explain in more details, because articles such as Jesse James' describe Ajax far better than I ever could. Essentially, the idea is this: when you click a button or some other event occurs, instead of executing a huge pile of JavaScript, the user's browser simply executes a small snippet of JavaScript that sends a request to a server and displays the response. Although it's possible for the JavaScript to do fancy rendering on the server's output, it's not necessary. You can very easily just download content from the server and display it exactly as-is.
Ajax simplifies a lot of common Web development problems. For example, have you ever attempted to validate user input on a Web form? A common solution is to implement a browser-level check in JavaScript. However, you also have to implement the same validation routines on the server, just in case the user has JavaScript disabled or is maliciously trying to bypass your controls. This means you've got the same logic in two places, which is error-prone and time-consuming. However, with Ajax you only need to implement your validation routine on the server. The JavaScript can simply call the server's routine and display the results to the user instead of trying to validate input itself.
Although the purpose of Ajax is not to minimize use of JavaScript, it certainly makes doing so easier. That's why I like it. No longer are you required to develop tons of software in some unsophisticated, weakly-typed language that is always open source and behaves inconsistently on different browsers. You just need to write enough JavaScript to download and display output from a server. And you can do so asynchronously, which means that the user's browser won't freeze while waiting for a response.
For an example of Ajax in action, see My experiment with Ajax. The "show comments" link calls a simple Ajax routine that asynchronously downloads comments from my server and displays them when the results are retrieved. I actually implemented some display-generating JavaScript instead of just displaying the server output as-is, but I could have very easily implemented this on the server instead, thus reducing the amount of JavaScript needed. View the JavaScript source if you're interested.
One sentence summary: A book that oozes Web 2.0 in every sense of the term.
Ben Skelton recommended I read Getting Real, a new book by 37signals. On a side note, this is the first time I've linked to Ben's blog. Ben, if your PageRank goes up because of this, you owe me.
Getting Real is the first book I've read that was written by a company instead of a person. I knew that corporations were people in the eyes of the law, but I had no idea they could also author their own books. Anyway, there's a reason for this: Getting Real is half book, half advertising. In addition to being a collection of ideas for modern Web development, it's also a not-so-thinly-veiled attempt to showcase 37signals' line of Web products. But don't worry, that's not as irritating as you might think.
Getting Real is a definitive "Web 2.0" book (ugh, I hate that term). The book itself isn't published in physical form; it's only available in digital (PDF) format. At first I found this a bit odd - do you really want to buy a book that was never formally published? - but then I found out that 37signals decided on this approach because it's consistent with the goals of Web 2.0: fast, agile over-the-Web deployment. Once you get past the fact that Getting Real isn't available on any bookshelf, it's actually quite a convenient method of delivery.
Over-the-Web delivery isn't the only thing unique about Getting Real: it's also a very frank, very practical discussion on modern Web development. The book highlights some of the best practices 37signals uses to develop their widely acclaimed Web products, such as Basecamp and Backpack.
The authors openly acknowledge that these practices aren't a "one size fits all" solution. They're most appropriate for small, agile Web companies like 37signals. More traditional software houses may not benefit from (or agree with) the suggestions in the book. And I like that. Too many books in this genre try to provide general methodologies which should work in any institution. The problem is, most of these methodologies wind up being so general that they don't really give you any concrete advice. Consistent with the goals of Web 2.0, Getting Real is capitalizing on The Long Tail: instead of trying to provide a general solution that works for everyone, it provides a concrete solution that works for a very specific niche of developers.
The book clearly lists specific suggestions for Web 2.0 developers. Some of them are common knowledge. Many of them are quite insightful. There were certainly some good ideas I'd never thought of before. For example:
Underdo your competition - don't load your application full of unnecessary features.
Don't just ask your customers what they want; also ask them what they don't want.
My only complaint about Getting Real is that it draws from a very narrow base of experience. The ideas presented in this book are the opinions of a single small company, not the result of years of research. As such, many of the ideas have not yet been proven. It might be dangerous to haphazardly base your development methodology off of Getting Real. However, this narrow focus is what also makes the book worthwhile, so take this complaint with a grain of salt.
I certainly recommend Getting Real. It provides fresh perspectives for Web developers, and it practices what it preaches. The format of the book and method of delivery are consistent with the principles inside, and to me that's worth something. The book itself is a case study on how effective the principles it describes can be.
The commercials said that someone was going to die on this week's episode. I figured it was going to be someone new and insignificant. At first, I thought I was right: Lynn McGill got wiped out. And it was quite touching. I thought that was the worst that would happen.
And then, at the end of the episode, Tony got killed.
For those of you who follow 24, you know that this is a big deal: Tony was one of the few remaining characters from the first season. He's been a central character on the show since its debut in 2001. With Tony out of the way, the only character left from the first season is Jack. And yes, I know that technically Kim was from the first season, but she's annoying so she doesn't count.
Without Tony, it's just Jack and a bunch of newbies. I don't know what'll happen now; so many characters have been getting killed off that pretty soon there won't be many left.
I've been using Gillette Power Stripe deodorant lately, and I must say I'm impressed. Works really well. But it's got me asking: why do I only get a stripe of power?
Is it too much to ask that I get a full stick of power? Considering how well the power stripe works, I figure a full stick of that power would be the best deodorant on the market. Why doesn't Gillette market a full power stick? Can the human underarm not handle that much power?
It's amazing how a software product can take on a life of its own.
I'm referring to the bizarre phenomenon where a piece of software can grow and expand into something that the developers didn't even think of. It's amazing how the intended use of a product can be so different from its actual use.
There are cases when this is beneficial. I can think of examples where people discovered things they could do with WebGENCAT that the developers never even thought of. It's quite a humbling experience when one of your users calls you and teaches you something about your own product.
However, most of the time the discrepancies between developers and users aren't so positive. Generally, when the users are zigging and the developers are zagging, the result is software that doesn't work as advertised. That's why it's important to work with your users so you can create a product that behaves as they expect.
I've certainly worked on projects where the developers think they know better than users. I've seen managers make software decisions based on nothing but their own experience: "I did it this way in the past, so I'm doing it this way again." The results of ignoring what your users want are disastrous.
Modern software development is a much different field than it was in the past; "if it ain't broke, don't fix it" no longer applies. Experience is still tremendously valuable, but the most valuable decision-making tool you have is your user's opinion. When making decisions in a software project, be sure to remember that what the user wants trumps your own personal feelings and thoughts.
I was writing an essay on the intended vs. actual use of software, but before I post it I'd just like to note that there is something odd going on with Vancouver weather.
It's snowing outside. And it's March. It's snowing in March. Does that seem just a little bit strange to anybody? It didn't even snow during Christmas, and now there's a few inches out there.
I'm going to attempt to sleep; I'll be training a new user at work today. Hopefully I'll get my software essay up here soon.
Wow. If you're not interested in anything on the Internet, you must not have many interests.
I can't imagine being without Internet access. On a few occasions, I've had to go offline for a day or so. I distinctly remember waking up one such morning, realizing I couldn't go online, and pacing around the house for hours looking for something to do. Pretty sad, actually.
Edgar, you fat magnificent bastard, you left us too soon.
Last night, Edgar Stiles was killed in a terrorist attack when nerve gas was released into the CTU headquarters. Even the mighty Jack Bauer was unable to prevent the attack. But now that Tony is conscious again, the terrorists had better look out.
Edgar was the stereotypical lardy computer geek, and reminds me of many Linux sysadmins I know. He will be missed. 24 won't be the same without his larger-than-life screen presence. Seriously, the dude takes up half the camera.
I believe that diplomacy is really important in interpersonal relationships. So many people are quick to fly off the handle and express their anger (how DARE you do something I don't approve of!). However, too few people are willing to approach conflict in a calm, rational manner. Sometimes I wonder if people are more interested in finding solutions or just venting.
I try to be diplomatic whenever possible; however, I find that it's getting harder and harder. I know how important it is to solve problems and take the higher ground in arguments, but some people are just so unreasonable.
Once in a while I just want to freak out and yell.
I know that nobody but Richard and I watches Saturday Night Live these days, but that's a shame because this week's episode had a great SNL Digital Short starring Natalie Portman. Take a look.
The (HUGE) old guy who works out in really tight underwear.
The guy who left a brown-stained pair of tighty whities on the shelf where everyone puts their water bottles.
The old lady who is always waiting for me to finish up at a station. Seriously, it seems like every time I sit down, she's right behind me waiting for me to get up and move on.
People who don't understand what a weight training circuit is, and sit on the abdominal machine for half an hour.
The cleaning crew dude who wasn't looking where he was going one day and accidentally punched me in the crotch.
The creepy fat firefighter dude who asked me if I wanted to sit on his lap.
The guy who sprays his boxers with Axe.
The weird dude who shows up on co-ed day and hits on the ladies in the swimming pool.
The scrawny Asian guy who flexes his tiny arms and admires himself in the mirror.
Do I complain too much, or are those complaints justified?
I'm convinced. In particular, the Aero Glass interface sounds like a good idea. You know how when an application is busy and you drag another window over top of it, part of the busy window goes white and doesn't get re-displayed until the application is finished thinking? Sounds like that problem is going away.
Let's be friends!