sesquipedalian spew

Blogging seems to have fallen down on the list of things I need to do, so as a result it has been a while since I’ve posted anything. One of the things I’ve been working on instead of keeping the interweb buzzing with my keen insight and immaculate prose is working on a new website. It has been around for a while, but my cohorts and I finally got around to upgrading the site to a place which we think is good enough to tell the world.

YupNope.com is another one of these Web2.0, ajaxy, opinion sites. Kind of like digg.com or reddit.com. We don’t anticipate killing off those leaders, but when I came up with the idea for the site (on a bus at 7am in the morning last summer), my main complaint with existing sites like YupNope was the complexity. I just wanted a simple site, where I could go, add something to the site and tell the world what I thought about it. I didn’t want to debate my feelings or read through mountains of inane comments on the subject. I just wanted to write something down and vote yup or nope on it. That’s it. Nothing more. And so, YupNope was born.

As it turns out YupNope served a greater purpose then getting us millions of dollars in investment and launching my own personal internet celebrity status into the stratosphere. Although I’m not discounting those things happening in the future, yupnope.com has already served a really good purpose. I’ve been involved in a startup company since 2006 called Starscale Inc.. It has been a part time thing for all the co-founders up until about two months ago when we took a web development contract that I’m working full time on (and getting paid!). Over the last three years, Starscale has built a huge set of code libraries based on the over 40 combined years of industry experience that we have. During that process, we needed a way to test the infrastructure and also explore what was missing. The only thing that could really do that was a real app. That’s where YupNope came in. A simple concept where we wouldn’t have to spend much time on figuring out _what_ the app had to do and could spend most of our time on _how_ we would implement the application in the most efficient, robust and scalable way. And it worked. Aside from the actual code that went into YupNope, we added tons of code to our libraries to do many many things that we hadn’t anticipated a need for. We spent time optimizing javascript, optimizing server side html generation, writing libraries to handle json in an efficient manner and much much more that applied not only to web application development, but to server side development in general.

So we hope YupNope becomes a raving internet success. In fact, that is truly the only way to test the robustness and scalability of Starscale’s platform. But even if no one ends up using the site, it has already earned its keep and to us it is a success.

If you’ve got an opinion, you’ve got YupNope.

I ran across what I believe to be a bug in Prototype last week. It has to do with the Ajax.Request.success() method which indicates if a given ajax request was successful or not, based on the http status code.

I’m currently developing against v1.5.1.1 and in that version of Prototype the success function looks like this.

  success: function() {
    return !this.transport.status
             || (this.transport.status >= 200 && this.transport.status < 300);
  },

I’m particularly concerned about the first operand for the || operator. What this says is that if the transport has a status of 0 or undefined, the request is successful. That doesn’t sound right to me. If the transport status is not available then the request should be a failure. That seems to me the only logical way to handle an unknown status situation. I’m not sure if there is some other thinking behind this. I’ve so far got no response to the ticket I’ve opened on the prototype trac installation.

Here’s what I’ve patched my local copy of prototype 1.5.1.1 with:

success: function() {
    return this.transport.status
        && (this.transport.status >= 200 && this.transport.status < 300);
  },

The function changed slightly in 1.6, but it still has the same issue.

For what it’s worth, I ran across this because Opera appears to violate the XMLHttpRequest specification. Specifically, the spec states with respect to the ’status’ function:

On getting, if available, it must return the HTTP status code sent by the server (typically 200 for a successful request). Otherwise, if not available, the user agent must raise an INVALID_STATE_ERR exception.

In at least one case, when the status is 504, Opera returns transport.status as 0. You can imagine how much my javascript code flipped out when the ajax request was reported as successful, but there was no response data.

Like I said above, I’ve opened a ticket on the prototype trac. Hopefully it will be addressed or explained to me at some point. See http://dev.rubyonrails.org/ticket/10030.

STRP has an excellent analysis of Tim Bray’s chapter in Beautiful Code. I can’t believe someone (even of Bray’s stature) has the gall to say stuff like “If you don’t know Ruby, learning it will probably make you a better programmer“. I’ll remind myself to either skip that chapter or read it knowing it is a biased evangelical Ruby diatribe.

You know you’ve produced a good next version of your product when your development team is actually excited about the new release and finds itself loathing to use use the old version in production because it is too limited. Of course this assumes that the development team actually uses your product in real life.

I’ve been doing quite a bit of web design in my spare time lately and wow, this is so accurate it is scary. I particularly like ‘Time spent trying to get the layout to work with CSS before giving up and using tables’. And of course getting a site to work in IE has been the bane of my existence for sometime.

In June, I embarked on an RV trip to Alaska with my wife, my sister, my brother-in-law and my two nieces. It was a lot of fun and was one of those life experiences I will never forget. We spent three weeks together in a 29ft RV traveling through Alberta, B.C., the Yukon and Alaska. There were lots of animals, beautiful scenery and we all made lots of memories.

Considering I hadn’t spent three weeks straight away from software development since I started working 8 years ago it was inevitable that I would think about RVing and software development and what they have in common.

So I present to you, my list of 10 ways that RVing is like software development.

I don’t understand the concept of sports blackouts. For those of you who don’t watch sports on TV, a blackout is when a sporting event is not televised in the market that it is taking place in. The only possible reason for this would be to encourage people to attend the game live. But I wonder how many people are like me. A minor fan who is highly unlikely to attend a game anyway and doesn’t get encouraged by lack of television access. Instead I become less of a fan. I don’t get to watch the game, I don’t get to follow the team this week (and in football there is only one game per week) and I don’t get to increase my level of fandom. In the end I am less likely to watch future games on TV, attend future games in person and spend any money on team. And to top it all off, TSN decides to televise a game from 2004 with the exact same two teams, Calgary and B.C., thus confusing matters even more. Stupid, stupid, stupid.

Oh yeah, could some one please tell me who won the stupid game.

Update: Arggggh. 45 - 45 in double overtime. So not only has my interest in the team decreased, but I’m now really annoyed that I missed what the reporter called ‘the most exciting game of the season’. Blackouts are stupid.

In another example of Microsoft being more about legal wrangling than software development, Jamie Cansdale has been threatened for making TestDriven.Net work with Visual Studio Express. TestDriven.Net is a very popular unit testing addon for Visual Studio and one that Cansdale earned a Microsoft MVP award for developing. I can’t believe the morons in Redmond are making a stink about this. How stupid.