awg's blog

VolSched - The Online Volunteer Scheduling Solution

A couple of years ago, I wrote a script called Shift Scheduler to solve the problem of scheduling volunteers for events. I used it for a couple of installfests, and I still get lots of emails from people with questions about it. Scheduling volunteers is a pain, and having a way to let volunteers sign up for the jobs they want to do is nice. It's also an underserved need.

I noticed that a lot of people who contacted me about Shift Scheduler were event organizers, not technical people, and that they needed help to set up the script on their servers. Even some technical people had trouble with it, since it requires an assortment of non-standard Perl modules. I decided it would probably be good to provide a hosted service where people could create events, jobs and shifts just as they would with Shift Scheduler, then give potential volunteers the URL to their event and let them sign up. I figured some people might even want the world to be able to see their events, in some sort of listing.

Thus, VolSched was born. It's pretty, it works well, and it provides all the features listed above. It's free to use, and I plan to eventually release the source so others can run it themselves. We'll see what the uptake is like, but hopefully people find it useful.

Getting Pretty Emacs Colors in Screen

Emacs 22 has extremely nice color schemes for syntax hilighting. However, they only work in terminals that support lots of colors. By default, screen doesn't support lots of colors, so you're stuck with the plain old color scheme in emacs when using screen.

I recently found a good guide about how to make the pretty colors work in screen. The original URL of the guide is http://pastie.caboo.se/125089.txt, and I've mirrored it on xvx.ca in case the original disappears.

Happy emacsing.

Getting Things Done With Tracks

I'm a pretty organized and pretty productive person, but I've always had trouble with keeping a to-do list up-to-date, and figuring out how to stay on top of projects. I have a notebook that I write things down in when I have meetings, and a notepad at work that I write things down that I need to do, but I'm not always good at checking these regularly.

I read an article in Wired about David Allen's Getting Things Done method, and I figured it sounded like a decent idea. But I realized that in many ways, I already do this: I try to keep my inbox as empty as possible, I write down things I need to do, etc. What I needed was a tool for Getting Things Done, and my experience with traditional to-do lists and pads of paper told me that they weren't it. I searched the web a bit and found Tracks, a Ruby on Rails application that implements GTD very nicely. I've been giving it a try over the past few days, and I wanted to write down some of my thoughts on it.

One thing GTD encourages that I've found handy is making everything you write down an "actionable item." This has really changed how I use the to-do list-like bits of Tracks. Before my todo list might have said something like "develop content for orientation lab session." Now it will say "email presenter re lab session content," "email labadmin re lab session content" and "meet with presenter and labadmin re lab session content." This means that I don't need to keep as many notes attached to a to-do item, since each one is a speific thing I need to do. This is made feasible by the GTD notion of "deferring" an actionable item. I need to email the presenter right away, but I don't need to email labadmin until next month, and I won't be able to meet with them until after I've heard back from both. So, I create all three to-do items, but only make emailing the presenter show up right away; the other two will show up in a month. Making my broad to-do items into small, concise actionable items has really helped me.

I have noticed a couple of issues: 1) I have to remember to put everything into Tracks. If I think of something while I'm in bed, or when I'm talking to someone, I have to remember it until the next time I'm at a computer (or write it down). 2) I need to figure out a way to integrate Tracks with my email. It'd be nice if I could tell Tracks I'm blocking on someone, and have it automatically unblock that item when I get an email from that person. I might just work on this. 3) A non-GTD issue: Ruby on Rails uses an ass-load of memory. I can't run it on xvx.ca, I have to run it on my home machine because it eats memory like nobody's business.

Anyway, I might post more about GTD/Tracks sometime, but that's it for now. Give it a try if you like, it's working pretty well for me.

Joel On Jon Postel

Joel on Software has an interesting article up called Martian Headsets. Joel describes, very nicely, the issues facing Microsoft (and all browser-makers) as they come out with new versions. In many, many ways I agree with what he says, however I take issue with one part:

And this is where Jon Postel caused a problem, back in 1981, when he coined the robustness principle: "Be conservative in what you do, be liberal in what you accept from others." What he was trying to say was that the best way to make the protocols work robustly would be if everyone was very, very careful to conform to the specification, but they should be also be extremely forgiving when talking to partners that don't conform exactly to the specification, as long as you can kind of figure out what they meant.

My issue with this bit of the article is that this is really a mis-application of Postel's robustness principle. After all, it was intended to apply to protocols. HTML is not a protocol, it's a language. It says so right in the name. Browsers do speak a protocol (HTTP), and in this part of their interaction with the internet, they definitely should follow the robustness principle, but to apply to robustness principle to a language is nonsensical.

Which isn't to say that a misinterpretation of the robustness principle wasn't one of the factors in the current browser-HTML-standards mess. No doubt, someone somewhere said "we should be lenient with our HTML, so that we'll work with as many pages as possible," possibly thinking (s)he was applying the robustness principle, possibly thinking (s)he was just being a nioe person. However, this is not a correct application of the robustness principle at all.

To see why this is a misinterpretation, let us consider how one might apply the robustness principle to another language: C. Your C compiler would want to be strict with its output; it would always produce valid machine code. Good, wouldn't want it to produce an executable that doesn't run. But your C compiler would also be lenient with input. That is, if I declared a function int func(arg1 int, arg2 char *), it would assume that what I really wanted was two arguments of types int and char *, called arg1 and arg2, and generate output accordingly. Of course, down this path lies madness. What if arg1 and arg2 really were types? No reason they couldn't be. Then what is the interpretation of that line? It's nonsense. Making assumptions about what the user intended in C would just be a bad idea. Why is HTML any different?

In the end Joel and I really see things the same way: there should never have been a quirks mode, every browser should have forced people to write valid HTML and people should have listened. But while Joel feels that Jon Postel's robustness principle is to blame, I assert that any application of Postel's robustness principle to a language is a misapplication. Either way, it is absolutely a hard problem that the browser developers of the future will have to face, and I don't see an easy way out. If they keep quirks mode, they perpetuate the problem of poorly-written webpages and crazy browser-specific hacks. If they make standards mode the default (or only) choice, they end up with users complaining about broken web pages and reverting to the previous version. No easy choice there.

Disabling the Annoying Emacs Startup Message

Since upgrading to emacs 22, I've noticed a couple of things. 1) the colors are really nice. Really, really nice. 2) Every time I start it, it shows me an annoying message about GNU. I like GNU as much as the next guy, but when I start emacs I want to see the file I opened right away, not some stupid startup mesasge.

The solution is to add the following to ~/.emacs:

(setq inhibit-splash-screen t)