LookMiiUp on Facebook Platform?

Last year, I made a site called "lookmiiup.com" that's for looking up a person's Wii number (like an ICQ# for a Wii; used to add friends and other stuff in the future) by identifiers like AIM name, phone number, etc. Yea, it's all but dead; I still have a release that I haven't done because of time / lost steam :(. Thinking about the new Facebook Platform, why can't a Facebook member ID be an identifier? And why not have it broadcast to your mini-feed when you register your Wii, and list all of your registered friends when you go to the LookMiiUp application?

The Wii has a fairly small market though; only about 2.75m units sold in the US. However, I'd guess that 50-75% of that number have Facebook accounts. Nintendo projects 35m units in the US by 2012, and it seems reasonable given the price gap and target demographics of the Wii vs. Xbox360 and PS3.

It would need more interesting features than just saying "here's who has a Wii" though; what games they have, or something. But even then, what's the incentive for them to add their stuff aside from it being shiny? Probably not much. Honestly I don't even think I'd use it :(

The other problem is making money; I doubt that it would ever make dollars. It might give a launch pad for future applications though, simply by giving an audience to market future ideas to or simply for credibility.

Thoughts?

Workflow-Enabled Rails Petstore

Note: this post is a work in progress.

As an exercise for my book, Enterprise Ruby on Rails, I will be creating a workflow based implementation of the iBatis Petstore application. It will use OpenWFE4ru (aka Rufus) and Globalize, and be fully unit and integration tested. It will contain no added GUI sweeteners, as it is meant to display best practices; convoluted AJAX code will just get in the way of that. I may base it on an older version of Rails Petstore (before it got mixed up with AJAX), or start from scratch--further evaluation is necessary.

Aside from those key points, it will be a typical Petstore application. I've created the designs and begun exploring necessary tools, however I have an exam to prepare for next week. But I'll find time soon.

Testing Rails - First Impression

Note: This post is a work in progress.

My first impression of the Rails testing framework was that it is the shit. Unfortunately I haven't been able to get it to work yet--my preferred database configuration is not supported by Rails/ActiveRecord. The configuration that I would prefer to use is not far outside of the norm by most standards; I simply want to have a single database with multiple schemas for test, devel and production, as opposed to Rails' preferred method of using three separate databases.

Something else that's irksome is Migration's lack of built-in support for unique and foreign key constraints, and sequences, outside of execute statements. It's easy enough to use raw SQL for those things, but it seems to make using Migration a moot point; it's easy enough to use the up/down database versioning with raw SQL files, I have been doing it for years.

Another issue that I ran into, is that ActiveRecord abstracts so much of the database interaction that simple things like rolling back a transaction might as well be impossible to find for a n00b like myself; I searched for an hour and decided to move on with a reconnect statement and TODO comment. In fact, I never even found documentation for how to deal with a constraint violation at all. I took my prior knowledge of Java and figured I could "rescue" the StatementInvalid error; but again, no mention of how to handle the connection.

Beyond those issues, testing has been pleasant. I created a simple registration controller that displays a form and handles its submission. I am able to verify the registration by doing a find on ActiveRecord. I am also able to easily test validation errors and cases such as "username already exists" (enforced by a database constraint)--two things which almost no applications I have developed have ever been tested for--save for HealthMatch. It is interesting to work with the Rails testing framework because the level of coverage possible mirrors the goal of ongoing effort on that project. Just last week I created a prototype DbUnit-enabled validation test base with an identical concept of fixtures, so I will be able to take a lot of this experience back there.

The main argument I've had against Rails (and PHP, and ...) is that dynamic languages in the context of a medium-scale, medium-lived project will face brutal regression issues. I hope that the testing framework lives up to my expectations and provides a level of coverage that makes my argument moot. The defective nature of Rails' pre-5.x MySQL-centric database support is annoying, but it isn't a deal breaker. It did, however, smudge up the glossy image I had of Rails after the reading about its testing framework I've done lately, which was total redemption in my eyes.

Source code for my demo is available in trac and directly from the subversion repository.

Enterprise Ruby on Rails

Various things over the past few weeks (MinneBar, discussions, encouragement) led me to put together an outline for a Ruby on Rails book/wiki. Basically, it would explore challenges that are relatively uncharted on the RoR platform, but are well known among .NET / Java folks. Up to this point I have not used Rails, but I'm not closed to the idea of using it--in a lot of ways, compiling this knowledge would serve as a Q&A session for me :), and hopefully help out others. The intent is to compile it to a wiki and baseline a book, to be released under creative commons attribution; this way work can carry on after I've gotten the answers that I want ;).

It is available here.