OSQA is a python/django based StackOverflow clone with a lot of nice capabilities. You might’ve seen me mention it on twitter.

Hernâni and Rick were tremendously helpful on IRC to help get past some of the things not covered in the installation documentation. Here are my notes on how to get OSQA working on OS X with SQLite (something very similar should work for Linux and mysql):

My OS X setup is: OS X 10.6.3, Python 2.6.4, Django 1.1.1.

First, install the pre-requisites:

sudo easy_install south
sudo easy_install markdown
sudo easy_install html5lib

Now create your local settings file:

cp settings_local.py.dist settings_local.py
vi settings_local.py

Setup your database settings in settings_local.py. Here are mine with sqlite:

DATABASE_NAME = '/Users/darugar/Packages/OSQA/db/osqa.sqlite3'
DATABASE_USER = ''
DATABASE_PASSWORD = ''
DATABASE_ENGINE = 'sqlite3'
DATABASE_HOST = ''
DATABASE_PORT = ''

Now it’s time to create the database:

python manage.py syncdb --all
python manage.py south --fake

That should do it, now you can run your server:

py manage.py runserver 0.0.0.0:9876

Once you’re up and running you should be able to go to http://localhost:9876/ and see OSQA in action.

I don’t know why but I’m seriously in love with this drawing from the six year old; it seems to have a real style. Better than anything I could draw, methinks.

Most of the examples I found for python-oauth2 show how to use the library to request and approve tokens, but not how to use the access token to access a protected resource (ie. how to actually make a call to the service you’re trying to access). Here’s an example:

import oauth2 as oauth
consumer = oauth.Consumer('consumer-key-here','consumer-secret-here')
token = oauth.Token('access-key-here','access-key-secret-here')
client = oauth.Client(consumer, token)
response = client.request('http://someservice.com/api/something/')

And here’s how you make a POST call:

import urllib
response, content = myclient.request("http://someservice.com/api/something/", \
    method="POST", body=urllib.urlencode({'name': 'value', 'another_name': 'another value'}) )

AndBot, recently featured in Mashable, is about the best source for Android news and reviews out there. If you do anything Android you definitely need to check it out.

To boot, its creator Courtney is a good buddy of mine, a fantastically smart and good guy.

I had a good laugh when I saw Mashable describe it as “one of the best-looking sites when it comes to researching Android apps” though, as I was recently giving Courtney a hard time about the design. Turns out it’s plenty good I guess

The scenario: user Alice wants to allow SimpleService to access Twitter on her behalf.

Before OAuth this would be done by having Alice give SimpleService her login credentials for Twitter. She would type in her Twitter username and password into SimpleService, and SimpleService would use those credentials to access Twitter on her behalf. This was bad because SimpleService now knew Alice’s credentials, and could do malicious things or carelessly leak her credentials to malicious people.

With OAuth Alice doesn’t have to give SimpleService her Twitter credentials. Instead she goes through a process wherein she tells Twitter that SimpleService is allowed to act on her behalf.

The flow is:

First, before Alice is involved, Twitter and SimpleService exchange secret information: SimpleService requests Twitter to provide it with a consumer token and a secret. The consumer token will be used to identify SimpleService to Twitter, and the secret will be used to secure the communications to prevent others from pretending to be SimpleService.

This is setup once, allowing SimpleService and Twitter to communicate in general.

Once setup, for each user that wants to allow SimpleService to access Twitter on their behalf, the following happens:

• The user Alice goes to the SimpleService website and requests SimpleService to access her Twitter account.
• SimpleService calls Twitter with a request_token call. This tells Twitter SimpleService is about to have a conversation with it regarding authorization.
• Twitter responds with a request_token.
• SimpleService, having received the token from Twitter, redirects the user’s browser to a Twitter authorize page, passing the along the request_token as part of the url.
• Twitter grabs the token (along with various signatures and timestamps to verify the request is not forged).
• Twitter displays a page to the user asking her if she wants to give SimpleService access to her Twitter account.
• If the user says no the game is over, and the token is not authorized.
• If the user says yes, Twitter redirects the user back to SimpleService, passing along an authorization token, letting SimpleService know the user authorized access.
• SimpleService now exchanges the authorization token for an access token: it calls Twitter with the authorization token, and requests Twitter to give it an access token.
• Twitter examines the token SimpleService sent it, verifies that it’s not forged and that the user Alice had earlier authorized that token for access. It now believes that Alice wants to grant SimpleService access to her Twitter account. Twitter responds to SimpleService with an Access token.
• SimpleService grabs the access token and stores it, associating it with the user Alice.

Now the initial authorization dance is done: SimpleService has an access token that allows it to access Twitter on behalf of Alice.

To actually access Twitter on behalf of Alice, SimpleService includes the access token with each call it makes to Twitter on behalf of Alice. Twitter checks the token, verifies that is valid, and allows SimpleService to access Alice’s resources.

To be an OAuth service provider (that is, play the part of Twitter), you need to:

• Have a way to exchange consumer tokens and secret keys with third parties (eg. SimpleService) that want to access your APIs.
• Provide a request_token service that provides tokens that start the conversation for each authorization.
• Provide an authorization page that tells the user that a third party (eg. SimpleService) is requesting access to her resources, and allows her to accept or reject the request.
• Make a callback to the service (eg. SimpleService), informing it that the request has been authorized.
• Provide an access_token service that accepts a request token that’s been authorized and provides an access token to the third party (eg. SimpleService).
• Store the access token for the user that authorized it.
• Accept access tokens as an authentication mechanism for API calls, verifying the token’s validity and authenticating the user associated with that token.

Having managed to blow the 140A fuse in my Lexus RX 300 by hooking up the wrong battery (thanks Kragen!), I wrestled with how to replace it for quite a while. It’s complicated and I didn’t find any good explanations on the web, so I’m writing it up here:

The 140A fuse is bolted into the fuse box, so no matter how hard you try to pull it from the top it won’t come off. You’ll need to disassemble the fuse box, remove the bolts, and then replace it.

First disconnect your battery to prevent any accidental shorts or sparks.

The fuse box is attached to the body of the car with 2 bolts, and there are multiple latches connecting the top portion of the fuse box to the bottom portion. Remove the bolts, then insert a flat screw driver head into each latch, pushing it apart to let the latch release. The top of the fuse box lifts up, so you’ll see each latch get free and be able to move up. There are 4 or 5 latches all around, including one semi-hidden one where the fuse box lays against the body of the car. You’ll only be able to see it when you remove the bolts.

Once the latches are open, pull the top half of fuse box up and move it around to give yourself some room to maneuver. You’ll see lots of wires connected to it. You may want to open up the air filter to open up more.

Now you need to remove the top panel in the top half of the fuse box. This is where I wasted a lot of time – it just didn’t seem to want to come out.

The trick is to push it down and get it out from the bottom of the top part of the fuse box, not to try to pull it up. Look for the latches around the top of the panel where the 140A fuse is – there’ll be little openings that a flat screw driver head can fit through. Put the screw driver in and free up the latch so the top panel can slide down towards the bottom of the fuse box. Once you have all the latches freed the top panel comes out fairly easily.

Now all you have to do is to remove the blots that hold the fuse in place. Replace the fuse and put everything back as you found it. The trickiest part is getting the hidden latch back in place, but once you have that you’ll be set.

Good luck. It’s tricky, so hang in there. I spoke with several mechanics, including a couple of mechanics from the dealership, and none of them could give a good explanation – in particular, 2 of them told me the top piece of the panel would come out from the top, and that the housing would probably break when removing it. Not true – it comes out from the bottom, and there’s no need to break anything.

At first I thought the arguments justifying Apple’s ban of non objective-c development by claiming that resulting apps would be lower quality were absolutely moronic (and hence the people making the arguments either blinded by religion or morons). After all, it’s not like there isn’t a review process already in place. But the more I think about it the more I see where they’re coming from.

I think we should apply the same model to the Web . Imagine if we all had to use the same development environment and tools, and that there was a single entity who could decide, arbitrarily, if the thing we just spent months building should see the light of day or not. Wouldn’t that be awesome?

If the internet has proved anything, it is that a closed, tightly controlled environment based on uniformity of tools and development environment, and a benevolent master overseeing everything is the right way to go.

I’d tried to use Google Wave on several occasions as a tool for remote collaboration. All attempts had ended in various degrees of disaster, so I didn’t have high hopes for this round. In fact we tried Google Docs, Zoho Docs, and even Etherpad as alternatives first, with Etherpad being the most effective solution. That is, until we tried Wave again.

It turns out effective remote collaboration for document authoring requires two distinct things:

• A shared document with:
  • near real-time updates for everyone
  • an indicator of who’s editing what and what’s recently changed
  • the ability to view and restore earlier versions
• A separate communications side channel

Wave provides strong shared document capabilities, as well as very nice communication capabilities via chat.

The problem, however, is that the “chat” can and often does take place within the document. The “chat” quickly becomes graffiti all over your nicely formatted document, and you have expend serious effort cleaning it up .

The solution is to separate out the discussion or chat mechanism from the document completely. In this case we used iChat with voice and video for all participants. I’m no fan of video conferencing, but I have to admit even the video was useful – particularly to gauge the level of engagement of each person at any point in time.

It is also very useful, by the way, to have multiple screens available. The document can live on one screen while the talking heads occupy the other.

I was surprised at how effective the setup was. We will definitely be using this again in lieu of travel.

Quote from Steve Jobs, via Miguel de Icaza:

We have to let go of this notion that for [us] to win, [our purported competitor] has to lose. We have to embrace the notion that for [us] to win, [we] have to do a really good job. And if others are going to help us, that’s great. Because we need all the help we can get. And if we screw up and do not do a good job, it is not somebody else’s fault, it is our fault.

Mr. Bray has joined the empire of no evil, the Android group no less, and has been writing useful things about Android and Nexus One. He also has deep roots in the world of scripting, has been an advocate, and has been fearless in his experiments with languages new fangled and old.

So I’d like to make a request of Tim, one that I think would make a tremendous impact. Tim: please help bring scripting to Android development.

I know that a lot of people like Java and find the current development environment just dandy. Which is great. But many other reasonable people would prefer to keep their hands clean of Java and feel a greater degree of productivity using higher level languages.

Imagine a scenario where you could write a Python, Ruby, or Javascript script, get it onto the phone using a simple interface (eg. just upload it to a url), and have a native app. Imagine how many more people would be developing apps, and how much more quickly.

I’m looking for something like this: supported and documented as a standard part of the Android SDK, all reasonable APIs needed to develop native apps exposed as Javascript (and/or Python or Ruby, but Javascript is likely the widest reaching bet). And a reasonable packaging process that is only slight more complex than tar.

There is absolutely no reason this can’t be achieved. In fact projects like Appcelerator and PhoneGap have already made tremendous strides in this direction. All it takes is a believer to take the initiative and make it happen.

I feel Tim is that believer. And so I humbly submit, Mr. Bray, that the most important impact you could have on Android is to embed a love and support of scripting languages into the SDK. Pretty please.

For future reference:

I needed to simulate a slow connection for testing an HTTP file upload, time the results, and see how reliable it was. Turns out it’s all doable with curl using the right set of incantations. Here they are:

curl -F file=@/tmp/sample-large-image.jpg -F some_parameter=1027504 \

    -u myusername:mypassword -w "\nTIME: %{time_total}\n" \

    --limit-rate 10k http://somewebsite.com/api/upload/

What this is saying is:

• Upload the file /tmp/sample-large-image.jpg . Note the “@” symbol – that’s what tells curl this his a file upload.
• Set the parameter some_parameter to 1027504
• Use HTTP basic auth to login, with user “myusername” and password “mypassword”
• Include the word “TIME” followed by how long the upload took in the output
• Limit the upload bandwidth to 10k bytes per second

curl continues to amaze with its flexibility.

Excuse the bullshit title, I’m just a little bit sad right now that my RSS feed is filled with “19 ways to do this” and “7 tricks of the other”. Are we ever going to move beyond this tripe or is this the confirmed future of the web?

Anyway, the point of this post, if there is any, is to reveal to you the secret of getting traffic to your blog and of adding twitter followers. Ready? Here it is:

There is no further secret that I’ve been able to figure out.

Take, for example, my recent post on How To Be A Good Participant On A Panel. It’s brilliant. Go read it. I’ll wait.

That post got tweeted a number of times, including by Dave McClure, one of the most interesting guys in the startup world, and it got a link from Simon Willison, whose link blog is the single best resource for finding all things of interest in the web/tech world.

I am pleased.

Now let me tell you about that blog post. It took about 45 seconds to write, and I came very close to not publishing it. It is, after all, just a little puff of air.

I have at other times written important, interesting, thought provoking masterpieces and even made some effort to get them noticed. Yet, as often as not, they fail to garner any interest.

My Become an Assassin post, however, still gets quite a bit of traffic (from people who actually want to become assassins).

Go figure.

Which is to say, there is no figuring it. When it comes to blogging or tweeting, the best policy is to not worry about it and just write whatever interests you, no matter how earth shattering or inconsequential it is. Resist the urge to censor yourself; just push publish.

Mark Suster and Fred Wilson have both posted on the topic of being a good panelist. I’ll throw in the best advice I ever got on the topic (from Alex, who got it from someone else):

Disagree with other panelists.

A panel of people agreeing with each other is generally tremendously boring, and any topic that’s interesting enough to be brought up as a question to panel must have at least two sides that can be argued.

So argue the other side. Find someone else on the panel willing to go toe to toe with you, and disagree with what they say. The point is not to start a fight, but to create an engaging discussion. It’ll force you to think on your feet and it’ll entertain the audience.

I was surprised at how little information I found on making use of Django’s permission system. Here are some quick notes on one way to use it:

Groups are groups of users. For example, you could define a group of users who have premium accounts, or have been verified in some way, or are somehow special:

from django.contrib.auth.models import Group, Permission
special_users = Group(name='Special Users')
special_users.save()
really_special_users = Group(name='Super Special Users')
really_special_users.save()

Now you have two groups defined and can define permissions for them. Django associates permissions with models (note: not model instances, but models). You’ll need to select a model to apply the permissions to, and do a small dance with “ContentType” to find that model’s content type:

from django.contrib.contenttypes.models import ContentType
somemodel_ct = ContentType.objects.get(app_label='myapp', model='somemodel')

can_view = Permission(name='Can View', codename='can_view_something',
                       content_type=somemodel_ct)
can_view.save()

can_modify = Permission(name='Can Modify', codename='can_modify_something',
                       content_type=somemodel_ct)
can_modify.save()

You’ve now defined two permissions and can associate them with your Groups:

special_users.permissions.add(can_view)
really_special_users.permissions = [can_view, can_modify]

Our groups and their associated permissions are ready to go. Now we just have to associate these permissions with users:

jack=User.objects.get(email='jack@test.com')
jack.groups.add(special_users)

jill=User.objects.get(email='jill@test.com')
jill.groups.add(really_special_users)

We’re all done. Now we can check the users’ permissions:

>>> jack.has_perm('myapp.can_view_something')
True
>>> jack.has_perm('myapp.can_modify_something')
False

>>> jill.has_perm('myapp.can_view_something')
True
>>> jill.has_perm('myapp.can_modify_something')
True

And to use it in your templates:

{% if perms.myapp.can_view_something %}
Here is something for you to see.
{% else %}
Can't show you!
{% endif %}

I remarked to a friend that Mark Suster’s entrepreneurial roots show in his approach to being a VC – he’s come out of nowhere and in short order aggressively pushed himself into being one of the most relevant voices out there. He seems to be working a lot harder than the others guys, exactly as you’d expect an entrepreneur to be. Not exactly what you’d expect of a VC.

His blog is fantastic, and I quite often agree with his advice.

That’s why I found it odd that his The Best Entrepreneurs Are Hyper Competitive & Hate Losing struck such a dissonant chord with me.

Shuffling through the successful business people I know and trying to gauge whether they would be the type of people who are obsessed with winning, even in a family game of scrabble, I don’t come to a clear conclusion. I know hyper competitive people, but I also know plenty of people who are able to separate their business behavior from their personal behavior. And not obsess with beating the competition.

Maybe that’s what’s not sitting well with me – Mark’s definition of winning seems to be beating the competition.

Some of the best entrepreneurs I know don’t obsess with the competition. They obsess with their own behavior.

Here’s a contrived example – look at Apple. Do you see Jobs competing with the others in the industries he enters, or do you see him trying create the best possible product, distinctly separate from what his competitors are doing?

Frankly I have a hard time picturing a lot of these guys stressing out over scrabble or Guitar Hero.

Mark’s a very successful guy and his approach has certainly worked for him, but I disagree that you need to be obsessed with winning in the way that Mark describes it.

Look at this way: you could destroy all your competitors and still not win. You could also win without destroying any of your competitors.

First, pick the right game. Then, pay attention to playing that game as best it can be played. Competing may be an important tactical part of playing the game, but it’s probably not the part to obsess over.

django-mptt is a library for storing tree oriented data using the Django ORM. It allows you to place your model instances into a tree structure and efficiently query for ancestors and children.

Here’s a brief tutorial on how to use it:

After installing, you’ll need to modify your model to include a “parent” field, and register it with mptt:

class Person(models.Model):
    contact   = models.ForeignKey( Contact, db_index=True )
    role      = models.CharField(max_length=20, blank=True)
    parent    = models.ForeignKey('self', null=True, blank=True, related_name='children')

    def __unicode__(self):
        return "Person: <%s>" % (self.contact.email, )

mptt.register(Person)

mptt dynamically adds fields to your model, so you’ll need to syncdb after you’ve added the parent attribute and the mptt.register call to your model.

The basics are fairly easy to use:

To move a node to the root of the tree, use move_to with a targe of None:

person1.move_to(None)
person1.save()

To make a node the child of another, set its parent:

person2.parent = person1
person2.save()

To find the children of a node, use the children field:

>>>person1.children.all()
[<Person: Person: <test2@testing.com>>, <Person: Person: <test3@testing.com>>]

Here’s a little snippet of code to setup a 15 node tree where each node has two child nodes:

[UPDATE] The code in this snippet is not correct – you have to save each node as you update it, then look it up again. You can’t modify a node, save it, then use the reference you already have for it. I’ll update the code when I get a chance

contacts = []
people = []
for n in range(15):
    c = mod.Contact(email="test" + str(n) + "@testing.com")
    c.save()
    contacts.append(c)
    p = mod.Person(contact=c)
    p.save()
    people.append(p)

people[0].move_to(None)  # Root
people[0].save()
for n in range(1,15):
    people[n].parent = people[(n-1)/2]
    people[n].save()

Now let’s take a look around:

>>>people[7].parent
<Person: Person: <test3@testing.com>>

>>>people[3].children.all()
[<Person: Person: <test7@testing.com>>, <Person: Person: <test8@testing.com>>]

Now let’s move things around a bit; we’ll take person3, which is 2 levels down from the root, and make it a direct child of the root:

>>>people[3].parent = people[0]
>>>people[3].save()

>>>people[0].children.all()
[<Person: Person: <test1@testing.com>> <Person: Person: <test2@testing.com>>, <Person: Person: <test3@testing.com>>]

And we can look at the ancestors of a given node:

people[14].get_ancestors()

I’m a big fan of Fantastic Mr. Fox. We just watched it again and it was a hit with everyone from the 2 year old to grandma.

The dialog an voice acting are excellent, and the animation is really refreshing. The story is smart and is different enough from your typical Disney fare to be a welcome change.

I recommend it, go see it.

I was doing some log analysis this morning and was struck by the variety of user agents accessing Xpenser. Quite a bit of mobile access with quite a variety of different browsers, as well as some more exotic items (various tablet PCs I don’t recognize, etc).

Then there’s the API access that’s been picking up quite significantly – in fact, I wouldn’t be surprised if it overtakes regular web access in a little while.

For quite a while the web we had a fairly uniform set of entry points – IE and FireFox for the most part, with a smattering of others thrown in. There is so much more variety now, and the variety is significant – for example, the difference between a mobile device and a desktop browser is much more significant than between IE and FF.

I’m hoping other modes of access become commonplace as well – boxee, tablet PCs, etc.

It feels like we’re at a transition point from uniformity to diversity again. This will mean pain the short term as we adjust, but a richer and more encompassing experience once we make it to the other side.

I’m looking forward to it.

Here’s a little script for finding files modified more than 7 days ago and moving them to another directory:

find . -type f -mtime +7 -print > /tmp/old_files.txt
cat /tmp/old_files.txt | while read line; do mv "$line" ../old_files ; done

I’ve seen a bit of uninformed chatter on this, so let me add my own uninformed 2 cents:

First, I think Google actually does want the web to be faster and better. They recognize that the web is their platform and any improvement to it has an eventual benefit for them.

But Google DNS also provides other benefits. It’s true that there is an advertising opportunity in hijacking mis-typed domains and displaying ads against them, as OpenDNS does. This is potentially a large market – domain squatters, for example, make a tidy living doing something similar. I don’t think Google will actually do this. At least not anytime soon – it’d just be too creepy coming from Google.

What Google is really after is data. In particular, traffic and usage data.

By using Google DNS you effectively tell Google exactly what sites you’re visiting, when. Google gets access to your browsing patterns without having to install a toolbar or spyware on your computer.

How valuable would usage data be to Google? Knowing exactly what sites you visited, when, and how frequently?

Extremely valuable. They could use this information to develop refined models of your interests and behavior, and use it to better target ads to you. Nice.

However, their privacy policy states that they won’t do this.

What they will do is use the data to form a better model of the web.  They’ll know, for example, how popular sites really are and how much traffic they get. They’ll also be able to build user and browsing pattern models – eg. people who use facebook are also likely to use sites X, Y, and Z. They’ll use this data to improve search and advertising.

Look for Google to start offering its DNS services for free to internet provides, corporations, or anybody else with large amounts of users. Instead of paying ISPs for access to their usage logs, now they can get their own, and it’ll only cost them the overhead of running a large scale DNS service.

Peter Norvig’s message has been that more data trumps better algorithms. Google DNS is a beautiful way for Google to get a tremendous amount of data with very little intrusion while looking (and behaving) like saints.