July 2009


iPhone hackathon 4 charity: Halifax edition

William Lachance, 28 July 2009

I think it’s fair to say that Halifax’s first iPhone hackathon for charity was a big success. The idea was pretty simple: get a group of people (developers, marketers, artists) together over a weekend and try to produce as many iPhone apps as possible over the course of a weekend. Sell the apps on the app store (or otherwise monetize them), then donate the proceeds to charity.

I think we managed to get a group of about 15 together. After the weekend was over, we had three apps in various stages of completion. They are:

  • PostCard: Send post cards, with a local twist.
  • Meet me here: A streamlined way to tell your friends where you are.
  • Civic Snitch: Report on problems in your neighbourhood using your phone. A front end to the amazing fixmystreet.ca (this is the one I worked on).

As usual for a hackfest, the energy level was amazing. In addition to seeing the familiar faces of MindSea, Applied Logic, Hand Puppet and Say Hi There, it was fantastic to meet the new faces at North Knight and an amazing group of unaffiliated (yet crazy competent) developers. A weekend is a bit too short a time to do anything but a trivial iPhone application, but we got a good start on all of them. Rumor has it that the postcard application is quite close to completion. Another few hacking sessions and we should have some apps that are good for release.

It’s hard to do justice to the overwhelming feeling of WIN that came out of this. Since co-founding Navarra a year ago, I’ve been at a ton of conferences, hack weekends, and other networking events and this has by far been the one I’ve felt the best about. What made it so great?

  • First and foremost, the feeling that the work you’re doing will be used for good.
  • The opportunity to take part in something untested and different. In these difficult times, charities are looking for new ways to fill gaps in fundraising– can software developers help?
  • The Halifax Hub’s open concept space which did so much to facilitate collaboration and communication (as it always does).
  • The amazing catered food from Local Source Organic (Splice Training also provided some tasty home-baked cookies).
  • The awesome high-quality t-shirts, featuring an amazing design by Nick Brunt (printing courtesy of Mindsea).
  • The free massages from Be Wellness.
  • DJ Rich.Ness spinning tunes for us to enjoy all of Saturday night

So what’s next? Well, that’s something we’re working out with a lawyer. :) The idea is to create some kind of legal structure that allows us to safely collect any app store proceeds and get them sent to charity, though we haven’t yet finalized on what that will look like. The hope is that we can create a model that can be reused in other cities (iHackMTL anyone?).

Likewise, the final decision on which local charities will be receiving the proceeds has not yet been made. Something like ten organizations submitted proposals before the hackfest. It’s great to see so much interest, but it’s obviously not possible to accomodate everyone this round. It’s fair to say that at least one app will be going directly to an organization which helps in some way to address poverty in the HRM. I think there’s a collective understanding among the participants at the hackfest that we’ve been quite blessed by circumstance and good fortune and that there’s a responsibility to help those who haven’t been so lucky.

As for the apps themselves, the plan is to put the source up on github ASAP under the MIT License. I’ll be sure to post an announcement when this happens (though this is of course only of interest to the hardcore geeks).

Thanks again to the participants and the sponsors (The Hub, Local Source Organic, Be Wellness, Splice Training, Say Hi There!, Mindsea, innovacorp, Nova Scotia Rural BroadBand and Development, Humina Huminah) for the amazing weekend. Most especially, Dale Zak, the event organizer (and happy hacker) deserves huge kudos for the amazing idea and the perseverance to make it happen.

No Comments »

Easily extensible command module through reflection

Mark Côté, 15 July 2009

The wikipedia describes reflection as “the process by which a computer program can observe and modify its own structure and behavior.” Sounds on the surface like some crazy theoretical computer science, but it’s actually easy to use reflection in real-life applications. At the risk of making this blog Python specific, I’ll show you a simple example of how you can use Python’s reflective character to create an easily extensible module for executing commands. This isn’t particularly advanced, but it does show the power of the current generation of programming languages.

Say you have some sort of application that supports a number of different commands–through network protocols or parsed files or the like. It’s not a heavy program, so you have one class that is responsible for executing the code associated with each command: you want to avoid the boilerplate of having an object for each command. In C++, each time you’d want to add a command, in addition to writing the function (and of course the declaration in the header file), you would have to add to a growing switch statement an association between the command name (probably declared as a literal somewhere to avoid spelling mistakes) and the command function. So that’s 3 or 4 things that you need to change just to make your app support a new command, and you get the ugliness of a long switch statement.

In Python, thanks to its reflective capabilities, you can create a command-execution function that requires exactly one change to add a new command: adding a new function with an appropriate name (and of course Python has no header files). This is due to the magic of getattr:

class CommandRunner(object):
    ...
    def RunCommand(self, cmd_name, args):
        cmd_func_name = 'Do_' + cmd_name
        try:
            cmd_func = getattr(self, cmd_func_name)
        except AttributeError:
            # handle non-existent command
        try:
            cmd_func(args)
        except:
            # handle exception executing command

You want to support a new command named “foo”? Just create CommandRunner.Do_foo()! If you’ve properly set up your exception handling for AttributeErrors, you can easily error out on nonexistent commands, while seamlessly executing supported commands.

Metaprogramming–no longer just for eggheads!

2 Comments »