Oh wait. We’re already in the future.
After many years of proposals, counter-proposals, coups and general disappointment the Australian Government has announced its scheme to allow the economic impact of carbon pollution to be managed by the free market.
I’m really really proud that as a country we’ve reached the point where there’s a plan in place. It’s taken longer than it should have. In 2007 it was a policy of both major parties yet for a while more recently it had been a policy of neither. We’re one of the first countries in the world to pull this off.
The plan announced by Julia Gillard sets an initial price of AUD $23 per ton of CO2 produced, along with subsidies for many industries and tax cuts to low and middle income Australians. A few heavily polluting industries will take a hit, but that’s the idea. Businesses that aren’t pollution-centric seem to largely support the scheme.
There will be a transition in 2015 to a free market emission trading scheme. Amusingly Tony Abbot. leader of the conservative, supposedly free market Liberal Party opposes the idea of allowing markets to determine prices. There’s been some shrill, populist freak-out over new taxes, but the impact is likely to be small enough peoples’ lives that it won’t be an issue at the next election. I’m expecting the bursting housing bubble will be more of a worry.
As we sunset foursquare APIv1 and announce some amazing new milestones for APIv2, now seemed like as good a time as any to reflect on some of the decisions we made in APIv2 and see how they’re holding up. Fortunately, we were able to draw on both our experience with APIv1 and from tight iteration with our client developers (especially Anoop, who is awesome!). We’re pretty happy with the result, but we still made a few mistakes. Hopefully there are some lessons for anybody else out there who gets stuck designing an API.
I like Zsh. It’s a powerful, efficient shell. It’s better than Bash by just about every metric (better performance, more features, better sh compatibility). I really have no idea why people keep using Bash.
Anyway, I put together a little piece of
zshrc to show my current status in right-hand prompt – a prompt that’s shown right-aligned in the shell. Zsh has a couple of features that make this really easy.
prompt_subst options instructs the shell to do variable substitution when evaluating prompts. So if you were to set your prompt to
'$PWD> ' then your prompt would contain your current directory. Of course you wouldn’t do it that way,
%~ does that much more nicely, but that takes us to Zsh’s second feature, ridiculously powerful variable substitution and expansion. In my prompt I just use the simple
$(shell-command) substitution, but there’s a full complement of file-io, string manipulation and more to be had.
This is probably old news to most folks, but I only found out about this recently, more than twelve years into being a Python programmer.
pdb (Python Debugger) module has a few useful functions. For years I’ve been using
pdb.pm(), the postmortem debugger. It can be run from the Python shell to invoke a debugger after an exception. Traditionally I’ve done:
% python -i myscript.py (some exception occurs) >>> import pdb >>> pdb.pm() (Pdb)
But for this to work you need to be able to pass arguments to the interpreter (-i) and the code needs to throw an exception that isn’t caught.
pdb.set_trace(). It begins the same interactive debugger that
pdb.pm() provides upon request, from code. So in the middle of a function that’s confusing me I add:
from pdb import set_trace;set_trace()
and my code will stop, ready for me to tear apart its runtime state. I just wish it had a more descriptive name so that I’d have found it earlier.
Bonus: printing stack traces
Python’s stack traces in exceptions are pretty useful. It used to be difficult to get the current stack in Python, involving raising and catching an exception. Now the
traceback module has
Today I again came across code that I was able to make simpler, clearer and safer using
collections.defaultdict. I keep coming across experienced Python programmers that don’t know about it. Perhaps it’s time to spread the good word.
defaultdict type is a dict subclass that takes a factory function to supply default values for keys that haven’t been set yet. For example
from collections import defaultdict frequency = defaultdict(lambda:0) for c in 'the quick brown fox jumps over the lazy dog': frequency[c] = frequency[c] + 1
Will count the frequency of characters in a string.
I often use
defaultdict for dicts of dicts (
defaultdict(dict)) and dicts of lists (
defaultdict replaces some pretty simple code, for example the above code could be written:
frequency = dict() for c in 'the quick brown fox jumps over the lazy dog': if c in dict: frequency[c] = frequency[c] + 1 else: frequency[c] = 1
but I find using
defaultdict is not just shorter but also much clearer.
The other classes in the
collections class, especially
Counter (which is an implementation of the pattern I just implemented here on top of
defaultdict) seem useful, but I’ve never found myself actually using them, whereas
defaultdict is a common part of my repertoire these days.
Launch your application, oh look, an update! Clicking “Update” takes you to the Mac App Store web site.
Click “View in Mac App Store” since apparently I’m not doing that yet, but wait!
Tell my browser that it’s okay to do what I just told it to do.
We’re launched into the Mac App Store app, so we need to click the grey on grey “Updates” button / tab / thing…
And click “Update all” or just “Update”.
Sign into my Apple account for some reason.
Oh we need to quit the app. Command-Tab…
Quit the app.
Back to the Mac App Store app again.
It’s updated and I can launch it again.
Ten only marginally confusing steps!
At least they got the gradients, drop shadows, rounded corners and noisy backgrounds right.
In the interest of getting some of the fragments of code I’ve written off my hard disk and out where someone might find them useful I’ve decided to start dumping them into git repos with some very minimal documentation. Minimal enough that I actually kick them out there.
The first is a simple Python library to access Google Voice’s calling and texting functionality:
% python Python 2.6.1 (r261:67515, Jun 24 2010, 21:47:49) [GCC 4.2.1 (Apple Inc. build 5646)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from googlevoice import * >>> gv = GoogleVoice('googleaccount', 'googlepassword') >>> gv.sms('+1415MYNUMBER', 'this is a test') >>> gv.call('+1415MYNUMBER', '18003569377')
The library depends on BeautifulSoup. It’s based on a bunch of work that I found on the internet. I don’t remember exactly whose techniques I ended up using, but there’s a bunch of example code out there, just not much that was simple to use and in Python.
For those of us on cable or DSL who are slightly too cheap to pay for a static IP, dynamic DNS services are really useful. My DD-WRT based router knows how to talk to dynamic DNS providers, so setting it up is really easy.
I’ve tried both DynDNS and No-IP, and while they work quite well they’re kind of annoying. They really want me to sign up for a premium service, after all that’s how they make money. As a result I need to periodically visit web pages to confirm that I’m using an address or pay a fee. It’s not a big fee, but I’m already paying someone, DreamHost to host DNS for me, and they’ve got an API…
So I threw together a little script that implements the DynDNS API and modifies your own DNS zones using the DreamHost API. You can get it from here:
The setup instructions are included in the README. Hopefully they’re pretty self-evident, but they are written from the perspective of someone who ran their own DNS servers (primary and secondary) for ten years.