This post originated from an RSS feed registered with Ruby Buzz
by James Britt.
Original Post: Wii Ruby talk prep
Feed Title: James Britt: Ruby Development
Feed URL: http://feeds.feedburner.com/JamesBritt-Home
Feed Description: James Britt: Playing with better toys
I’m still not quite sure what the theme of my MountainWest RubyConf talk will be. I have ~30 minutes, but realistically I need to plan for fewer, perhaps 15-20 minutes.
I’m glad the talks are shorter. More topics covered, less chance of a talk getting too bogged down. It’s more of an opportunity to toss out numerous ideas and situations than to expound on one or two in any detail. I’m currently inclined to make my talk a mix of demos and observations, in the form of design choices and unanswered questions.
Working with the theme of “Play” there are two threads. One is to use Ruby to create apps with which you play. Specifically, showing how to use the Wii remote with JRuby. I’ve been working on audio synthesis apps controlled by a Wiimote. I’m also (perhaps too ambitiously) looking to hook in the Wiimote to a demo Gemini game.
The other thread is the idea of creating an API that affords playing with code. The Java libs for using the Wiimote expose behavior with a certain granularity. You can use that to get stuff running, but it does not always make for easy tweaking. I’ve written some Ruby code to wrap the Java calls, with an eye on making it easy to get up and running.
Designing an intuitive API is not simple. It’s a bigger issue with the Java audio libraries I’ve been using. JSyn, for example, is quite flexible, but there’s a notable learning curve for even basic noises.
I’ve been hacking around some, making up code as I go. I first see what I can do, how hard it is, how useful the results, and after a few experiments think about how to encapsulate common behavior. The catch is that I’m still too inexperienced to really know what is common behavior with this code. A more subtle problem is that “common” can be self-fulfilling. I’ve had discussions with Rubyists over the use of $:. One opinion was that it was cryptic, not self-descriptive . It was claimed that some people would have to keep looking up its meaning, wasting time. My counter to this was that you only have to look it up a few times before you just remember it. Basically, if you treat it as arcane then it becomes arcane. If you just use it, it becomes mainstream, for better or worse.
With an API there comes a point when people just adapt to what’s available, develop habits and practices, and start to consider those practices as the right way to do things. If you then propose a change to the API it can feel wrong or awkward because of how it conflicts with established practices. What’s often not seen are the different practices that would evolve with a new API, and whether those new practices would be an improvement. (As an example, consider people trying to learn touch typing after years of hunt-and-peck. Or trying to change code editors [vi <-> emacs]. It all seems so hard and wrong, until you break though and internalize the new behavior.)
As I play around with Ruby wrappers for JSyn or WiiUseJ I have to keep in mind what affordances I’m creating (e.g., super-ease of creating a certain kind of tone or grabbing remote data) and what possibly interesting pathways I’m obscuring. I want it to be easy to play with the code. I don’t want to presume too much about how it should be used. Options should be discoverable (so one isn’t wasting time figuring out basic behavior) but not rigid. One should feel encouraged to explore what can be done while not getting bogged down in how to do it.
There may be an inclination to think of Wii libs as meant to help write games, but biasing the code for game development would be short-sighted. What’s more interesting are all things that aren’t obvious, all those quirky unexpected things that come out when playing with code is easy and fun. You can’t help biasing code; all code comes with a point of view, but one can try to keep the bias fairly benign. If you think of code as a open field, you want paths, not fences. Making new paths should not only be possible, but encouraged.
(Side note: MWRC registration ends today. Still a few seats left. Well worth attending.)
Previous Topic
