If you create a model class in Django and then create a model subclass of that, then Django creates a 1:1 relationship to a table with the extra fields defined in the subclass. This results in there being an instance of the parent class as well as an “extended version” of that object in the subclass. That works out rather well for most cases, but there’s a few edge cases where it’s not sufficient.

Say I have an object A and a subclass B:

class A(Model):
	created = DateTimeField(auto_now_add=True)


	
class B(Model):
	modified = DateTimeField(auto_now=True)

I’ll wind up with some tables like this:

A

B

What this means is that if I instantiate PK 1 via A’s manager, I’ll get an A and only ever an A because the information about what kind of object it is exists only in B’s table. So if I have, say, a blog engine like Tumblr where there are text, image, video, audio, and other kinds of posts and I’ve made them all model classes based off RootBlog, I can’t do a lookup by PK and expect the right object; I’ll always get a RootBlog object.

Traditionally, if you had this problem, you’d use abstract classes and just have a different object series for each kind of post. That works, but it means you can’t do shortcuts that just pass around an ID and get the right object — you have to pass around the type as well.

However, there is one trick that’s a result of the 1:1 relationship that could be of some assistance here. When you create an instance of our example object A, it will have a property called ‘b’ that is a link to its corresponding full instance of B. The problem is that we can’t easily follow this without giving the ancestor direct knowledge of all its descendants’ names.

The iPhone 2.1 update also appears to have updated Core Location to track speed and direction…

<+30.43312668, -97.76630400> +/- 47.42m (speed 12.59 kph / course 176.00) @ 2008-10-09 14:16:35 -0500

Problem: the iPhone above is stationary. I suspect it’s a consequence of GPS getting a better fix on the location as time goes by. Kind of neat, though. Gotta wonder what apps will come from that…

Or, rather, what I can do with that.

Codesign error: no certificate for identifier “iPhone Developer” was found in your keychain

Getting this error when building an iPhone app? Yeah … you’re going to love the solution:

After much tinkering around, I tracked the problem to a keychain error.

And TADAAAAA: Go to Keychain Access -> Preferences -> Certificates and deactivate both automatic checking gizmos.

Quit Xcode, relaunch. It worked for me. Instantly.

To get money, I have to bug people. It’s a sad fact of software development, but if the software didn’t destruct in a period of time, I’d be working for naught.

Right now, Notae goes four weeks (28 days) in a full-access demo and then locks down, hard. I’m seeing the majority of conversions within the first three days, and most of the rest in the first week. While I look at it and say “I would, myself, appreciate thirty days to get used to something as intimate as a notes program” I can also see getting used to it within two weeks as well.

Of course, with a time period that short, you run the risk of someone downloading it, opening it, poking around, and then forgetting about it. Some weeks later he goes to test it out seriously and bam the demonstration period has expired. Suck.

A compromise, then. I’m considering letting Notae run in a full demo for two weeks, and then locking out the user for two weeks before resetting the demo. That should be just enough time to get used to it if you just downloaded it and then enough of a wait so that if you wanted to try a new release after a couple of weeks that it would let you. The registration dialog would explain this and then give either the date of expiration or the date the lockout will reset.

My concerns, then, are these:

• Is two weeks enough time to get to know a program you’ll use pretty much daily?

• Is two weeks downtime enough? I’ve also considered four weeks here.

I remember trying TextMate back when it sucked, around 1.0 or 1.1 or something like that. It was this bastard program that everyone hyped for RoR development and called insanely cool and yadda yadda. Everyone was raving. So I downloaded it and tried it out. I hated it. It broke everything I knew and loved about the Mac in terms of how it worked, and I kept accidentally triggering macros and didn’t see the point to code folding and, really, it was a strange new land that I was totally not ready for.

About a year passed, I think, and I was at a WWDC session this past summer when much of the session was about using TextMate to speed up development. Then I see that some of TextMate’s ideas were incorporated into Xcode 3.0 (code folding, for one). Later, I’m two rows behind Allen as he won an award for the best Mac OS X developer tool.

As I was writing up my long rant on the advertising of Mac software, I was pondering a killer idea for the market. I didn’t include it in the article because I had wanted to do it myself, but, alas, it appears that it’s been done, now.

My idea, specifically, was rotating ads, posted and paid for by the developer, each with time limits to force a rotation. This way, you get a nice selection of ever-changing ads for software going. Depending on how much you paid, you get a higher placement. I had it all worked out, really.