Archive for May, 2006

This Post Requires a New Category

Updated embarassing mis-spelling of Category

I have a question for my reader(s). Do you ever wake up in the morning and think to yourself, “Damn, I am one kick-ass son of a bitch?” Well I used to, until I found the blog of Justice Gray.

I’ll let that sink in for a second.


Are you thinking what I’m thinking?

Fucking Justice?!? Are you kidding me?!? That is the raddest name in the history of rad names. If radness were a monster, Justice would be the King-fucking-Kong of rad. The emotions I’m feeling right now are… (Livejournal moment)

  • Disbelief
  • Awe
  • Jealousy
  • Radness

That is all.


Ajax Through My Eyes

I swore to myself a while ago that I wouldn’t write anything about Ajax, but I’m about to break this promise, mostly due to writing like this, and other various bits from around the web that quite simply just don’t appear to make any sense. So here are my thoughts, which are based on theories untested and mysteries unsolved.

First off, what is Ajax? Well, despite the capitalization, it’s an acronym coined in an Adaptive Path article written over a year ago, after Google released GMail and everyone started diving into their javascript source code to figure out how they did all that fancy page refresh stuff. It stands for “Asynchronous JavaScript + XML”, which is somewhat misleading for reasons explained later.

At the core of Ajax is one simple little javascript object called XMLHttpRequest. Peruse the article from Apple in the link I just provided. It describes the history of the object, it’s methods (or messages, Vlad), properties, and has some small examples on its usage. Passing the article through Jeff’s Super Information Condenser produces the following output:

  • XMLHttpRequest has been around for many years, first in Microsoft’s IE as an Active-X object.
  • The object is now supported in some form by all major browsers in use today, with some quirks.
  • There are two methods of interest. open(), which prepares a connection to a URL, and send(), which makes a request asynchronously (most of the time) to the URL.
  • There are a few properties of interest as well, namely onreadystatechange (an event handler you pass a function to), readyState (the current state of the object), and responseText (which is the actual response returned by the request to an URL)

Passing the condensed information through Jeff’s Even Superer Information Condenser, we end up with this:

At the core of Ajax is javascript’s XMLHttpRequest object, which lets you make and manage asynchronous requests to a server.

Notice how my Information Condenser says XMLHttpRequest is “At the core of Ajax.” So what else is Ajax comprised of, you may be asking yourself? Well, to answer that question, you’ll have to go back and re-read the Adaptive Path article I linked to above. If you want my version (which I’ll assume you do, because I’m like that), here goes: No one fucking knows.

My take on Ajax is basically that Ajax means using XMLHttpRequest to get information from a remote URL without doing a full page refresh. Exhilarating, eh? Which kind of makes me wonder why we have full on “Ajax frameworks” like Atlas, replete with special updatePanels and Control Toolkits. I personally fail to see why it needs to get so damn complicated. Maybe it’s time to play around with it a little bit to see what the big deal is.

Being Agile is Hard

Scott Bellware is having some “fun” over on his blog trying to explain why he is a fan of, and practices, Agile development. He’s frustrated because, in his experience, many people have misconceptions about what TDD, XP, Scrum, etc actually are, and then go on to attack these processes based on these same misconceptions.

Keeping to that theme, I’ll present a few of my observations. First, some background about me.

I started my life as a developer very recently… I graduated with a Computer Technology diploma in late 2002. One of my instructors happened to be Grigori Melnik, a Russian robot without an “off” switch. He had us pair-programming on assignments, and writing simple tests before we wrote our implementation. He also spoke a lot about XP practices, so you could say that I was indoctrinated right from the beginning.

So you’d expect that when I entered the “real world” of development, I’d dive right in to using these same Agile processes, right? Well, no. I can honestly say that I was mostly convinced of all the benefits, but actually practicing them was hard for the following reasons:

  • Tool support sucked. Unit testing wasn’t integrated into Visual Studio, and there was no refactoring support at all.
  • I had difficulty working with others in a pair. Communicating is hard, and takes practice, especially when you’re in a new field.
  • Writing tests from scratch is very hard, unless you’ve got some mentoring.
  • Coding by yourself can be almost therapeutic. Pop in some headphones, crank up the Styx, and get in the groove, baby.

For these reasons, I never really rocked out to the Agile beat. I knew about it, I had been around it my entire programming life, but it never really took hold. This is where we come back to the part where I get on topic. In Scott’s post I referenced above, he states how he’s basically come to the conclusion that Agile cannot be taught or evangelized through the written word. So he started teaching courses and speaking at user groups. Walking people through it. Letting them try stuff out under an experienced watchful eye.

I think this is the only way someone can really get what an Agile practitioner is talking about. If someone like me, who came into the development world after XP and Scrum had been developed, who had instructors teaching me this stuff from the get-go can’t latch onto the concepts without help, then what are the chances experienced developers are going to latch on? They’ve been pumping out code for years, probably doing quite well for themselves, so why change? How many other “red pills” have come along in their time, only to be shat out the other end without the promised effect?

All I can say to Scott is to keep doing what he’s doing. It probably does make a difference to many people, and may even help them code better. But even with all the benefits, there will be those who just will not be Agile. We’ve offered at least a few people jobs on my current project, only to have them take one look at “The Pit” and say “This just isn’t for me, sorry.” I remember showing our workspace to some former co-workers. They stared around at our expansive setup for a while, until one of them said, “I have way more space in my cubicle.” Whoa. Touche.

Help Me Meet My Doom

Are you male? Do you like to drink? Do you like to drink excessively? How about boobies… Do you like those as well? What about public humiliation of others? Well, if you’ve answered yes to any of those questions, then I’ve got a proposition for you:

Come to my stag.

If I know you, you’re invited. But be prepared to write off the entirety of this coming Sunday, and possibly Monday as well. Bring friends if you wish, but no females allowed (unless they’re strippers).


Once we’ve had a few drinks at The Point, we’ve got a bus that’ll take us to The Roadhouse sometime after 10:00pm. There’s no obligation to pay for anything, other than your own booze, however if you take the bus we’ve been advised that we should tip the bus driver (I’d say ~$10 each is pretty fair. Cheaper than a cab by far).

I also need to emphasize that this will be your last chance to party with me. Once I’m married, I’ll become a soulless automaton endlessly repeating the words “Yes, dear,” with an invisible leash around my neck that gets inexplicably yanked whenever I look at foreign booty. You’ve been warned.

If you’ve got any questions, please ask them using the Comments form on this page, so that everyone can see the responses. Feel free to pass the link to this page on to anyone we may have forgotten to notify.


Naming Unit Tests

Paul Gielens over on the ASP.NET weblogs has recent post talking about naming patterns for unit tests. He mentions the following naming pattern:

  1. Context
  2. Stimulus
  3. Result

That sounds awfully familiar to what we’ve been taught to use on my current project:

  1. Setup
  2. Execute
  3. Verify

Each test has one method (or system) under test, which is the “execute” step noted above. We test this method once, after we’ve written our setup, and then we verify the results are as expected. Our test names always contain the execute step, and then we’ll usually have a quick little description after that to describe how a test is different from another (the setup):

		public void testSearchUsersByName_NameIsNull()

I much prefer our naming to “Context, Stimulus, Result”. That sounds more like the scientific process the skinny grey aliens use when they probe us. I don’t really know that, but I’m just saying…