Someone asked this among a group of perfectly intelligent UC Berkeley staffers and no one had a good answer, so I think this is a good exscuse to start using this blog in one of the ways I originally intended it: answering my own questions.  More to come…


First of all, not all of California has a Mediterranean climate. A Mediterranean climate is one in which summers are hot and dry and winters are mild and rainy, similar to the regions bordering the Mediterranean Sea. These conditions exist in CA from about Cape Medocino south to Baja, and east to the Sierra Foothills.

Read the rest of this entry »

I’m just getting started with git.  Turns out if your git binaries are in a path specified in something like .bash_profile on your remote machine, something like git clone ssh:// will fail with an error like bash: git-upload-pack: command not found because sshd ignores .bash_profile, so git won’t find its binaries. So you need to alter the PATH env var in .bashrc instead. Fun.  The git-clone-pack man page is worth a look.

Django 1.0 is coming, and it’s bringing needed but backwards-incompatible changes to the admin site, ostensibly the best thing about Django.  One problem I’ve run into while migrating to the new version is inline editing of related classes in existing classes.  For example, it’s pretty common (and recommended) to “extend” Django’s built-in User model by creating your own, related Profile model.  For the old admin site, you specified the ability to edit a relate Profile in the User form in the Profile model:

class Profile(models.Model):
    user = models.ForeignKey(User, unique=True, edit_inline=True)

That was simple, but kinda quirky. Changing the way the User form looks by changing the related Profile model? Weird. BUT, it did let you make changes to the User model w/o mucking with the built in Django code.

The new way of doing things is to specify all your admin site options in a separate file, and inline editing is now a little more reasonable: if you want to edit related objects in a model’s form, you specify that in that model’s admin options. But this means you need to alter Django’s built-in User model’s admin options, which could mean muckiness. So here’s what I did in my myapp/

from django.contrib import admin
from django.contrib.auth.models import User
from myapp.models import *
class ProfileAdmin(admin.ModelAdmin):
    # just some stuff for my profile forms
    filter_horizontal = ('teams',)
    radio_fields = {'appointment': admin.HORIZONTAL}
    list_display = ('user', 'picture', 'appointment', 'affiliation'), ProfileAdmin)
# need to make an inline class...  ick
class ProfileInline(admin.StackedInline):
    model = Profile
    max_num = 1
# the meat: grab the existing UserAdmin class, modify it, unregister User,
# and re-register User with the modified UserAdmin
UserAdmin =[User].__class__
UserAdmin.inlines = [ProfileInline,], UserAdmin)

Took me a while to realize held instances of the ModelAdmin classes, not the classes themselves. This technique also assumes that User gets registered with the admin site before you run this code. I’m guessing the order in which admin.autodiscover() registers models is the same as the INSTALLED_APPS setting in

In case you’re working through Developing Facebook Platform Applications with Rails, you might have run into problems with authenticity tokens and FBML forms.  Quick dumb fix to save you 2 seconds:

    action="<%= new_invitation_path %>"
    type="Karate Poke"
    content="YAYS I added this facebbok app">
      actiontext="Invite your friends to use Karate Poke"
    <%= hidden_field_tag :authenticity_token, form_authenticity_token %>