To get a gold medal in a level of Link’s Crossbow Training, you have to get a combined score of 80,000 across three stages. Most of my gold medal points are distributed like so:
So I just get awesome at the target levels, then cruise through the others, not caring about my score. It works, but it seems like cheating.
Really, I think they should’ve just left out the Ranger and Defender levels, they’re nowhere near as fun.
The Wii has been idle recently while we’ve been playing Guitar Hero and Orange Box on the 360. But seriously, bang-for-buck, Link’s Crossbow Training is the best entertainment purchase I’ve made in years.
For $20, you get the game and the Zapper, a gun-style housing for the Wii remote+nunchuck. And the game is awesome. It’s the type of game you can throw in at parties and people who don’t play video games will be into. Basically a version of Duck Hunt or Barker Bill’s Trick Shooting for 2007.
I’ve read some negative things about the Zapper, mostly that it’s slower to move than the Wii Remote. I’ve played through RE4:Wii Edition 8 times with the remote, and look forward to trying it with the Zapper (even though it fires with A). Yes, the Zapper is slightly slower than the remote alone, but you gain massive stability, the type emulated by the stock add-ons in RE4.
If you’re more of a headshot-type person, try the Zapper.
Occasionally I play with devkitPRO to get code running on the Nintendo DS. This homebrew SDK is really low-level. When the developer-friendly abstraction includes symbols like VRAM_A_MAIN_BG_0x06000000, you know you’re working at a pretty tedious level.
I’ve done embedded development before, but the impression I get is that NDS development is hard. I sometimes wonder what the official Nintendo SDK looks like. I’m sure it’s a bit more abstract than remembering which processor to ask for which button inputs. I’m not sure if it’s this low-level because of the weird hardware peculiarities of the DS, or just a missing layer above libnds.
When you come across a good homebrew Nintendo DS application, be impressed: It’s like writing a dekstop application in assembly.
Of course, SvnRecord was too good to be true. After a week of implementation, using Subversion as a backing store for a web app seems infeasible for anything non-trivial. Problems I ran into:
The Svn::Ra protocol layer is gimped. As far as I can tell, you can’t ask across the network: “List all the (versioned) properties of this file at revision n.” It seems everything useful requires the Svn::Client layer, which works with a local working copy on disk to do most useful things.
Because of this, to get decent performance for operations like that, you’d have to setup a ramdisk. This makes deployment a pain, and adds truckloads of platform dependencies.
The documentation sucks. I had to spend my time flipping through the comments in the bindings, the underlying .h, the svn client itself, 2 books, and all the unit tests to get anything done.
The Ruby bindings suck. There’s a dozen alias functions that do the same thing, all the underlying “do_something” and “do_something{2,3}” replacements are still there. It’s easy to segfault the bindings. The user has to deal with most of the underlying implementation of library, using classes like Svn::Ra::Callbacks to mirror what the C library is doing. Ruby shouldn’t be passing around auth_batons and such.
Memory. Just opening an Ra session adds 20M to RSS. Fetching a few files bring the processes to 130MB. This is probably a bad interaction between Ruby’s GC and Subversion’s APR pool memory management. I could find no way to flush the pools, and as there’s no docs, I’m done looking. Having 4 mongrels on one server doing this would be insane.
I’m mostly disappointed because SVN isn’t the old legacy project it feels like. It’s a pretty young project (in Unix terms), and I expected it to have less gotchas and problems.
Of course, I could look into other version control systems, but the whole point was that Subversion is well-understood and has been installed by thousands of people. I guess I’m back to timetravel tables in PostgreSQL.
There are really two common, well-understood Unix services which provide ACID-like storage backends: The database systems pretty much every web app is built on, and source control systems.
I got tired of creating yet another table with created_at and expired_at columns to implement versioning, so I started SvnRecord, an ActiveRecord-like class for storing versioned data in a SVN repository. I have a few ActiveRecord classes that could benefit from having versioned, textual information associated (wiki-style).
Subversion has fast checkout of the current version of each file, and an easy way to set arbitrary attributes. Versus a using a database table, the biggest difference in actual use is that you can only query by its primary key (the filename), but you can get it at any revision or timestamp with decent performance.
The SWIG-generated Ruby-SVN bindings aren’t well documented, and a little more low-level than I’d like, so it’s taking some time. If it weren’t for the unit tests SVN provides, I would’ve never figured out the auth_baton and Callbacks stuff.
Currently it’s in a prototype state. In a few weeks, hopefully it’ll be polished enough to publish.