Bought a GP2X

I splurged on a GP2X (the open-source handheld game/entertainment console) the other day, and it arrived today in the mail. I also went ahead and bought a couple accessories at the same time: the TV-out cable, a USB-SD card reader, and the GP2X “cradle” (which will allow for connecting USB controllers, if I figure out how to get the darn thing to sit right).

I was under the mistaken impression that either the device itself or the cradle would come with an AC/DC power adapter cord, but that’s not the case. Luckily, a quick trip down to Radio Shack to grab a “Digital Camera Power Adapter” solved that issue (although I hope to find my AA battery charger around the house somewhere…).

I also picked up an inexpensive 2GB SD card for storage—an SD card is really a necessity for any substantial usage of the GP2X. All told, I’ve dropped almost USD $300 on this little adventure.

I am “cautiously optimistic” about the potential for this device. The hardware isn’t nearly as ergonomic or solidly-constructed as, say, a Nintendo handheld, but everything seems to work. I can’t say my expectations for quality were terribly high, anyway; I knew it was a risky purchase, but it seems to have paid off. Anyway, what it lacks in craftsmanship, it makes up for in ease of development for homebrew software.

In fact, a Rubygame user had already ported Rubygame-1 to the GP2X in January 2006, and I downloaded and ran it today on my own GP2X to check for myself. It sure was nice seeing those silly pandas spinning and squishing on a handheld device! Nearly any Rubygame app that works on the PC should work just fine on the GP2X, although probably with some changes to the player controls. (“If there were any Rubygame apps, that is!”, he says with a wink and a nudge.)

I’m hoping to ‘officially’ support Rubygame on the GP2X for future versions, and possibly add some GP2X-specific features, such as dimming the backlight or changing the CPU clock speed.

Not cleaning up Instiki after all.

Creating a new project with Rails: fun!

Cleaning up someone else’s existing, out-of-date, and not very Railsish project: not so much.

Instiki is a nifty little app, and it definitely gets the “Instant” and “Wiki” parts right, but it leaves much to be desired: no proper user login/authentication, no preview on edits*, a clunky (if I could get it to work at all) file upload system, no page renaming or redirects, etc. (* On the other hand, I _do_ like the fact that you have a 30 minute grace period to make more changes, without it counting as a second new revision.)

Typo (this blog software) has everything Instiki is missing, but is missing everything I need Instiki for. That is, namely, the ability to jot quick, interlinked notes—that whole wiki thing. It just takes too much effort to make a new post with Typo (too many screens to go through), and there’s no handy way to link between them to build up a web of related notes or articles.

If I had a magic alchemy bucket, I’d throw Typo and Instiki inside (and sprinkle a little Flickr on top) and come out with the perfect application to suit my needs. (Unfortunately, I lost said magic bucket in a wrestling match against a walrus. Don’t let their lazy appearance fool you: they’re feisty devils!)

Given how much fun it is to make a new app with Rails, though, I’ve been working on my own blikimajig software. Yeah, I know people always say, “Don’t reinvent the wheel; you should just improve the existing stuff.” But that’s one of those things that everybody says you “should” do, but almost nobody actually does. Besides, if no one ever redesigned the wheel, we’d be driving Flintstones-esque cars with big stone rollers instead of proper tires, right?

Then again, this is the kind of thinking that made me start Rubygame over two years ago… which may or may not be a good thing, depending on how you look at it.

We’ll see.

Cleaning up Instiki

I’ve been cleaning up Instiki for the past couple days.

Actually, I don’t want to be cleaning it up, I want to be extending it. But I figured before I extend it, I should make sure all the tests run. That way, I’ll know when I’ve broken something with my bumbling around in Rails.

Instiki comes packaged with a vendor rails, but it’s an oldish version, so I got rid of that nonsense—who needs old versions, anyway? Pshaw!

So now I’m running the tests, and fixing things that the newer Rails doesn’t want, like using @flash and @params (use flash and params instead), or end_form_tag, or assert_template_xpath_match. Deprecated, deprecated, deprecated!

Eventually, I’ll clean up enough deprecated code that I can actually read what the real errors are. Bleh.

Looking at Rails

I picked up “Agile Web Development with Rails” yesterday. Despite using ruby for over 3 years, I have not up until this point put any concentrated effort into learning and using Rails. I’ve been running (or rolling, as it were) through the tutorial, an online bookstore app.

By and large, the impression I have so far of Rails is that it’s very convenient. It seems like Rails has built-in just about anything you’d want to do—at least, in the limited domain of database-driven web applications.

As I learn more and more about Rails, I can’t help contrasting it with Rubygame. It has been somewhat humbling, but also motivating.

There are rather different design philosophies at play between the two projects; of particular interest is Rails’ notion of favoring “convention over configuration”. In Rails, it’s extremely simple to do things, as long as you follow the conventions that are in place; if you want to do something outside of the conventions, it takes a bit more work.

Rubygame, on the other hand, tries not to make any assumptions about how it will be used (or, so I tell myself). I want to encourage out-of-the-ordinary applications; I hope to see some really cool and weird applications coming out of it. As a result, there’s no assumption that you will want to make a tile-based game, or an RPG game, or will want to use images loaded from files, etc. It’s open-ended.

Rails has a well-defined and highly-encouraged structure to it. Rubygame lets you build your own structure (or forces you to, depending on how you look at it).

There is a definite appeal to the structured approach of Rails: everything has its place, and it doesn’t take much guesswork to figure out where that should be. With Rubygame, you have to decide for yourself.

So, should Rubygame be more structured? Should it assume that you’re going to organize your code in certain ways; that you will need certain types of classes and objects and elements?

Perhaps this is a spurious comparison. Rails is a framework—Rubygame is a library. Someone could build a structured framework using Rubygame, but I’m not sure it’s appropriate for Rubygame itself to enforce structure. Still, there may be some aspects or qualities of Rails that would be useful in the context of Rubygame.

It’s certainly something to think about.