Tag Archive for 'django'

Winning at the shell game: iPython on Google App Engine

iPython is an awesome extended Python shell that gives you goodies like tab completion for instances, history tracing (so you can easily copy interactive sessions as doctests), etc. And, if you install it, your Django project on Google App Engine will automatically start using it instead of the regular python shell when you use ./manage.py shell.

To install iPython on OS X Tiger (yes, my Leopard discs are still safely in their box since I downgraded and I don't see any reason to bring them back out yet), I followed the following steps:

  1. Download the latest iPython from the iPython distributions page (ipython-0.8.4.tar.gz)
  2. Untar it, cd into the folder
  3. As per the instructions on the iPython download page:
    python setup.py build
    sudo python setup.py install
  4. To test it out on my Google App Engine/Django project, from my project folder: ./manage.py shell

(Note: The docs mention that you need to have readline installed on Mac OS X in order to use some of the features like tab completion and syntax highlighting. It just worked out of the box for me on OS X Tiger 10.4.11 -- I'm not sure if I had installed readline at some point or whether it was just there. Check out these instructions if you're having trouble.)

Once you have it installed, try out the cool code completion:

from my_app import models
models.

Press ⇥, and you'll see a list of all your models. models.my_model. ⇥ will show you the properties for that model and so on.

To create doctests, simply enter your test instructions in the shell and then type hist -n to get a dump of your history without line numbers that you can copy and paste into your doctest.

You can press ⌃ P and ⌃ ⇧ P to interactively bring up the previous and next commands in the history. If you've typed a bit of the command before doing this, it will filter to show you only those commands from your history that match the text you've entered.

You can also access the system shell without leaving iPython by preceding system calls with an exclamation mark. !ls, for example, will show you a listing of the current working directory.

And there's much more you can do that you can read about on the iPython documentation (or just type ? in the iPython shell itself and browse the docs interactively).

Check out iPython, it's yummy!

I found out about iPython from an excellent blog post by AkH on useful tips and good practices for Django projects. Thanks, dude!

Email address validation with Django and Google App Engine

Email address validation is a quixotic affair that's sure to end with you sporting a false sense of achievement and your users in tears. Many "better mousetrap" regular-expression-based validation system on the web today are overly strict and reject perfectly valid email addresses.

Beyond regular expressions and other string-based techniques, your options are to check the DNS server (but DNS lookups can fail on occasion) and vrfy the SMTP server (but many SMTP servers turn this off to stop email harvesters). Ultimately, you can actually send an email to the address and see if there are any bounces.

Or, we could just not bother.

That, at least, is the approach that the Google App Engine SDK currently takes.

Both the google.appengine.ext.db.EmailPropery() and the google.appengine.api.mail.is_email_valid() functions only check that a non-empty string instance is passed.

The problem with that is that you really don't want your good friends asdfhdsjkj and asdfghdsj to make regular camio appearances in your lovely database.

It feels to me that the best approach is to accept that we can't truly validate email addresses and instead perform some light validation that doesn't provide false positives while blocking the most obviously non-validating addresses. This seems to be the approach taken by the validation regular expression in Django (email_re in django.core.validators).

Phil Haack has a good article about all this from last year this titled I Knew How To Validate An Email Address Until I Read The RFC in which he quotes several unlikely-looking yet valid email addresses from RFC 3696 (Application Techniques for Checking and Transformation of Names) including such gems like !def!xyz%abc@example.com. I ran the whole list through Django's validator and they all passed.

All this to say that I'm using the Django email validator in my Google App Engine apps and it appears to be working well.

“Google App Engine: To Django or to webapp?” Revisted

When I was first starting out with Google App Engine (GAE), I wrote a short post detailing my thoughts on whether to use Django or Google's own webapp framework for GAE projects. In that post, I concluded that "there isn't a compelling reason to use Django at the moment with GAE".

Since then, I've re-evaluated my decision and, a few weeks ago, I ported the Singularity web app to Django from webapp.

Here are the main factors that contributed to my decision:

  • I wanted to use features in the latest Django trunk (0.97+) and the Google App Engine SDK ships with 0.96. I also did not want to be tied in to updates from Google for the Django framework.
  • Google released the Google App Engine Helper for Django which makes it very simple to set of a GAE Django app.
  • And, finally, looking through the source of Rietveld, I saw that Guido van Rossum is using Django for his Google App Engine app. And heck, I think he knows a thing or two that I may not.

Going with Django means that you can take advantage of more existing functionality (Django middleware, etc.) and, should you want to move away from Google App Engine in the future, there will be less code to rewrite. (Though, realistically, if you're doing anything with data, you're pretty much tied in to the DataStore at the moment until there is a suitable, scalable alternative that you can port to without completely refactoring your data layer.)

So my new take on this is that it makes a lot of sense to build Google App Engine applications using Django instead of pure webapp.

To get started, check out the Google App Engine Helper for Django.

Google App Engine: To Django or to webapp?

Update: "Google App Engine: To Django or to webapp?" Revisited.

Google App Engine (GAE) supports both its own framework, called webapp, and Django.

So, which one do you use?
Continue reading 'Google App Engine: To Django or to webapp?'

Implementing simple deep-linking in Flex (and Flash) using Django

Django Flex Deep Linking

I'm playing around with Django (and considering whether to use it to build the back-end for Singularity). I love the regular expressions-based Front Controller that Django uses and the first thing I thought when I saw it was that it would be incredibly easy to use this to implement deep linking in Flex and Flash applications. I whipped up a proof-of-concept a few moments ago which I thought I'd share with you.

Continue reading 'Implementing simple deep-linking in Flex (and Flash) using Django'

Wikinear: location-based Wikipedia

Wikinear: location-based Wikipedia articles

My friend and fellow Brightoner Simon Willison of Django/OpenID fame has just released a lovely little mashup called wikinear that uses FireEagle and Wikipedia to show you Wikipedia articles that are relevant to your current location.

If you are on the FireEagle beta, you can play with it right now. Otherwise, Simon has four invites that will go to the first four people to comment on his blog post (as I write this, there are three remaining, so hurry!)

Related links:

Getting started with Django on OS X

I've started setting aside a few hours every night to try new things. Two nights ago, I felted. Last night, I played with my Arduino board and light sensors. Tonight, I wanted to play with Django.

I use the term "play" loosely.

The problem is that there's no easy way to get started with Django. You have to jump through a few hoops to prove that you're truly worthy. I can't help but compare that to how easy it is to play with PHP (install MAMP, WAMP, or XAMMP and Bob's your uncle; you're up and running with Apache, PHP and MySQL in a single-click.) Similarly, Rails had Locomotive in Tiger and apparently comes pre-installed in Leopard (that's not enough to make me go back to Tiger after downgrading.)

Django looks lovely, but for it to really go mainstream it has to be easy for developers to set it up and play with it. To kick the tires, as it were, without jumping through too many hoops. Django needs its Locomotive.

All that said, I was resolved to play with it so I decided to try and find the simplest way to get a Django development environment running under OS X. During my rants on Twitter last night, Gareth Rushgrove had kindly suggested XCode + Macports but I didn't want to go through the hassle of installing the monolithic XCode.

Here's what I did do to get Django running on my OS X box running Tiger:

  1. Simon Willison had mentioned on Twitter that SQLite is a good development database (and MySQL is notoriously difficult to set up with Python). Seeing that Python 2.5 came with everything you need to work with SQLite3, I started by installing the Python 2.5.2 Universal Binary. (Using Django's Object-Relational Mapping engine, you can apparently just switch it out for MySQL, etc., on deployment.)
  2. Next, I checked out the Django trunk from SVN using Terminal: svn co http://code.djangoproject.com/svn/django/trunk/ and followed the official installation instructions.

If you've been following along, at this point, you should actually have a working Django install that you can develop on using SQLite3. (That wasn't too difficult at all actually; but neither have I seen it spelled out like this anywhere else.)

To test your installation, bring up Terminal and type:

django-admin.py startproject mysite

You should see Django create the mysite folder for you.

Navigate to that folder (cd mysite) and look at the files that Django created for you (ls). You'll be using these to build your Django application.

singularity:~/django/myfirst/mysite aral$ ls
__init__.py     manage.py       settings.pyc    urls.pyc
__init__.pyc    settings.py     urls.py

Next, run the development server:

python manage.py runserver

You should see something along the lines of:

Django version 0.97-pre-SVN-7254, using settings 'mysite.settings'
Development server is running at http://127.0.0.1:8000/
Quit the server with CONTROL-C.

Finally, to make sure that SQLite is working, edit the settings.py file in your mysite folder to populate the following two lines

DATABASE_ENGINE = 'sqlite3'
DATABASE_NAME = '/Users/aral/projects/mysite/mydb'

Replace the path with the path to your project folder. The mydb file doesn't exist yet. Create it by bringing up Terminal and entering:

python manage.py syncdb

You should see a stream of output starting with:

Creating table auth_message
Creating table auth_group
Creating table auth_user
Creating table auth_permission
Creating table django_content_type
Creating table django_session
Creating table django_site

Create a superuser account when prompted.

Finally, to see the schema of the database that Django has created for you, fire up sqlite3:

singularity:~/django/mysite aral$ sqlite3 mydb
SQLite version 3.1.3
Enter ".help" for instructions
sqlite> .schema
CREATE TABLE "auth_group" (
    "id" integer NOT NULL PRIMARY KEY,
    "name" varchar(80) NOT NULL UNIQUE
);
// etc.

I hope this helps you get started with Django on OS X. I'm looking forward to playing with it in the coming days.

Resources:






Bad Behavior has blocked 0 access attempts in the last 7 days.