Write
Birdcage Status Post 0
So, about three weeks ago I committed to posting daily about my programming explorations. How’d that work out? Oh.
Recently, I’ve started learning Objective-C. I needed a new Mac OS application, so I decided to write it. My previous Cocoa work has all been through PyObjC, so this is a new experience. It’s nice to be able to use the Cocoa apis directly, but I miss having a REPL. (And before you point me at MacRuby, F-Script, or Nu, make sure that language’s documentation explains how to handle return-by-reference, such as in this)
It’s a fun, though infuriating experience.
Fun with Descriptors in Python
I always like discovering new features in my favorite languages, especially when it scratches an itch I’ve been having. A week ago, I was wishing I could have a method in Python be both an instance method and a class method, though now I can’t recall exactly why. But last night, I saw Ian Bicking’s article Decorators and Descriptors, and I realized I could do that with descriptors.
Descriptors, for those of you who didn’t read the link above, are functions that are run when methods (or attributes) are looked up on new-style classes. The default descriptor on functions is what’s responsible for sticking the self at the front of the argument list. Here’s one that changes the function based on whether it’s being called on a class or an instance:
Still not sure what this would be useful for, but I thought I’d paste it here, because it was fun.
Isshoukenmei
I’ve been away from blogging for quite a while, and I’ve suffered for it. Every day I let go by without engaging some new programming tool or skill is a day I grow weaker. So I’m making a commitment to write every day about something I’ve done to engage. Unfortunately, now it’s 2:35 AM and I really should sleep, so this one’s really short.
Steve Yegge wrote an excellent essay on prototype-based object mapping. It’s of interest to me because my company’s app has had two different half-assed (and differently half-assed) implementations of the prototype pattern, one of which we’ve just removed. We’re using it to model people (well, actually, contact information), but people don’t have just single-valued properties. They have names with multiple parts, and multiple phone numbers (how many people these days have not just a cell phone but a work cell and a personal cell?) and many other complex values, and I’ve been at a loss for a good way to store these. Steve’s essay has helped to convince me that we don’t need to discard the prototype pattern; we just need to get it right for this use.
In the next few days, I hope to blog here about getting it right.
Time zones in Google App Engine
Time zones are a human — by which I mean comical and insanely complex — thing. If you’re the sort of person who likes to bore people with inane trivia, and I know I am, you’ll find endless grist for your mill in Riyadh Solar Time, where they tried to make 0:00 fall on sunset. Every day. In the best case, that meant the DST offset changed daily. In the worst case, it changed moment by moment. Imagine the hassle of keeping your clocks up to date.
But even in the relatively sane time zone world we have here in the US, things are still pretty complex. There are places that don’t observe DST, and places where time zone borders make things complicated. So my policy for time zone handling in software is similar to my policy for unicode handling in software: convert to UTC on input to the application, and convert to the desired timezone on output. That way, you can do all the datetime math you need, without worrying about getting caught in a time rift or something.
Another way datetimes are similar to strings is this: a datetime without a timezone attached is meaningless. If I tell you a meeting is at 14:00, you could perhaps guess the time zone based on where the meeting will be held. But if you couldn’t do that (perhaps it is an online meeting) you actually don’t know when it will occur at all, because that might be 14:00 Central Time, 14:00 Pacific Time, or 14:00 Central European Time.
Google’s App Engine drops the ball a little when it comes to datetimes. If fed a timezone-aware datetime, it will convert it to UTC for storage. But when the value is read back out of the datastore, there will be no timezone attached. The context of the datetimes is lost, and you could make a case that part of the value of the datetimes is being lost as well.
So I wrote a type wrapper that fixes that. It attaches the UTC timezone to datetimes when they’re read out, as well as ensuring that only UTC datetimes are stored and everything else is converted. That part is perhaps a little redundant, but I wanted consistency.