The other site, which just launched, is my wife’s new art site. She makes wood-fired ceramic sculptures of bizarre, cute creatures, and the new site was hand-drawn by her to reflect their style. It’s implemented as a Wordpress theme, which gives her a much easier way to manage the content of the site, and it also means that she can now blog about her process and other art topics. Check out some of the cool time-lapse videos of her sculpting the critters.

Anyway, that’s what I’ve been up to. Hopefully soon I’ll be able to get back to building more cool things and talking about them, as well as clearing out my backlog of draft blog posts.

Of course, I couldn’t just make the fix and call it a new release. I’ve neglected XBList in the last year as I’ve been deep into work and other projects, but I’ve been accumulating little fixes, and as long as I had the code open today I added a much-asked-for feature: Halo 3 integration. OK, it’s not the best integration, but there are now menu items that link straight to your friends’ Halo 3 Service Record page, and better yet, Halo 3 emblems are now loaded in preference to the old Halo 2 emblems. If your friend has both, they’ll just get the Halo 3 emblem. I was amazed at how many people on my friends list (who hadn’t had Halo 2 emblems) popped up with Halo 3 insignia once I finished the feature. I hope this is enough to tide people over for a while.

I also improved the detection of Xbox.com outages. They seem to be better now, but around December the site was down all the time, and now XBList will be pretty clear about when it’s Xbox.com’s fault that you can’t log in. Hopefully that’ll reduce some confusion.

Please pick up XBList 3.2.0 and let me know what you think! The full changelog may be of some interest also.

The first step is to actually install IIS7. Unlike in Windows XP, IIS isn’t installed by default. That’s great, but it can be kind of hard to find it when I need it.

You’ve got to click this link that says “Turn Windows features on or off” which will (after some time) bring up a big tree of features you can check or uncheck.

You’re going to want most of “World Wide Web Services”. If you are also interested in installing PHP, make sure everything I’ve circled in red is checked. I just added everything to be safe. What’s important is that you have the ISAPI and CGI stuff. I also checked the IIS6 compatibility bit so that installers for things like PHP might have a better chance at automatically configuring things (fat chance).

At this point you can start dropping things into C:\inetpub\wwwroot and everything should be peachy. I don’t put my sites there since I have them checked out into various folders in my Documents folder. So I need to create some virtual directories to point to my sites. This probably won’t work off the bat - you’ll get 403 errors that complain about wrong permissions or something. You need to make sure that the “IIS_IUSRS” and “Authenticated Users” users have read access to the directory. I’m not sure why “Authenticated Users” needs to be there but it made it work. Make it look like this:

At this point your folder should be accessible from the virtual directory, and any ASP.NET stuff will probably work. If you’re not interested in installing PHP, you can stop here.

Installing PHP on IIS7

PHP doesn’t really play well with IIS. However, we can get it going good enough for local testing of your PHP code. First, go install PHP5 from php.net. Choose to install it as an ISAPI extension for IIS, but don’t worry too much, since it won’t work anyway. Now open up IIS Manager. If you’ve followed the steps above (specifically, selecting the correct “Windows features”), your IIS manager should look something like this:

What’s important is that you have the parts outlined in red - the “CGI” icon, the “ISAPI Filters” icon, and the “ISAPI and CGI Restrictions” icon. Those mean the right bits are installed.

Now double-click the “Handler Mappings” icon, and click “Add Script Map…” Fill out the form like this:

Make sure it’s pointing to your real copy of php5isapi.dll. At this point your Handler Mappings screen should look like this:

Also make sure that your “ISAPI Filters” screen looks like this:

If not, add PHP like this:

If you’re running the 64-bit version of Vista like I am, there’s one last thing to do in IIS Manager. Since the PHP ISAPI extension is a 32-bit app, you’ll need to set your app pool to run in 32-bit mode. I’ve already written one blog post on this (to get MySQL working with ASP.NET), and the instructions are the same. Basically open up the app pool’s advanced settings dialog and flip it to 32-bit mode:

If you forget this you’re likely to get errors that look like “Calling LoadLibraryEx on ISAPI filter “C:\Program Files (x86)\PHP\php5isapi.dll” failed”.

If you load up your PHP files you’ll probably get something like “failed opening required” blah blah. This is because the PHPRC environment variable isn’t set correctly by the PHP installer. We’ll have to do it ourselves. Go to the Control Panel and search for “env”:

Now add a System environment variable like this (point it at the directory PHP is installed):

At this point you must reboot your computer to get the environment variable to take effect. Annoying but true. At this point PHP should work, more or less.

I still have some problems with PHP the way I’ve described configuring it. The most obvious is that the IIS worker crashes every once in a while:

I suspect reconfiguring PHP to be run as a CGI handler instead of an ISAPI module would help here, but it hasn’t been annoying enough to make me go change it. Another avenue to investigate is the new FastCGI support that’s available for IIS7.

The other problem I’ve had is that I have a handful of image files in one of my sites that are managed by Subversion and get locked and unlocked pretty frequently. After I’ve committed an image, it loses its permissions and can’t be served from IIS anymore, and I need to go reset the permissions. That’s pretty annoying, and I’m not sure if it’s a bug in Subversion or in one of my SVN clients (TortoiseSVN and Subclipse).

At least this setup works enough to try things out quickly. I hope it helps anyone else who’s struggling with one of these setups.

I went to a lot of shows in college, too, and I was even in my own band, which was at the very least loud. After a couple particularly noisy concerts left me feeling uncomfortable about the idea of hearing damage, I (and the rest of my band) picked up some earplugs.

You may have used earplugs like these, foam pellets that block out all noise. These are great for sleeping through construction or operating loud machinery. But using them at a rock concert completely misses the point. Instead, we went to Guitar Center and picked up some earplugs that are designed for musicians.

I bring my pair with me to every concert I go to. They don’t just block out sound, they actually make concerts sound better. First, they reduce the volume to a comfortable level, not quiet but not painful either. More importantly, they filter out a lot of the “shimmery” noise you get in a big crowd - the random static of the crowd yelling, the echoes of the room, and the highest part of distorted guitars. Once you’ve gotten those out of the way, lyrics become understandable, individual instruments pop out of the noise, and bass becomes richer, without as much rattle. It’s really a better way to listen to concerts. And of course you’re protecting your ears from permanent damage. They are definitely a win all around.

Instead, what I saw in Firefox 2 was:

It actually took me a very long time to get to this point because I hadn’t even bothered to try it out in non-Firefox browsers, since I assumed Firefox was right and I was missing some arcana in the spec. I had tried it out in Internet Explorer 6, but I had taken that as even more evidence that Firefox was right (if it differs between IE6 and Firefox, it’s usually IE6 doing it wrong). However, when I finally popped my test case into Safari 3 and Opera 9 and they agreed with IE, I realized that it was really a Firefox bug. Not too much searching later I came across this css-discuss post which pointed out the bug and offered two solutions. Either I could force my LIs to take up the whole space by setting “width: 100%” on them, or I could use the proprietary Mozilla CSS property “-moz-float-edge: content-box“. Either one made the list items act like I expected them to, though you give up some flexibility with the first method, and the second won’t validate.

This bug has been filed as Bug 163110 since August 2002, and many duplicate bugs or similar-but-not-quite-duplicate bugs have been filed since. Unfortunately, it doesn’t look like anyone is working on fixing it, and I don’t expect to see this problem go away in Firefox 3, which should be shipping relatively soon. I’m just going to have to add it to the list of bugs and workarounds I need to keep in mind whenever I’m navigating the minefield of modern web design.

Update (5/29/08): This has been fixed as of Firefox 3 RC1. Yay!