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.

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'}) )

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

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.

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.

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.

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.

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.

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.