Django community: RSS
This page, updated regularly, aggregates Community blog posts from the Django community.
-
Django Simple Captcha et tout devient si simple
Comme d'habitude le mois d'aout fut une vraie folie. Et qui dit mois de folie dit, billet qui prennent du retard. Heureusement que j'ai pu tricher en publiant la première interview. (ben oui c'est beaucoup plus rapide de poser des questions que d'y répondre, enfin beaucoup plus rapide d'écrire les questions dans un mails ... -
Generic relationships in Django
"Last week I’ve completed an interesting task within our project: building internal link-shortening system based on persisted objects, not on constant URLs. The main requirement was to get as loosely-coupled design as possible. In the perfect world the “shortenable” classes should know absolutely nothing about link-shortening mechanism. How to get such a flexibility in Django? I’ve used the ContentTypes framework with generic relations and it works pretty well!" by Marcin Swierczynski -
Permissions with Django-nonrel
Quick update: Florian Hahn has implemented a solution for permission handling with Django on non-relational databases. Django's own permission system unfortunately requires JOIN support and thus doesn't work. After his original announcement the code has been optimized, so a permission check can be done with just two database operations. Also, his backend now scales with the number of users. Florian has posted installation and usage instructions on his blog. Check it out if you need permission support in your project. Leave a comment -
Another nashvegas Update
So something that has been bugging me since the recent release of nashvegas was the lack of handling errors in migration scripts. There were several issues impeding me being able to handle errant scripts gracefully, by which I mean reporting the error via a sys.exit() call. I was sub-shelling to manage.py dbshell where I would PIPE the contents of the script to stdin. Turns out that dbshell executes the database client process via os.execvp which as the Python document states: These functions all execute a new program, replacing the current process; they do not return. So, obviously, I was not going to get a return code from the underlying call, that I might check and take evasive action. Because I was getting to the database client indirectly through dbshell, I was unable to control things like setting flags or variables to control the behavior of the database client. So, even if I were to somehow get around the first problem of os.execvp being used, I still would not be able to set the necessary flags needed to get the client to behave how I wanted it to. Therefore, I decided that I'd just copy the argument building from each of … -
Another nashvegas Update
So something that has been bugging me since the recent release of nashvegas was the lack of handling errors in migration scripts. There were several issues impeding me being able to handle errant scripts gracefully, by which I mean reporting the error via a sys.exit() call. I was sub-shelling to manage.py dbshell where I would PIPE the contents of the script to stdin. Turns out that dbshell executes the database client process via os.execvp which as the Python document states: These functions all execute a new program, replacing the current process; they do not return. So, obviously, I was not going to get a return code from the underlying call, that I might check and take evasive action. Because I was getting to the database client indirectly through dbshell, I was unable to control things like setting flags or variables to control the behavior of the database client. So, even if I were to somehow get around the first problem of os.execvp being used, I still would not be able to set the necessary flags needed to get the client to behave how I wanted it to. Therefore, I decided that I'd just copy the argument building from each of … -
Another nashvegas Update
So something that has been bugging me since the recent release of nashvegas was the lack of handling errors in migration scripts. There were several issues impeding me being able to handle errant scripts gracefully, by which I mean reporting the error via a sys.exit() call. I was sub-shelling to manage.py dbshell where I would PIPE the contents of the script to stdin. Turns out that dbshell executes the database client process via os.execvp which as the Python document states: These functions all execute a new program, replacing the current process; they do not return. So, obviously, I was not going to get a return code from the underlying call, that I might check and take evasive action. Because I was getting to the database client indirectly through dbshell, I was unable to control things like setting flags or variables to control the behavior of the database client. So, even if I were to somehow get around the first problem of os.execvp being used, I still would not be able to set the necessary flags needed to get the client to behave how I wanted it to. Therefore, I decided that I'd just copy the argument building from each of … -
from zope import django: persistence
Having recently come from the Plone world to join Mozilla, I am in the delicious but fleeting position to compare two major Python web frameworks with some pretension of familiarity. Through a series of articles focusing on specific features, I will compare the Zope family of frameworks (as they are used in Plone) with the Django framework, which is gaining popularity at Mozilla and currently runs support.mozilla.com and addons.mozilla.com. -
from zope import django: persistence
Having recently come from the Plone world to join Mozilla, I am in the delicious but fleeting position to compare two major Python web frameworks with some pretension of familiarity. Through a series of articles focusing on specific features, I will compare the Zope family of frameworks (as they are used in Plone) with the Django framework, which is gaining popularity at Mozilla and currently runs support.mozilla.com and addons.mozilla.com. -
Organising your Django code
There are several options when it comes to organising your code in a Django project. There isn’t a ‘correct’ way, and it will depend on the size of the project, if it is a team development, or purely the preference of the developer. Templates Django gives you the ability to put your templates anywhere, either [...] -
A different kind of URL shortener
Today I'm launching my first Google App Engine site. While I built it largely to play with GAE, it is also useful in its own right (I like to think so anyway). It does two different things: Link shortening without redirection. Put in a godawful long Amazon link and get back a shorter Amazon link. Works with eBay and a few others too. I welcome recipes for other sites. (For the programmers in the audience, which is most of you -- yes, the processing is via regular expressions.) It does some basic checks to confirm that the shortened URL returns the same page as the original one. Link expansion. Put in a link from a URL shortening/redirection service, e.g. bit.ly, and see where it redirects to. Works with a slew of popular link-shorteners, including the house brands goo.gl and nyti.ms. Some of the shortening services do offer a way to see the link target before you visit it, but they're all different; this presents a simple unified interface to that feature. There's a bookmarklet too. If you have someone in your online life who frequently bombards you with, say, mile-long eBay links, tell them about it. http://urlworks.appspot.com/ -
Simple full text search
The full text search has now been implemented. ScratchBlog can now perform powerful full-text search on the current blog posts. This full-text search has been implemented using an entirely new search module written from scratch, which uses simple python, combined with the power of python regular expressions. This new module can be used with other Django projects, as well as with django-nonrel projects along with GAE, if required. It doesn't intend to replace any existing text-search engines which are intended for any sort of complex or scalable searches, where huge amount of data is directly involved. You may use this for simple full-text search on the fly, without using any sort of indexing. It is ideal for any small projects, or where the data volume for the text don't go blizzard. This search module will be released here soon. Till then, keep searching. -
Simple full text search
The full text search has now been implemented. ScratchBlog can now perform powerful full-text search on the current blog posts. This full-text search has been implemented using an entirely new search module written from scratch, which uses simple python, combined with the power of python regular expressions. This new module can be used with other Django projects, as well as with django-nonrel projects along with GAE, if required. It doesn't intend to replace any existing text-search engines which are intended for any sort of complex or scalable searches, where huge amount of data is directly involved. You may use this for simple full-text search on the fly, without using any sort of indexing. It is ideal for any small projects, or where the data volume for the text don't go blizzard. This search module will be released here soon. Till then, keep searching. -
Announcing Django Packages!
I'm part of a two person team that just launched that BETA site for http://djangopackages.com, a site that is designed to list all the Django Applications, Frameworks, and Packages created by the Django community. While there are already a few places to look for these things, it is quite easy to argue that they are challenging to navigate, don't give any hard metrics, or are woefully incomplete/unstable/closed. Our goal was to provide an attractive, easy-to-navigate, easy-to-add-data, stable site and share it with the world.Also, this was our entry into Django Dash 2010, and was the culmination of a few days of brainstorming over paper, a lot of research, and two days of feverish coding/designing. The project was feature complete to our specifications at 5pm the second day, and the rest of the time was spent adding in UI tweaks, usability enhancements, and trying to deploy our creation.Since then, we've cleaned up a the UI, improved the design, and got the site stable. The code is open source and on github, so fork and contribute!Design Consideration: No 'Like' button or 'Rate my app' rating systemsWe wanted hard metrics. So the package numbers are pulled from the repo sites such as Github, … -
Django Dash Lessons Learned
Our experience with Django Dash 2010 was that it was an wonderful exercise in classic Django development, cowboy/cowgirl coding, and drinking copious amounts of caffeinated beverages. The result, Django Packages, is something we are happy with, are continuing to improve, and hope will improve the community.Lesson: Fixtures are a mustDjango gives you this amazing Admin control panel. As soon as you get your models in place and are entering test data, start creating fixtures. For the dash we named them initial_data.json and loaded them into the individual app directories. This meant that every time we blew away the database we got a reload with records in place. Sometimes this means you have to hand-edit JSON (or YAML if you swing that way), but the alternative is to waste time re-entering the same data again and again. Don't forget to change the names of your test fixtures before you launch!From the command-line how to save a fixture pydanny-style:./manage.py dumpdata package > apps/packages/fixtures/initial_data.jsonOne nice thing about fixtures is that when you do have the time/need, you can use them to help you write tests. And it makes development easier for contributors.Lesson: Research ahead of timeIn the days before the contest, we researched to see … -
New features for Django Packages
-
Quina calor!
Aquestes darreres setmanes han estat d'allò més interessants, caloroses però interessants. La calor ha vingut fonamentalment d'uns dies que hem passat a Menorca. Ja hi havia anat una vegada de vacances i me va encantar, aquesta vegada no ha estat diferent, encara que hi havia molta més gent que la darrera vegada. Però no vull donar enveja, així que també toca parlar de programació. Aquests dies hem estat i encara estarem durant unes quantes setmanes més, fent feina amb un projecte que implica fer feina amb un cms anomenat ezPublish. L'ezPublish és un CMS prou potent, orientat a treure continguts sigui com sigui. Tu escrius el que sigui a la part de l'administrador i l'eZ intentarà renderitzar-ho com pugui. Supòs que si el que importa és el contingut en sí això és fantàstic, però quan es tracta d'afegir-hi regles de negoci per damunt eZPublish és un malson comparat amb frameworks com Django. Està clar que no podem fer una comparació justa ja que ezPublish no té la flexibilitat d'un framework però crec que l'experiència serveix per reafirmar-me amb l'apreciació de que si el teu negoci no és generar continguts sinó que vols controlar el que passa a la web i … -
Musings about django.contrib.auth.models.User
Dawned on me that the Django auth user model that ships with Django is like the string built-in of a high level programming language. With the string built-in it's oh so tempting to add custom functionality to it like a fancy captialization method or some other function that automatically strips whitespace or what not. Yes, I'm looking at you Prototype for example. By NOT doing that, and leaving it as it is, you automatically manage to Keep It Simple Stupid and your application code makes sense to the next developer who joins your project. I'm not a smart programmer but I'm a smart developer in that I'm good at keeping things pure and simple. It means I can't show off any fancy generators, monads or metaclasses but it does mean that fellow coders who follow my steps can more quickly hit the ground running. My colleagues and I now have more than ten Django projects that rely on, without overriding, the django.contrib.auth.models.User class and there has been many times where I've been tempted to use it as a base class or something instead but in retrospect I'm wholeheartedly happy I didn't. The benefit isn't technical; it's a matter of teamwork … -
Musings about django.contrib.auth.models.User
Dawned on me that the Django auth user model that ships with Django is like the string built-in of a high level programming language. With the string built-in it's oh so tempting to add custom functionality to it like a fancy captialization method or some other function that automatically strips whitespace or what not. Yes, I'm looking at you Prototype for example. By NOT doing that, and leaving it as it is, you automatically manage to Keep It Simple Stupid and your application code makes sense to the next developer who joins your project. I'm not a smart programmer but I'm a smart developer in that I'm good at keeping things pure and simple. It means I can't show off any fancy generators, monads or metaclasses but it does mean that fellow coders who follow my steps can more quickly hit the ground running. My colleagues and I now have more than ten Django projects that rely on, without overriding, the django.contrib.auth.models.User class and there has been many times where I've been tempted to use it as a base class or something instead but in retrospect I'm wholeheartedly happy I didn't. The benefit isn't technical; it's a matter of teamwork … -
Musings about django.contrib.auth.models.User
Dawned on me that the Django auth user model that ships with Django is like the string built-in of a high level programming language. With the string built-in it's oh so tempting to add custom functionality to it like a fancy captialization method or some other function that automatically strips whitespace or what not. Yes, I'm looking at you Prototype for example. By NOT doing that, and leaving it as it is, you automatically manage to Keep It Simple Stupid and your application code makes sense to the next developer who joins your project. I'm not a smart programmer but I'm a smart developer in that I'm good at keeping things pure and simple. It means I can't show off any fancy generators, monads or metaclasses but it does mean that fellow coders who follow my steps can more quickly hit the ground running. My colleagues and I now have more than ten Django projects that rely on, without overriding, the django.contrib.auth.models.User class and there has been many times where I've been tempted to use it as a base class or something instead but in retrospect I'm wholeheartedly happy I didn't. The benefit isn't technical; it's a matter of teamwork … -
Musings about django.contrib.auth.models.User
Dawned on me that the Django auth user model that ships with Django is like the string built-in of a high level programming language. With the string built-in it's oh so tempting to add custom functionality to it like a fancy captialization method or some other function that automatically strips whitespace or what not. Yes, I'm looking at you Prototype for example. By NOT doing that, and leaving it as it is, you automatically manage to Keep It Simple Stupid and your application code makes sense to the next developer who joins your project. I'm not a smart programmer but I'm a smart developer in that I'm good at keeping things pure and simple. It means I can't show off any fancy generators, monads or metaclasses but it does mean that fellow coders who follow my steps can more quickly hit the ground running. My colleagues and I now have more than ten Django projects that rely on, without overriding, the django.contrib.auth.models.User class and there has been many times where I've been tempted to use it as a base class or something instead but in retrospect I'm wholeheartedly happy I didn't. The benefit isn't technical; it's a matter of teamwork … -
Centralized logging for fun and profit!
Setting up a centralized log server using syslog isn't as hard as many may believe. Whether it's logs from Apache, nginx, email services, or even from your own Python applications having a central log server gives you many benefits: Benefits to a centralized logs Reduces disk space usage and disk I/O on core servers that should be busy doing something else. This is especially true if you want to log all queries to your database. Doing this on the same disk as your actual database creates a write for every read and an extra write for every write. Removes logs from the server in the event of an intrusion or system failure. By having the logs elsewhere you at least have a chance of finding something useful about what happened. All of your logs are in one place, duh! This makes things like grepping through say Apache error logs across multiple webservers easier than bouncing around between boxes. Any log processing and log rotation can also be centralized which may delay your sysadmin from finally snapping and killing everyone. Syslog Review In case you aren't terribly familiar with how syslog works, here's a quick primer. Syslog separates out various logs … -
Tips & Tricks for your Django Powered Database
Tonight was our Django meetup here in San Francisco. Four of us presented (three from Whiskey, outnumbering everyone as always ;), with some pretty great material. A few of my favorites were .update() from Andy McCurdy, (I have to love anyone that agrees), formfield_overrides (not sure how I didn... -
Wondering about django orm caching frameworks
So briefly looking over the code reveals that: johnny-cache will cache the rows returned by the execution machinery in django’s sql compiler (monkey-patches the compilers). It looks like it has fancy-pants invalidation (it basically has bulk invalidation through 2-tiered cache key scheme, unlike cache-machine with relies on set_many) and even support for transactions. I’m using this and it’s awesome. django-cache-machine will cache the result of the QuerySet.iterator method. It seems that it has some limitations: it only (automatically) invalidates on forward relations (FKs) so you have to perform carefull invalidation through your code (eg: you use qs.update(), run queries through models without the custom CachingManager, use Model.create() and whatnot …). Also, cache-machine will be heavy on the memcached traffic (1 call for every invalidated object, using set_many though …) django-cachebot will cache the rows on the same level as cache-machine (at QuerySet.iterator call). Also, it has a very nice feature that will prefetch objects from reverse relations (like FK reverse descriptors and many to many relations – eg: Group.objects.select_reverse('user_set') and then group.user_set_cache will be equal to group.user_set.all()). Unfortunately the author only tested it on django 1.1 and it needs a django patch to work (the django manager patch is only … -
Wondering about django orm caching frameworks
So briefly looking over the code reveals that: johnny-cache will cache the rows returned by the execution machinery in django's sql compiler (monkey-patches the compilers). It looks like it has fancy-pants invalidation (it basically has bulk invalidation through 2-tiered cache key scheme, unlike cache-machine with relies on set_many) and even support for transactions. I'm using this and it's awesome. django-cache-machine will cache the result of the QuerySet.iterator method. It seems that it has some limitations: it only (automatically) invalidates on forward relations (FKs) so you have to perform carefull invalidation through your code (eg: you use qs.update(), run queries through models without the custom CachingManager, use Model.create() and whatnot ...). Also, cache-machine will be heavy on the memcached traffic (1 call for every invalidated object, using set_many though ...) django-cachebot will cache the rows on the same level as cache-machine (at QuerySet.iterator call). Also, it has a very nice feature that will prefetch objects from reverse relations (like FK reverse descriptors and many to many relations - eg: Group.objects.select_reverse('user_set') and then group.user_set_cache will be equal to group.user_set.all()). Unfortunately the author only tested it on django 1.1 and it needs a django patch to work (the django manager patch is only … -
Wondering about django orm caching frameworks
So briefly looking over the code reveals that: johnny-cache will cache the rows returned by the execution machinery in django's sql compiler (monkey-patches the compilers). It looks like it has fancy-pants invalidation (it basically has bulk invalidation through 2-tiered cache key scheme, unlike cache-machine with relies on set_many) and even support for transactions. I'm using this and it's awesome. django-cache-machine will cache the result of the QuerySet.iterator method. It seems that it has some limitations: it only (automatically) invalidates on forward relations (FKs) so you have to perform carefull invalidation through your code (eg: you use qs.update(), run queries through models without the custom CachingManager, use Model.create() and whatnot ...). Also, cache-machine will be heavy on the memcached traffic (1 call for every invalidated object, using set_many though ...) django-cachebot will cache the rows on the same level as cache-machine (at QuerySet.iterator call). Also, it has a very nice feature that will prefetch objects from reverse relations (like FK reverse descriptors and many to many relations - eg: Group.objects.select_reverse('user_set') and then group.user_set_cache will be equal to group.user_set.all()). Unfortunately the author only tested it on django 1.1 and it needs a django patch to work (the django manager patch is only …
