django on SWiK

Will Larson: Dynamic Ad Targeting With django-monetize

Fri, 29 Aug 2008 12:55:37 -0700

This is probably the most exciting Django project I have worked on, and I'm glad that it has gotten to sufficient usable point to share. It is my pleasure to present django-monetize.

django-monetize is a pluggable Django app which aims to make it trivial to intelligently monetize your Django projects. It was designed with two guiding principles:

There are many forms of monetization, and generally a mix-and-match approach will outperform a single monetization solution (for example, a thoughtful combination of donations, Amazon Affiliates and AdSense will perform better than AdSense alone). Switching between and experimenting with different forms and combinations of monetization is a key part of success.
You can greatly enhance monetization by effectively targeting subgroups of your readers. Your monetization will be more effective if you have the ability to display different ads to users coming from search engines (perhaps AdSense would perform better) or Reddit (perhaps... silly tshirts would sell?), using different browsers (wait, I'm marketing my OSX app to internet explorer users?), and viewing different kinds of materials (someone reading an indepth tutorial would be more likely to donate than someone reading your rant about licorice jellybeans).

Supported Forms of Monetization

So far, django-monetize has built in support for Amazon Affiliates' Custom Links, Amazon Affiliates' Omakase, Amazon Affiliates' Search Links, Amazon Honor System donations, Dreamhost referrals, Google Adsense ad units, Paypal donations, and SliceHost referrals.

Its trivial (and encouraged) to add more of your own or customize the existng ones to be more appropriate for your website. It is easy to create your own custom adverts (perhaps an e-book you wrote, linking to a popular blog entry you put together, or advertising your new startup).

Installation

Install django_monetize like you would any other application. Check it out from its repository, add the django_monetize directory to your Python site-packages folder so that:

import django_monetize

works without throwing an error.

Then simply add django_monetize to the INSTALLED_APPS setting in your settings.py file and you're good to go. django_monetize doesn't contain any models (or use the database in any way), so you don't need to perform a sync.

Using `django-monetize`

The real magic in django-monetize is the level of customization and control that it allows. First lets examine usage at the template level. We'll start with the simplest examples and get more complex as we explore the flexibility.

{% load monetize %}

{% monetize_slot %}
<p> Welcome to my site! </p>
{% monetize_slot %}

That will display two slots, both using the default monetization option (we'll look at setting up the targetting and default logic after we look at template configuration).

{% load monetize %}

{% monetize_slot "header" %}
<p> Welcome to my site! </p>
{% monetize_slot "footer" %}

Now we are labeling the slots. We can use labeling to display different types of monetization options in different locations. This is the simplest concept of targeting.

{% load monetize %}

{% monetize_slot "header" request.META.HTTP_REFERER %}
<p> Welcome to my site! </p>
{% monetize_slot "footer" request.META.HTTP_USER_AGENT %}

Now we're labeling slots and passing them them the referer and user agent respectively. django-monetize will check against our targeting configuration and see if the current referer/user_agent is something we have specified targeting for, and will use the targeted advertisement if it exists, but will otherwise revert to the default advertisement.

{% load monetize %}

{% monetize_slot "header" object.title object.series object.tags %}
<p> Welcome to my site! </p>
{% monetize_slot "footer" %}

Here for the top slot we are beginning to see the flexibility of the targeting mechanism. It will first check if we have a targeted value for the object's title, will then check if we have targeted for any of the values in the object.series list, and will finally check if we have targeted any of the values in the object.tags list.

It will target on the first targeted value it reaches, and won't process the remaining parameters.

Finally, note that once you have found the targeted term, you are also able to specify the type of monetization for that targeted term in different slots. Thus you can display different ads in differently named slots even if you target on something as simple as this (which might be sufficient for mostly static content):

{% load monetize %}

{% monetize_slot "header" "django" %}
<p> Welcome to my site! </p>
{% monetize_slot "footer" "django" %}

Pretty flexible, eh?

Valid Parameters for `monetize_slot` template tag

We were using monetize_slot in a variety of different ways in the above examples, and it behoves us to clarify the arguments that it can accept.

It can be called with zero arguments, in which case it uses the default monetization option.
It can be called with one argument, which must be the name of the slot. In that case it will use the default monetization option's targeted value for that slot--if such a targeting exists--and will otherwise resort to using the default option.
It can be called with two or more arguments. The first argument must be a string representing the slot's name. Subsequent arguments may be: strings (they may be strings stored in a context variable, or may be absolute strings declared in the template like{% monetize_slot "header" "django" %}), dictionaries (whose values are processed using iteritems()), or iterable items (defined as non-dictionary-non-string objects which have the __iter__ method). If it runs into a type of object which is not one of the above types (for example, when it is handling the contents of a queryset of your tags) it will convert the object into a string by calling unicode(obj). This means you'll target a specific object by using the string returned by its __unicode__ method.

Configuration

First, django-monetizemakes an important distinction between None and False. None indicates 'use the default monetization method', whereas False indicates 'do not use a monetization method.' Acknowledging that this is an arbitrary and confusing decision, thus far it seems like a reasonable solution.

Configuration of ad targeting is done within your project's settings.py file. There is an at least somewhat similar Django project, django-ads, which stores its configuration within the database. While that allows for a more dynamically modifiable system, django-ads doesn't address the issue of ad targeting and customization to the extent that django-monetize does, and I didn't see a reasonable way to store the configuration within the database (short of storing strings of Python code that were then evaluated, which strikes me as far from an acceptable solution).

There are three values used in the settings.py file: MONETIZE_TARGET, MONETIZE_DEFAULT, and MONETIZE_CONFIG. Lets start with a complex example an break it down.

MONETIZE_DEFAULT = (
    'django_monetize/amazon_search.html',
    ('amazon_search_terms','Django book'),
    ('amazon_search_title','Search for Django books!')
)

MONETIZE_TARGET = {
    'django':'django_monetize/paypal_donate.html',
    'Author (Will Larson)':'django_monetize/amazon_honor.html',
    'Author (Joe Somebody)':(
        'django_monetize/amazon_honor.html',
        ('amazon_paypage','Joe Somebodys Amazon Honor Paypage url'),
    ),
    'tutorial':{
        'header':'django_monetize/paypal_donate.html',
        'footer':'django_monetize/amazon_omakase.html',
        None:(
            'django_monetize/amazon_search.html',
            ('amazon_search_terms','JQuery'),
            ('amazon_search_title','Buy books on JQuery!'),
        ),
    },
}

MONETIZE_CONTEXT = {
    'amazon_affiliates_id':'your affiliates tracking id',
    'amazon_paypage':'default amazon paypages url',
    'paypal_business':'paypal accounts email address',
    'paypal_item_name':'My website',
    'paypal_currency_code':'USD',
    'paypal_tax':'0',
    'paypal_lc':'US',
    'paypal_bn':'PP-DonationsBF',
    'paypal_image':'http://www.paypal.com/en_US/i/btn/btn_donate_LG.gif',
}

Okay. So the first thing to realize is that monetization options have three possible appearances:

They can be a string that is the name of a template. In that case the template will be rendered using the context in MONETIZE_CONTEXT.
They can be a tuple or list whose first value is a template name, and other values are tuples/lists in the form (key,value) which are used to override the default values in MONETIZE_CONTEXT when rendering that monetization option.
They can be a dictionary whose keys are ad slots (header, footer, or whatever you name them) and their values are either form #1 or form #2. There is also a magic value, None which is used to specify its default value if it doesn't define its value for all slots.

Next, MONETIZE_DEFAULT is where you establish the default monetization option, which is one of the three appearances above (string, list with string and overrides, dictionary with slot names that each have a string or list of string and overrides).

Finally, MONETIZE_TARGET is a dictionary of terms to target on, where each target has one of the three monetization appearances.

Up and At 'Em

Right now the repository is stored at GitHub, which I realize isn't Google Code and thus will be problematic for some Django users. I am moving up to New Jersey this weekend, and won't have time to setup the Google Code repository until next week.

In that same vein, I haven't had the time to integrate it into this site yet, and thus it hasn't received heavy testing. Forking it on GitHub and making your changes followed by a push request would be the easiest way to contribute, but mailing patches to me at lethain@gmail.com would work as well.

The README file in the repository should be helpful, but at the present time you should consider this blog entry to be a more authoritative resource until I vet README for changes as I refined things (I tried practicing Documentation Driven Development, meaning that I wrote the documentation before I wrote the code, and it worked out pretty well for me, but I imagine it has introduced a few inconsistencies).

Eric Holscher: Screencast 2: Logging in Django, for fun and profit

Fri, 29 Aug 2008 09:55:08 -0700

This is the second screencast of a week long series.

Part 1: Using Django's Error Page
Part 2: Logging in Django
Part 3: Using the Debugger (teaser)

So that I don't spam all of the Django Community Feed (Bad RSS handling has done that more than once, Sorry!) I'm only going to be posting this post and the last post summarizing all of the screencasts on the aggregator. So if you're trying to keep up with all of the screencasts that will be coming out this week, either stay tuned to the site or subscribe to my feed.

Screencast 2: Logging in Django

Setup

This screencast is going to be about how to use the python logging module in Django. It's in the Python standard library, so there is nothing extra to install to use the simple python logging module. The screencast also makes use of the excellent Django-Logging, which should be downloaded and installed beforehand.

svn checkout http://django-logging.googlecode.com/svn/trunk/ django-logging

This allows for you to follow along on the second part of the screencast. I also do a little bit of work inside my django-testmaker app, so you can go grab that if you want to follow along as well. If not no big deal, the screencast is more about general logging anyway.

Video and Download

The video is available to download in higher res or for streaming.

Download (21MB H.264 .mov)

Screencast 2: Using Logging in Django from Eric Holscher on Vimeo.

Writeup

Part 1: python logging module

We start out with some really simple logging methods. The first is a simple print statement inside of your views. This outputs the command to the terminal in your development server. The next way to do it is with a simple logging command:

import logging logging.error('your error goes here!')

During the screencast I say that logging.error goes to Standard Out, when in actuality it goes to Standard Error. In this case they're the same thing...Then I go through how logging is done within the testmaker app. This is the basic setup for python's logging module that I used:

logging.basicConfig(level=logging.INFO, format='%(message)s', filename= "/file/to/log/to", filemode='w' )

More documentation about this and the python logging module is available here It includes a lot of really good information about the logging module, like lots of message formatting options. I show how you can tail a log file from testmaker and talk about the neat advanced features of the logging module like logging across a network. As you can see the logging module is very powerful!

Part 2: django-logging

In the second part of the screencast we show how to use the Django Logging middleware. This is what is going to go into your settings_debug.py:

from settings import * DEBUG = True INTERNAL_IPS = ['YOUR.IP.HERE'] MIDDLEWARE_CLASSES += ('djangologging.middleware.LoggingMiddleware',) LOGGING_LOG_SQL = True

This then has all of your logging output appended to the bottom of the page you're currently on. This gives you a similiar capability of using the error page to debug, except you don't have to have an error. You can debug while the pages are still working.

The next and last really neat feature is showing the SQL queries that are being executed to render a page. This is incredibly useful for fine-tuning your django sites. With the ORM, there are tiny little tweaks that you can sometimes make to decrease (or increase!) the numbers of queries you execute pretty dramatically. Having this enabled during development is a good way to catch those mistakes, and really understand what is going on under the hood of your Django apps.

Remember, when you wrap all of your logging stuff in the logging module, you can do some really neat things after the fact. I was able to use all of the django-logging stuff while still logging output to a file and whatever else happened to be going on with the logger at the time. This in incredibly powerful, and allows you to almost have django-style 'pluggable logging backends' that do different things.

Again in this one I end a little silly: Thanks for your time and have a good day (since I'l hopefully see you again tomorrow :))

Nuno Mariz: Portuguese translation of Django 1.0

Fri, 29 Aug 2008 07:55:21 -0700

I've just submitted a patch for the Portuguese translation.
If you are a Django user and know Portuguese, please take a look to the translation strings and submit any fix before the final 1.0 release.
Meanwhile, you can download the unofficial version in the downloads section.

Alberto García Hierro: Postback: Why I choose AGPLv3 for my code

Fri, 29 Aug 2008 02:55:58 -0700

It's been a few days since I posted my decision to release all my code related to Django under the AGPLv3 license. It generated quite a few reactions I didn't expect, so let me tell you the full story.

It all started when I needed to support, let's call it technology X - which is pretty hot right now -, in byNotes. I first searched if someone had done it and I found there was a generic and abstract Python implementation, but it needed a lot of work to be adapted to Django. So I decided to build my own solution from scratch. The same day I released the first version, I found an announcement posted the previous day from another developer who had also coded technology X support for Django. It's a pity when that happens, since one of us could have spent that time implementing technology Y. However, it's difficult to avoid those situations, so we must live with it.

The bad thing (TM) happened a few days later, when I was chatting with a friend on freenode. I told him I've written support for technology X and it could be useful for a project he's working on. He told me about a relatively popular site - I didn't know it was built on Django - which had been supporting technology X for a few months. I checked the site and I found nothing about the source code for technology X, even when it's something potentially useful for a lot of sites.

I don't blame them for not releasing their technology X implementation, after all they're free to do what they want with their code as long as they respect the licenses for other projects or frameworks they may rely on. However, the Django community lost something in this scenario. If relatively popular site had released their implementation of technology X, the other developer would have worked on Y while I would have worked on Z. Django would now have support for X, Y and Z, but thanks to the decision of relatively popular site to keep their implementation of X closed, we now have 2 free implementations of X. And that hurts the community, since now someone will have to spend time working on Y and Z instead of doing another things.

Are you starting to see my point? Now, with my code released under AGPLv3 instead of BSD, any site using it would have to contribute their changes back. So, if they improve my implementation of technology X, I can spend more time working on technology Y and that benefits the Django community.

I fail to see how this is being greedy. And if, as someone suggested, my code is so trivial, there's no problem reimplementing it. Anyway, I didn't claim my code does something extraordinary. In fact, I'm sure anyone could implement it. When I release something I've written, my intention is not rocking your world, but saving you from wasting time. If I've already written support for X, you're better working on Y instead of reinventing the wheel.

However, I'm not totally happy with the AGPLv3, because of its viral nature. I would be fine with something like the LGPL but with the Affero clause and I'm sure I'm not alone. Id est, you may link closed source code with my software, but you must release any modifications you make to my code. However, there's no such license for now, so I have to use AGPLv3. Do you want this to change? Spread the word, I'm sure a new license by the FSF combining the LGPL with the Affero clause it's going to benefit us all.

Two-Faced Django Part 5: JQuery Ajax @ Irrational Exuberance

Fri, 29 Aug 2008 02:05:45 -0700

Alberto García Hierro: Wapi 0.2 released

Fri, 29 Aug 2008 01:59:57 -0700

I've just finished preparing the Wapi code for the 0.2 release, so you can now download it. oauthsp will be ready in a few days (probably this weekend).

Eric Holscher: Screencast: Debugging with the Django Error Page

Thu, 28 Aug 2008 18:55:07 -0700

Screencast: Debugging with the Django Error Page

... Django on Jython on GlassFish, JavaFX performance

Thu, 28 Aug 2008 18:08:13 -0700

A compilation of today's news of interest:

From Chris a report on the performance improvements of JavaFX: where JavaFX is close to Java in performance. Big improvements since this Earlier Post. I know the JavaFX compiler team (Robert, Per, Brian) and they are all top notch.

From Leo Soto, the Django Framework now runs on Jython. See Leo's blog entry and the Wiki page for details... and How to Run it on GlassFish. One more scripting language and framework! Jython is moving much faster than I had anticipated; Frank is already Working on Jython 2.5.

Simon Willison: Django 1.0 release party

Thu, 28 Aug 2008 18:03:14 -0700

Django 1.0 release party. The big ass-party will be at the Tied House in Mountain View on Saturday the 6th from 7pm. RSVP on the linked announcement.

Simon Willison: Django 1.0 beta 2 released!

Thu, 28 Aug 2008 18:03:14 -0700

Django 1.0 beta 2 released!. 1.0 draws ever closer. Important new features include major documentation and comment system refactorings, plus the removal of a bunch of deprecated code (including oldforms). Feature and string freezes are now in place, so it’s just bugs and documentation improvements between now and the final release.

Alberto García Hierro: Building a website API with Django. Part 6: Documentation

Thu, 28 Aug 2008 18:03:14 -0700

This entry puts and end to "Building a website API with Django". I think I've covered everything you need to build a website API with Wapi, so it's now time for you to start playing with it. I hope you've enjoyed reading this series as much as I enjoyed writing it. I've finally pylinted and documented almost all the code, so Wapi 0.2 should be released in the next few hours. From now, I'll try to keep the current API and every backwards incompatible change will be documented.

Documenting your API with Wapi

Documenting your functions

As we've seen on part 4 on this series, every API parameter takes an optional third argument which documents it. In addition, every function docstring is also passed to the documentation template. Furthermore, validators applied to parameters are also autodocumented. Let's see an example:

@readonly
@required_parameter('type', int, _('Admin division type, ranging from 1 to 4.'), validators=RangeValidator(min_value=1, max_value=4))
@required_parameter('id', int, _('The administrative division id.'))
def geo__admin(self, request, dct):
    """Returns information for the given administrative division type and id. Keep
    in mind that administrative divisions identificators are not guaranteed to
    be permanent, as it happens with geoname identifiers."""

If you want to check how it looks when passed to the documentation, check the byNotes API documentation.

urls.py

You'll also need to plug your documentation view into your urls.py, but it's pretty simple:

from wapi.documentator import ApiDocumentator
from notes.api import BynotesApi

urlpatterns = ...
(r'^api/1.0/doc/', ApiDocumentator(api=BynotesApi()))

Grouping functions into namespaces

By default, Wapi orders your functions alphabetically. However, usually you'll want to reorder this namespaces and given them friendly names. In Wapi, you can do this using the NAMESPACES class attribute in your API class:

class BynotesApi(object):
    NAMESPACES = ( 
        (_('User information'), 'user'),
        (_('Positions'), 'position'),
        (_('Fetching notes'), 'notes'),
        (_('Friends'), 'friends'),
        (_('Posting notes'), 'post'),
        (_('Geographic functions'), 'geo'),
    )

The format of the tuples is (namespace_friendly_name, namespace_prefix).

Example template

     {% for namespace in namespaces %}
    <div class="api-ns" id="ns-{{ namespace.short_name }}">
        <h2>{{ namespace.name }}</h2><ol>
        {% for function in namespace %}
        <li id="{{ function.name }}" class="function">
            <h3>
                {{ function.endpoint }}.{ format }
                {% if function.requires_login %}
                    <span class="warn">{% trans "Requires login" %}</span>
                {% endif %}
            </h3>
            <span>{% trans "allowed methods" %}:</span>{% if function.is_read %} GET{% endif %}{% if function.is_write %} POST{%endif %}
            <p class="fdoc">{{ function.doc }}</p>
            {% if function.required_parameters %}
                <h4>{% trans "Required parameters" %}:</h4>
                {% for parameter in function.required_parameters %}
                    <p class="parameter">
                        <span>{{ parameter.name }} ({{ parameter.type_name }}):</span>
                        {{ parameter.doc }}
                    </p>
                    {% if parameter.doc_info %}
                        {% for name, value in parameter.doc_info %}
                            <p class="parameter-info">
                                <span>{{ name }}:</span>
                                {{ value }}
                            </p>
                        {% endfor %}
                    {% endif %}
                {% endfor %}
            {% endif %}
            {% if function.optional_parameters %}
                <h4>{% trans "Optional parameters" %}:</h4>
                {% for parameter in function.optional_parameters %}
                    <p class="parameter">
                        <span>{{ parameter.name }} ({{ parameter.type_name }}):</span>
                        {{ parameter.doc }}
                    </p>
                    {% if parameter.has_default %}
                        <p class="parameter-info">
                            <span>{% trans "Default" %}:</span>
                            {{ parameter.default }}
                        </p>
                    {% endif %}
                    {% if parameter.doc_info %}
                        {% for name, value in parameter.doc_info %}
                            <p class="parameter-info">
                                    <span>{{ name }}:</span>
                                {{ value }}
                            </p>
                        {% endfor %}
                    {% endif %}
                {% endfor %}
            {% endif %}
        </li>
        {% endfor %}
        </ol>
    </div>
{% endfor %}

Current limitations

As you may have noticed, translating function documentation is currently not supported in Wapi, since the docstring must be a bare string. Some work has been done on this, but the current solution requires modifications to makemessages, so I think it was better to leave this changes for Wapi 0.3, which will be released post Django 1.0.

Simon Willison: Django snippets: Sign a string using SHA1, then shrink it using url-safe base65

Thu, 28 Aug 2008 18:03:14 -0700

Django snippets: Sign a string using SHA1, then shrink it using url-safe base65. I needed a way to create tamper-proof URLs and cookies by signing them, but didn’t want the overhead of a full 40 character SHA1 hash. After some experimentation, it turns out you can knock a 40 char hash down to 27 characters by encoding it using a custom base65 encoding which only uses URL-safe characters.

Alberto García Hierro: AGPLv3 explained

Thu, 28 Aug 2008 18:03:14 -0700

I think there are lots of people which misunterstand the Affero GPL v3, so I decided to write this entry to clarify some things.

Keep in mind I'm not a lawyer, so you should read my advice with a grain of salt. I've been using free software licenses for some years and I always take the time to read and understand them, but that doesn't mean I cannot make mistakes or misunderstand some sections.

You can

Sell commercial software under an AGPLv3 license: Nobody prevents you from selling AGPLv3 licensed code, even when you didn't write it. However, customers buying the software from you must abide by the license terms. Paying for an AGPLv3 product doesn't mean you can avoid the license terms. However, if you're the copyright owner, you can sell the same software under a different license.
Build another software on top of it: AGPLv3 grants you permission to download and modify any software which you can use, even if it's over a network (this an importante difference with the GPLv3). You're free to modify it or use it into another project, making your project a derivative work of the original software.
Link to or use BSD licensed code: 3-clause BSD licensed code (don't confuse it with 4-clause BSD license) let's you use or import it into AGPLv3 projects. You can also distribute both codebases as a single package. However, keep in mind that you are not allowed to change the license in the file headers nor claim copyright over the external project you imported.
Look at code under AGPLv3 license, even when you work on projects with more restrictive licenses: AGPLv3 is about code freedom, not about patents nor algorithms. You're free to look at AGPLv3 code and then do a clean-room reimplementation of it.
Use GPLv3 libraries: Using a GPLv3 library doesn't impose additional restrictions over the library nor over the AGPLv3 code, so there's no problem here.
Use LGPLvx libraries: No version of the LGPL imposes any restrictions over the code using it.

You can't

Write BSD or closed source software on top of it: AGPLv3 is designed to keep the code always free, so you can't use nor import AGPLv3 code into a closed source project.
Copy AGPLv3 code into another project under a non-AGPLv3 license: Even a single line. It's no allowed, because you're bypassing the license term under the code was released.
Mix GPLv3 and AGPLv3 code: This may seem counterintuitive, but it's true. You can't make a GPLv3 derivate work and an AGPLv3 software, since you're removing the obligation to distribute the source to users over a network. On the other hand, you can't add the Affero clause to a GPLv3 codebase, since you're imposing additional restrictions on it. The same applies for GPLv2.
Use GPLv2 libraries: GPLv2 only libraries don't allow you to use them in GPLv3 projects, so you're in the same case when using AGPLv3.

You must

License your derivative works under AGPLv3: If you modify AGPLv3 code or use it in another project, the resulting code must be under an AGPLv3 license.
Provide a way to download the code over the same medium used to deliver the software service to the user: If you run a website which uses AGPLv3 code, your pages must provide a link to the software you're running in the webserver (zipfile or version control system, it doesn't matter).

For Django developers

Django is released under a 3-clause BSD license, so you're free to build AGPLv3 software on top of it.

Alberto García Hierro: URLsafe base64 encoding/decoding in two lines

Thu, 28 Aug 2008 18:03:14 -0700

Simon has recently featured this snippet which shrinks a SHA1 hash from 40 to 27 characters using base65 encoding. I've been using another approach for some time and, modestly, I think mine is better, so let me tell you how I do it before you start using the suboptimal approach.

Python does it for us

First, the base64 module already provides a pair of functions, aptly named urlsafe_b64encode and urlsafe_b64decode, which do quasi-safe url encoding using base64. For example:

>>> base64.urlsafe_b64encode(sha1('foobar').digest())
'iEPX-SQWIR3p67lj_0zigSWTKHg='

The problem here is the equal sign, since we can't put it safely in a URL. However, since we are using this to store a hash and we're going to generate the hash again when we verify the data, we can encode the hash again instead of decoding the base64-encoded string, which lets us safely remove the equal sign. Furthermore, we are also using 27 characters, the same as the other more complex implementation.

Can we decode it? Sure!

Sometimes, you'll want to decode the base64 encoded data. However, once we remove the equal sign, we can't no longer pass the base64 encoded string to urlsafe_b64decode:

>>> base64.urlsafe_b64decode('iEPX-SQWIR3p67lj_0zigSWTKHg')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python2.5/base64.py", line 112, in urlsafe_b64decode
    return b64decode(s, '-_')
File "/usr/lib/python2.5/base64.py", line 76, in b64decode
     raise TypeError(msg)
 TypeError: Incorrect padding

Let's examine how base64 works. The input string is processed in 3-byte blocks which are split into 6-bits pieces. Hence, we have 2^6 == 64 possible values per piece which translates to a single character into our base64 alphabet. So, every three byte block is translated to a 4 characters string. When the last block has less than three bytes, it's padded with zeros and one equal sign is added for every padding byte. This leads us to the conclusion that base64 encoded strings always have a length divisible by four. Let's take advantage of this:

>>> s = 'iEPX-SQWIR3p67lj_0zigSWTKHg'
>>> base64.urlsafe_b64decode(s + '=' * (len(s) % 4))
'\x88C\xd7\xf9$\x16!\x1d\xe9\xeb\xb9c\xffL\xe2\x81%\x93(x'

So now we have our original string back.

Putting it all together

from base64 import urlsafe_b64encode, urlsafe_b64decode

def uri_b64encode(s):
     return urlsafe_b64encode(s).strip('=')

def uri_b64decode(s):
     return urlsafe_b64decode(s + '=' * (len(s) % 4))

Peter Baumgartner: Managing Django Projects on Your Server with Style

Thu, 28 Aug 2008 18:03:14 -0700

My preferred directory structure and third party repo management for hosting multiple projects (running multiple versions of Django) on a single server.

Simon Willison: Using Akismet with Django's new comments framework

Thu, 28 Aug 2008 18:03:13 -0700

Using Akismet with Django’s new comments framework. A nice example that demonstrates two features that were recently rolled in to the Django 1.0 betas: the new signals library and the new comments framework.

Ivan Sagalaev: Празднование релиза Django 1.0

Thu, 28 Aug 2008 18:03:13 -0700

Куда все идутЯ приглашаю:07.09.2008 15:00, PodМосковье, М.Кисловский пер., 6Празднование релиза Django 1.0Есть идея отпраздновать вместе с остальным миром долгожданный релиз Django 1.0! Приглашаются все, кому это интересно. Познакомимся (кто не знаком), пообщаемся, расскажем друг о друге, сделаем фотки и пожелаем доброго пути любимому фреймворку. Программировать не будем :-) В качестве места сбора предлагается клуб “PodМосковье”. Говорят, [...]

Simon Willison: Capital Radio (the new site)

Thu, 28 Aug 2008 18:03:13 -0700

Capital Radio (the new site). Launched today, this is the Django-powered project I’ve been working on with the fantastic team at GCap.

Django 1.0 release party

Thu, 28 Aug 2008 17:59:59 -0700

Come help us celebrate the release of Django 1.0!

Next week is going to be huge. We’ll be releasing Django 1.0 early in the week, and then the first DjangoCon kicks next Friday.

To celebrate the release of Django 1.0, we’ll be holding a dinner party at the Tied House in Mountain View on Saturday, September 6th at 7pm. The date and time are designed to tie in with DjangoCon, but anyone is invited — especially those who can’t attend DjangoCon.

We’ve reserved the whole restaurant for Django friends and fans. Dinner starts at 7pm, and the festivities should continue until about 10:30 or so. The party’s free, though the dinner and drinks aren’t. Tied House has good food and great beer; come hungry!

To make the night extra fun, we’ll be holding “lightning talks” at the party — five minute presentations on various Django-related topics. We’ll be asking speakers at the conference to present vastly twimmed-down versions of their conference talks, and we’ll be opening the floor up to anyone to present their own cool shit.

Tied House is located in downtown Mountain View (map). For DjangoCon attendees, that’s about 15 minutes away from the conference venue; we’ll caravan over (and provide transportation for folks without cars) right after the day’s talks end.

If you’ll be coming, please RSVP so that we can get an accurate headcount.

We’re also looking for sponsors for the party, so if you’re interested please contact us.

We hope to see you all there!

Django 1.0 beta 2 released!

Thu, 28 Aug 2008 17:59:59 -0700

In accordance with the (updated) Django 1.0 release roadmap, today we've released the second "beta" testing version of Django 1.0.

To grab a copy of 1.0 beta 2, head over to the Django downloads page, and be sure to read the release notes. Please keep in mind, though, that this release is not meant for production use, and is intended primarily for developers who are interested in checking out the new features in 1.0 and helping to identify and resolve bugs prior to the final release. The 1.0 alpha and beta releases will not receive long-term support and will not be updated with security fixes, since their main purpose is to serve as a stepping-stone on the path to the final Django 1.0, due to be released on September 2, 2008.

As of this release, Django is officially in a feature freeze for 1.0; from here on out, we'll only be working on bugs and stability before the final 1.0 release. If you'd like to help out, please review our documentation for contributors and feel free to join in one of the development sprints scheduled for the run up to 1.0.

JSON " Blog Archives " Standardizing RESTful JSON

Tue, 19 Aug 2008 20:09:31 -0700

At work, I've been putting together a Django layer I'm calling Djata that provides a RESTful interface with multiple, extensible parsers and formatters…that you can plug into your urls.py in one line and optionally write an api module to configure and extend each of your data views. I can easily conform to this JSON spec and largely already do with many more features (ranges, indexing, pagination, predicates, authentication, field selection, map and table JSON). I have permission to publish it and my driving application "Bugwar" (yet another test result database), so Ryan's been working on setting up an open source project server.

Pydev adventures: Configuring pydev to work with django

Tue, 19 Aug 2008 19:05:50 -0700

minidetector

Tue, 19 Aug 2008 14:57:06 -0700

Sign in with OpenID Simon Willison’s Weblog minidetector. Neat piece of Django middleware that adds a “mobile = True” attribute to the request object if the request’s user-agent matches a list of strings of known low-power browsers in mobiles, PDAs or ga

Using Eclipse and PyDev for django | magpiebrain

Tue, 19 Aug 2008 14:53:34 -0700

Pydev adventures: Configuring pydev to work with django

Tue, 19 Aug 2008 14:53:34 -0700

Alberto García Hierro: Building a website API with Django. Part 4: Complex functions

Tue, 19 Aug 2008 05:49:05 -0700

We've talked about how the API functions are defined in WAPI, but we've only scratched the surface. This entry will go on details about function namespacing, optional parameters, parameter sets, parameter validation and allowed request methods, showing some real examples from the code I wrote for byNotes.

Namespacing your functions

As we've seen in the first post in this series, you API is loaded at an URL, for example http://example.com/api/1.0/rest/, so if you define a function named foo, it will be accessible from http://example.com/api/1.0/rest/foo.xml (or json or yaml). This is enough if your API consists only of a few functions. But what happens when your API has 50 functions?

WAPI provides support for namespacing your API. You only need to prepend your method with your namespace name and the binding will take care of splitting them. For example, the ReST binding uses the pattern namespace/function_name, while the upcoming XML-RPC binding will use namespace.function_name. Let's see an example:

class BynotesApi(object):
...
@required_parameter('id', int, _('The geoname id you want to retrieve information for.'))
def geo__hierarchy(self, request, dct):
    """Returns the hierarchy for the given geoname id, starting from itself."""
    try:
        geoname = Geoname.objects.get(pk=dct['id'])
    except Geoname.DoesNotExist:
        return SingleSerializableResponse(None)

    return SerializableResponse([geoname] + geoname.hierarchy)

As you see, the namespace separator in WAPI is "__" (two underscores). So when this method gets exposed with the rest binding it will live at geo/geoname.{ format }, while the XML-RPC binding will serve it from geo.geoname.

Optional parameters and parameter sets

Sometimes your functions will accept optional parameters, so WAPI also provides support for working with them and lets you provide a default parameter. Note that if you don't specify a default value, there's always an implicit default value: None. Id est, the key in the dct parameter will always be present, so you don't need to check for it. The syntax for optional parameters is:

@required_parameter('id', int, _('The geoname id you want to retrieve information for.'))
@optional_parameter('parent', bool, _('Wheter to include information for the parent location.'), default=False)
def geo__geoname(self, request, dct):
    """Returns information about a given geoname, like class and code, coordinates, ..."""
    try:
        geoname = Geoname.objects.get(pk=dct.get('id'))
    except Geoname.DoesNotExist:
        return SingleSerializableResponse(None)

    method = None
    if dct['parent']:
        method = 'parent'

    return SingleSerializableResponse(geoname, method=method)

Well, you can also see that this serialization is receiving an additional parameter we haven't seen before (method). That's related to the complex serializations we'll see in the next article.

Another common use case is having multiple functions which receive the same parameters (or a subset of them). In WAPI, this is implemented using parameter sets. For example, there are multiple API functions at byNotes which support pagination, so I've defined a parameter set I add to all those functions, saving me from DRY:

from wapi.parameters import FunctionParameter, FunctionParameterSet

PAGINATION_PARAM_SET = FunctionParameterSet(
    FunctionParameter('since_id', int, _('Return only notes with id greater than since_id.')),
    FunctionParameter('offset', int, _('Skip the first offset notes.'), default=0, validators=RangeValidator(min_value=0)),
    FunctionParameter('limit', int, _('The maximum number of notes returned.'), default=30, validators=RangeValidator(min_value=1,    max_value=50)),
)

Ignore the validators argument for now, we'll see it in the next paragraph. As you can see, parameter sets don't specify if the arguments are required or optional, since this approach provides more flexibility. Adding them to one of you functions uses the same syntax we've seen before:

@optional_parameter('geoname', int, _('Geoname identifier for the area you want to restrict notes to.'))
@optional_parameter(PAGINATION_PARAM_SET)
def timeline(self, request, dct):
    """Returns latest public notes. If a geoname is provided, only notes
    posted from it and its children will be returned."""
    since_id, start, end = get_range(dct)
    nset = Note.live.order_by('-id').filter(id__gt=since_id, public=True)
    if dct.get('geoname'):
        geoname = get_object_or_404(Geoname, id=dct.get('geoname'))
        nset = nset.filter(Note.in_geoname_q(geoname)[0])
    return SerializableResponse(nset[start:end])

optional_parameter and required_parameter decorators know how to deal with parameter sets, so you don't need to learn a new syntax. Parameter sets also support iteration and slicing, just in case you want to use only a subset of them.

Extended parameter validation

As we saw in part1, WAPI does basic type validation and conversion to all the parameters a function receives. However, sometimes you want to perform additional validation and that's when wapi.validators comes handy. First, let me say this validators are not same as django.core.validators (altought some wapi.validators call django.core.validators) and aren't incompatible with them, so you can't pass a validator from django.core.validators to a WAPI function. However, by the next release of WAPI I may add some code to "automagically" convert them, so you'll be able to pass any validator.

Currently WAPI provides validators for string length, unicode, range, comma separated values and multiple choices. If you want another validator added before the next release, ping me as soon as possible with the details.

Validators are specified using the validators keyword when creating a function parameter, and it can be a single instance of wapi.validators.Validator or an iterable containing some of them. For example:

@required_parameter('place_name', unicode, _('Place name for the event (this is only for display, this parameter is not for the full address).'), validators=StringValidator(max_length=50))

Allowed request methods

By default, functions in WAPI are readwrite. Id est, RestBinding exposes them as GET and POST methods. There are two decorators for altering this behavior, readonly and writeonly. As you surely have guessed, readonly methods get exposed only as GET, while writeonly methods only work with POST. As a final note, keep in mind that WAPI does not mix GET and POST, parameters passed by GET are ignored in POST requests.

Next article in this series

In the next article, I'll write about object serialization using wapi.serializers and how you can chain and include other serializations and pass parameters to them.

Google App Engine Open Source Projects

Tue, 19 Aug 2008 03:23:47 -0700

Ohloh, the open source network

Mon, 18 Aug 2008 22:16:44 -0700

antonius - Ohloh

Mon, 18 Aug 2008 22:16:40 -0700

Ed Menendez: Celebrity Fantasy Game In Django

Mon, 18 Aug 2008 22:13:31 -0700

If you've played fantasy football or any fantasy sport you know what I'm takling about. If you're new to the concept, you pick a roster of celebrities and if they show up in the news, you get points.

The site was written using Django (trunk as of the 13th!) and Postgres 8.2. We've built a fantasy games package on top of the Django core which we would probably open-source if the community showed some interest in it.

This is our 2nd major site in Django and we really love it. To begin with, Python is a great language. When we built our fantasy engine, it was originally coded on MySQL. We encountered quite a few problems porting it over to Postgres. There are lots of little things where MySQL does type conversions for you automatically and Postgres (correctly in my opinion) does not. I definitely feel the conversion was worth it so that now we're on an enterprise level database.

django on SWiK

Will Larson: Dynamic Ad Targeting With django-monetize

Supported Forms of Monetization

Installation

Using django-monetize

Valid Parameters for monetize_slot template tag

Configuration

Up and At 'Em

Eric Holscher: Screencast 2: Logging in Django, for fun and profit

Screencast 2: Logging in Django

Setup

Video and Download

Writeup

Part 1: python logging module

Part 2: django-logging

Nuno Mariz: Portuguese translation of Django 1.0

Alberto García Hierro: Postback: Why I choose AGPLv3 for my code

Two-Faced Django Part 5: JQuery Ajax @ Irrational Exuberance

Alberto García Hierro: Wapi 0.2 released

Eric Holscher: Screencast: Debugging with the Django Error Page

... Django on Jython on GlassFish, JavaFX performance

Simon Willison: Django 1.0 release party

Simon Willison: Django 1.0 beta 2 released!

Alberto García Hierro: Building a website API with Django. Part 6: Documentation

Documenting your API with Wapi

Documenting your functions

urls.py

Grouping functions into namespaces

Example template

Current limitations

Simon Willison: Django snippets: Sign a string using SHA1, then shrink it using url-safe base65

Alberto García Hierro: AGPLv3 explained

You can

You can't

You must

For Django developers

Alberto García Hierro: URLsafe base64 encoding/decoding in two lines

Python does it for us

Can we decode it? Sure!

Putting it all together

Peter Baumgartner: Managing Django Projects on Your Server with Style

Simon Willison: Using Akismet with Django's new comments framework

Ivan Sagalaev: Празднование релиза Django 1.0

Simon Willison: Capital Radio (the new site)

Django 1.0 release party

Django 1.0 beta 2 released!

JSON " Blog Archives " Standardizing RESTful JSON

Pydev adventures: Configuring pydev to work with django

minidetector

Using Eclipse and PyDev for django | magpiebrain

Pydev adventures: Configuring pydev to work with django

Alberto García Hierro: Building a website API with Django. Part 4: Complex functions

Namespacing your functions

Optional parameters and parameter sets

Extended parameter validation

Allowed request methods

Next article in this series

Google App Engine Open Source Projects

Ohloh, the open source network

antonius - Ohloh

Ed Menendez: Celebrity Fantasy Game In Django

Using `django-monetize`

Valid Parameters for `monetize_slot` template tag