Atomic Spin Roundup

In mid 2012, I moved to downtown Detroit and joined Atomic Object as a full-time software developer. Ultimately, it wasn’t the right fit for me, and I recently decided to go back to freelancing. Nevertheless, it was a positive experience, and I’ve gained new friends, knowledge, skills, and experience.

Over the course of the two years I was at Atomic, I wrote a wealth of articles for the company blog, Atomic Spin, on a variety of topics related to software development, ranging from specific technologies, to best practices, to community groups and events. Each article was crafted with care and attention. Enjoy!

On Programming Languages and Technologies

On Development and Management Practices

On the Community, Conferences, and Groups

Birthday!

Today, I am the ripe old age of 22. Soon my hair will be falling out and I’ll be wearing dentures. ; )

We went out to a casual-nice Italian restaurant last night (maybe one step up from Olive Garden on the ladder of classiness), and had yummy food. And tonight, we had Chinese take-out and ice cream cake. Woo-hoo!

It’s a brand new blog(s)!

You may notice that something seems different around here. Today I migrated my blog from that crusty old Typo to the shiny new Mephisto! Most things are working well, but excuse the dust.

You might also notice that the Rubygame posts have vanished mysteriously! Well, in fact, they have been moved to…the new Rubygame blog!

I’ve been sitting on the rubygame.org domain name for a while now, but I was never sure what to do with it. But then I figured, “Hey, let’s put all the Rubygame news on that domain, and use jacius.info for my other projects and personal stuff!” Evenutally, I’m also going to set up a copy of the documentation and downloads on rubygame.org, as well.

And it gets cooler: both blogs are running from the same Mephisto instance, using its multi-site feature! Pretty slick.

But wait, there’s more! Within the next day, everything will be using Mongrel, so it’ll load nice and fast.

Good news all around! … well, except for the old RSS and Rubygame post links not working.

P.S. I’ve tried to keep all the article URLs the same, with moderate success. Unfortunately, the old RSS feed link doesn’t work anymore. But that’s the way the cookie crumbles, I guess. Maybe I can set up a redirect to fix that. I’m also trying to get monthly archives listen in the sidebar, etc. etc. Also, the domain change for the Rubygame posts means that links to them at this domain will fail. Blech. I’ll see if I can set up redirects for that, too.

Update: I found a redirect solution on BlogFish. Hurray! Sorry for flooding your RSS readers, though.

P.P.S. You might be wondering what happened to my plans to use Radiant, since I was hacking on the Radiant-Comments extension earlier this week. Radiant is a really cool platform, but the extensions just aren’t solid enough for me to set up a proper blog without a lot of work. Maybe some day, I’ll switch this blog over to Radiant (and break the RSS feed again ;-) ) but in the meantime I needed a working setup, and Mephisto provided that with a minimum of fuss.

Culling Projects

I have a personal tendency to accumulate projects. Lots of projects. So many projects that I could never find the time work on them all. So, older projects get put on the shelf as new, sexier projects grab my attention (and then those new projects become shelved when the next one comes along). The sheer psychological pressure of this massive backlog of projects is intimidating, so I end up avoiding them all.

And so it was with Rubygame. It was fun and cool for a while, back in summer 2004. Then it started to get old, and I often felt discouraged by the lack of feedback. (Of course, that was due in large part to the fact that I did not promote it or make any announcements on mailing lists; something I still have not done.)

I trodded along out of “duty” (guilt?). Occasionally I would receive some little scrap of feedback; an email, maybe even a patch, which would keep me going for a while. But, my interest in Rubygame has been stop-and-go since 2005, and mostly stop, at that. School work and dealing with my own ongoing personal issues definitely contributed to that.

2007 has been different. There has been considerably more interest in Rubygame than in past years. A new developer, apeiros, brought in fresh ideas that excited me. Rubygame was even featured in a talk by Andrea O. K. Wright that was presented at Ruby Hoedown, Ruby East, and RubyConf.

But Rubygame has been buried among the detritus of other projects that didn’t make it, and I haven’t been able to pick it up and dust it off, because I’ve kept my hands full with yet more new projects.

I’ve had enough of the juggling act, though. I’m culling tiny dead projects that I won’t finish, and gathering up my concentration for more important things. Rubygame is important enough that it won’t be culled; but, there might be some changes.

Here’s hoping that another project doesn’t come along before I finish the project of culling old ones.

Defaults and Constraints

I read an article in Scientific American Mind, “When Words Decide” by Barry Schwartz, about how the phrasing of a question or proposal can dramatically alter the way people answer it.

Among the examples was the astounding difference in organ donor rates between countries with an opt-in policy (where you must sign a form in order become an organ donor upon death) and those with an opt-out policy (where you must sign a form in order not to). As you can probably guess, in countries with an opt-out policy, organ donor rates were much higher: from eyeballing the graphs, it looks like about 95% in opt-out countries, but only about 15% in opt-in countries.

Beyond simple laziness of avoiding the extra hassle of signing a special form, the author suggests that people accept the default because they perceive it as being the recommended choice. Unless they have some special reason to go against the flow, they usually won’t.

Upon reading this, it occured to me that one of the brilliant things about Rails is the way it directs the flow through its use of defaults and constraints. It’s very easy to create a working application with Rails, because the stream is carrying you towards one anyway.

Defaults and constraints are two sides of the same coin. While constraints make it harder for you to go against the flow, defaults make it easier for you to go with the flow. (To put it yet another way, a default is a tour guide leading the way, while a constraint is a security guard preventing you from wandering into a restricted area.)

Both defaults and constraints can be inspiring and liberating as a creator, though I’m not quite sure what it is about them that makes it so. Perhaps it’s the fact that they give you a jumping-off point. But not all defaults and constraints are helpful and positive; some are stifling and discouraging.

Helpful defaults seem to have two qualities:

  1. In most cases, the default is what you wanted anyway.
  2. It’s easy to override the default in special cases.

Helpful constraints have two corresponding qualities:

  1. In most cases, it’s advantageous to obey the constraint.
  2. It’s not impossible to circumvent the constraint in special cases.

Harmful defaults or constraints break those qualities. The worst default is one that is never what you want, but is impossible to override. Likewise, the worst constraint is one that denies you some advantage, but is impossible to circumvent.

For the most part, both Rails’ defaults and its constraints are helpful, although there are a few of them that are a bit too difficult to override/circumvent.

As for applying this lesson to Rubygame… it’s definitely showing up in the work I’m doing with event hooks in the development-3.0.0 branch, and I’m quite pleased with how it’s going.

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.

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.

Ambient Wildlife and Bouldered Paths

Lately, I’ve been thinking a lot about sound, color, and abstract artificial life. No doubt that this most recent bout is directly tied to my recent purchase of Electroplankton (the best, albeit only, $60 I’ve spent on Ebay), but all three are recurring themes that have been agitating my brain for years.

Wouldn’t it be wonderful to play with colorful creatures that scamper around and make musical sounds as they jump and chase each other? It sounds like the love child of Brian Eno and Will Wright, to be sure.

Continue reading Ambient Wildlife and Bouldered Paths