Habits: Exercising starting Monday

So back in June I wanted to start exercising as my first habit development. I was all gung-ho, but there was one obstacle I didn't foresee. I had to undergo two surgeries over the course of July and August, leaving me unable to exercise for three weeks total. That destroyed my drive to exercise.

Now I'm done that, and through my crazy Halloween season, so I'm going to start up exercising again! I've picked Monday as my start date. Those of you who know me well might know why. I just wanted to announce to the world that I'm starting up again, and if you want to keep me to task, follow @egerlachhabits on Twitter and let me have it if I don't tweet saying I've exercised each and every morning!

How to get your NFP unstuck when it's in Limbo

I was recently contacted by a friend in a predicament. One of their friends sits on the board of a not-for-profit corporation which has recently landed itself in limbo. More than half their directors resigned en-mass.

For those who aren't aware, the Board of Directors of an organisation is the highest body of a corporation, and answers only to the general meeting--the collective of the members. The Board of Directors needs to have a certain number present--a quorum--in order to conduct business. This number can be defined by law or by the corporation's by-laws. In this case, the by-laws of the corporation required the Board to have five of eight Directors present in order to have quorum. With five directors resigned, this Board could conduct no business.

In order to elect more directors the corporation must call a general meeting. But in order to call a general meeting, the corporation needs a quorum of directors. Quite the pickle!

What you have to do to fix this depends on the jurisdiction in which you are incorporated.

As a Federal Corporation:

This is easy. Section 132 sub-section (2) of the Canada Not-for-Profit Corporations Act allows the remaining directors to call a special meeting to elect new directors.

As an Ontario Corporation:

The only way out I could find for Ontario corporations is a little more complicated. Section 295 of the Corporations Act of Ontario allows a members petition to call a general meeting. It requires 10% of the members of the corporation to sign it, and then the directors have to call a meeting within 21 days. However, if they don't (or in this case can't) then any one of the members whose signature is on the petition may call the meeting. So it takes a bit longer, but it can be done.

The good news is, the laws of Canada and Ontario both allow a not-for-profit corporation to get unstuck if it gets stuck. It's pretty rare to have that many directors resign at once, but in volunteer organisations (which are almost always not-for-profit corporations), it's more likely. Good to know there's a way out.

Domain-Driven Design, meet Interaction-Driven Design?

I've been reading Domain-Driven Design by Eric Evans as a result of being part of a Lean Book Club (thanks to Darcy for introducing me to the club). I'm only on chapter 6, but it's a good book so far. The main thrust of the book is explaining how a well-developed, well-maintained model of your domain allows you to build better software and how a "ubiquitous language" shared by developers and domain experts is necessary to make sure that model means the same to everyone. The book has already given me some insights into why some of the projects I've been involved with in the past (either as developer or as domain expert) have succeeded or been failures.

As a result a bunch of the book so far deals with talking with domain experts and how to crunch the knowledge you get from them into a useful domain model and ubiquitous language. Much of the rest of what I've read so far deals with how to take that model and build your software around it, continuing to develop the model along the way. Eric says: Use the model at the core of your whole development. I'm really looking forward to the rest of the book and to see how Eric brings all this together.

But then, I was having lunch with someone, and we started talking about user interaction. Specifically how some designers only think in static terms, and don't think about interaction. My mind had been thinking about this Domain-Driven Design stuff, and so I was looking at all software development through a "domain model"-oriented lens. But during this conversation I swung my perspective, and started thinking about how a good designer might interact with good developers.

Interaction-Driven Design?

Is there a similar process in developing a set of interactions and a "ubiquitous language" with designers as there is with domain experts? If a domain model is the result of interactions between developers and domain experts, what's the analogous result of interactions between designers and developers? I'm not sure about exactly what the answers to these questions are, but I'm pretty sure there's a comparison to be drawn.

What's interesting to me is that there might be some consequences that arise if both domain-driven and interaction-driven design need to be used simultaneously. In many cases I can think of, business software is defined by the domain experts, and then used by them. There are cases however where the domain experts have to define the software and then have interaction designers make that domain model accessible to other users. In these cases, you might have to continue the model and ubiquitous language up from the domain experts through the developers to the designers, and then you may have to do more knowledge crunching up there, and then bring it back down to the domain experts. This means you have three parties iterating you model instead of just two.

It may be the case that all three parties can sit down in a room and work it out together, but I worry that you might lose the "implement-ability" of your model if the developers don't sit in the middle. One of the tenets of domain-driven design as Eric Evans sees it is that the model sits at the heart of the software. I imagine that you might lose that without the developers in the middle... but in the middle the developers' jobs get more than twice as hard.

This is a really interesting problem to me, and I don't have any answers right now. Anyone else have thoughts?

Building Natty Narwhal Ubuntu Images for Amazon EC2 (with instructions that actually work)

For my current project, I'm using Amazon's Elastic Compute Cloud (EC2). I've chosen Ubuntu as my OS, and so I started with the Ubuntu EC2 Starters Guide, and the UEC images therein. Those are a good base, but I need my own configuration on first boot of the VM.

Naturally, I looked around to see how Ubuntu built their EC2 images, and found in the EC2 FAQ that they build them using python-vm-builder-ec2. Sweet! That seems easy. Oh wait, the EC2 part of vmbuilder has been broken since Lucid. Oh, there's a patch in that bug report. Darn, that doesn't work either.

Fine, let's look up UEC (Ubuntu Enterprise Cloud) stuff and see if that provides successful information. Oh look! How to make your own UEC image, with different instructions! Maybe that will work? Oh no, the part file provided doesn't work with vmbuilder, and the instructions don't port over to EC2 that well. Grrrrr.

Well, looks like I need to provide my own instructions (and eventually fix the wiki). So here I go:

1. Start by creating a part file that will work. As per the vmbuilder man page, each line in the part file can have four fields: mountpoint size (device) (filename). In the man page, it says the third and fourth fields are optional. They're not. So a valid part file is: root 400 /dev/sda1 rootfs /mnt/ephemeral 2000 /dev/sda2 instance

2. Next, build an Ubuntu vm image. This works as long as you don't use any of the ec2 options: $ sudo vmbuilder xen ubuntu --suite=natty \ --firstboot=/usr/share/doc/python-vm-builder-ec2/examples/ec2-firstboot.sh \ --part=./part

3. Bundle and upload your newly created image: $ mkdir image $ ec2-bundle-image --image ubuntu-xen/rootfs --destination ./image --cert $EC2CERT \ --privatekey $EC2PRIVATEKEY --user $EC2USER --arch i386 $ ec2-upload-bundle --access-key $EC2ACCESSKEY --secret-key $EC2SECRETKEY \ --bucket $EC2IMAGESBUCKET --manifest ./image/roofs.manifest.xml $ ec2-register --cert $EC2CERT --private-key $EC2PRIVATEKEY \ $EC2IMAGES_BUCKET/rootfs.manifest.xml

4. The last line of that step will return "IMAGE ami-xxxxxxxx" where the "ami-xxxxxxxx" part is your AMI ID to use when launching instances.

Some notes:

1. You could specify a different --kernel and --ramdisk when you ec2-bundle-image, but the defaults work well. I couldn't find a list of AKIs and ARIs with descriptions. If someone could help me out on that it would be awesome.

2. You need to set up the environment variables (the things that start with $) to make this work. The names should be self-explanatory.

3. You may want to customize your first boot script from the ec2 default.

4. You can use the --addpkg parameter to add packages to your vm in the vmbuilder step (one package name per --addpkg). That's from the old JeOSVMBuilder docs. Lots of "hidden" info about vmbuilder there.

Balancing Robot at KwartzLab TON

At July 12th's KwartzLab Tuesday Open Night there was a Balancing Robot made by Phil and Nick, two UW mechatronics students, for their 4th year project. It's designed to eventually allow telepresence, but the fact that it stands on its own is awesome!