My cycling priorities

2010/03/19 1 comment

Here are my priorities as a cyclist:

1. Stay safe.
2. Be courteous.
3. Obey the law.
4. Get where I’m going.

I think 3 and 4 sometimes switch places.

I will try to be courteous to drivers, unless doing so makes me unsafe. This means that at intersections where drivers are likely to turn right, I will pull out and take the lane when possible, even if it slows you down. I don’t mean to be rude, but I’ve had drivers right hook me too many times (no actually collisions yet, thanks be to God).

Sometimes being safe and being courteous means riding through a red light to get out of the way, or to avoid putting myself in a dangerous situation on the other side of the light. I will do this on occasion, but only if absolutely nobody is coming the other way.

Getting where I’m going in a timely manner and obeying traffic laws are important to me, but not as important as the other two. I will not ride in a manner that disrespects or frightens other people, just to get where I’m going.

I haven’t yet figured out my priorities between obeying the law and getting where I’m going. I will sometimes run red lights in empty intersections, but I always look first. I do think it’s important for cyclists to take their responsibilities on the road seriously, as part of claiming our place as a normal part of traffic. My actions and values are sometimes at odds, it seems. Does anyone else wrestle with this dilemma? How do you address it?

Postscript: I will also almost never ride on a sidewalk, because that’s (ironically) an easy way to get run over by cars, who may be pulling out of driveways or parking lots. It also frequently violates the courtesy rule with respect to pedestrians, who always have the right of way.

Advertisements
Categories: Cycling, Sustainability

Psycopg2 has a web site? Sweet!

It just came to my attention that psycopg2, the python driver for PostgreSQL database has a website again! For several months (years?) the site was unavailable, except for an plaintext rant about the author’s ire toward Trac. Now it has several pages of nice-looking sphinx documentation. I haven’t delved into it yet, so I don’t know how good it is, but it’s nice to see a professional looking website providing the public presence for the driver that lets me get at my data. It may be technically irrelevant, but it gives me a little more confidence that the software isn’t as hackish as the site used to be.

If you haven’t seen it yet, I recommend hopping on over to their site, http://initd.org/. It’s well worth a look.

Welcome back psycopg2!

Tricks with iterators.

2010/02/25 1 comment

This post is a follow up to Iterators and Iterables Clarified. If you’re not sure how iterables and iterators differ, how to create them, or why you’d care, start there.

OK, so files are iterators which can be exhausted. Once you’ve looped over a file, it’s done. But let’s say I want to implement a file object that can be restarted. There are a couple things you can do: Probably the simplest technique is that you can create a wrapper around a file object that rewinds the file each time it gets iterated over:

A rewinding file iterable


#/usr/bin/env python

class RewindingFileIterable(file):
def __iter__(self):
self.seek(0)
return self

>>> f = RewindingFileIterable(‘names.txt’)
>>> for __ in xrange(2):
>>> for line in f:
>>> print line,
Tom
Dick
Muhammad
Tom
Dick
Muhammad

Unfortunately, this technique has two problems.
Read more…

Categories: Uncategorized

Iterators and iterables clarified.

2010/02/25 1 comment

So what exactly is a python iterator, and how is that different from an iterable?

An iterable is an object that implements a method __iter__(), which, when called, returns an iterator. The __iter__() method can be called by the iter() function, and is also called behind the scenes in a for loop.

An iterator is a specific kind of iterable. It is an iterable which also implements a next() method, which returns a value each time it is called, until it runs out of values, at which point it raises a StopIteration exception. (And raises a StopIteration every time thereafter). Iterators also as a general rule return self when __iter__() is called.

Read more…

Categories: Code Tags:

Getting django-south working with gis models.

2009/12/14 3 comments

Just a quick note for posterity…

Django’s south data migration utility has a weird bug that turned up when I was trying to work with gis fields.

I’ve been banging my head all day Friday and today against trying to get south working on my geodjango project. My original problem was (I think) that south 0.5 (which is what Karmic installs by default) doesn’t set up m2m columns when you do a ./manage.py startmigration app --initial. (this seems to have been fixed three weeks ago in Changeset 548:486840db6350, though I’m not sure that’s the right revision) Once I realized that, and upgraded to the latest version (via pip), I had a new problem: South couldn’t figure out what do do with my Point column:

jcdyer@aalcdl07:/cgi/django/brp/projects/brp$ ./manage.py startmigration content_base --initial
Creating migrations directory at '/cgi/django/brp/apps/cdla_apps/content_base/migrations'...
Creating __init__.py in '/cgi/django/brp/apps/cdla_apps/content_base/migrations'...
+ Added model 'content_base.Item'
+ Added model 'content_base.ItemType'
+ Added M2M 'content_base.Item.subject_set'
+ Added M2M 'content_base.Item.date_published_set'
( Nodefing field: coordinates
( Parsing field: coordinates
WARNING: Cannot get definition for 'coordinates' on 'parkway.location'. Please edit the migration manually to define it, or add the south_field_triple method to it.
Created 0001_initial.py.

It went ahead and created the migration for me, but left some boilerplate for me to clean up in the frozen ORM definition. Where the frozen orm said:

'coordinates': '< < PUT FIELD DEFINITION HERE > >',

I just had to put in the definition of a geometry field. Working from a nearby example that looked like this:

'milepost': ('django.db.models.fields.FloatField', [], {'null': 'True', 'blank': 'True'}),

I changed my code to:

'coordinates': ('django.contrib.gis.db.models.PointField', [], {'null': 'True', 'blank': 'True'}),

I haven’t yet figured out what the south_field_triple method is.

Edit: Bafflingly, there’s a PointField on another table in the same app which has no problem defining itself.

Categories: Code

Water utilities and pricing rates

2009/11/22 5 comments

I read recently in an article in the Carrboro Citizen that OWASA is trying to increase rates because people are getting too good at conserving water, and they’re not making money. It seems patently ridiculous to me that people should be punished for saving water. On the other side of the same coin, it also seems ridiculous that the utility company should be punished for people saving water. Especially considering that most likely they had some hand in people saving water: imposing drought restrictions, offering free or reduced cost rain barrels, low-flow shower heads, and so on.

The way things are set up, that’s how it goes. The utility company and the populace are at odds with each other. One or the other has to suffer if water consumption goes down. And we want water consumption to go down. By all reasonable measures, that’s a good thing. It seems strange that even so progressive a community as Orange County hasn’t resolved this issue.

This conundrum points to a certain silliness in the system. Our water utility should be in the business of managing our water resources, but presently what they do is simply sell our water to us. The more we use, the more we get charged, and the more money they make. It incentivizes the consumers to use less water, but it incentivizes the utility to get us to use more water. In the Carrboro Citizen article, Town Alderman calls this “The cost of doing good.”

So what can we do about it? Is there some way we can separate the amount of water used from the amount of income the utility brings in? If the water company earned a flat fee per residence (or per resident, I’m not sure which makes more sense), they would not have a financial incentive to make people use more water, nor to impose a punitive effect on the public for doing the right thing in using less water. There would be no “cost of doing good.”

On the other hand, if households paid a flat fee for water, what would the average person’s incentive be for using less water? There should be a cost for doing bad. Warm fuzzy feelings haven’t proven particularly effective at lowering resource usage.

Could people pay on a per-gallon basis, while the utility receives a flat rate? Then both the customer and the utility would have an incentive to use less water. But then where would the variable rate income go? To general city/county coffers?

Better yet, perhaps the government could come up with a reward structure for some combination of quality of service provided and care taken of the water supply (measured by some combination of amount of water saved (relative to some baseline), quality of water provided to the public, and outbound water quality). Whatever the metric, the utility could be paid by how well they met that standard. Thus their financial interests could be aligned with the public good.

Just noticed: the Carrboro Citizen article says that Owasa is looking to find ways to avoid imposing usage restrictions on customers during droughts, rather than trying to raise rates. The point still stands though, that the current pricing scheme disincentivizes the utility from practicing proper stewardship of our water supply. We should find a way of rewarding them that gets them on our side, taking care of both our citizens and our resources.

Categories: Uncategorized