Django community: RSS
This page, updated regularly, aggregates Community blog posts from the Django community.
-
Autobench Cloud
After seeing Nicholas Piël benchmark a bunch of Python web servers, I was just itching to try some different configurations. So, I thought I would try to copy his autobench setup to do some testing of my own. The problem is, where do you get several computers to run the benchmark? And having to recompile httperf on several machines would be a lot of work. Amazon EC2 and Ubuntu to the rescue! The key was that I wanted to be able to launch several instances at once and only have to connect to one of them to control them all. I thought I would have to build a custom AMI because I only wanted to do the custom configuration once. Turns out, I was wrong. Ubuntu provides ready-to-go images that can be instantiated with a custom script. So, the first thing to do is pick the AMI you want to use from the link above. I went with us-east-1, 32bit, and EBS root so that I could use micro instances. You can choose instance root if you want to use small instances. Next, make sure you have a security group (I created a new one called Autobench) that permits both … -
Simplifying the Testing of Unmanaged Database Models in Django (Updated for Django 4.2 in 2024)
Editor's note: This post was originally published in September, 2010 and was updated in December, 2024 to incorporate changes in Django and improvements suggested by our readers. It has also been tested for compatibility as of the Django 4.2 release. -
Autobench Cloud
After seeing Nicholas Piël benchmark a bunch of Python web servers, I was just itching to try some different configurations. So, I thought I would try to copy his autobench setup to do some testing of my own. The problem is, where do you get several computers to run the benchmark? And having to recompile httperf on several machines would be a lot of work. Amazon EC2 and Ubuntu to the rescue! The key was that I wanted to be able to launch several instances at once and only have to connect to one of them to control them all. I thought I would have to build a custom AMI because I only wanted to do the custom configuration once. Turns out, I was wrong. Ubuntu provides ready-to-go images that can be instantiated with a custom script. So, the first thing to do is pick the AMI you want to use from the link above. I went with us-east-1, 32bit, and EBS root so that I could use micro instances. You can choose instance root if you want to use small instances. Next, make sure you have a security group (I created a new one called Autobench) that permits both … -
Django Patterns: View Decorators
Problem and Analysis Sites often have many views that operate with a similar set of assumptions. Maybe there are entire areas that the user must be logged-in to visit, or there is some repetitive boilerplate functionality that a group of views shares like being rate-limited. Bolting on "login required" or "rate limiting" functionality can be a bit repetitive since it often requires "bail out early" logic. Take for example a simple rate-limiting implementation: syntax:python def simple_rate_limiting(request, duration=10): # grab the end-user's IP address remote_addr = request.META.get('REMOTE_ADDR') # create a cache key combining IP and url requested key = '%s.%s' % (remote_addr, request.get_full_path()) # if the key exists then the user has been here recently if cache.get(key): return True else: cache.set(key, 1, duration) return False def rate_limited_view(request): if simple_rate_limiting(request): return HttpResponseForbidden('Slow down!') # normal view logic continues here # There is nothing particularly bad about this implementation - we are checking for a condition based on the request and if necessary bailing out early. The problem starts to appear when additional "common" components get added to the mix, such as: loading an object based on a url param checking for auth adding something to the template context/response And now for a … -
DjangoCon 2010 report I
-
JOINs via denormalization for NoSQL coders, Part 1: Intro
Non-relational databases like App Engine or MongoDB natively don't support operations like JOINs because they don't scale. However in some situations there just exists the need to use such operations. This is the first part of a series presenting one way to handle JOINs (at first in the to-one direction) on NoSQL databases while maintaining scalability. Additionally you'll learn some useful NoSQL coding techniques throughout this series. Why would I need JOINs? Let's take the example of users and their photos. Here users represent the to-one side and photos the to-many side: It's common that users have the possibility to search for pictures of other users. While searching for photos of a specific user is easy to achieve on non-relational databases via Photo.objects.filter(user=some_user) for example, searching for photos of users given some specification like Photo.objects.filter(user__gender='female', popularity='high') isn't equally simple to achieve. Obviously we need JOINs here (which aren't supported on NoSQL databases) because we span a filter over two models. A straightforward solution to this problem is to get all female users first and then to get all popular photos whose user property points to these users: user_pks = User.objects.filter(gender='female').values('pk') female_user_photos = Photo.objects.filter(user__in=user_pks, popularity='high') Getting only the primary keys of … -
Looking for a disciplined Software Developer
At 2degrees we're looking for an experienced and disciplined Software Developer to work on the Django-based back-end of our Web site, as well as implement AJAX-based functionality from time to time.Prior Python, Django or JavaScript experience is desirable but not strictly necessary as we are looking to hire the best Software Developer we find regardless of the technologies they've used in the past.Learn more about this position and contact us if you're interested! -
Configure the output of the Django development server
I recently opened up my home dev server for a closed, friends and family alpha launch of my new commerce/community site Wantbox.com. Now that people besides me are hitting the server, I wanted to see client IP addresses in the dev server output. Current output: [19/Sep/2010 19:23:39] "GET / HTTP/1.1" 200 2555 [19/Sep/2010 19:23:39] "GET /static/media/css/site.css HTTP/1.1" 200 14311 [19/Sep/2010 19:23:40] "GET /static/media/js/site.js HTTP/1.1" 200 620 [19/Sep/2010 19:23:40] "GET /static/media/img/logo-home.gif HTTP/1.1" 200 4963 Desired output: [19/Sep/2010 19:23:39] 166.137.139.17 "GET / HTTP/1.1" 200 2555 [19/Sep/2010 19:23:39] 166.137.139.17 "GET /static/media/css/site.css HTTP/1.1" 200 14311 [19/Sep/2010 19:23:40] 166.137.139.17 "GET /static/media/js/site.js HTTP/1.1" 200 620 [19/Sep/2010 19:23:40] 166.137.139.17 "GET /static/media/img/logo-home.gif HTTP/1.1" 200 4963 I wasn’t able to track down any built-in configuration options to runserver, but thanks to the sage advice of “Python/Django evangelist” Peter (most recently, the creator of The Prince of Pinot) I got this workaround (applies to Django 1.2.1): open django/core/servers/basehttp.py change line 614 from: msg = "[%s] %s\n" % (self.log_date_time_string(), format % args) to: msg = "[%s] %s %s\n" % (self.log_date_time_string(), self.client_address[0], format % args I’m not crazy about messing with the core Django code, but I found no other way to get the output I wanted short of running a “real” … -
Multiple cache backends in Django
Out of the box, Django’s cache framework includes different cache back-ends (including the venerable memcached) and granularities (site-wide, view-specific, etc.). How could you improve on this awesomeness? One way is to use multiple back-ends. This might be desirable if your application needs a vanilla-flavored memcache for the site, and a second cache for a data [...] -
Afficher la version de django
un petit mémo tout con, mais qui peut-être utile. Il peut arriver d'avoir besoin d'afficher la version de django utilisé pour un projet précis. Comment faire ? La fonction get_version() du __init__ de django est la pour ça. Un petit from django import get_version est le tour est donc joué. -
Django and AJAX image uploads
Note: this is a repost from my blog. You can find the original post here. This is my first post to the Mozilla WebDev blog. Woot, exciting! Table of contents: Demo Summary Server side (Django) Model Form View Generating the thumbnail with PIL Client side Graceful degradation Demo Screencast Screenshots: The upload form, empty and [...] -
Django and AJAX image uploads
Note: this is a repost from my blog. You can find the original post here. This is my first post to the Mozilla WebDev blog. Woot, exciting! Table of contents: Demo Summary Server side (Django) Model Form View Generating the thumbnail with PIL Client side Graceful degradation Demo Screencast Screenshots: The upload form, empty and [...] -
Going Green
There are so many ways to serve up Django and other WSGI apps. I’ve used nginx and uWSGI (thanks to a great blog post by Zachary Voase), IIS and isapi-wsgi, Apache and mod_wsgi, and even CherryPy as a development “runserver” replacement. I’ve recently started hearing more and more about asynchronous servers, lightweight threads, and greenlets and such. I also came across the Green Unicorn project that, though not very speedy with its default worker class, has recently integrated gevent to make it a very attractive offering. This post describes how I got a Django project up and running on WebFaction (affiliate link) using Gunicorn and gevent. It was quite fun! One of the advantages of using this method on WebFaction in particular is that they already have nginx running in front of all your apps. It bothered me, when using uWSGI, that I had to have an additional nginx instance running, or having to run full blown Apache to use mod_wsgi. Simpler is better and, even though I opted to compile some things, Gunicorn seemed simpler. Especially when it came to finally running the Django project. Install Python As you’ll see with most of this, I like to play with … -
Google Analytics referring sites and https
The problem: recently a client reported the he does not see another site he owns in the list of referring sites in his Google Analytics account(for his main website) but was absolutely sure that he recieves trafic from this website. The research and the reason: at first I thought that the problem is cause by [...] -
Going Green
There are so many ways to serve up Django and other WSGI apps. I’ve used nginx and uWSGI (thanks to a great blog post by Zachary Voase), IIS and isapi-wsgi, Apache and mod_wsgi, and even CherryPy as a development “runserver” replacement. I’ve recently started hearing more and more about asynchronous servers, lightweight threads, and greenlets and such. I also came across the Green Unicorn project that, though not very speedy with its default worker class, has recently integrated gevent to make it a very attractive offering. This post describes how I got a Django project up and running on WebFaction (affiliate link) using Gunicorn and gevent. It was quite fun! One of the advantages of using this method on WebFaction in particular is that they already have nginx running in front of all your apps. It bothered me, when using uWSGI, that I had to have an additional nginx instance running, or having to run full blown Apache to use mod_wsgi. Simpler is better and, even though I opted to compile some things, Gunicorn seemed simpler. Especially when it came to finally running the Django project. Install Python As you’ll see with most of this, I like to play with … -
Django Patterns: Pluggable Backends
As the first installment in a series on common patterns in Django development, I'd like to discuss the Pluggable Backend pattern. The pattern addresses the common problem of providing extensible support for multiple implementations of a lower level function, be it caching, database querying, etc. -
Django Patterns: Pluggable Backends
As the first installment in a series on common patterns in Django development, I'd like to discuss the Pluggable Backend pattern. The pattern addresses the common problem of providing extensible support for multiple implementations of a lower-level function, for example caching, database querying, etc. Problem The use of this pattern often coincides with places where the application needs to be configurable to use one of many possible solutions, as in the case of database engine support. Consider the following: The application needs to support Backend A and Backend B but if you look closely at the methods exposed there are some discrepancies: Backend A has slightly more verbose method names than Backend B Backend B does not accept a default value on the get() method In Django we see this pattern all over the place: django.contrib.auth django.contrib.messages django.contrib.sessions django.core.cache django.core.files.storage django.core.mail django.core.serializers django.db Analysis Here is a first stab at getting our Application to talk to backend A and B: class ApplicationBackend(object): def __init__(self, backend): # here we are self.backend = backend def get(self, key, default=None): if isinstance(self.backend, BackendA): return self.backend.get_data(key, default) elif isinstance(self.backend, BackendB): try: return self.backend.get(key) except BackendB.KeyError: return default def set(self, key, value): ... etc ... Notice … -
Django Patterns: Pluggable Backends
As the first installment in a series on common patterns in Django development, I'd like to discuss the Pluggable Backend pattern. The pattern addresses the common problem of providing extensible support for multiple implementations of a lower-level function, for example caching, database querying, etc. Problem The use of this pattern often coincides with places where the application needs to be configurable to use one of many possible solutions, as in the case of database engine support. Consider the following: The application needs to support Backend A and Backend B but if you look closely at the methods exposed there are some discrepancies: Backend A has slightly more verbose method names than Backend B Backend B does not accept a default value on the get() method In Django we see this pattern all over the place: django.contrib.auth django.contrib.messages django.contrib.sessions django.core.cache django.core.files.storage django.core.mail django.core.serializers django.db Analysis Here is a first stab at getting our Application to talk to backend A and B: class ApplicationBackend(object): def __init__(self, backend): # here we are self.backend = backend def get(self, key, default=None): if isinstance(self.backend, BackendA): return self.backend.get_data(key, default) elif isinstance(self.backend, BackendB): try: return self.backend.get(key) except BackendB.KeyError: return default def set(self, key, value): ... etc ... Notice … -
Django Patterns: Pluggable Backends
As the first installment in a series on common patterns in Django development, I'd like to discuss the Pluggable Backend pattern. The pattern addresses the common problem of providing extensible support for multiple implementations of a lower-level function, for example caching, database querying, etc. Problem The use of this pattern often coincides with places where the application needs to be configurable to use one of many possible solutions, as in the case of database engine support. Consider the following: The application needs to support Backend A and Backend B but if you look closely at the methods exposed there are some discrepancies: Backend A has slightly more verbose method names than Backend B Backend B does not accept a default value on the get() method In Django we see this pattern all over the place: django.contrib.auth django.contrib.messages django.contrib.sessions django.core.cache django.core.files.storage django.core.mail django.core.serializers django.db Analysis Here is a first stab at getting our Application to talk to backend A and B: class ApplicationBackend(object): def __init__(self, backend): # here we are self.backend = backend def get(self, key, default=None): if isinstance(self.backend, BackendA): return self.backend.get_data(key, default) elif isinstance(self.backend, BackendB): try: return self.backend.get(key) except BackendB.KeyError: return default def set(self, key, value): ... etc ... Notice … -
Django Patterns: Pluggable Backends
As the first installment in a series on common patterns in Django development, I'd like to discuss the Pluggable Backend pattern. The pattern addresses the common problem of providing extensible support for multiple implementations of a lower-level function, for example caching, database querying, etc. Problem The use of this pattern often coincides with places where the application needs to be configurable to use one of many possible solutions, as in the case of database engine support. Consider the following: The application needs to support Backend A and Backend B but if you look closely at the methods exposed there are some discrepancies: Backend A has slightly more verbose method names than Backend B Backend B does not accept a default value on the get() method In Django we see this pattern all over the place: django.contrib.auth django.contrib.messages django.contrib.sessions django.core.cache django.core.files.storage django.core.mail django.core.serializers django.db Analysis Here is a first stab at getting our Application to talk to backend A and B: class ApplicationBackend(object): def __init__(self, backend): # here we are self.backend = backend def get(self, key, default=None): if isinstance(self.backend, BackendA): return self.backend.get_data(key, default) elif isinstance(self.backend, BackendB): try: return self.backend.get(key) except BackendB.KeyError: return default def set(self, key, value): ... etc ... Notice … -
Booktools
A little-known bit of trivia about our book, Python Web Development with Django: we wrote the manuscript in Markdown. I think it was my idea. One of the major motivations for using a text-based format -- versus the unfortunate de facto standard, Microsoft Word -- was integration with good developer tools and workflow. Our manuscript and all our project code was in a Subversion repo, so each author always had the latest updates. HTML generated from the Markdown files was great for generating nice printed/printable output too. We could have used any number of similar formats: Markdown, Textile, reStructuredText. If we did it again we'd probably use reST plus Sphinx. That would grant all the same advantages, plus give us a little more formatting flexibility and tool support. This workflow enabled certain kinds of programmatic action on our text, notably two things: automated testing of the interactive examples within the text, and automated extraction of example snippets from source code files. I wrote scripts for each of these tasks. I've cleaned them up a little, to try to make them a little more general-purpose, and published them (with minimal example files) in a bitbucket repo: http://bitbucket.org/pbx/booktools There's a little documentation … -
Django on uWSGI and Nginx
I recently moved Pegasus News from Perlbal, Lighttpd, and Apache to Nginx and uWSGI. We balance the traffic between 3 physical servers, and the systems were struggling under the load even after weeks of Apache conf tweaking. We began having issues with excessively slow page loads, request timeouts, and intermittent errors with OGR transformations. I decided to move us to a lighter application server so that we could get the most out of our system resources, and after a lot of research and testing I chose uWSGI. While I was at it, I decided to replace Perlbal and Lighttpd with Nginx because of its great configuration syntax and excellent performance. I also upgraded us to Ubuntu 10.04 and Postgres 8.4. The result was a resounding success! Memory usage and CPU load on each of the web nodes dropped dramatically. Swap usage dropped to almost nothing. The overall responsiveness of the site improved noticeably, and the timeout errors and OGR failures disappeared entirely. If you'd like to give this stack a try, read on for an overview of the setup on Ubuntu 10.04. I'm using the standard Ubuntu source package for Nginx, but modifying it slightly and them installing it with … -
Django 1.2.3 lançado
Django 1.2.3 lançado -
Django 1.2.3 lançado
Django 1.2.3 lançado -
Entorns virtuals
Quan un es dedica a la programació seriosa amb Python (ja sigui amb Django o amb qualsevol altre framework) hi ha un parell de coses que s'han de tenir en compte: saber amb quina versió de Python programarem i si aquesta versió estarà suportada per la distribució del servidor de producció és una d'elles, potser la més simple. Una altra un poc més complexa és la de plantejar-nos des del principi com durem el mantenimient de l'aplicació. Amb els servidors dedicats cada cop a més bon preu, no és genys extrany plantejar-se tenir un servidor dedicat per les nostres aplicacions web en Python per exemple. És també molt habitual que les aplicacions tenguin un cicle de vida molt més llarg que les llibreries que hem utilitzat per a crear-les. Ara podem fer servir la versió 1.2.3 de Django, però d'aquí tres o quatre mesos tindrem la 1.3, amb altres llibreries pot passar una cosa semblant. Quan tenim una aplicació en producció la màxima sempre ha de ser la de si no està trencat no ho arreglis. Si la nostra aplicació funciona amb Django 1.1 i hem anat aplicant els pegats de seguretat, llavors plantejar-nos migrar a una versió major és …
