April 2008 Archives

And now a bit of Developer's Notebook-ery.

I have lately been learning the ropes of XNA Studio, Microsoft's free-beer framework for game development. It's especially helpful for those interested in creating software for the XBox 360 game console.

After spending some time doodling the basic class structures needed for the particular project I have in mind, it was time for me to write some tests. Since reading Damian Conway's excellent Perl Best Practices, I've been a devotee of test-driven development: a software-creation work cycle where the programmers write tests for their code even before they write they code being tested.

So you start with a bunch of tests that all fail, and you know your job is done when, however many work-hours later, they all pass. And then you keep those tests handy, so that they'll bark at you if any new code-change you introduce causes older code to break. This is all very good stuff, and I can't imagine working any other way, now.

But while I know all about writing tests in Perl on Unix, I knew next to nothing doing it with C# on Windows. A friend pointed me at NUnit, a Windows-programming port of a popular unit-testing framework from the Java world. Well, great, sez I; sounds perfect. But getting it to actually work for me was a chore. Here is what eventually worked for me.

1. Installed Testdriven.Net, which includes two full versions of NUnit (among a bunch of other testing frameworks).
2. In my copy of Visual C# 2005 Express Edition (a free-beer IDE that Microsoft recommends for XNA development), created a minimal test-using project based on this code snippet from the XNA forums.
3. Manually added a reference to nunit.framework.dll to the project, as per that same post. Used NUnit's v2.2 framework, not v2.4.
4. Launched the v2.2 NUnit's GUI testing application, and had it open the .dll file that the project's build process had created.

I found that trying this with the v2.4 NUnit stuff resulted in a dialog box full of verbiage that I'm currently too Windows-ignorant to grok, but there clearly seemed to be some kind of version mismatch afoot. I got the same message when I tried installing the latest version of NUnit directly. And I haven't been able to get Testdriven.Net itself working - it's supposed to integrate with Visual Studio itself. I am led to understand, though, that the fact I'm using Express versus a commercial edition may be an obstacle here.

I'm curious if things would have been easier if I were using Visual C# 2008 Express, instead of the 2005 version. But, it all works well enough for the nonce.

As threatened earlier, my first use of this blog as a (very occasional) soapbox about the world of web application design and deployment. Particularly when it involves other peoples' work, ho ho.

A colleague from my past recently had bike accident. He got roughed up badly enough to require emergency surgery, from which he is currently mending rapidly. I stayed up to date with his fall and recovery through frequent updates that his wife's been making to a CarePages.com page, and as far as that goes, I certainly appreciate the existence of the channel.

As relieved as I am that my friend will be OK, though, I'm bitterly disappointed with some serious flaws in CarePages' design.

First of all, when invited to the site by an email telling you that your in-hospital friend or loved one has had a new page created for them, you have to submit to a full user-registration process before you can see the page at all. This is pretty bad, since to coming to the site expecting to learn news about your sick friend or family member and seeing instead a lengthy account-creation form is just tacky. But, sadly, it's such a common metaphor across various weirdly paranoid websites (including several newspapers I could name) that many users are inured to this sort of abuse. (And, yes, I did check Bugmenot to see if they had a suitable account, but no such luck.)

Far worse, however, is the site's update-notification system. Once you've registered, you start to receive email whenever the person's page gets updated. But, frustratingly, the email contains no details about the update - only a link back to the website. When you click the link, you have to log in again, because - as far as I can tell - there's no option to keep a session cookie with the website!

And here we cross the line from annoying to incompetent. When a significant percentage of your users are worried-sick friends and family who (depending upon the situation) may be holding their breath with dread every time there's news, what you don't do is announce this news with a content-free email and a link that makes them fumble around for their password when they're too stressed out to type straight.

All these mistakes have been made countless times before by other websites serving a variety of functions, and they're certainly irritating, but I shrug them off. But for CarePages, of all places, to feature them all is entirely inappropriate, to the point where I have to call it breathtakingly negligent. There's no argument that CarePages provides a very useful service - it's a popular site. But they can do a lot to improve their user experience.

So I just used plain old email to wish my friend a swift recovery. Oh, RFC 821: you are much maligned, but you're there when we just need simplicity.

Appleseed has a new phone number: (866) 620-5694. I've updated the contact pages throughout this website to point at that rather than the older number.

The older one was, in fact, my personal cell number. I've used that as my sole phone pointer through my entire career as an independent consultant, and it suited me fine. However, as soon as I launched and began publicizing this new website, I began receiving cold calls from hopeful vendors and other b2b types on my cell, and that just wouldn't do.

The new number will help me better sort and field the increase in call volume that comes with having a new business web presence. It's toll-free from anywhere within the US, so it ought to prove a bit more convenient to my callers as well.

Customers and contacts to whom I freely give my cell number are, of course, welcome and encouraged to continue using it!

Though I wrote the first entry two days ago, I didn't link the blog into the site until just now. Setting it up proved to be a slightly more interesting task than I had bargained for.

The blog runs on Movable Type, my favorite blogging software. (It currently plays second banana to Wordpress in the global blog-infrastructure popularity contest, but it's one hundred percent Perl, and therefore I'm much more comfortable with bending it into the shape I need.) Usually, an MT site runs as an entirely self-contained creature, using its very own templating toolkit and CSS-based styling system to define its look and functionality. However, I wanted it to look exactly like the rest of my site, which uses the Mason templating system, as well as perfectly good CSS that I already had lying around.

I decided to solve this problem by having Movable Type output Mason's templating tags as needed, so that the pages it created would pull from the same HTML and CSS files that the rest of the site uses. Most of the pages on a Movable Type site are static files constructed from templates, so it wasn't difficult to customize these templates to output Mason tags. This is how, for example, the blog's own sidebar content appears as part of the usual appleseed-sc.com sidebar on the right, underneath Appleseed's contact information. That's pretty neat. This page on the Mason HQ wiki provided some good advice.

However, in two spots visible to the blog's end-users - writing comments, and searching on tag names - MT runs CGI scripts to produce on-the-fly page content. Figuring out how to work that into my Mason templates was quite a chore, and took the better part of a day. But in doing so, I ended up learning a great deal about Movable Type, Mason, and Perl's API into Apache 2. The short answer is that instead of calling the CGI script directly, the site makes a separate HTTP request to it, captures the output, runs it through the Mason interpreter, and then presents that to you. It must also quietly pass Cookie and Set-cookie headers around as needed, so that features like the comment form's info-remembering checkbox work correctly.

It was a sufficiently interesting and illuminating task that I allowed myself to keep slogging at it until it was done, even though it was entirely unbillable labor. But (with coaching from my friend and fellow expert Andy Turner) it's done now. Back to work!

(Minor note: to my chagrin, Movable Type's comment form uses different name and id attributes, which is technically not valid XHTML, and causes more persnickety validation programs to tut-tut at me. It's currently the only bugaboo on my otherwise whistle-clean website. I'll get around to finding a fix for it later.)

Hello! Thank you for visiting the Appleseed Software Consulting blog.

I plan to use this space to share updates about the business with Appleseed’s clients (and potential clients). I may also post occasional thoughts about software and other relevant technology here.

I do not expect to post here every day. The best way to stay up to date is through the Atom feed, which you can use with your favorite feed reader. (A popular choice, and one that almost certainly works with your comuter, is Google Reader.)