Django community: RSS
This page, updated regularly, aggregates Community blog posts from the Django community.
-
Lightning Fast Shop (LFS) - Kai Diefenbach
-
Djangocon keynote: fostering community - Karen Tracey
-
Twitter reactions on Karen's keynote at djangocon.eu
-
Djangocon lightning talks tuesday morning
-
Lightning talks monday afternoon at djangocon.eu
-
I hate your database - Andrew Godwin
-
Domain specific languages in django apps - Matthieu Amiguet
-
Building secure django websites - Erik Romijn
-
Django and the real-time web - Zachary Voase
-
Class-based generic views (anti)patterns - Bruno Renié
-
Django and mongodb - Daniel Greenfeld and Audrey Roy
-
PostgreSQL when it is not your job - Christophe Pettus
-
Djangocon.eu keynote - Jacob Kaplan-Moss
-
Scaling Your Clouds
My post yesterday seems to have gotten all the cloud fanboy’s panties into a twist, so I figured I’d give them something else to rage about. There were lots of claims that without the cloud you can’t scale, or you dont have redundancy, or you can’t come up with the result … -
Scaling Your Clouds
My post yesterday seems to have gotten all the cloud fanboy's panties into a twist, so I figured I'd give them something else to rage about. There were lots of claims that without the cloud you can't scale, or you dont have redundancy, or you can't come up with the result of 2 + 2. I can't even ... -
backbonejs django generic view
I recently had a chat with @Deacalion about backbonejs who recommended I had a look into it. So I’ve spent some time learning backbonejs whilst keeping in mind how I might use it with my own Django based projects. The questions I wanted to answer are as follow. Do I want to use backbonejs and if so [...] -
The Cloud is Not For You
Update: Did I hurt your feelings with this post? Read Scaling your Clouds so you can rage even more. Well, maybe not specifically you, but the mass that screams it will solve their problems. It’s been a fun year so far. There’s been exciting things happening both for me personally, as … -
The Cloud is Not For You
Update: Did I hurt your feelings with this post? Read Scaling your Clouds so you can rage even more. Well, maybe not specifically you, but the mass that screams it will solve their problems. It's been a fun year so far. There's been exciting things happening both for me personally, as well as a... -
Quick deploy with Chef-Solo and Git
Using Chef with Chef-Server requires to install a lot of weird stuff on your server; even after you manage to set it up, you're not safe from its quirks. However, you don't really need a chef-server to set up and update your machines - you can get away with chef-solo and git. -
The Organism Application
I had an email from a self-confessed django beginner, asking for some assistance. Here is my solution, as I worked through it. ## The Application ## The application is designed to allow tracking information related to identifying various organisms. An organism may have many identifying features, such as on a tree, the height, and the leaf morphology, or on a bird, the colour of the feathers, size of the egg and so on. To make it simpler for the users, it would be useful to classify organisms as belonging to a type, which can then be used to limit the available choices of identifying features: if an organism is a bird, then we only show those features that make sense for a bird. To do all of this, we can have a class structure that looks somewhat like: {% highlight python %} # models.py from django.db import models class OrganismType(models.Model): description = models.CharField(max_length=200) class IdentificationField(models.Model): type = models.ForeignKey(OrganismType, related_name='id_fields') name = models.CharField(max_length=200) class Meta: unique_together = ('type', 'name') class Organism(models.Model): common_name = models.CharField(max_length=200) latin_name = models.CharField(max_length=200, unique=True) type = models.ForeignKey(OrganismType, related_name='organisms') class IdentificationDetail(models.Model): organism = models.ForeignKey(Organism, related_name="id_details") field = models.ForeignKey(IdentificationField) description = models.CharField(max_length=250) class Meta: unique_together = ('organism', 'field') {% … -
Karen Tracey to Deliver Keynote at DjangoCon Europe 2012
I am very proud to announce that Karen Tracey, Lead Developer at Caktus and Django Core Developer, will be delivering a keynote address at DjangoCon Europe next week. This will be Karen's first speech to the Django community, of which she has been an exemplary member since 2006. DjangoCon Europe is the central meeting point ... -
Karen Tracey to Deliver Keynote at DjangoCon Europe 2012
I am very proud to announce that Karen Tracey, Lead Developer at Caktus and Django Core Developer, will be delivering a keynote address at DjangoCon Europe next week. This will be Karen's first speech to the Django community, of which she has been an exemplary member since 2006. -
Dummies doing (even more) dummy things
This is a follow-up to the Dummies doing dummy things post. I originally posted info about this update on the mailing list some time back, but it has been pointed out to me that it might be a nice thing to put on the dev blog too since it's well, related to development!I have been at it with further profiling in Evennia. Notably even more aggressive on-demand caching of objects as well as on-object attributes. I found from profiling that there was an issue with how object access checks were done - they caused the lock handler to hit the database every lock check as it retrieved the needed attributes.Whereas this was not much of a hit per call, access checks are done all the time, for commands, objects, scripts, well everything that might need restricted access. After caching also attributes, there is no need to hit the database as often. Some commands, such as listing all command help entries do see this effect (although you still probably wouldn't notice it unless you checked before and after like I did). More importantly, under the hood I'm happy to see that the profile for normal Evennia usage is no longer dominated by … -
Django class based views in action - forms handling
Django class based views offer a wide range of features - supporting forms, objects lists and many more. In this article I'll show some of the class based views in action - those related to forms and object lists. -
Querysets aren't as lazy as you think
It should be reasonably well-known by now that querysets are lazy. That is, simply instantiating a queryset via a manager doesn't actually hit the database: that doesn't happen until the queryset is sliced or iterated. That's why the first field definition in the form below is safe, but not the second: class MyForm(forms.Form): my_field = forms.ModelChoiceField(queryset=MyModel.objects.all()) my_datefield = forms.DateTimeField(initial=datetime.datetime.now()) Even though both elements are calling methods on definition, the first is safe because the queryset is not evaluated at that time, whereas the second is not safe because it is evaluated at that time, and therefore remains the same for the duration of the current process (which can be many days). For the record, you should always pass the callable: initial=datetime.datetime.now, without the calling brackets. Now, there are a couple of gotchas here. It is perfectly possible to define manager methods that are not safe to use in places like the queryset argument to the first field above. Here's an example: class PublishedManager(models.Manager): def get_query_set(self): return super(PublishedManager, self).get_query_set().filter( published_date__lte=datetime.datetime.now()) Clearly, this is an attempt to create a manager that automatically filters items which have been published. In the normal course of calling this in a view, it will work exactly …
