Steven Osborn
"I would love to change the world, but they won't give me the source code".

Django manage.py wrapper script for Google App Engine

April 10, 2008 – 11:54 pm

I’m used to running mange.py in my Django apps and I kept forgetting the name of the Google App Engine equivalents. My script only knows how to do two things at the moment, “runserver” and “publish” but now I can manage everything the way I’m accustomed to.

Update: Aprill 11 - Added toggle_debug, automatically switches debug off when publishing and back on for development.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
#!/usr/bin/env python
#
# Simple convience script for common publishing and develop tasks
# This script expects dev_appserver.py to be in your $PATH
import os, sys, re
 
def main(argv):
 
    command = ""
 
    try:
        command = argv[1]
    except:
        usage()
        exit(2)       
 
    if command == 'publish':
        publish()
    elif command == 'publish-debug':
        publish(True)
    elif command == 'runserver':
        runserver()
    elif command == "--help" or command == "-h":
        usage()
        exit(0)
 
def usage():
    print """
    Usage: python manage.py [command] <options>
 
    Commands:
        publish - 'updates' Google App Engine with your current version
        publish-debug - 'updates' Goolge App Engine with debug turned on
        runserver - launches the development server on port 8080
 
    Options:
        --help, -h - Prints this screen
 
    For more information on a particular command, run [command] --help
    """
def get_gae_dir():
    """ Locate dev_appserver.py and return the directory is in. """
 
    # There's probably a smarter way to do this...
    script = 'dev_appserver.py'
    stdin, stdout = os.popen2('which %s'%script)
    xpath = stdout.read().strip()
    stdout.close()
    stdin.close()
 
    # If the file is a symlink, find out where the actual file lives.
    try:
        tmpdir = os.readlink(xpath)
    except OSError:
        tmpdir = xpath
 
    return os.path.abspath(os.path.dirname(tmpdir))
 
def toggle_debug(status):
    st = 'False'
    if status:
        st = 'True'
 
    os.rename('settings.py','settings.py.bak')
    orig = open('settings.py.bak').read()
    p = re.compile('DEBUG\s=\s(True|False)')
    n = p.sub('DEBUG = %s'%st,orig)
    nw = open('settings.py','w')
    nw.write(n)
    nw.close()    
 
def gae_parent(script):
 
    DIR_PATH = get_gae_dir()
    DEV_APPSERVER_PATH = os.path.join(DIR_PATH,'google/appengine/tools/%s'%script)
 
    EXTRA_PATHS = [
      DIR_PATH,
      os.path.join(DIR_PATH, 'lib', 'django'),
      os.path.join(DIR_PATH, 'lib', 'webob'),
      os.path.join(DIR_PATH, 'lib', 'yaml', 'lib'),
    ]
 
    sys.path = EXTRA_PATHS + sys.path
    execfile(DEV_APPSERVER_PATH, globals())
 
def publish(debug=False):
 
    if(debug):
        toggle_debug(True)
    else:
        toggle_debug(False)
 
    sys.argv[1] = "update"
    try:
        sys.argv[2] = os.path.abspath(os.path.dirname(os.path.realpath(__file__)))
    except IndexError:
        sys.argv.append(os.path.abspath(os.path.dirname(os.path.realpath(__file__))))
 
    gae_parent('appcfg.py')
 
def runserver():
    toggle_debug(True)
    sys.argv[1] = os.path.abspath(os.path.dirname(os.path.realpath(__file__)))
    gae_parent('dev_appserver_main.py')
 
if __name__ == '__main__':
    main(sys.argv)

Google App Engine Limitations

April 9, 2008 – 6:57 pm

I’m really digging the concept that is Google App Engine, but I think they a little bit of work to do before I would be willing to put any effort into porting to their platform. Their marketing points for this include the fact that it allows you to build, deploy and iterate your application quickly, but the fact that I have to now port just about every Python library out there to use BigTable and URL fetcher is a serious productivity loss.

  • Python Only - This doesn’t bother me, but is still a deal breaker for a lot of people.
  • No way to schedule tasks. (cron)
  • No way to dynamically route subdomains. You can’t point *.yourdomain.com at a single script. So your urls have to look like example.com/tulsa and not tulsa.example.com
  • You can’t use any existing libraries that make network fetches. Google forces you to use their URL Fetcher class. Which is broken in several ways:
    • No way to set timeout
    • No HTTP Auth Support
    • Does not follow redirects
  • You have to user BigTable for your Database Layer, so you have to port any existing database code you have. There is also no ORM for Django to use BigTable yet, which means Django Admin interface will not work.

On the bright side, their publishing and versioning process is outstanding. The administration interface is pretty sexy so I’ve take quite a few screen shots for anyone who didn’t get an invite and would like to see it.

Picture 1


Google’s OpenID Provider Via Google Web Engine

April 8, 2008 – 10:32 am

Shortly after Google released Google Web Engine last night, Ryan Barrett of Google released an application for the platform that essentially makes Google an OpenID Provider. Check it out here:

http://openid-provider.appspot.com/

(Thanks Sam for the scoop)

Update: Digg It!


Google App Engine SDK

April 8, 2008 – 12:59 am

I just learned about Google App Engine a couple of hours ago and I have to say I’m pretty excited about what their doing. I really like the fact that they didn’t go out and try to invent their own IDE and scripting language. I’m still really reluctant to move toward cloud computing services. I still want to cling on to my hardware and OS.

Some cool points:


Keeping Google’s Android Honest

March 31, 2008 – 10:52 pm

I just want to start off by urging anyone who is writing open source applications for the Android mobile platform to release their applications under the GNU General Public License V3.

The Open Handset Alliance is about to wrap up the first round of the Android Developer Challenge and they’re ready to deliver tons of money in rewards for application development.

What OHA hasn’t delivered any source code for their Apache 2 licensed platform and even when they do they have made no guarantees that you’ll have the freedom to run modified versions of it on your devices. It is certainly possible and not highly unlikely that OHA could release Android’s core libraries under the Apache 2 license, but require a signed version of those libraries on devices shipped from manufactures.

So if you release your application under other open source licenses (including GPL V2), services providers and device manufactures have no legal obligation to allow unsigned/modified versions of you application to run on their devices. They can just take your application and your freedom along with it.

If you think that this couldn’t happen, take a look around. No other device around has created as much buzz as Apples iPhone and the way they are treating application developers is criminal. Even if OHA releases a truly open platform that is unlike anything before it, you have nothing to lose by choosing GPL V3 for your open source Android application. You’ll just be protecting and doing your part to ensure Android stays honest, open and free.


One Button to Rule them all.

March 31, 2008 – 6:42 pm

There have been quite a bit of talk about the current state of OpenID login screens that are becoming cluttered with provider specific buttons with no end in site.

Scott Blomquist has some really interesting ideas for implementing a IdP independent button that would replace all of the existing buttons, while providing an improved, consistent experience for the end-user.


Improving OpenID Delegation

March 27, 2008 – 10:32 pm

When I authenticate using my delegated OpenID I’m actually proving I own two different URIs. I own http://steven.bitsetters.com which I’m delegating from and I own (or at least have some control over) http://steven.myvidoop.com. So a RP can easily associate both endpoints with my account. The problem comes when I decide to change the endpoint I’m delegating from. Let’s say I get tired of Wordpress (I know it’s a stretch) and decide to use Blogger instead. Now I want to delegate using http://steve918.blogger.com. Currently this would require me to login to every site I previously signed into as steven.bitsetters.com and add steve918.blogger.com as an associated URL. (Assuming the RP even supports associating more than one OpenID per account. ) The thing is, this process of explicitly adding my new delegated OpenID leads to an extremely high cost of switching that is not necessary.

As I mentioned in my previous post, delegation is an important part of the OpenID ecosystem, but it needs to be manageable for muggles. If reliers could make this association for me, I’m free to bounce from one social networking site to the next and use what ever delegated ID I feel contains my social graph and most useful profile information at that time. Having this free switching economy also makes it much more appealing for all the sites I mentioned previously to provide delegation services.

The only scenario this seems to affect is someone who is using a single endpoint, but delegating through it with multiple identities. Basically people masquerading different profiles through the same IdP account. In this case I think it’s up to the RP to allow the user to decide which OpenID they wish to make public (if any) on that site.

The real problem in this scheme is that all the extra work falls on the RPs and realistically I don’t think many of them will go above and beyond hacking in the bits that are provided to them via easily available OpenID libraries. So as a community maybe we can extend the libraries to include support for easily storing and managing endpoints. I’m honestly not even sure how realistic this is, but I think doing so could make it easier for RPs to check all the boxes on the best practices checklist.


OpenID Delegation: Ship It.

March 24, 2008 – 2:11 pm

It seems when everyone’s talking about the lack of OpenID relying parties compared to identity providers they often leave out an important role in the OpenID stack: Delegation. Of course this doesn’t solve the problem everyone is feverishly complaining about, but it is curious to see no one ever really mentions delegation.

Any website who aggregates significant amounts of user data that is a content rich endpoint for the user is a perfect candidate for providing delegation services. I just want to make it known that just shipping simple delegation is a great option and an important one. If you ask people to give you a URL that most describes them on the internet they’ll probably point you to their page on one of the following:

Ideal delegation sources:

  • Facebook
  • MySpace
  • FriendFeed
  • Twitter
  • MySpace
  • Digg
  • Delicious
  • SourceForge
  • Magnolia
  • Jyte
  • LinkedIn

For these sites choosing to ship delegation instead of their very own identity provider has a lot of important benefits for the site and it’s users. As a content provider shipping delegation is unbelievably simple from an implementation standpoint. It’s a one time cost of a couple of developer hours and that’s it. Now your users can login to their favorite OpenID sites as joe.yoursite.com and you don’t have to employ a team of developers to maintain your OpenID implementation and user management. Users also benefit because their OpenID endpoint is now a content rich place that actually describes them.


OpenID Personas = Cruft

March 20, 2008 – 12:30 pm

I use personas in the same way I think most people are using them in OpenID today. I don’t think of them as identity containers, but as address bundles. I have one very creatively labeled “Work” and another labeled “Home”. Hmm…. That sounds exactly like how I manage my identity in my address book except now the UI is more complex and spread out all over the place.

It seems to me that a good deal of OpenID providers today have translated multiple user accounts and/or online identities into OpenID “personas”. Which is essentially an attempt at replicating our mental picture of the semantic web. For users the web consists of many user-names for many websites; the correlation is typically one to one. The OpenID model draws a different picture where your authentication is now a one to many relationship which is why these methodologies don’t mesh well.

The point is with very few exceptions (mental case) we are all individuals with one personality or persona who happen to have multiple sets of data that describe us. The concept of personas only serves to confuse users in a failing attempt to replicate previous models.

This is how I want to manage my identity online: Easy and familiar.

profile.jpg


I blog therefore I am.

March 15, 2008 – 1:16 am

I am now the official Steven Osborn of the internet. How did I accomplish the feat? Well, it wasn’t by spending hours practicing to be an accomplished pianist or by becoming an experienced realtor. I certainly didn’t take the time to become a doctor and I’m not much of an athlete.

What I have done is discovered the dark art of blogging. In this society where the success or failure of an individual or business is measured by their Google PageRank™; bloggers rule the world. We now live in a time where any slightly technical opinionated idiot can make a name for themselves and become blogfamous. Due to a small glitch in social history Geeks have managed to become social icons and have created numerous virtual hangouts where they can accumulate virtual friends, participate in virtual games and do virtual chores all the while avoiding actual human contact.

So what will I do now that I’ve reached the ePeen level cap? Try to take over the world!

Notice: This message may or may not self destruct in 30 years dot com.