Django community: Community blog posts RSS
This page, updated regularly, aggregates Community blog posts from the Django community.
-
Now Serving: Everyone!
This has been a very exciting week for us, as we're now officially launched! We've taken away all the beta aspects of the site and now anyone can signup for the site! This also means that the world can see your recipes, so feel free to share with anyone/everyone! We've added a new sharing feature that lets you enter someone's e-mail address to pass a recipe along. You can also share the recipes via Twitter, Facebook and a new short URL (like http://frkn.it/r/1137/). You may have noticed a couple other changes around here in the last week. The site got an overall look/feel upgrade and a shiny new logo. We're still polishing but pretty pleased thus far. And the logo looks great on t-shirts... As usual, we've also fixed a couple bugs: The fork history now works regardless of which browser you're using. Fixed recipes being duplicated in the "All Recipes" area. Fixed the message when you get followed by someone else. Added About, Pricing & Contact pages. However, we're not about to rest on our laurels. We've got plenty to do and will be rolling out new things as we finish them. If you were a beta user, we'll … -
4 things to know for NoSQL Django coders
Update 2: Take a look at the django-dbindexer. Since its release it's possible to use __month= queries so you don't have to use tricky code which uses a date range query for example. Additionally django-dbindexer adds support for simple JOINs. Update: MongoDB backend is now available too :) This is the first post in a series that should give you an impression of what non-relational / NoSQL model code looks like with django-nonrel. As mentioned in the previous post, you can see django-nonrel in action on our new website (we use it ourselves in the spirit of dogfooding). While everything discussed here should work on all nonrel DBs we currently only have an App Engine backend and soon a MongoDB backend (more on that once it's finished). If you want to help with other backends (Redis, SimpleDB, CouchDB, etc.) please join the discussion group. We'll dive into the source of our website which contains a very simple "CMS" and a blog app which can host multiple independent blogs. It runs the admin interface unmodified, but with some limitations. Overall, the code is surprisingly similar to normal Django code, but you'll also find that nonrel-compatible models need their own way of … -
Web Site Performance Optimizations
Recently I have done some optimizations to make telvee a little faster using django_compressor and making sprites for background images. Good news is substantial changes to development environment and the design wasn’t required. I’ll get into details below. But first I’d like to write about the theory a little bit. I follow (and read with [...] -
Django patterns, part 4: forwards generic relations
My last post talked about how to follow reverse generic relations efficiently. However, there's a further potential inefficiency in using generic relations, and that's the forward relationship. If once again we take the example of an Asset model with a GenericForeignKey used to point at Articles and Galleries, we can get from each individual Asset to its related item by doing asset.content_object. However, if we have a whole queryset of Assets, doing this: {% for asset in assets %} {{ asset.content_object }} {% endfor %} will result in as many queries as there are assets - in fact it's n+m, where n is the number of assets and m is the number of different content types, as you'll have one extra query per type to get the ContentType object. (Although it might be slightly less than that if you've used ContentTypes elsewhere, as the model manager caches lookups on the assumption that they never change once they've been set.) However, luckily we can make this much more efficient as well, again using a variation of the dictionary technique. generics = {} for item in queryset: generics.setdefault(item.content_type_id, set()).add(item.object_id) content_types = ContentType.objects.in_bulk(generics.keys()) relations = {} for ct, fk_list in generics.items(): ct_model = … -
Django patterns, part 4: forwards generic relations
My last post talked about how to follow reverse generic relations efficiently. However, there's a further potential inefficiency in using generic relations, and that's the forward relationship. If once again we take the example of an Asset model with a GenericForeignKey used to point at Articles and Galleries, we can get from each individual Asset to its related item by doing asset.content_object. However, if we have a whole queryset of Assets, doing this: {% for asset in assets %} {{ asset.content_object }} {% endfor %} will result in as many queries as there are assets - in fact it's n+m, where n is the number of assets and m is the number of different content types, as you'll have one extra query per type to get the ContentType object. (Although it might be slightly less than that if you've used ContentTypes elsewhere, as the model manager caches lookups on the assumption that they never change once they've been set.) However, luckily we can make this much more efficient as well, again using a variation of the dictionary technique. generics = {} for item in queryset: generics.setdefault(item.content_type_id, set()).add(item.object_id) content_types = ContentType.objects.in_bulk(generics.keys()) relations = {} for ct, fk_list in generics.items(): ct_model = … -
Forget The Pony
This is too good not to share (and thank you Eric for tweeting the link): Forget that pink pony as the mascot of Django, one of our very own, Eric Florenzano, appears to already have magical powers. I wish we could have seen the light saber during one of his PyCon talks. :) -
Forget The Pony
This is too good not to share (and thank you Eric for tweeting the link): Forget that pink pony as the mascot of Django, one of our very own, Eric Florenzano, appears to already have magical powers. I wish we could have seen the light saber during one of his PyCon talks. :) -
Forget The Pony
This is too good not to share (and thank you Eric for tweeting the link): Forget that pink pony as the mascot of Django, one of our very own, Eric Florenzano, appears to already have magical powers. I wish we could have seen the light saber during one of his PyCon talks. :) -
jQuery 1.4.2 Released
Just a quick note alerting everyone to the fact that jQuery has gotten EVEN EASIER AND FASTER. Go check out the release notes. Related posts:jQuery 1.4 Released jQuery 1.3.1 Go For Launch jQuery 1.4 Alpha 1 Released Related posts:jQuery 1.4 Released jQuery 1.3.1 Go For Launch jQuery 1.4 Alpha 1 Released -
В одну корзину
Один из самых часто задаваемых вопросов на форумах по Джанге -- как на одной странице выводить информацию из разных информационных блоков (пример такой ветки или вот совсем свежий). Давайте попробуем разобраться в стандартных способах решения данной задачи. Я специально не хочу рассматривать тут какие-то сторонние решения просто из-за того, что их много и они не интересны с точки зрения изучения классических методик применения возможностей Джанги. Основной проблемой с которой сталкиваются вопрошающие -- как получить все нужны данные в одной вьюхе и зачастую из разных приложений. Это усугубляется тем, что у большинства в подсознании сидит необходимость разделения приложений на максимально независимые компоненты. И это правильное желание. Другое дело, что не надо этим принципом злоупотреблять. Если всё-таки ваши приложения нуждаются друг в друге достаточно сильно, то нет ничего плохого в том чтобы иметь в них перекрестные импорты и заимствовать функционал (в том числе по получению данных) так или иначе. Другое дело что таком случае стоит подумать о том, что возможно они настолько жестко связаны, что должны быть единым целым, т.е. одним приложением по сути. Но и даже в этом случае имеет смысл как-то чуть-чуть отделить общие данные от локальных. Обычно исходной целью стремления получить данные из разных приложений являются всякие виджеты, информеры … -
jacobian's django-deployment-workshop
jacobian’s django-deployment-workshop. Notes and resources from Jacob’s 3 hour Django deployment workshop at PyCon, including example configuration files for Apache2 + mod_wsgi, nginx, PostgreSQL and pgpool. -
DjangoSki checklist
Sadly Matt Berg won't be able to make it DjangoSki. Far too busy at the moment in Uganda working on the next version of Child Count. That's a shame, we'll get him next year when he's had time to catch up on his skiing a bit ;). Very fortunate to have Brian Leroux, a self described "software hack" from Nitobi coming to speak in Matt's place. Brian works on mobile apps and things like PhoneGap, XUI and Lawnchair. Checklist for DjangoSki: Laptop Passport (for any non-Canadians that is) Skis / snowboards and gear Hot tub gear We have a few sprint topics planned on the wiki, but if you've got your own, please come ready with those ideas. -
buildout vs pip, virtualenv and requirements files
The Python world is blessed with two mainstream choices for integrating Python packages into an application: buildout and pip. This post looks at the pros and cons of each, to try to help you pick which one is best for you. -
buildout vs pip, virtualenv and requirements files
Repeatable software configurations are crucial for reliable software deployments. Applications (particularly web applications based on frameworks) are often made up of dozens, if not hundreds of separate packages. When you deploy your application, you want to be sure that the packages and their versions are the same as those that were tested through development and staging. Buildout Buildout, developed originally by Jim Fulton at Zope Corporation, was an attempt to address this problem. zc.buildout 1.0.0, released back in January 2008 (after over a year of betas) has become the accepted way of managing the hundreds of packages that make up Zope, BlueBream and Plone. Buildout isn't restricted to Zope, of course - it's usable for any setuptools-aware Python software. Buildout is based around configuration files, most commonly a single file called buildout.cfg. Buildout itself doesn't do very much; most functionality is provided by add-on modules. These modules are called 'recipes'. They're easy to write, and there are dozens of custom recipes to perform specialised tasks. However, the key piece of functionality that buildout offers is to allow the developer to simply list the packages (eggs) required by their application, and optionally their versions. Minimum, maximum and ranges of acceptable versions … -
buildout vs pip, virtualenv and requirements files
Repeatable software configurations are crucial for reliable software deployments. Applications (particularly web applications based on frameworks) are often made up of dozens, if not hundreds of separate packages. When you deploy your application, you want to be sure that the packages and their versions are the same as those that were tested through development and staging. Buildout Buildout, developed originally by Jim Fulton at Zope Corporation, was an attempt to address this problem. zc.buildout 1.0.0, released back in January 2008 (after over a year of betas) has become the accepted way of managing the hundreds of packages that make up Zope, BlueBream and Plone. Buildout isn't restricted to Zope, of course - it's usable for any setuptools-aware Python software. Buildout is based around configuration files, most commonly a single file called buildout.cfg. Buildout itself doesn't do very much; most functionality is provided by add-on modules. These modules are called 'recipes'. They're easy to write, and there are dozens of custom recipes to perform specialised tasks. However, the key piece of functionality that buildout offers is to allow the developer to simply list the packages (eggs) required by their application, and optionally their versions. Minimum, maximum and ranges of acceptable versions … -
buildout vs pip, virtualenv and requirements files
Repeatable software configurations are crucial for reliable software deployments. Applications (particularly web applications based on frameworks) are often made up of dozens, if not hundreds of separate packages. When you deploy your application, you want to be sure that the packages and their versions are the same as those that were tested through development and staging. Buildout Buildout, developed originally by Jim Fulton at Zope Corporation, was an attempt to address this problem. zc.buildout 1.0.0, released back in January 2008 (after over a year of betas) has become the accepted way of managing the hundreds of packages that make up Zope, BlueBream and Plone. Buildout isn't restricted to Zope, of course - it's usable for any setuptools-aware Python software. Buildout is based around configuration files, most commonly a single file called buildout.cfg. Buildout itself doesn't do very much; most functionality is provided by add-on modules. These modules are called 'recipes'. They're easy to write, and there are dozens of custom recipes to perform specialised tasks. However, the key piece of functionality that buildout offers is to allow the developer to simply list the packages (eggs) required by their application, and optionally their versions. Minimum, maximum and ranges of acceptable versions … -
Vim IDE per Django i Python
Encara que faig servir distints editors i entorns integrats (IDE) per programar en Python i Django hi ha sempre la constant de retornar cap a Vim i gVim. La cosa està però, en que per al desenvolupament normal no vull renunciar a un parell de coses que fan la vida més fàcil: Resaltat de sintaxi amb colors personalitzables i/o una paleta de colors còmoda per fer-hi feina. Autocompletat (dins cert límits, que això és un llenguatge dinàmic) i ajuda integrada. Plantilles per no haver d'escriure molt. Per exemple els shebangs, o els models de Django. Distints tipus de tabulació segons el llenguatge, quatre per Python, però 2 per HTML i Javascript. Possibilitat de tenir oberts molts arxius a la vegada i accedir-hi fàcilment Navegació pel sistema d'arxius integrada I poca cosa més. Després quant més potent sigui l'editor millor, i per això Vim n'és de potent!! El problema és que ja m'agradaria poder fer servir amb agilitat un 20% de les seves capacitats. En la meva recerca de l'editor perfecte he anat modificant el .vimrc i afegint plugins diversos, i configuracions que anat trobant d'aquí i d'allà. Per si a algú li va bé, he posat el meu .vimrc i … -
Loading Templates Based on Request Headers in Django
We have been experimenting with A/B testing using Google’s Website Optimizer. The tool is very nice, but we ran into issues with A/B testing in pages with dynamic content. Website Optimizer is really geared for optimizing static pages and elements (like sign-up pages). You have to put the HTML for A and B versions in Website Optimizer up front. That is fine for some CSS changes or button element changes, but not very useful in changing an item whose content is variable. Another method that Website Optimizer uses is different URLs for the same page (but not using query strings) and Website Optimizer handles the redirect. That could work, we thought, if only we could deliver different over-ridden templates based on the sub-domain. So version A could be www.washingtontimes.com/news/2010/Feb/16/some-story-name/ and version B could be www2.washingtontimes.com/news/2010/Feb/16/some-story-name/. But Django doesn’t let you change the TEMPLATE_DIRS setting on the fly. Looking at Loaders I started investigating how template loaders work in Django, and found a big problem: the loaders don’t have access to the request. Without the request information, you obviously can substitute template directories based on request headers. Then my co-worker, Jonathan Hensley, mentioned django-ab. Django-ab looks like a great project, but we couldn’t use it since the … -
Django Signals: Be lazy, let stuff happen magically
When I first learned about Django signals, it gave me the same warm fuzzy feeling I got when I started using RSS. Define what I'm interested in, sit back, relax, and let the information come to me. You can do the same in Django, but instead of getting news type notifications, you define what stuff should happen when other stuff happens, and best of all, the so-called stuff is global throughout your project, not just within applications (supporting decoupled apps). For example: Before a blog comment is published, check it for spam. After a user logs in successfully, update his twitter status. What you can do with signals are plentiful, and up to your imagination, so lets get into it. What are Django signals? In a nutshell, signals allow certain senders to notify a set of receivers that some action has taken place. They're especially useful when many pieces of code may be interested in the same events. This might remind you of Event driven programming, and rightfully so, the core concepts are very similar. Django provides a set of built-in signals that let user defined code get notified by Django itself of certain actions, for example: # Sent before … -
Django Signals: Be lazy, let stuff happen magically
When I first learned about Django signals, it gave me the same warm fuzzy feeling I got when I started using RSS. Define what I'm interested in, sit back, relax, and let the information come to me. You can do the same in Django, but instead of getting news type notifications, you define what stuff should happen when other stuff happens, and best of all, the so-called stuff is global throughout your project, not just within applications (supporting decoupled apps). For example: Before a blog comment is published, check it for spam. After a user logs in successfully, update his twitter status. What you can do with signals are plentiful, and up to your imagination, so lets get into it. What are Django signals? In a nutshell, signals allow certain senders to notify a set of receivers that some action has taken place. They're especially useful when many pieces of code may be interested in the same events. This might remind you of Event driven programming, and rightfully so, the core concepts are very similar. Django provides a set of built-in signals that let user defined code get notified by Django itself of certain actions, for example: # Sent before … -
Django Signals: Be lazy, let stuff happen magically
When I first learned about Django signals, it gave me the same warm fuzzy feeling I got when I started using RSS. Define what I'm interested in, sit back, relax, and let the information come to me. You can do the same in Django, but instead of getting news type notifications, you define what stuff should happen when other stuff happens, and best of all, the so-called stuff is global throughout your project, not just within applications (supporting decoupled apps). For example: Before a blog comment is published, check it for spam. After a user logs in successfully, update his twitter status. What you can do with signals are plentiful, and up to your imagination, so lets get into it. What are Django signals? In a nutshell, signals allow certain senders to notify a set of receivers that some action has taken place. They're especially useful when many pieces of code may be interested in the same events. This might remind you of Event driven programming, and rightfully so, the core concepts are very similar. Django provides a set of built-in signals that let user defined code get notified by Django itself of certain actions, for example: # Sent before … -
Early registration for our Advanced Django class ends soon
Early registration ends Friday for the March Advanced Django Class I'm teaching, so if you're planning on coming, you should sign up soon! I'm really excited about this class: we'll get to dive really deep into the good parts of Django. We'll cover all sorts of advanced usage of Django's APIs, spend a bunch of time playing with all the cool stuff out there in the Django ecosystem, and actually spend a whole day setting up and configuring a real-world deployment stack. Many more details are over on the class description page, along with contact info if you've got any questions. -
Django Advent
Django Advent. I can’t believe I haven’t linked to this already—Django Advent is “a series of articles about upcoming releases of the Django web framework”. Seven have been posted so far, covering topics from 1.2 including multi-db, messages, object permissions and natural keys. -
Early registration for my Advanced Django class ends soon
Early registration ends Friday for the March Advanced Django Class I’m teaching, so if you’re planning on coming, you should sign up soon! I’m really excited about this class: we’ll get to dive really deep into the good parts of Django. We’ll cover all sorts of advanced usage of Django’s APIs, spend a bunch of time playing with all the cool stuff out there in the Django ecosystem, and actually spend a whole day setting up and configuring a real-world deployment stack. -
Django patterns part 3: efficient generic relations
I've previously talked about how to make reverse lookups more efficient using a simple dictionary trick. Today I want to write about how this can be extended to generic relations. At its heart, a generic relationship is defined by two elements: a foreign key to the ContentType table, to determine the type of the related object, and an ID field, to identify the specific object to link to. Django uses these two elements to provide a content_object pseudo-field which, to the user, works similarly to a real ForeignKey field. And, again just like a ForeignKey, Django can helpfully provide a reverse relationship from the linked model back to the generic one, although you do need to explicitly define this using generic.GenericRelation to make Django aware of it. As usual, though, the real inefficiency arises when you are accessing reverse relationships for a whole lot of items - say, each item in a QuerySet. As with reverse foreign keys, Django will attempt to resolve this relationship individually for each item, resulting in a whole lot of queries. The solution is a little different, though, to take into account the added complexity of generic relations. Assuming the list of items is all …