My talk from Ignite Phoenix IV is now up on Blip TV: Building cross-platform desktop Wii applications

You can also download it as an mp4 file here

BTW, I am granting release of the video under a Creative Commons license

Cross-platform desktop Wii applications by James Britt / Neurogami is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 License.

At the upcoming Desert Code Camp in Phoenix, AZ, there is to be a session titled Open forum with Community Leaders

But there’s also an invite-only after gathering.

I can understand wanting to keep the attendance restricted, to help boost the signal out of the noise. But I’m curious about the selection process. I was among a list of about eight people who got an E-mail invitation to the second session. Certainly there are more people in the Phoenix area whose input would be just or more valuable , and who are just as deserving as being on that CC list.

So, who are the “community leaders”? Why would you call them that? Who and what are they leading? Do we have community followers? Do the followers agree on who are the leaders?

I don’t see myself as leading anyone, and have no interest in doing so. I find the term “community leader” , um, misleading. Few people are doing any real leading. Me, I organize or instigate or simply help out. I may take the lead on this or that project, but I’m not leading any people, except maybe over to a free seat over in the back of a user group meeting.

What I try to do is give people a hand in leading themselves, if they are interested. From ruby-doc to rubyaz.org to the talks I’ve given and articles written, I’m much more interested in providing tools and resources than in telling anyone what to think or do.

Yes, I’m opinionated (like everyone else on the planet), but I seriously expect everyone to take everything I say with a good deal of skepticism. One reason for writing is for me to find out what I think, and hopefully get feedback to learn where I’m wrong.

Maybe I’m leading by example, but I don’t think that’s what is meant when labeling people as “community leaders”. It seems intended to declare a specific distinction among people, something of, for lack of a better term, a class distinction. Not to be all Marxist theoretical here, but the leader/follower distinction partitions people, and does not encourage useful gradations. It’s something like an orchestra; you are either the conductor or you’re not; you are either giving directions or taken them. Rarely does the first violinist swap places with the conductor; everyone has their assigned role and they stick with it.

I much prefer a jazz improve jam session approach. People are leaders for certain things at certain times. No one assumes that the leader at this moment will be be the leader later on. Each person not only believes they could lead, but is expected to do so by the others. Back when punk wasn’t total laughable bullshit, it was common for people to be the band one night, and in the audience the next. You were expected to participate; that was the whole point.

You are not on this Earth to be a spectator.

Certain distinctions are practical, and many of the people who get tagged “community leader” have some aspect worth noting. Often that aspect is having done something. Doing is important, and worth recognizing, but there are degrees of doing, whereas leading is pretty much an all or nothing behavior. Emphasizing a vague notion of “leading” isn’t useful. But people can do in varying degrees, with varying skills, and should be so encouraged.

Maybe a better term is “community doers.” Or just “doers.” It’s more objective, more open to participation, and presents a more valuable goal.

I’d rather see people doing than leading or following any day.

Looks like I’ve been selected to give a presentation on developing Wii desktop apps at the next Ignite Phoenix.

Now my heart’s all aflutter …

Better get cracking on those slides.

Thanks to all who voted for my talk!

Every so often I get prompted (more or less) for my thoughts on Haml. Someone suggested I write them up.

I’m not a fan. Some vocal number of people are big Haml enthusiasts, and while I think I get what they see as its virtues, it just doesn’t work for me.

In no particular order, here’s what irks me.

I already know HTML. I have no trouble reading it, no trouble writing or editing it. I have an editor, vim, that makes working with HTML fairly simple. I’ve no compelling reason to learn another syntax in order to end up with markup that’s already easy to write. (BTW, if you are not using an editor with auto-tag completion and other HTML/XML helpers you are making a mistake). I get the impression that many Haml fans are programmers who don’t already know (or are not comfortable with) HTML, so they have a learning curve no matter what, and Haml may be less onerous than HTML. Me, I’m not afraid of HTML or XML, and I find Haml Perlishly cryptic.

It seems to grab the worst features of Python and Perl: Magic indentation and write-only syntax. No, I’m not interested in debating the merits of either. I view static indentation as I do most forms of static typing: needlessly restricting in an attempt to solve problems that don’t come up much in Real Life code but make for nice pedantic rants about “But what if?”. I also know that one man’s cryptic is another man’s poetry. Much poetry is an acquired taste, and often bad.

I have a hard time navigating Haml documents. With HTML I can easily jump from the start or end tag of a element to the matching one. This is quite handy when I want to insert something at the end of an element; from the start tag, hit %, and jump to the end tag. Perhaps this is also possible in Haml, but I’ve not figured it out. Instead, in Haml, I do the Dance of Matching Indentation, and sadness follows.

It seems that whenever I see examples of Haml (or Yaml, for that matter), they are pretty short. That’s because the allure of magic indentation wears thin for large docs. (Cute anecdotal tale that preaches to the choir: I made this observation about Python code to a Python fan, and was told that it worked to ensure you kept your methods short. That was the first and only time I was told that the white-space tax had a punitive purpose.)

I can hit some keys in vim and auto-format my HTML docs. I can easily cut and paste chunks of markup and move them around, and have my editor handle the formatting. Not so with Haml, where there is constant risk of offending the gods of The True Indentation.

I often work with Web designers who will send me HTML pages that need to be re-worked into templates. Having to covert that into some other format just so I can get HTML in the end is dopey.

I like HTML over XHTML. See http://hixie.ch/advocacy/xhtml (though the suggestion to use the still “Working Draft” HTML5 is somewhat puzzling).

I’m sure I could do something clever and make sure I send my pages using the application/xhtml+xml MIME type, but I don’t. I don’t see the benefit when I can use HTML 4 and the default Web server configuration. It Just Works FTW.

I used to use XHTML, largely because I could more easily check my Web pages using an XML parser and XPath. But tools such as WWW::Mechanize have become really good at handling HTML 4, so the charm of XML has faded.

Just for gits and shiggles I spied on the headers exchanged when fetching http://haml.hamptoncatlin.com

My browser sends this (indicating that it will accept assorted XHTML-friendly MIME types)

    GET / HTTP/1.1
    Host: haml.hamptoncatlin.com
    User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.14) Gecko/20080419 Ubuntu/8.04 (hardy) Firefox/2.0.0.14
    Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
    Accept-Language: en-us,en;q=0.5
    Accept-Encoding: gzip,deflate
    Accept-Charset: UTF-8,*
    Keep-Alive: 300
    Connection: keep-alive
    Referer: http://www.google.com/search?q=Haml&ie=utf-8&oe=utf-8&aq=t&rls=com.ubuntu:en-US:official&client=firefox-a
    Cache-Control: max-age=0

It gets back this:

    HTTP/1.x 200 OK
    Date: Sun, 22 Mar 2009 01:34:55 GMT
    Status: 200 OK
    Server: Mongrel 1.1.5
    Content-Type: text/html
    Content-Length: 4734

... followed by an XHTML file.

I don’t mean to single out the Haml site. This is quite common. If you’re going to go the XHTML path, though, consider doing it in earnest, or it comes off as posturing.

That’s basically it. For those who like Haml, more power to you, just please don’t hand it to me to work with.

If you think I’m wrong on any of my points, please drop me a line with some specific, factual, technical information.

UPDATE:

Thanks to Arthur and Nathan for pointing out that Haml allows for different output types by setting, for example,

Haml::Template.options[:format] = :html4

someplace or other.

UPDATE 2:

This is a nice thread on the trouble with Haml Haml doesn’t like javascript

While I appreciate people trying to help me get a grip on Haml, the discussion tends to look like this:

Anti-Haml: It's hard to work with

Ham'l Qaeda: But  look how beautiful it is!

Anti-Haml: It imposes superficial constraints

Ham'l Qaeda: But  look how beautiful it is!

Anti-Haml: It gets in the way of doing things I want to do

Ham'l Qaeda: But  look how beautiful it is!

Anti-Haml: It makes embedding JavaScript annoying

Ham'l Qaeda: Your are a flawed being  for desiring that. 

And  look how beautiful it is!

:)

I was having problems when adding unpacked gems to the load path in a Monkeybars app. On Windows, if the expanded path that had spaces, items added using the add_to_classpath or add_to_loadpath methods would end up with %20 where the spaces should be. The packaged file would not get loaded.

resolver.rb is a file created as part of a Monkeybars app skeleton. It lives in the src/ dir of your app.

Here’s my path-adjusting version: http://gist.github.com/103874

I added line 30 to the original version of the file.

This should get added back to the main Monkeybars repo (I have it in one of my forks, which I use in place of stock Monkeybars), but until then if you are having odd file loading issues with files in jars, see if it isn’t because of borked spaces in expanded paths.

I have a long-running background process of trying to learn German. I can understand a fair amount, but have difficulty calling to mind the words when I want to say or write something.

I wrote a Monkeybars app to do a sort of flash-card thing with German vocabulary (see my IBM devWorks article), but for whatever reasons I don’t run it much.

I do, however, have a Twitter client running most of the time, and I figured I should be able to get Twitter to teach me German: http://twitter.com/teachmegerman

If you follow @TeachMeGerman you’ll get a tweet every hour with a vocabulary item.

I may adjust the interval, but so far this seems OK.

I’m not sure how many words are in the list; maybe 100. Each tweet is randomly selected.

Now the experiment is to see how well this sort of ambient education works out.

The Ruby Best Practices blog has gone live

My first post is Solve the problem, not just a problem

You can read the comments on Disqus

I’m quite flattered to be among the initial group of people contributing to this project. Big props to Greg Brown for getting this together, and his sharing his O’Reilly limelight with us.

His book, Ruby Best Practices, is really good. I’ve looked at many Ruby books, and most are mediocre. A few stand out, and RBP is in that small collection.

I’m typically skeptical of things claimed as “the best” way to do this or that, and what I write for the RBP blog will not be claiming anything to be the One True Way (and, incidentally, neither does the book; instead, it examines various options, details pros and cons, and presents a well-reasoned example).

What I hope to do is explore the thinking process involved in coding, examine how different problems may be solved, and give readers something to ponder.

I’m open to suggestions on topics, and welcome all comments on my posts.

A Mac Mini, actually. For occasional development work.

Many things are quite nice and well done. Others, annoying. It looks very nice, but I was amazed that my choice of simple desktop background colors was limited to one of 8 shades of melancholy. There’s a difference between subdued and drab, and while I would really want a gradient background (as I have on my Kubuntu laptop), even a solid shade of a vibrant rust or golden green would be nice.

Likewise for “spaces”, the Mac version of multiple desktops. KDE3 lets me give each a unique color—makes it easy for me to place myself. Puzzling that the Mac, which seems to otherwise excel in UI goodness, falls down here. And one more “why isn’t a Mac more like ” complaint: To resize a window you have to use the One True Corner. You can’t (as far as I can see) simply grab any edge or corner and adjust freely. Makes for more work.

When I switched from XP to Kubuntu a few years ago, I had a similar experience. I liked XP as a general OS, and there were a number of apps that did not have suitable counterparts in Linuxistan, but one BSOD too many made me decide that, being a developer, I needed the stability more than the pleasantries. I had been using Linux via VMware for a while so it wasn’t a sudden radical leap, but making it my daily OS (with KDE3 as the desktop manager) was jarring.

I first tried the stock Ubuntu install, which uses Gnome, but I was not able to tweak the UI as I liked. I could not, for example, give each desktop a unique background, and the menu system seemed hard to customize. KDE was more to my liking, but it, too, had a fair share of quirks.

I think KDE3 gives you Dolphin as the default file manger. Dolphin seemed heavy on white space and icons and weak on more useful information, and I ended up using Konqueror instead since it seemed to have more of the better features of the XP file manager. While spending time getting things “just so” I was thinking about the little things that worked or didn’t. Changing your OS + desktop manager seemed to entail swapping annoyances more than a clear move to better or worse. What was annoying depended on what you were used to. I figured someone moving from KDE to XP would be finding the same number of nits to pick.

Over time I just got used to how things worked. I also found things that were so much better on KDE. For example, to move a window, you hold Alt and click anywhere, and drag. Very nice. I sometimes do this on my Vista box with amusing effects. (I tried this on my Mac; no luck.)

I need now to get acquainted with various Mac tools and keyboard shortcuts. I imagine that over time I’ll stop gnashing my teeth over funky Mac UI decisions, get used to the Mac Way, and be enjoying the good parts while ignoring the bad.

I have Synergy running, so I can use the Kubuntu laptop as my base and switch over to the Mac or the Vista boxen as needed. Very handy. Now I just need to install all those extra dev things …

I had a blast at MountainWest RubyConf 2009.

Some random thoughts:

Big thanks to Yehuda Katz for taking the time to explain the changed planed for Rails 3. (I copped to not fully paying attention to his talk because I was still hacking on my own presentation.) Things look really interesting.

A lengthy dinner with Jim Wierich, David Brady, and Matthew Nielsen. Aside from the top-notch geekery, there was much laughter watching oddball videos and discussion favorite TV shows. I also learned that goofy off-the-cuff remarks can find their way on Twitter very quickly. :) Monster props to Dana Gray for picking up our tab, too.

Dinner with Brain Marick and associates the night before was a treat as well. I mean that in multiple ways, as Kay Johansen grabbed the check that night. Be sure to watch Brian’s lightning talk on Micro-scale Retro-futurist Anarcho-syndicalism when the video comes around.

The talks were amazing. The shorter format made for punchier content, with more topics covered. Mike Moore and Pat Eyler did a great job of keeping things running and on time.

The hackfest was great. Big thanks to Engine Yard

Remi Taylor did a remarkable lightning talk on rackbox After losing time due to video hookup issues, he still managed to blaze though without complete composure. True lightning. The crowd was quite impressed.

I more or less made a point of not hanging with folks from Phoenix. Nothing personal, but conferences such as these are the among the few chances to meet new people or to hang with folks I’ve only interacted with on-line.

I need to re-think my presentation style. Many people whose opinion I respect had good things to say, and I had a nice chat with James Edward Gray II about ways to fix some issues in my code. Still, I felt I was too stiff, and the talk lacked a clear focus. I’m thinking I need to drop the slides and do more live coding with more demonstration apps.

There was a discussion on the back channel about talks and slides, and a few people (including me) seemed to think that having no slides at all would be a good thing. Dave Brady, for example, was too sick to give his talk at the schedule time, but he came to the conference the next day and gave his talk right at the start of the lunch break. Without having brought his slides, he demoed his code and used Emacs to show a few text notes to reinforce his words. It was great.

It would be nice to have a conference along those lines. 20-30 minute talks, with no slides. Use your editor to display text if needed, but focus on what is said and code being run. Might need a catchy name. RawCamp. RawConf. LiveConf. SomethingSomething. Or something like that.

PS: Videos are starting to appear! http://mwrc2009.confreaks.com

At MountainWest RubyConf 2009 I gave a talk on using the Wii controllers to drive Ruby code.

PDF version of the slides

Video should be appearing on the Confreaks site before too long.

The code for the Wii libraries are on GItorious: http://gitorious.org/users/neurogami

The video.

Food!

During the conference, folks will have to fend for themselves to find food. To make life a little simpler I Googled up some maps of various restaurant types near the SLC library.

The library on Google maps: http://is.gd/mlN2

Within 1 mile:

Restaurants http://is.gd/mlO8

Italian http://is.gd/mlOR

Indian http://is.gd/mlP3

Vegetarian http://is.gd/mlPn

Mexican: http://is.gd/mlQ0

Bars and stuff: http://is.gd/mlS7

Food stuff within 2500ft:

All restaurants: http://is.gd/mlRt

Veg: http://is.gd/mlQd

Indian: http://is.gd/mlQy

Mexican: http://is.gd/mlPS

Italian: http://is.gd/mlR3

Every so often I find a need for some small script that will reduce or eliminate some annoyance.

One case is running out of disk space. I really could not tell you what in the world is consuming my laptop drive, but 200G is evidently not enough.

Every so often I think to check the amount of free space, and move off or delete this or that. But sometimes I suddenly find myself with zero free space, and some applications just don’t handle this well.

I decided to create a cron task that would check the disk usage and warn me when free space fell below some set amount.

The Ruby code was simple (though potentially hackish. If there’s a better way to get the amount of free disk I’d like to hear of it).

Here’s grabbing the disk space

def free_diskspace drive
  results = `df -h #{drive}`
  # Filesystem         Size  Used Avail Use% Mounted on
  data = results.split( "\n").last.split(' ')
  value = data[3]
  value.sub!( /G$/, '')
  value
end
 

To issue an alert when space is low, I used KDE’s built-in kdialog command. There’s a Ruby lib that wraps this, but invoking it directly is simple enough.

def alert msg
    puts `kdialog  --display :0 --error "#{msg}"`
end
 

The logic is basic:

space = free_diskspace '/dev/sda1' 
alert "Running low on disk space: #{space}"  if space.to_f < 2.0

One point that wasn’t obvious when I wrote this: the cron task may not be using the same X display as the user, so the message box may not be seen. The fix is the explicit use of --display :0 when calling kdialog.

I’m putting together a sample app, trying to pay attention to all the little steps, all the things that need to be in place if you want a Wii-enabled Monkeybars app.

I’ve written a few small such apps, but each time there was some variation. Over time I’ve sort of settled on Here’s How You Do It, but, sadly, the reference for this is the set of previous examples. What I really want, at some point (if not by the time of my talk, then soon after) is that creating a basic Wii app is reasonably stupid simple. Getting started so you can play around should not be a pain in the ass, or no one (i.e. me) will do it.

For example, after you generate the basic Monkeybars app layout you need to have the WiiUseJ jars in place. Where do they come from? Well, right now, it’s “one dir up and two dirs down”, as I snag them form a previous project. I’m not so sure that’s a long-term solution.

Should these jars (and .so and .dll files) by in the git repo? I first though not, since those things are not my code, and folks would be better off grabbing whatever is the current version from wherever they call home.

But, seriously, what a pain in the balls. I have some idea what I need and I find it annoying to have to go find the right project with the right files. Now I think I’ll push then up with the Ruby code, ensuring that the all the files are right there, and that they are compatible. I could then go a git pull to slurp down the files and have them dropped off where they need to be. Or make a gem that provides a script for copying over all required files from a common local directory.

When a program wants to talk to a Wiimote it first needs to connect to it over Bluetooth. The Java code throws an exception if it doesn’t catch a connection signal coming off the Wiimote. To send that signal a user needs to press the Wiimote 1 and 2 buttons at the same time. You can watch for a (vague) message at the console telling you when to do this, but for a real application you really want some sort of message box.

My programs so far were having the controller kickoff the Wiimoting, with a signal to the view to toss up a “spinner” dialog box asking the user to hit 1+2. I used a retry loop to allow for some number of attempts before giving up should no signal come.

Some of this code is in a module that is part of WiiUserJRuby, but you still have to wire a few parts up. Writing yet another program, I’m wondering how to make this easier. My current inclination is to write a generator that gives you a controller and view with the default Wiimotable code in place. As part of my explorations with Jimpanzee (AKA my fork of Monkeybars) I added, in addition to code to allow an inline Swing DSL, some extra generators to take advantage of the inline Swing option.

I ended up taking that out and putting it into a tool called Rhesus (it made Rhesus pieces; assorted MVC tuples for use in Monkeybars).

Rather than keep adding a series of Groovy Cool Monster features to Monkeybars, I’d rather see a set of optional tools. Rhesus, for example, could provide a generator for kick-starting Wii Monkeybars projects.

This would allow me to keep the core code in WiiUseJRuby from being Monkeybars-centric. I saw how ingrained things were when I tried to hook my Wii code into a Gemini game. Among the assorted issues I ran into was the realization that it made zero sense to have core Wii Ruby code trying to signal a view; none of that exists in Gemini. I settled for just writing to the console. It’s hacky, but the Wii code was not set up for flexible notifications.

Now, I don’t want to spend that much time trying to account for numerous what-if’s, but I do want to encourage people to try things, and that means making things inviting. Make basic things simple, interesting things possible, keeping the barriers low.

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.)

With Happy Camper Studios and Rising Tide Software soon to be memories, the people who gave those entities life are moving on to other things.

I’m continuing with contracting/consulting/product development, but my former business partner Logan Barnett, AKA Logustus, is looking for a more predictable gig.

If you are looking for world-class Ruby talent in the Phoenix AZ area, do not delay.

Hire him.

If you are looking for a kick-ass Ruby developer, hire Logan.

If you are looking for a kick-ass application designer, hire Logan.

If you are looking for a kick-ass co-worker, hire Logan.

Seriously, he’s really, really good.