Django community: RSS
This page, updated regularly, aggregates Community blog posts from the Django community.
-
Pycon 2010 report I
Pycon was an incredible learning experience and networking opportunity. I met many good friends again and made just as many new ones. In addition, this was the first time I presented and did so on Pinax two times. Furthermore, in the name of diversity, this instance of Pycon saw the premiere of the Financial Assistance Grant for Women. We also had a dedicated talk on Diversity as a Dependency. The benefit this focus on diversity was that...um...yeah...like...uh...um...Diversity RocksDid I learn a lot at pycon? Heck yeah. Networking was life changing. And unlike previous conferences, I'm in a position to take advantages of opportunities offered. The next few weeks and months will see a lot of changes and challenges for me. Note: I've got to keep some things under wraps for now so I'm going to have to aggressively moderate comments. Feel free to comment, just don't take comment rejections personally. -
Background task processing and deferred execution in Django
Or, Celery + RabbitMQ = Django awesomeness! As you know, Django is synchronous, or blocking. This means each request will not be returned until all processing (e.g., of a view) is complete. It's the expected behavior and usually required in web applications, but there are times when you need tasks to run in the background (immediately, deferred, or periodically) without blocking. Some common use cases: Give the impression of a really snappy web application by finishing a request as soon as possible, even though a task is running in the background, then update the page incrementally using AJAX. Executing tasks asynchronously and using retries to make sure they are completed successfully. Scheduling periodic tasks. Parallel execution (to some degree). There have been multiple requests to add asynchronous support to Django, namely via the python threading module, and even the multiprocessing module released in Python2.6, but I doubt it will happen any time soon, actually I doubt it will ever happen. This is a common problem for many, and after scouring over many forum posts the following proposed solution keeps popping up, which reminds of me of the saying "when all you have is a hammer, everything looks like a nail". … -
Background task processing and deferred execution in Django
Or, Celery + RabbitMQ = Django awesomeness! As you know, Django is synchronous, or blocking. This means each request will not be returned until all processing (e.g., of a view) is complete. It's the expected behavior and usually required in web applications, but there are times when you need tasks to run in the background (immediately, deferred, or periodically) without blocking. Some common use cases: Give the impression of a really snappy web application by finishing a request as soon as possible, even though a task is running in the background, then update the page incrementally using AJAX. Executing tasks asynchronously and using retries to make sure they are completed successfully. Scheduling periodic tasks. Parallel execution (to some degree). There have been multiple requests to add asynchronous support to Django, namely via the python threading module, and even the multiprocessing module released in Python2.6, but I doubt it will happen any time soon, actually I doubt it will ever happen. This is a common problem for many, and after scouring over many forum posts the following proposed solution keeps popping up, which reminds of me of the saying "when all you have is a hammer, everything looks like a nail". … -
Background task processing and deferred execution in Django
Or, Celery + RabbitMQ = Django awesomeness! As you know, Django is synchronous, or blocking. This means each request will not be returned until all processing (e.g., of a view) is complete. It's the expected behavior and usually required in web applications, but there are times when you need tasks to run in the background (immediately, deferred, or periodically) without blocking. Some common use cases: Give the impression of a really snappy web application by finishing a request as soon as possible, even though a task is running in the background, then update the page incrementally using AJAX. Executing tasks asynchronously and using retries to make sure they are completed successfully. Scheduling periodic tasks. Parallel execution (to some degree). There have been multiple requests to add asynchronous support to Django, namely via the python threading module, and even the multiprocessing module released in Python2.6, but I doubt it will happen any time soon, actually I doubt it will ever happen. This is a common problem for many, and after scouring over many forum posts the following proposed solution keeps popping up, which reminds of me of the saying "when all you have is a hammer, everything looks like a nail". … -
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 … -
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 …
