Django community: RSS
This page, updated regularly, aggregates Community blog posts from the Django community.
-
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 … -
Caktus Sends Team of Five to PyCon 2010 in Atlanta
Python and Django are tools we use on a daily basis to build fantastic web apps here at Caktus. I'm pleased to announce that Caktus is sending five developers--Colin, Alex, Mike, Mark, and myself--to PyCon 2010! PyCon is an annual gathering for users and developers of the open source Python programming language. This year the US conference is being held in Atlanta, GA. We'll be driving down tomorrow (Thursday) from Chapel Hill, NC and staying for the conference weekend plus one day of the sprints. -
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 … -
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 … -
Stupid simple templatetags with Django
Writing simple templatetags is only marginally less painful that writing complex tags. django-simpletags aims at making writing simple tags simple. -
Our new website on App Engine
It's nonrel blog time, again! We really wanted to post last week, but we had to finish something before PyCon. Drums please... We've moved our blog to our new website built with Django nonrel. It's hosted on App Engine, but it should also work with other cloud DBs once we have more DB backends. The code is open-source, so you can build your own Django nonrel-based website and contribute improvements. The project comes with a simple CMS (a shamefully simple CMS :) and you can also create multiple independent blogs. For example, we now have two blogs on this site: Life & work: This will be some kind of life and work (practices) diary - without code Django nonrel / NoSQL: That's the blog you are reading now For now, we'll mostly focus on Django, but if you want to follow us more closely you should also consider subscribing to the other blogs. Features All content is written in reStructuredText markup and Pygments is used for code highlighting. You can manage all pages and blog posts via the admin interface. Comments are handled by Disqus. It doesn't make sense to write a new comments app because Disqus offers a much … -
Django tip: Automatic logins
In the Django documentation we see the following: When you’re manually logging a user in, you must call authenticate() before you call login(). That’s all really nice, because it makes sure that all your authentication backends are tried out; but if you want a really quick remedy for getting the job done, then you’ll need to set the user.backend property to the specific backend that authenticated the user. Beware that the Django developers can change these requirements. I wanted this to avoid writing my own backend, so I did this to log users in via a special view accepting a hash from the URL (from an e-mail that had a link that’d automatically log a user in). This could also become useful if you want to become a different user. def get_hash(s): import hashlib m = hashlib.md5() m.update(str(s) + settings.LOGIN_SECRET) return str(m.hexdigest()) def auto_login(request, user_id, secret): user = get_object_or_404(User, id=user_id) if not secret == get_hash(str(user_id)): raise Http404() user.backend = "django.contrib.auth.backends.ModelBackend" login(request, user) return HttpResponseRedirect(reverse('frontpage')) BEWARE! I strongly suggest that you don’t log any superusers in this way. You could add a conditional statement not user.is_superuser or similar. -
To hell with web standards
Ian Hickson (emphasis added): Someone whom I can’t identify publicly, since he posted only on one of the secret W3C member lists, contributed to the following thread […] Net result: the latest publication of HTML5 is now blocked by Adobe, via an objection that has still not been made public […] Secret W3C member lists? Anonymous holds? What is this, the Senate? Some might say this is Adobe’s fault. -
Why toppcloud will not be agnostic
Why toppcloud will not be agnostic. Ian Bicking’s toppcloud aims to offer deployment with the ease of use of AppEngine against a standard, open source Ubuntu + Python 2.6 + mod_wsgi + Varnish stack. Here he explains why he’s not going to vary the required components: keeping everything completely standardised means everyone gets the same bugs (and the same fixes). -
Python 2.6 - an orphan child
The current dominating version of python is 2.5. Most of the frameworks and vendors have comfortably settled on 2.5. Some of the upcoming technologies will support Python 3 exclusively. That leaves our old friend Python 2.6 out in the cold. The situation Python 2.6 - it is really not worth the effort to support it. I mean if you start breaking your code and such, you might as well upgrade to Python 3. The problem Python 2.6 provides a lot of nice features over Python 2.5 ("except as" is my personal favorite). A lost of the libraries are standardized (e.g. json over simplejson) and improved in terms of performance. However - it is not backward compatible to 2.5. The version difference of 0.1 makes it very easy to start using Python 2.6 for everything only to realize at the end that one has to regress to 2.5 for production. The solution Either stick with python 2.5 or stick with python 2.5. Conclusion It seems that in quest of progress, and by splitting their core language into three, Python community has went against one of it's core principles: "Simple is better than complex". After all if your application uses components all … -
Presenting django-devserver, a better runserver
Presenting django-devserver, a better runserver. I really like this—it’s a Django management command (./manage.py rundevserver) which adds SQL logging and cache access summaries to the console output of Django’s local development server. It solves a similar set of problems to the debug toolbar, but requires slightly less setup and doesn’t inject additional HTML in to your pages. You can add your own custom modules to it as well. -
Eating my own Dog Food
For several years now I've hosted this blog here on blogspot/blogger. Its been both a good and bad experience. For writing out simple posts it has made things pretty easy. However, if I try to post code examples I've got to deal with the various quirks of the blog engine. How it escapes special characters and that you can't easily do color colorization has been really annoying. Yes, I know you can do some hoop jumping to make this work, but I decided a long time ago that if I had to do that then I would host my own blog.Speaking of which, a few months back I got called out for not eating my own dog food. Yup, as a Python developer shouldn't I use something Python powered? I currently do Django professionally so those are in my tool chest so this should be trivial. Heck I also do some serious Pinax work so why not that?Whatever I put it under, it would be a nice move. I would be able to format and control my blog to a much better degree. I could easily supply code examples. I could use the hosting to demonstrate pet projects or launch … -
Picture Perfect
The hot new feature this week is photos. We've added the ability to attach your own photos of what you make to your recipes. This is a pretty early version, so we want to polish things more as we go, but please don't let that stop you from uploading pictures of your latest creation! Added photo galleries to recipes. For example: Whole Wheat Graham Bread Fixed the way ingredient/instruction sets are created. If you have a recipe that looks wrong to you, simply edit and re-save it and it should look much better afterward. Fixed an issue in the forking history where the path to the current recipe lacked highlighting. Fixed misleading text about who's recipe it was in the forking history. Fixed how the "Original Recipe" link works in forking history. Featured recipe of the week: Raw Fudge Balls by Madeleine McLaughlin. We tried these this past week and they were fantastic. My two boys adored them and more than once my wife caught them sneaking into the fridge for more!
