Monthly Archives: September 2010

Secret Mormons!

That insightful guy on the religious discussion forum might be more than he says he is.

Ben reports.

“Their emotional commitment exceeds their equity stake.”

Ben Horowitz, on why his company prefers to give funding to founding CEOs.

Django Hacking Postmortem

The other day at Hacker Dojo we had an informal Django meetup for people to bring their projects and ask each other questions.

It went pretty well I think! Five people showed up, which I think is pretty near the limit of the number of people you can have collaborating before you have to break into subgroups.

One participant (Adelein) first proposed the meetup because she had some questions about many-to-many relationships between Django models. Because I also learned some stuff as we talked through her problem, I’ve decided to write it up here.

The Problem

Adelein is building a social app where developers can talk about what tools they use for different kinds of development. The app lets users create one or more toolboxes, each with one or more tools in it. The same tool (say Vim, or Apache) may be in any number of toolboxes, owned by any number of users. Users can also leave comments on tools to explain why and how they use them. Her Django models (aka database schema) looked something like this:

(Schema diagram purists: keep your criticisms of my graphs to yourself. I’m trying to quickly get a point across, not please a pedantic professor.)

She had a form that showed a tool, the toolbox you had put it in, and your comment on it. Her initial description of her problem was that when she saved the form the information about the tool in the toolbox was getting saved, but the comment wasn’t. As it turned out though, this was more a symptom of a deeper problem. In the schema above, the Tool Note table really knows nothing about the relationship between tools and toolboxes. So there was no way for Django to know that it needed to update the note as well when saving a tool-toolbox relation.

The Solution

Since the UI for the app seemed to assume that there would be one note for each tool you put in your toolbox, we decided that it would be better to have the note refer to that relationship rather than to the tool itself. This meant cracking open the black box of the “thru-table” that Django would normally manage automatically for a many-to-many relationship.

(Sidebar: When I’ve had similar problems in the past, I’ve avoided Django’s built in many-to-many feature because I didn’t understand or trust the magic behind it. So instead I explicitly created and managed the table connecting individual tools with individual toolboxes, or in my case individual (but re-usable) pages with individual volumes. This meetup has given me a bit more confidence in the many-to-many feature though, so I’m pretty sure I’ll use that next time.)

The new schema looked like this:

Nice! But how do we implement that in Django?

Here’s the code to do it, based on a similar example from the excellent Django documentation:

class Tool(models.Model):
  name = models.CharField(max_length=64)
 
class Toolbox(models.Model):
  name = models.CharField(max_length=64)
  user = models.ForeignKey(User)
  #This is the magic part.  We specify the through-table when 
  #declaring the many-to-many field.
  #The name has to be given as a string because ToolboxTool 
  #hasn't been declared yet at this point in the file.
  tools = models.ManyToManyField(Tool, through='ToolboxTool')
 
class ToolboxTool(models.Model):
  tool = models.ForeignKey(Tool)
  toolbox = models.ForeignKey(Toolbox)
  note=models.CharField(max_length=512)
 
  class Meta:
    #This tells the DB that a tool can only be in a given toolbox once.
    #That last comma is to make it clear to python that we're making a tuple of 
    #strings, inside another tuple.  Otherwise it would collapse the outer 
    #parentheses and try to parse each string as a separate tuple.  Not what we 
    #want. see http://docs.djangoproject.com/en/dev/ref/models/options/#unique-together
    unique_together = (('tool', 'toolbox'),)

What’s Next

If there’s sufficient interest, I may sponsor more Django Hacking nights. I’d also like to mix it up a bit and have similar events on other tools I use or am interested in (Javascript, Vim, Haskell). As shown by this meeting, an informal event like this can be thrown together with very minimal effort over just a couple of days. Feel free to leave a comment if you’d like to participate in future ones, especially on any of the topics I’ve listed here.

Good Blogs are Embarrassing

So says Jason Cohen in How I got 6000 RSS subscribers in 12 months. He’s the guy who writes the Smart Bear blog. He makes a bunch of good points, but this is my favorite:

Reveal

Everyone says to “be authentic” and “admit faults” and “tell stories.” All good advice, but repeated so often it’s hard to know what it means anymore.

With few exceptions, my most popular posts reveal something typically kept secret.

If it’s embarrassing, that’s a good sign. If you’re scared that people will think less of you, that’s a good sign. If you know a lot of people will disagree, that’s a good sign.

It’s the controversial sentiment that thousands of people themselves secretly agree with but never had the courage to say. They appreciate and love you for your courage.

It’s the embarrassing underbelly people love to read about — a peek into a world normally hidden, a peek into a story people don’t want to talk about. When it’s embarrassing it’s honest, and when you tell the truth even when it’s difficult, everyone appreciates it.

It’s the story that makes you seem weaker, dumber, more scared, less sure — that’s the story everyone can relate to, though few will admit it. Be one of the few.

What’s more inspiring: Me confidently instructing you how to run a company, or me admitting that I was scared, unsure, almost gave up more than once, didn’t know what I didn’t know, and yet persevered?

Of course there’s a line between personal and professional, between appropriate and inappropriate, between revealing other people’s secrets and revealing your own. You need to decide where that line is, and it’s not true that you have an obligation to talk about home life in order to be authentic.

I probably don’t reveal enough here to keep things interesting. Take this as my resolution to change that.

Rent Control Doesn’t Work

But sometimes the corrupt elegance of its failure is breathtaking:

In the end, the goal of the rent control laws is thwarted (the low rents are enjoyed by well-paid tenured faculty rather than the needy), the income tax laws are thwarted (a sizable part of compensation is untaxed), and all this is done by a nonprofit institution (the university) whose ostensible purpose is to serve the public interest.

Greg Mankiw: A Dastardly Clever Scheme

The Bedbug Argument for Federalism

From Jonathan Adler at The Volokh Conspiracy:

If local communities wish to strike a different risk balance than the feds, the EPA should not stand in their way. It is one thing for the EPA to inform local choices, and help clarify the relevant health trade-offs, quite another to impose one set of health preferences on the nation as a whole. If EPA’s resistance to propoxur was motivated by spillover concerns, such as potential groundwater pollution that could cross state lines, the federal rule would make sense. But it is not and does not. This is precisely the sort of environmental problem which state and local preferences should control.

Slate’s Shady ‘Slatest’ Shenanigans

If you’ve been reading Slate for very long, you may have noticed that they recently added a new feature called The Slatest. I ignored it for quite a while, until one day I finally saw a Slatest story that looked interesting.

And then I got pissed.

Despite the heavy Slate branding, the Slatest isn’t actually built from Slate’s content. It’s just a feed of news articles from other sites. But actually getting to the news story on the original site requires an insane number of clicks.

Let’s walk through it.

Here’s the Slate home page. The Slatest links are in blue, near the center of the screen.

If you click one, you’re taken to a page like this:

Ok, that’s a little annoying, I was expecting to be taken to the article, but apparently Slate wants me to read this little blurb first. Whatever. I’ll click the headline link and go to the story.

What? Two clicks in and I’m still not at the story? I see that there’s a little more content this time, but surely this paragraph isn’t the whole article. Looks like the headline is a link. Maybe this time it’ll take me to the actual article.

At this point, swear words are running through my mind. Why the hell, after all these clicks, am I not at the article yet? Even worse, why is Slate showing me the exact same text that was on the previous page?!

I spot the “New York Times” link at the bottom of the post and try that. FINALLY! I’m at the article I wanted to read.

But at this point I’m too pissed to be interested in the article anymore. I’m taking snapshots so I can blog about this utter fail in website navigation.

To Slate: Quit doing this.

To the New York Times and other sites linked in the Slatest: You’re the ones who should be really mad. Not only is Slate taking your content to dress up its homepage, it’s hiding the links to your sites in tiny type at the bottom of posts, and leading unsuspecting readers on wild goose chases through the Slate site to find the articles they’re interested in. You ought to send Slate a nastygram.