Django community: RSS
This page, updated regularly, aggregates Community blog posts from the Django community.
-
Django E-Commerce
Pakt publishing have released a new Django book called Django 1.2 E-Commerce, written by Jess Legg. I'll have a copy soon and post a review here. In the meantime they are offering a free chapter of the book; Chapter 2 Setting up Shop in 30 minutes. -
Django E-Commerce
Pakt publishing have released a new Django book called Django 1.2 E-Commerce, written by Jess Legg. I'll have a copy soon and post a review here. In the meantime they are offering a free chapter of the book; Chapter 2 Setting up Shop in 30 minutes. -
Django E-Commerce
Pakt publishing have released a new Django book called Django 1.2 E-Commerce, written by Jess Legg. I'll have a copy soon and post a review here. In the meantime they are offering a free chapter of the book; Chapter 2 Setting up Shop in 30 minutes. -
"Using MongoDB in your Django app - implications and benefits"
Straight from DjangoCon 2010 here in Berlin. Slides from my talk on "Using MongoDB in your Django app - implications and benefits" are available as a HTML5 web page so you'll need one of those fancy browsers like Chrome to be able to view it. Sorry. -
"Using MongoDB in your Django app - implications and benefits"
Straight from DjangoCon 2010 here in Berlin. Slides from my talk on "Using MongoDB in your Django app - implications and benefits" are available as a HTML5 web page so you'll need one of those fancy browsers like Chrome to be able to view it. Sorry. -
MongoDB backend for Django-nonrel released
Update: It's possible to use simple JOINs via the django-dbindexer now. Finally, Django-nonrel has a MongoDB backend, which was originally started by George Karpenkov and then finished by Alberto Paro, Flavio Percoco, and I adapted the code to the nonrel backend API. This means you can use the Django ORM (from django.db import models) directly with MongoDB. Even better, you can write code that can run on both MongoDB and App Engine (via our App Engine backend) and possibly also SQL. For example, this website is running Django-nonrel on App Engine, but the same code also works with the MongoDB backend and even with Django's SQL backends. So, Django-nonrel allows for writing portable Django apps. This portability will often only be possible between non-relational DBs, but for many simple apps SQL should work, too. You're probably wondering by now: Does the admin interface work? Yes, but it's limited by MongoDB's query capabilities. For example, you can't do JOINs (except for JOINs made possible by django-dbindexer). Installation First, install pymongo, for example via "easy_install pymongo". Then, clone the MongoDB backend (or download the source) and install it by running "python setup.py install". Next, clone the Django-nonrel repository (or download the source) … -
3rd Year Project: Back to Backtrac
After contacting the university regarding my 3rd year project/dissertation, my ideal choice has been confirmed. I'll be making a distributed backup system, based around a Django web interface and AMQP. Backtrac is a pretty old project, and one whose name I am likely to change once I'm working on it. It was started in my [...] -
Making Django and NoSQL Play Nice
Presentation by Nice Alex Gaynor (Berlin, Germany). -
mongoengine vs. django-mongokit
django-mongokit is the project you want to use if you want to connect your Django project to your MongoDB database via the pymongo Python wrapper. An alternative (dare I say competing alternative) is MongoEngine which is bridge between Django and straight to pymongo. The immediate difference you notice is the syntax. django-mongokit looks like MongoKit syntax and MongoEngine looks like Django ORM. They both accomplish pretty much the same thing. So, which one is fastest? First of all, remember this? where I showed how django-mongokit sped past the SQL ORM like a lightning bullet. Well appears MongoEngine is even faster. That's an average of 23% faster for all three operations! -
Django-samaritan, parce que tout le monde a le droit d’aimer Bruce Willis
Le mois de mai est toujours un mois compliqué. Normalement c'est à cause de tout ces jours fériés qui sont autant d'obstacle au travail et qui nous oblige à être tout le temps en retard en mai. Pourtant, cette année, malgré que deux des jours fériés de mai tombent un samedi et que le ... -
Generating aggregate data across generic relations
Edit: I've created a github repo for performing generic aggregation and annotation based on the code from this entry Aggregation support was added to django's ORM in version 1.1, allowing you to generate Sums, Counts, and more without having to write any SQL. According to the docs aggregation is not supported for generic relations. This entry describes how to work around this using the .extra() method. The state of the art To take an example from the docs, it is possible to span relationships when performing aggregations: syntax:pycon >>> Store.objects.annotate(min_price=Min('books__price'), max_price=Max('books__price')) Here we are querying the Store object and annotating the result set with two extra attributes, 'min_price' and 'max_price', which contain the minimum and maximum price of books that are sold at that store. Conversely, if we want to find the minimum and maximum book price over the entire queryset, you would write: syntax:pycon >>> Store.objects.aggregate(min_price=Min('books__price'), max_price=Max('books__price')) The aggregate() method returns a dictionary as opposed to a queryset. This is an incredibly clean API! Suppose you want to aggregate across a GFK This is tricky. A generic foreign key is comprised of two attributes, a ContentType and a foreign key. The models that are GFKed to do not contain … -
Generating aggregate data across generic relations
Edit: I've created a github repo for performing generic aggregation and annotation based on the code from this entry Aggregation support was added to django's ORM in version 1.1, allowing you to generate Sums, Counts, and more without having to write any SQL. According to the docs aggregation is not supported for generic relations. This entry describes how to work around this using the .extra() method. The state of the art To take an example from the docs, it is possible to span relationships when performing aggregations: >>> Store.objects.annotate(min_price=Min('books__price'), max_price=Max('books__price')) Here we are querying the Store object and annotating the result set with two extra attributes, 'min_price' and 'max_price', which contain the minimum and maximum price of books that are sold at that store. Conversely, if we want to find the minimum and maximum book price over the entire queryset, you would write: >>> Store.objects.aggregate(min_price=Min('books__price'), max_price=Max('books__price')) The aggregate() method returns a dictionary as opposed to a queryset. This is an incredibly clean API! Suppose you want to aggregate across a GFK This is tricky. A generic foreign key is comprised of two attributes, a ContentType and a foreign key. The models that are GFKed to do not contain a reverse … -
Generating aggregate data across generic relations
Edit: I've created a github repo for performing generic aggregation and annotation based on the code from this entry Aggregation support was added to django's ORM in version 1.1, allowing you to generate Sums, Counts, and more without having to write any SQL. According to the docs aggregation is not supported for generic relations. This entry describes how to work around this using the .extra() method. The state of the art To take an example from the docs, it is possible to span relationships when performing aggregations: >>> Store.objects.annotate(min_price=Min('books__price'), max_price=Max('books__price')) Here we are querying the Store object and annotating the result set with two extra attributes, 'min_price' and 'max_price', which contain the minimum and maximum price of books that are sold at that store. Conversely, if we want to find the minimum and maximum book price over the entire queryset, you would write: >>> Store.objects.aggregate(min_price=Min('books__price'), max_price=Max('books__price')) The aggregate() method returns a dictionary as opposed to a queryset. This is an incredibly clean API! Suppose you want to aggregate across a GFK This is tricky. A generic foreign key is comprised of two attributes, a ContentType and a foreign key. The models that are GFKed to do not contain a reverse … -
Generating aggregate data across generic relations
Edit: I've created a github repo for performing generic aggregation and annotation based on the code from this entry Aggregation support was added to django's ORM in version 1.1, allowing you to generate Sums, Counts, and more without having to write any SQL. According to the docs aggregation is not supported for generic relations. This entry describes how to work around this using the .extra() method. The state of the art To take an example from the docs, it is possible to span relationships when performing aggregations: >>> Store.objects.annotate(min_price=Min('books__price'), max_price=Max('books__price')) Here we are querying the Store object and annotating the result set with two extra attributes, 'min_price' and 'max_price', which contain the minimum and maximum price of books that are sold at that store. Conversely, if we want to find the minimum and maximum book price over the entire queryset, you would write: >>> Store.objects.aggregate(min_price=Min('books__price'), max_price=Max('books__price')) The aggregate() method returns a dictionary as opposed to a queryset. This is an incredibly clean API! Suppose you want to aggregate across a GFK This is tricky. A generic foreign key is comprised of two attributes, a ContentType and a foreign key. The models that are GFKed to do not contain a reverse … -
Generating aggregate data across generic relations
Edit: I've created a github repo for performing generic aggregation and annotation based on the code from this entry Aggregation support was added to django's ORM in version 1.1, allowing you to generate Sums, Counts, and more without having to write any SQL. According to the docs aggregation is not supported for generic relations. This entry describes how to work around this using the .extra() method. The state of the art To take an example from the docs, it is possible to span relationships when performing aggregations: >>> Store.objects.annotate(min_price=Min('books__price'), max_price=Max('books__price')) Here we are querying the Store object and annotating the result set with two extra attributes, 'min_price' and 'max_price', which contain the minimum and maximum price of books that are sold at that store. Conversely, if we want to find the minimum and maximum book price over the entire queryset, you would write: >>> Store.objects.aggregate(min_price=Min('books__price'), max_price=Max('books__price')) The aggregate() method returns a dictionary as opposed to a queryset. This is an incredibly clean API! Suppose you want to aggregate across a GFK This is tricky. A generic foreign key is comprised of two attributes, a ContentType and a foreign key. The models that are GFKed to do not contain a reverse … -
Changed project structure
We really wanted to avoid this, but with the soon-to-be-announced MongoDB backend we realized that our current project structure for djangoappengine-based projects makes portability between different nonrel backends and installation on MongoDB-based projects unnecessarily difficult. Please adapt your project to the new recommended structure. We've published detailed installation instructions in the djangoappengine documentation which also describes how to create symbolic links on Windows 7, Vista, and XP and Linux and MacOS X. What changed The "common-apps" folder is deprecated. From now on, you'll get a warning if that folder exists in your project. The "django", "djangoappengine", and "djangotoolbox" links should now be placed right into your main project folder. We've also moved "djangotoolbox" into a subfolder of the djangotoolbox repository, so please change the link accordingly. That was necessary because we had to add a setup.py installation file for MongoDB users. Also, the app.yaml file has to reflect those changes. Please remove the "common-apps/" prefix from all paths in your app.yaml. See the django-testapp/app.yaml for an example. Finally, replace your manage.py file with the one in django-testapp. Just download the django-testapp/manage.py from the repository and copy it into your projects. Now you can delete the "common-apps" folder. Again, please look … -
Learned Something New Today
I learned something very interesting today regarding JavaScript. Back in the day, I used to put something like this in my HTML when I wanted to include some JS: <script language="javascript"> ... </script> Then I learned that I should be using something like this instead: <script type="text/javascript"> ... </script> I've been doing that for years and years now. Turns out I've been wrong all this time. Well, at least for 4 years of that time. I stumbled upon RFC4329 today for whatever reason and noticed that it said the text/javascript mimetype is obsolete. I dug into the RFC a bit and found this: Various unregistered media types have been used in an ad-hoc fashion to label and exchange programs written in ECMAScript and JavaScript. These include: +-----------------------------------------------------+ | text/javascript | text/ecmascript | | text/javascript1.0 | text/javascript1.1 | | text/javascript1.2 | text/javascript1.3 | | text/javascript1.4 | text/javascript1.5 | | text/jscript | text/livescript | | text/x-javascript | text/x-ecmascript | | application/x-javascript | application/x-ecmascript | | application/javascript | application/ecmascript | +-----------------------------------------------------+ Use of the "text" top-level type for this kind of content is known to be problematic. This document thus defines text/javascript and text/ ecmascript but marks them as "obsolete". Use of experimental … -
Learned Something New Today
I learned something very interesting today regarding JavaScript. Back in the day, I used to put something like this in my HTML when I wanted to include some JS: <script language="javascript"> ... </script> Then I learned that I should be using something like this instead: <script type="text/javascript"> ... </script> I've been doing that for years and years now. Turns out I've been wrong all this time. Well, at least for 4 years of that time. I stumbled upon RFC4329 today for whatever reason and noticed that it said the text/javascript mimetype is obsolete. I dug into the RFC a bit and found this: Various unregistered media types have been used in an ad-hoc fashion to label and exchange programs written in ECMAScript and JavaScript. These include: +-----------------------------------------------------+ | text/javascript | text/ecmascript | | text/javascript1.0 | text/javascript1.1 | | text/javascript1.2 | text/javascript1.3 | | text/javascript1.4 | text/javascript1.5 | | text/jscript | text/livescript | | text/x-javascript | text/x-ecmascript | | application/x-javascript | application/x-ecmascript | | application/javascript | application/ecmascript | +-----------------------------------------------------+ Use of the "text" top-level type for this kind of content is known to be problematic. This document thus defines text/javascript and text/ ecmascript but marks them as "obsolete". Use of experimental … -
South 0.7.1
The first bugfix release of South is now out, and there's plenty of fixes.It's been perhaps a little too long since the 0.7 release, so I'm pleased to announce that 0.7.1 has now arrived. It's really all small changes, as befits a point release - the release notes highlight the few slightly more major changes. In other news, I'll be at djangocon.eu next week, talking about both South up to now, as well as what I think the future holds. The jury's still out on what exactly will happen, but I have a few interesting proposals I'll be talking about, some of which are a bit more grand than others. If you're not going to be able to make it, don't worry, I'm sure you can all be subjected to me in two-dimensional video form later on. It's a once in a lifetime experience, mostly because few people are awake enough to try listening to it a second time. I'll also obviously be posting my proposals here and in other appropriate places, to gauge feedback. -
South 0.7.1
The first bugfix release of South is now out, and there's plenty of fixes. It's been perhaps a little too long since the 0.7 release, so I'm pleased to announce that 0.7.1 has now arrived. It's really all small changes, as befits a point release - the release notes highlight the few slightly more major changes. In other news, I'll be at djangocon.eu next week, talking about both South up to now, as well as what I think the future holds. The jury's still out on what exactly will happen, but I have a few interesting proposals I'll be talking about, some of which are a bit more grand than others. If you're not going to be able to make it, don't worry, I'm sure you can all be subjected to me in two-dimensional video form later on. It's a once in a lifetime experience, mostly because few people are awake enough to try listening to it a second time. I'll also obviously be posting my proposals here and in other appropriate places, to gauge feedback. -
Exciting Python Developer Job
Meebo, the instant messenger in your browser company, are seriously looking for Python developers right now to work in Mountain View, California. From what I can gather they are expanding, and are building a number of sites in the Django framework. -
Exciting Python Developer Job
Meebo, the instant messenger in your browser company, are seriously looking for Python developers right now to work in Mountain View, California. From what I can gather they are expanding, and are building a number of sites in the Django framework. Meebo are hiring! If you have experience with Django, or some other web framework, and you live in California (or can relocate) this may be an excellent opportunity for you to work for a cool technology company. Contact Kiko Griffin if you're interested — and please mention where you read this! See Meebo's job page for more information… -
Exciting Python Developer Job
Meebo, the instant messenger in your browser company, are seriously looking for Python developers right now to work in Mountain View, California. From what I can gather they are expanding, and are building a number of sites in the Django framework. Meebo are hiring! If you have experience with Django, or some other web framework, and you live in California (or can relocate) this may be an excellent opportunity for you to work for a cool technology company. Contact Kiko Griffin if you're interested — and please mention where you read this! See Meebo's job page for more information… -
Another book to review! (Django E-Commerce)
The nice folks at Packt has sent me another book to review. This time the book is Django 1.2 E-Commerce. The sample title looks great which includes setting up an e-commerce site in 30 mins using the usual suspects from the Django framework: Admin, generic views and using Checkout from google. The example looks practical and easy to follow ... makes me like this book already. For those of you who want to get a whiff of what this book is like ... here is a link to the sample chapter.https://www.packtpub.com/sites/default/files/7009-chapter-2-setting-up-shop-in-30-minutes_0.pdf -
Review: Django 1.1 Testing and Debugging
The lovely people of Packt Publishing asked me to review Karen Tracey's latest book Django 1.1 Testing and Debugging. I didn't actually read the book but rather skimmed it, apart from some selected parts and from what I read it's obvious that Karen has an ability to write to people who are not experts on the subject. Years of being a top contributor on the Django users mailing list must have something to do with it. But here's the cracker. I didn't learn anything from this book (actually, I wasn't aware of the pp command in the pdb debugger). Is that a complaint about the book? No! It just means that the book was aimed at beginners and apparently I'm not a beginner any more. Great! One thing I would have liked to see is more about testing strategy since this is something beginners often have problems with. I don't know if there even is such a word as "testing strategy" but I'm referring to the thinking behind what to test and more importantly sometimes what not to test. Beginners have a tendency to write tests for the most specific things and thus spending all their time assuring the most …
