It’s got a nice “lobby room” soundtrack playing, a slick “killer robot arm” that simulates tracking on the reader, menus about the latest weapons and events in the game and–
oh, wait: it’s a serious website, intended to fill “the coming need of defenses against autonomous military robots”.

The most tantalizing parts are the “Tools” and “Services” menus, which “require authorization with your key card for access”. Yes, that ubiquitous keycard we all carry, savior of heroes like Solid Snake and..wait, what?

Ooh, I see. Started by a teenage dot-com billionaire, responsible for such amazing innovative sites such as “tracking your own personal timeline”, “environmentally-green plumbers”, and the “post over IP protocol”(enabling one to send snailmail..over the INTERNET).
Truly another excellent addition to the pantheon.

(Found via El Reg, of course)

Builder’s docs seem to imply that a namespaced tag always needs to be in block form:

xml.bqcm :UselessMetadata {|n| n<< "flue"}

or

xml.bqcm :UselessMetadata do xml.text!("flue") end


But you’ll end up with wonky indenting because Builder is sensibly expecting that you should take care of the whitespace yourself when using this form:

<bqcm:UselessMetadata>
flue
</bqcm:UselessMetadata>

The clean way to do it is giving the symbol as the first argument:

xml.bqcm(:UselessMetadata, "flue")

which provides:

<bqcm:UselessMetadata>flue</bqcm:UselessMetadata>

EDIT(2:18pm)
“But what if I have attributes AND a simple text value?”
Just make sure the attributes are sent in an explicit hash as the second parameter:

xml.bqcm(:UselessMetadata, {:QuestionableAttribute=>"chimney"}, "flue")

“I still want to send my text like I was doing, and I want proper indenting NOW NOW NOW”
Fair enough:


xml.bqcm :UselessMetadata do
xml.__send__ :_indent
xml.text!("flue")
xml.__send__ :_newline
end


1. Requiring an Administrator to install. I’m in no hurry to upgrade to Vista, but it rightly points out that There Is No Excuse for requiring root privileges to create a new folder and stick a few settings into the registry. I don’t care if the “amazing” installer software cost you a pretty penny, or if you absolutely need DRM somehow on a demo package. It took me maybe a night or two to learn how to use WiX. Now you have a Microsoft-approved installer that will absolutely do the right thing if you can manage to enter a few XML values correctly.

2. Not publishing CRCs or MD5s of the complete file. Considering all the hoops to jump through, “custom download managers”, and lack of BitTorrent on the big sites, it’s really really easy to get a corrupted file, and the only way to confirm is..download it again from somewhere else.

3. Repackaging installers — I’m looking at you, Manifesto and GamersHell, specifically. Relating to #2, now I don’t even know if you repackaged the developer-provided installer correctly if your funky add-on throws out “MainGame.lib corrupted. Abort/Retry/Ignore?” (and I’m not kidding, have we traveled back to DOS days?).

Someone is probably thinking “just use a torrent hub”. Unfortunately, I’ve had a hankering for checking out obscure space-sims like Starshatter or Space Interceptor, and no torrent sites(in Space Interceptor’s case, not even the original publisher) are keeping the files around.

Not that I complain too much about a corrupted download from Gamershell keeping me from enjoying the majesty of Tarr Chronicles. But I still haven’t found a working demo for Sector 13, and I’ve actually been looking forward to that one.

On my systems, the TM plugin would insist that I had an ancient rails/rubygems version, and to try upgrading. After a long headscratch, I deduced that it was probably seeing the ancient Apple-installed gems even though I have shiny MacPorts-installed gems. For some reason, the TM plugin will ignore your .bash config files and even any TM_RUBY variables you try to set in the project. Instead, you’ll need to add a PATH variable to your underlying MacOSX environment file(~/.MacOSX/environment.plist).

Take your PATH from your bash profile(specifying your preferred location for rSpec/ruby/macports/etc.) and place it into a key just like the other variables in the file. Mine ended up looking like:
<key>PATH</key>
<string>/opt/local/bin:/usr/local/bin:/usr/local/sbin:/bin:/sbin:/usr/bi
n:/usr/sbin</string>
Save the file, then logout/reboot. The TM plugin should now be working.

After getting it working, I can say it’s been a resounding success in my testing. All of the new features for Depot Central have been thoroughly spec’d out, and even though this release will open the floodgates for public posting, it’s been the least problematic so far.

One hurdle people might run into is whether to let god auto-daemonize the process(a useful feature indeed), but our hand is forced by Sphinx already daemonizing itself along with its own PID file(trying to let both god and a process daemonize itself is pretty much crossing the streams). Fortunately, sphinx provides its own “stop” command so we don’t have to go crazy trying to lookup a PID in our god config:


w.start = "searchd -c #{RAILS_ROOT}/config/#{RAILS_ENV}.sphinx.conf"
w.stop = "searchd -c #{RAILS_ROOT}/config/#{RAILS_ENV}.sphinx.conf --stop"
w.pid_file = File.join(RAILS_ROOT, "log/searchd.#{RAILS_ENV}.pid")
Easy peasy. I absolutely adore god's ability to plug into the event system on OSX, so between god and launchd, I've almost got a bulletproof config[1].