While I was attempting my upgrade, I figured I’d also look and see where my database space was going since I’ve had to have a size increase a couple of times now and I’m not generating tens-of-megabytes worth of content. The culprits: the subtext_URLs and subtext_Referrals tables. Which is to say, my list of referral sites and the links to the associated blog entries. The URLs table was in the 40MB range, which is pretty out of hand.

I did a quick search to see if this was common and found this entry on Phil Haack’s site from a couple of years back, talking about how to clear the cruft out of these tables. Ran those SQL commands and I’m back into the 5MB size for the URLs table.

Anyway, this serves as a little reminder to give your database a little love and attention. Hopefully we’ll offer more in the way of an admin interface for these sorts of things in Subtext 3.

Well, I gave it the old college try, but I ended up pretty well trashing my site in the course of my attempt to upgrade to Subtext 2.0, so I had to get restored from backup. Yow!

There seemed to be something odd to begin with when the upgrade process wouldn’t run - it sort of locked me out of the site. I got around that only to see it say I needed to “install,” not “upgrade.” Ummm… well, OK. So I did that. The database got upgraded, but then I hit the final wall: I’m in a medium trust environment and the build won’t run in medium trust.

Looks like I’m not the only one having a problem.

I guess I’ll have to see if I can help rectify some of this.

I love playing Rock Band, and when I get the chance to play, I usually play drums.

I’ve seen this kit from Ion in some of the game magazines and on web sites, but I finally found the official site for it: the Drum Rocker kit from Ion.

It’s an actual drum kit from a real drum manufacturer that has a controller box you can swap for either control by Xbox 360 or an Alesis DM5 module, making it useful in an actual drum kit capacity. Not just for gaming anymore!

Admittedly, I play on medium difficulty. I’m no expert by any means. But the noise the standard drums generate plus the sometimes questionable accuracy plus the fact that I’ve always wanted a drum kit… sort of sounds like it adds up to this.

I damn near clicked that pre-order button just now. Just the $300 price tag stopped me. It may not stop me for long.

Something I’ve noticed as I work with developers of varying skill levels is that one of the key differentiating factors between the junior folks and the senior folks is the ability to think in the abstract - that is, patterns and concepts, not concrete implementations.

How many times have you been one of the people in this conversation?

Senior Developer: OK, so the task at hand is to create a Doorman that works in a hotel or apartment building. We know he’s going to hail taxi cabs, handle the door for people, make small talk, and do a few other things. Today we’re just looking at the door handling part.

Junior Developer: What kind of door is it?

SD: It really doesn’t matter, and we won’t really know until the Doorman gets placed somewhere, so we need to be flexible. What we probably should do is have an interface like “IOpenDoor” with an “OpenDoor” method. Then we can provide any number of implementations to that to handle different door types. (This is the strategy pattern.) The question on the table is, “Does the doorman need to do anything else with the door besides open it?”

JD: What if the door is heavy?

SD: It doesn’t matter - that’s an implementation detail. What we’re looking at here is the pattern. Like, we know the Doorman needs to open the door, but does he need to close it, too? Should it be “IDoorController” with “Open” and “Close” methods? Or do we consider all doors to be self-closing?

JD: If the door is glass and the Doorman kicks it closed, he might break the door.

SD: Um… OK… right… but really we need to look at the pattern here. Is it the right way to go? Are we missing something around the Doorman’s interaction with the door that we should know about?

Another Senior Developer: The door might be open due to some other action, but the Doorman might be requested to hold the door, so we might need a “HoldOpen” method on that interface.

SD: Good point. That’s a door state we didn’t consider.

JD: What if the door has a knob instead of a handle?

SD: Step into my office.

Now, I’m not saying that all junior developers are unable to think in the abstract, and I’m definitely not saying that all senior developers (or at least people with a “senior” title) can. What I’m saying is that the ability to think in the abstract is key to being able to step beyond simple coding and into the world of development.

Working on some localization stuff, I’ve come across the need for resource assemblies to be created from .resx files in a post-build step - I have the .resx files, but I don’t want them at all to be attached to my application. I just want them built into a tiny hierarchy of resource-only assemblies so I can get a ResourceManager on them and have string lookup behave as expected.

I also find that sometimes I need to recompile .resx without recompiling the whole app and I forget the command-lines to do all that.

The overall process:

1. Convert your .resx files to .resources files using resgen.exe.
2. Link your .resources files into assembly format using al.exe.

Again, what I’m showing here assumes that the assemblies you’re compiling are resource-only - which is to say, there is no code to compile and you’re not linking resources into existing assemblies.

For a culture-neutral (default) resource-only assembly, you’ll use:

resgen.exe "Path\To\Culture\Neutral\Strings.resx" "Path\To\Output\Folder\Strings.resources"
al.exe /embed:"Path\To\Output\Folder\Strings.resources" /out:"Path\To\Bin\Strings.dll"

The first command line generates the .resources file from .resx and puts it in an output folder. It doesn’t really matter where the output folder is; it’s a temporary place to store the .resources file before it gets compiled into an assembly. The second line links the .resource file into assembly format and puts it in your application’s “bin” folder, where you can start to consume it.

For a culture-specific resource-only assembly, you add culture-specific parameters and output locations into the mix:

resgen.exe "Path\To\Culture\Specific\Strings.es.resx" "Path\To\Output\Folder\Strings.es.resources"
al.exe /c:es /embed:"Path\To\Output\Folder\Strings.es.resources" /out:"Path\To\Bin\es\Strings.resources.dll"

In the above example, we’re compiling general Spanish resources, as noted by the “es” in there. If we wanted Spanish specific to Mexico, we’d use “es-MX” as the culture. The key differences to note:

• In the .resx and .resources files, we specify the culture before the extension. While this isn’t mandatory, it is standard convention and helps you keep your source .resx and output .resources files organized.
• In the al.exe command line, we add the /c: parameter to specify what culture we’re linking for and we put the output assembly in a folder under “bin” that is named after the culture we’re linking for. We also add “resources” just before the .dll extension so the ResourceManager knows it’s a resource assembly. (You don’t do that for culture-neutral resources, so you didn’t see that before.)

This is pretty easy to do in a Visual Studio project post-build step, too:

"$(VS80COMNTOOLS)..\..\SDK\v2.0\Bin\resgen.exe" "$(ProjectDir)\Strings.resx" "$(TargetDir)Strings.resources"
"$(WINDIR)\Microsoft.NET\Framework\v2.0.50727\al.exe" /embed:"$(TargetDir)Strings.resources" /out:"$(TargetDir)Strings.dll"
"$(VS80COMNTOOLS)..\..\SDK\v2.0\Bin\resgen.exe" "$(ProjectDir)\Strings.es.resx" "$(TargetDir)Strings.es.resources"
"$(WINDIR)\Microsoft.NET\Framework\v2.0.50727\al.exe" /c:es /embed:"$(TargetDir)Strings.es.resources" /out:"$(TargetDir)es\Strings.resources.dll"

Note we had to specify some paths to resgen.exe and al.exe because the post-build step isn’t run as part of a Visual Studio 2008 command prompt environment.

Obviously, change your paths and parameters as needed, but the above compiles and links a neutral and a generic Spanish “Strings” assembly in a post-build step.