Django

General
Development
Edit

News

[2995 total ]
Yann Malet: uWSGI reaches the 0.9.3 Milestone

Posted 18 days ago

uWSGI project [1] reaches the 0.9.3 milestone. You can review the complete announcement [2] on the mailing list  and download the code here [3]

This new release brings some new exiting features :

- Nginx 0.7.x module
- ... [More] configuration via python module
- support (non-standard) for Python 3.x
- Twisted client resource adapter
- graceful restart of worker processes and hot-plug substitution/upgrade
of the uWSGI server
- shared memory area to share data between workers/processes
- Tomcat handler
- support for virtualenv

In this post [4] I have covered the usage of both the "configuration via a python module" and the "virtualenv support".

uWSGI allows you to run your favorite wsgi application on top of prefered web server (apache, cherokee or nginx).

[1] http://projects.unbit.it/uwsgi/
[2] http://lists.unbit.it/pipermail/uwsgi/2009-November/000020.html
[3] http://projects.unbit.it/downloads/uwsgi-0.9.3.tar.gz
[4] http://yml-blog.blogspot.com/2009/11/setting-up-django-project-with-cherokee.html [Less]

Josh VanderLinden: Bash Time Saver

Posted 18 days ago

The other day I was helping a friend get their Django site back online, and I found myself doing a couple of very similar commands when backing up the databases:

$ pg_dump -U some_database -f some_database_backup.sql

I use Bash as ... [More] my shell in Linux, and apparently it's capable of doing some neat string substitution. I wanted to try something I had seen a few days prior to save myself a few keystrokes. ... [Less]

Antoni Aloy López: Desplegament de Django

Posted 19 days ago

Una de les característiques que més m'agraden de Django per desenvolupar és que ja ve amb el seu propi servidor integrat. És un servidor no apte per entorns de producció, de fet a les planes de Django es recomana repetides vegades que NO es faci ... [More] servir a producció, però que va molt bé al desenvolupament.

El que fa tenir aquest servidor és per una banda acursar el temps necessari per començar a desenvolupar. Una vegada creat el projecte i la primera aplicació, posam el servidor en marxa amb un python manage.py runserver i ja tenim accés a un complet servidor web.

A més ens permet depurar des del principi les nostres aplicacions. La consola del servidor que acabam d'executar mostrarà els missatges del servidor i els logs que li enviem com un servidor web qualsevol, però a més ens servirà de consola de depuració de Python.

Encara que hi ha entorns com Eclipse+Pydev que ens permeten posar punts de ruptura directament al codi, un dels mètodes més simples consisteix en escriure import pdb;pdb.set_trace() allà on vulguem que s'aturi el programa. Llavors, en arribar-hi a la consola on hem executat el servidor ens apareixerà l'entorn de depuració de Python (el pdb). Si volem fer un poc més de feina podem instal·lar l'ipdb i tendrem una consola de depuració amb autocompletat i resaltat de sintaxi.

A Python diuen allò de "batteries included" per indicar que amb Python hi ha tot el necessari per arrancar, Django segueix la mateixa filosofia, de manera que no necessitam configurar cap servidor web per començar a fer-hi feina i ens proporciona a més eines de depuració prou potents: la possibilitat de depurar amb pdb/ipdb o semblants, la depuració mitjançant els missatges d'error de les plantilles o la possiblitat de depurar evitantn la recàrrega amb l'opció de --no-reload del servidor de desenvolupament.

Una vegada ja tenim l'aplicació creada i depurada passam al desplegament. Pels experts de sistemes no ha de ser cap problema seguir les instruccions de les instruccions de desplegament de Django. Es pot desplegar en Apache (mod_python o mod_wsgi), damunt ngnix, lighthttp, Cherokee, ... En general no es tant cosa del servidor com de triar una tecnologia considerant el nostre entorn d'execució.

Perquè pensau que Django està pensat per ser escalable per amunt i per avall. Segons les restriccions del nostre entorn de producció ens convindrà elegir una tecnologia o una altra. Decidir si ens convé tenir un sols servidor http o separam l'execució de l'aplicació del servidor de continguts, quin tipus de caché farem servir, etc. etc.

Tot és molt flexible, però aquesta flexibilitat fa que ens tenguem que fer preguntes, Django no decideix per nosaltres com s'ha d'instal·lar. Fa recomanacions però en general s'adapta al que hi ha.

Si un disposa d'uns tècnics de sistemes com els que jo tenc la sort de fer feina, aquesta flexibilitat és fantàstica, segons l'aplicació decideixen la tecnologia que es fa servir, la caché, les instàncies que s'aixecaran o com es serveix el contingut estàtic. Si un s'ho ha de fer tot i no disposa d'un servidor propi (o al manco d'un servidor virtual) el desplegament vindrà marcat pel que ens deixi el nostre ISP.

Posar una configuració? Doncs no, dependrà de cada aplicació i de cada entorn. Sols un parell de recomanacions:

wsgi funciona molt bé
Si podeu separau el servidor d'aplicacions Django del servidor de contingut estàtic.
Amb un poc més de pressupost es pot tenir un servidor dedicat o virtual configurat i podrem treure tot el suc a la nostra aplicació.

0 comentaris,
0 trackbacks (URL)

Automatic translations of this post by Apertium [Less]

Alex Gaynor: Getting Started with Testing in Django

Posted 19 days ago

Following yesterday's post another hotly requested topic was testing in Django. Today I wanted to give a simple overview on how to get started writing tests for your Django applications. Since Django 1.1, Django has automatically provided a ... [More] tests.py file when you create a new application, that's where we'll start.

For me the first thing I want to test with my applications is, "Do the views work?". This makes sense, the views are what the user sees, they need to at least be in a working state (200 OK response) before anything else can happen (business logic). So the most basic thing you can do to start testing is something like this:

from django.tests import TestCase
class MyTests(TestCase):
def test_views(self):
response = self.client.get("/my/url/")
self.assertEqual(response.status_code, 200)

By just making sure you run this code before you commit something you've already eliminated a bunch of errors, syntax errors in your URLs or views, typos, forgotten imports, etc. The next thing I like to test is making sure that all the branches of my code are covered, the most common place my views have branches is in views that handle forms, one branch for GET and one for POST. So I'll write a test like this:

from django.tests import TestCase
class MyTests(TestCase):
def test_forms(self):
response = self.client.get("/my/form/")
self.assertEqual(response.status_code, 200)

response = self.client.post("/my/form/", {"data": "value"})
self.assertEqual(response.status_code, 302) # Redirect on form success

response = self.client.post("/my/form/", {})
self.assertEqual(response.status_code, 200) # we get our page back with an error

Now I've tested both the GET and POST conditions on this view, as well the form is valid and form is invalid cases. With this strategy you can have a good base set of tests for any application with not a lot of work. The next step is setting up tests for your business logic. These are a little more complicated, you need to make sure models are created and edited in the right cases, emails are sent in the right places, etc. Django's testing documentation is a great place to read more on writing tests for your applications. [Less]

Yash: Django Secret Question suggestion

Posted 19 days ago

Its been a while since I blogged and I wanted to get some feedback on the approach I took to solve a password reset problem in one of django project I came across.

Situation:

So there is a model SecretQuestion which has a ... [More] OnetoOneField relation with User model.

Now when a user requests for password reset the application asks for the email of the user and checks if its associated with a registered user. If it is a valid associated email it should redirect to a page ... [Less]

Eivind Uggedal: VPS Performance Comparison

Posted 19 days ago

My latest side project, was it up?—a free web monitoring service, required a
number of VPS instances due to its distributed nature. I previously conducted
a comparison of Slicehost and Prgmr. This time I needed to purchase
several ... [More] instances and therefore went out and did a more throughout and wider
comparison of which VPS provider would give me the most bang for my buck.
I targeted VPS offerings in the $20 space (and the cheapest Amazon EC2 option):

 
Monthly cost
Memory
Memory/$
Storage
Transfer

Slicehost
$20.00
256MB
12.80MB
10GB
100GB

Linode
$19.95
360MB
18.05MB
16GB
200GB

Prgmr
$20.00
1024MB
51.20MB
24GB
160GB

Rackspace
$21.90
512MB
23.38MB
20GB
—

Amazon
$62.05
1.7GB
28.05MB
160GB
—

Note that the monthly cost of Rackspace’s offering does not include any data
transfer. At $0.22/$0.08 out/inn per GB you’d have to pay an additional $15
per month for 50GB of in-bound and 50GB out-bound transfers. Amazon charges
$0.17/$0.10 out/inn per GB of bandwidth which would amount to $13.5 extra
per month for 50GB transfer both ways.
The following table
shows the specifications of the various providers’ systems:

 
Arch
CPU
VCPUs

Slicehost
x86_64
Opteron 2212
4

Linode
i686/x86_64
Xeon L5420
4

Prgmr
x86_64
Opteron 2347 HE
1

Rackspace
x86_64
Opteron 2347 HE
4

Amazon
i686
Xeon E5430
1

Linode is the only provider which gives you a choice between a
32-bit and 64-bit architecture. I therefore performed all
tests on both platforms on Linode. Amazon’s smallest VPS is
32-bit while all other providers uses 64-bit DomU’s.

Prmgmr and Amazon gives you access to 1 virtual CPU while
Slicehost, Linode, and Rackspace gives you 4. More VCPUs is
not necessarily better though. With as many VCPUs as physical
CPUs a single domU can burst to the full system capacity. If
the system gets busy though, the amount of VCPUs could lead
to increased context switching. 4 VCPUs should therefore give
you better ideal performance, while 1 VCPU gives you a more
stable performance profile.

Aside from cost, performance was the most important criteria
for me when selecting a provider for was it up?.
5 different benchmarks were carried out every 3 hours over a week, leading
to 56 runs each. The slowest system used up to 3 hours to complete all 5
benchmarks. Weeklong benchmarking was used to account for variance in
host load during the day/night and week. I speculated that the
host systems could be more utilizied on weekdays when people in the US
were awake (all providers under test were US based).
At the end of this article you’ll find a table summarizing the averages
and standard deviations of the 5 benchmarks on all providers.

Unixbench single process score (higher is better).

Single process Unixbench were the first test carried out.
I had to patch Unixbench to disable a failing
test and graphical tests. The scores
reported are points, were a higher score is better than a lower. To my
surprise Amazon, the most expensive offering, were clearly the looser
on this workload. All providers had fairly little variance on this test,
except for Slicehost who even dipped below Amazon’s scores at some instances.
Could this be the first signs of a very full host? Or maybe my neighboring
nodes got slashdotted? The clear winner is Linode on both 32 and 64-bit
architectures.

Unixbench 4 parallel processes score (higher is better).

Parallel Unixbench followed. I had to patch the
Unixbench controller script to always use 4 parallel processes. Normally
Unixbench selects how many processes to spawn depending on the amount of
virtual CPUs the system has.

Linode continues to impress with the best Unixbench scores for both its
supported architectures. The results are similar for the single process
benchmark, Amazon is slowest overall with Slicehost beeing the most
unstable environment. Its important to note that both providers with
only one virtual CPU, Prgmr and Amazon, has the lowest scores for both
Unixbench tests.

SQL-bench on PostgreSQL. Runtime in seconds (lower is better).

SQL-bench on PostgreSQL is a large single-threaded database benchmark
created by the MySQL project. I had to patch the
suite to disable one test which did not run on PostgreSQL and decrease the
ammount of some iterations to make the suite finish in a reasonable time.

As we see from the graph, this benchmark varies greatly over time for most
proviers. If we consult out summary table we note that 64-bit Linode
has the best average time with 64-bit Linode in second place. Slicehost’s
average runtime is highest by a large margin. Amazon is clearly the most
stable host in the SQL-bench tests with several orders of magnitude less
standard deviation than other providers.

Django test suite on PostgreSQL. Runtime in seconds (lower is better).

Django test suite on PostgreSQL was run to hopefully give a picture of
how the various hosts performed under a web application load. This is a
single-threaded benchmark.

The results are very similar to those of the SQL-bench runs against the same
database system. Linode 64-bit and 32-bit has the lowest average runtimes
and Amazon has a surprisingly low standard deviation. Similar to the SQL-bench
runs Rackspace has the highest standard deviation while Slicehost has the
highest average runtimes, more than 2.5 times slower than Linode 64-bit.

Django test suite on in-memory SQLite. Runtime in seconds (lower is better).

“>

Django test suite on in-memory SQLite exactly the same as the previous
benchmark against a different database system. This memory intensive benchmark
faired badly for Amazon as it has the highest average runtime. Overall the runtimes
are fairly stable, only Slicehost has a significant standard deviation.
As with all the database and Django specific benchmarks Linode 64-bit has the lowest
average runtime with 32-bit Linode close behind.

1: Single process Unixbench

2: Parallel Unixbench

3: SQL-bench on PostgreSQL

4: Django test suite on PostgreSQL

5: Django test suite on in-memory SQLite

x: average

σ: standard deviation

 
1 x
1 σ
2 x
2 σ
3 x
3 σ
4 x
4 σ
5 x
5 σ

Slicehost
278
45.12
409
108.79
2132
361.07
932
177.8
424
39.08

Linode x86_64
570
1.48
1128
8.75
1251
261.67
352
55.79
190
6.67

Linode i686
719
3.68
1389
14.13
1392
234.04
399
27.71
216
6.79

Prgmr
243
1.41
274
1.82
1463
238.91
563
55.33
289
2.46

Rackspace
321
3.03
665
21.09
1600
403.31
677
266.02
322
4.98

Amazon
211
1.33
247
1.38
1557
6.62
663
5.67
496
5.22

Summarizing the benchmarks gives us one clear winner: Linode. 32-bit
gave the best results on the Unixbench runs while 64-bit was fastest
on the Django and database tests. Since Linode also has the highest
included bandwidth I have a hard time recommending any of the other
providers if performance and price is most important for you.

If I had an opportunity to compare these providers again, I would have
included more multi-threaded benchmarks. I’ll probably not do a new
comparison as this article has taken a lot of time and been over
6 months in the making.

If you’re going to buy a VPS I’d appreciate it if you used
my referral page for Linode or for Slicehost
when doing so. [Less]

Andy McKay: David Ascher keynote at DjangoSki

Posted 20 days ago

We are pleased to announce the first keynote speaker for DjangoSki is David Ascher.

David Ascher is the CEO of Mozilla Messaging. He's been involved with
Python for many years and has dabbled around in Django too. He co-authored Learning ... [More] Python and worked on Komodo whilst at ActiveState (where he became the CTO).
Most recently Mozilla Messaging released the rather cool RainDrop, which is written in Python.

David has done some great talks at Python conferences in the past, providing thought provoking and entertaining talks. We think he can ski too,
but we'll find that out.

We would also like to thank our first sponsor for DjangoSki, OpenRoad Communications.

If you would like to sponsor DjangoSki and get your company in front of key Djangoers whilst supporting a great conference, contact ClearWind. For more information on the DjangoSki conference, go to djangoski.com. [Less]

Antoni Aloy López: Una ullada a Sphinx

Posted 20 days ago

Si heu fet servir la documentació de Python, Django o potser alguna de les aplicacions més importants o darrerament li heu fet una ullada al Building Skills with Python us n'adonareu que comparteixen un estil comú. Django ha personalitzat les ... [More] plantilles, però com podem veure a la part on explica com es crea i es contribueix a la documentació, podem feure que Django fa servir Sphinx.

Sphinx és l'eina amb la qual s'estan creant les documentacions dels principals projectes basats en Python (encara que ens permet escriure qualsevol tipus de documentació) i poc a poc esdevé la killer appplication de la documentació tècnica.

Començar amb Sphinx és prou senzill, sols necessitam tenir Python instal·lat i

$ easy_install Sphinx
$ sphinx-quickstart

i anar contestant les preguntes. Si heu compilat alguna vegada algun programa al món Unix veureu com quan acabin les preguntes s''haurà creat un directori amb un arxiu anomenat Makefile (make.bat per altres). Executant-lo ens crearà un directori build amb les bases del que pot ser la nostra documentació.

I és que Sphinx és bàsicament un compilador orientat a la creació de documentació. Agafa documents escrits en Restructured Text i crea un lloc web en HTML, genera un pdf o latex. Això vol dir que per poder treure'n el màxim partit s'ha de conèixer Restructured Text i fer-li una ullada a les comandes que Sphinx incorpora per crear les taules de contingut, fer el resaltat de sintaxi, incorporar imatges o fórmules matemàtiques. Una vegada passat el període d'aprenentatge (que ja us dic que és curt) veureu que el resultats que s'obtenen són espectaculars.

Ja he dit sovint pel blog que m'agrada escriure la documentació (i escriure en general) en text pla, utilitzant LaTeX, Markdown o ResTructured Text. Sphinx ajunta el fet de poder escriure la documentació com m'agrada amb un resultats realment professionals. És a la documentació hipertextual el que LaTeX és per a la documentació científica.

Potser ara us estareu demanant perquè fer la documentació amb aquesta eina i no limitar-nos a un document amb OpenOffice (o fins i tot en Word!!!), se m'acudeixen un parell mallorquí de raons:

El text pla es pot posar damunt un control de versions.
Permet que molta gent participi en la creació de la documentació.
Sphinx ens dóna unes plantilles que fan que la documentació llueixi.
El ressaltat de sintaxi Python ve de sèrie i costa ben poc fer el ressaltat per altres llenguatges.
El cercador està inclòs a la documentació

Però sobretot, perquè amb Sphinx escriure documentació és divertit. Pots distribuir-te la feina com vols, no has de passar ànsia per la maquetació final, ni per que les imatges se t'han descol·locat i no saps on han anat a parar (si heu fet documents de més de 20 planes amb un processador de text sabreu què vull dir). I que escriure documentació no sigui feixuc segurament farà que ens faci menys peresa documentar i tothom ens estarà eternament agraït. Jo ja he començat amb la documentació d'appfusedjango que no se digui que no predic amb l'exemple.

Personalment crec que Django ha marcat un abans i un després en el món de la documentació de projectes, de tal manera que cada dia més projectes i aplicacions emulen la manera de documentar de Django i Django (com Python) fa servir Sphinx. Demostrant que per a que un projecte tengui èxit no basta que sigui bo sinó que ha d'estar ben documentat.

No cerquem en Sphinx la bala de plata. Fer bona documentació no és senzill, Sphinx sols fa que sigui menys pesat i ens dóna un resultat final molt més amigable als nostres lectors. Un dels creadors de Django,Jacob Kaplan-Moss, ha escrit un conjunt de posts damunt com s'ha d'escriure bona documentació: Writing great documentation, de lectura imprescindible. Però tot i que no sigui fàcil s'ha de començar, ens hem d'avesar (i jo el primer) a que Sphinx sigui part de les eines de projecte, a escriure documentació i a millorar el nostre estil, tanmateix diuen que la pràctica fa el mestre, no?

0 comentaris,
0 trackbacks (URL)

Automatic translations of this post by Apertium [Less]

Alex Gaynor: Django and Python 3

Posted 20 days ago

Today I'm starting off doing some of the posts people want to see, and the number one item on that list is Django and Python 3. Python 3 has been out for about a year at this point, and so far Django hasn't really started to move towards it (at ... [More] least at a first glance). However, Django has already begun the long process towards moving to Python 3, this post is going to recap exactly what Django's migration strategy is (most of this post is a recap of a message James Bennett sent to the django-developers mailing list after the 1.0 release).

One of the most important things to recognize in this that though there are many developers using Django for smaller projects, or new projects that want to start these on Python 3, there are also a great many more with legacy (as if we can call recent deployments on Python2.6 and Django 1.1 legacy) deployments that they want to maintain and update. Further, Django's latest release, 1.1, has support for Python releases as old as 2.3, and a migration to Python 3 from 2.3 is nontrivial. However, it is significantly easier to make this migration from Python 2.6. This is the crux of James's plan, people want to move to Python 3.0 and moving towards Python 2.6 makes this easier for them and us. Therefore, since the 1.1 release Django has been removing support for one point version of Python per Django release. So, Django 1.1 will be the last release to support Python 2.3, 1.2 will be the last to support 2.4, etc. This plan isn't guaranteed, if there's a compelling reason to maintain support for a version for longer it will likely override this plan (for example if a particularly common deployment platform only offered Python 2.5 removing support for it might be delayed an additional release).

At the end of this process Django is going to end up only supporting Python 2.6. At this point (or maybe even before), a strategy will need to be devised for how to actually handle the switch. Some possibilities are, 1) having an official breakpoint, only one version is supported at a given time, 2) Python 3 support begins in a branch that tracks trunk and eventually it switches to become trunk ones Python 3 is the more common deployment, 3) Python 2.6 and 3 are supported from a single codebase. I'm not sure which one of these is easiest, other projects such as PLY have chosen to go with option 3, however my inclination is that option 2 will be best for Django since issues like bytes vs. string are particularly prominent in Django (since it talks to so many external data sources).

For people who are interested Martin von Löwis actually put together a patch that, at the time, gave Django Python 3 support (at least enough to run the tutorial under SQLite). If you're very interested in Django on Python 3 the best path would probably be to bring that patch up to date (unless it's wildly out of date, I haven't checked), and starting to fix new things that have been introduced since the patch was written. This work isn't likely to get any official support, since maintaining Python 2.4 support and Python 3 would be far too difficult, however there's no reason you can't maintain the patch externally on something like Github or Bitbucket. [Less]

Andy McKay: Djangopeople JSON parser

Posted 20 days ago

I bet you've always wanted to parse your djangopeople.net account into JSONP so you can use it somewhere else on the web. Well your wait is over: djangopeople-jsonp.appspot.com will do just. Some examples of some famous and not so famous Django people. (and of course mr nobody).