Django community: RSS
This page, updated regularly, aggregates Community blog posts from the Django community.
-
Fastest "boolean SQL queries" possible with Django
For those familiar with the Django ORM they know how easy it is to work with and that you can do lots of nifty things with the result (QuerySet in Django lingo). So I was working report that basically just needed to figure out if a particular product has been invoiced. Not for how much or when, just if it's included in an invoice or not. [610 more words] -
Dutch Django meeting in Amsterdam, part two
Part two of the December Dutch django meeting. (See part one). Reusable django apps - Klaas van Schelven Basically a continuation of the lighting talk he gave last time. They make software for lawyers. These sites don't have lots of page views, so there are no performance issues, for instance. But the "problem" that they have is the amount of small customized changes that the customers want. One wants a social security number per person, the other wants to know the sex. They do not want to clutter the generic code with all those small customizations, however. You'd end up with lots of SHOW_SSN = False switches in your settings, otherwise. The official solution (*note Reinout: see James Bennett's video) is to "parametrize your views". def my_view(request, template="xyz", form_class=SomeForm, model_class=SomeClass). That's a whole whopping lot of parameters! System Message: WARNING/2 (<string>, line 21); backlink Inline emphasis start-string without end-string. Their solution: EightSpaces. "Class based everything", basically. It is called "eight spaces" as what you'd normally put in your models.py is indented eight spaces to the right: it is wrapped in two levels of eightspaces code: one wrapping class definition and one wrapper method. I've seen worse names :-) The wrapping … -
Final days of the lenovo laptop
On my way home from the Dutch Django meeting, I'm sitting in the train to Utrecht. I take out my LAPTOP. OUCH. The dArn thINg is HOT again. The same as it was when I arrived at the Django meeting. Once every two weeks (since about three months) my lenovo laptop somehow wakes up again if I've suspended it. While sitting in my backpack! Why on earth?!? I'm sure it was sleeping some 5 seconds after I closed the lid. I mean, I'm checking that every time I put the laptop in my backpack since it happened the first time. Pretty irritating (and scaring) if you take a HOT laptop out of your bag. Why? No idea. Except that this is a cheapo lenovo thinkpad. Thinkpad? Didn't "IBM thinkpad" use to have legendary linux (which I'm using) support? Yes, it used to have. Until they brought out a cheaper line (the "SL510" model in my case) without the original thinkpad firmware. So with the thinkpad logo, but with some cheap, relatively unsupported, firmware. Just google for "thinkpad", "linux" and "speakers". Or "volume control". Or... My volume control doesn't work. My mute button doesn't work. The only thing that prevents me … -
South and mutiple databases tests
Ok, today was the second time I was bitten by this. Time to write down the solution so I can find it back in google :-) The problem occurs when you have multiple databases, with the second one being just for one app. For example an existing database from the customer with some read-only data. So you probably have one app just for reading that data with a database router that allows only that app's models in that database. What happens when you have south enabled and you run the tests: $> bin/test ... Creating test database... Syncing... Creating table aaa Creating table bbb ... No fixtures found. Migrating... Running migrations for ccc: - Migrating forwards to 0001_initial. ... No fixtures found. Synced: > aaa > bbb Migrated: - ccc Creating test database 'the_second_database'... Syncing... Creating table ddd Creating table eee No fixtures found. Migrating... Traceback (most recent call last): ... django.db.utils.DatabaseError: no such table: south_migrationhistory Well, yes, that south_migrationhistory table doesn't exist in the second database. It doesn't need to be. When creating/migrating the databases (outside the tests), it all goes perfectly OK as only the default database is getting created/migrated. Only south in combination with tests fails as … -
Settings in Django
-
Settings in Django
I want to talk a bit about how we handle our large amounts of application configuration over at DISQUS. Every app has it, and it seems like theres a hundred different ways that you can manage it. While I'm not going to say ours is the best way, it has allowed us a very flexible application config... -
The First Few Weeks - ep.io
The First Few Weeks—ep.io. Another take on managed Python Django/WSGI hosting, from Andrew Godwin and Ben Firshman. -
Hello from Gondor
Hello from Gondor. “Effortless production Django hosting” from the Eldarion team. -
Creating a PostgreSQL User and Database
Coming Soon. -
Running mod_wsgi in Daemon Mode
If you are tired of having to reload Apache each time you make a change to the Python files in Django then read on. There is a way around this and it is done by using mod_wsgi and running it in daemon mode which allows you to touch the WSGI file and have Apache automatically pick up on the changes you have made without having to restart. All you need to do is add the... -
Running mod_wsgi in Daemon Mode
If you are tired of having to reload Apache each time you make a change to the Python files in Django then read on. There is a way around this and it is done by using mod_wsgi and running it in daemon mode which allows you to touch the WSGI file and have Apache automatically pick up on the changes you have made without having to restart. All you need to do is add the... -
New Ventures
For the past month and a bit, I've been working part-time on my new venture. Along with Ben Firshman, I'm working on ep.io, a Python/WSGI hosting service, with resource-based (not instance-based) billing. It's been an interesting ride - designing shared hosting so it's both secure and so you can measure and bill resources accurately is a difficult task - but we're finally out of the woods and have everything working reasonably normally, leaving only the slow crawl of beta-testing and polishing (and working out a payment provider). We've also launched a blog, which only contains an initial post now, but it's where we'll be noting down what we've learnt, and general deployment advice, hopefully making it useful as a general learning resource as well as a corporate mouthpiece. Initially we've focused on supporting Django, as it's the thing Ben and I use most often, but the entire stack was built with general WSGI applications in mind (and, indeed, they do run). The stack we've built is quite flexible, so it could potentially be used for a variety of different languages or frameworks, but we think focusing on doing Python (and doing it well) is a good goal. If you want … -
New Ventures
For the past month and a bit, I've been working part-time on my new venture.Along with Ben Firshman, I'm working on ep.io, a Python/WSGI hosting service, with resource-based (not instance-based) billing. It's been an interesting ride - designing shared hosting so it's both secure and so you can measure and bill resources accurately is a difficult task - but we're finally out of the woods and have everything working reasonably normally, leaving only the slow crawl of beta-testing and polishing (and working out a payment provider). We've also launched a blog, which only contains an initial post now, but it's where we'll be noting down what we've learnt, and general deployment advice, hopefully making it useful as a general learning resource as well as a corporate mouthpiece. Initially we've focused on supporting Django, as it's the thing Ben and I use most often, but the entire stack was built with general WSGI applications in mind (and, indeed, they do run). The stack we've built is quite flexible, so it could potentially be used for a variety of different languages or frameworks, but we think focusing on doing Python (and doing it well) is a good goal. If you want to … -
django-static version 1.5 automatically taking care of imported CSS
I just released django-static 1.5 (github page) which takes care of optimizing imported CSS files. To explain, suppose you have a file called foo.css and do this in your Django template: {% load django_static %} <link href="{% slimfile "/css/foo.css" %}" rel="stylesheet" type="text/css" /> And in foo.css you have the following: @import "bar.css"; body { background-image: url(/images/foo.png); } And in bar.css you have this: div.content { background-image: url("bar.png"); } The outcome is the following: # foo.css @import "/css/bar.1257701299.css"; body{background-image:url(/images/foo.1257701686.png)} # bar.css div.content{background-image:url("/css/bar.1257701552.png")} In other words not only does it parse your CSS content and gives images unique names you can set aggressive caching headers on, it will also unfold imported CSS files and optimize them too. I think that's really useful. You with one single setting (settings.DJANGO_STATIC=True) you can get all your static resources massaged and prepare for the best possible HTTP optimization. Also, it's all automated so you never need to run any build scripts and the definition of what static resources to use (and how to optimize them) is all defined in the template. This I think makes a lot more sense than maintaining static resources in a config file. The coverage is 93% and there is an example app to look at in the if you prefer that over a README. -
django-static version 1.5 automatically taking care of imported CSS
I just released django-static 1.5 (github page) which takes care of optimizing imported CSS files. To explain, suppose you have a file called foo.css and do this in your Django template: {% load django_static %} <link href="{% slimfile "/css/foo.css" %}" rel="stylesheet" type="text/css" /> And in foo.css you have the following: @import "bar.css"; body { background-image: url(/images/foo.png); } And in bar.css you have this: div.content { background-image: url("bar.png"); } The outcome is the following: # foo.css @import "/css/bar.1257701299.css"; body{background-image:url(/images/foo.1257701686.png)} # bar.css div.content{background-image:url("/css/bar.1257701552.png")} In other words not only does it parse your CSS content and gives images unique names you can set aggressive caching headers on, it will also unfold imported CSS files and optimize them too. I think that's really useful. You with one single setting (settings.DJANGO_STATIC=True) you can get all your static resources massaged and prepare for the best possible HTTP optimization. Also, it's all automated so you never need to run any build scripts and the definition of what static resources to use (and how to optimize them) is all defined in the template. This I think makes a lot more sense than maintaining static resources in a config file. The coverage is 93% and there is an example app to look at in the if you prefer that over a README. -
django-static version 1.5 automatically taking care of imported CSS
I just released django-static 1.5 (github page) which takes care of optimizing imported CSS files. To explain, suppose you have a file called foo.css and do this in your Django template: {% load django_static %} <link href="{% slimfile "/css/foo.css" %}" rel="stylesheet" type="text/css" /> And in foo.css you have the following: @import "bar.css"; body { background-image: url(/images/foo.png); } And in bar.css you have this: div.content { background-image: url("bar.png"); } The outcome is the following: # foo.css @import "/css/bar.1257701299.css"; body{background-image:url(/images/foo.1257701686.png)} # bar.css div.content{background-image:url("/css/bar.1257701552.png")} In other words not only does it parse your CSS content and gives images unique names you can set aggressive caching headers on, it will also unfold imported CSS files and optimize them too. I think that's really useful. You with one single setting (settings.DJANGO_STATIC=True) you can get all your static resources massaged and prepare for the best possible HTTP optimization. Also, it's all automated so you never need to run any build scripts and the definition of what static resources to use (and how to optimize them) is all defined in the template. This I think makes a lot more sense than maintaining static resources in a config file. The coverage is 93% and there is an example app to look at in the if you prefer that over a README. -
django-static version 1.5 automatically taking care of imported CSS
I just released django-static 1.5 (github page) which takes care of optimizing imported CSS files. To explain, suppose you have a file called foo.css and do this in your Django template: {% load django_static %} <link href="{% slimfile "/css/foo.css" %}" rel="stylesheet" type="text/css" /> And in foo.css you have the following: @import "bar.css"; body { background-image: url(/images/foo.png); } And in bar.css you have this: div.content { background-image: url("bar.png"); } The outcome is the following: # foo.css @import "/css/bar.1257701299.css"; body{background-image:url(/images/foo.1257701686.png)} # bar.css div.content{background-image:url("/css/bar.1257701552.png")} In other words not only does it parse your CSS content and gives images unique names you can set aggressive caching headers on, it will also unfold imported CSS files and optimize them too. I think that's really useful. You with one single setting (settings.DJANGO_STATIC=True) you can get all your static resources massaged and prepare for the best possible HTTP optimization. Also, it's all automated so you never need to run any build scripts and the definition of what static resources to use (and how to optimize them) is all defined in the template. This I think makes a lot more sense than maintaining static resources in a config file. The coverage is 93% and there is an example app to look at in the if you prefer that over a README. -
Docs or it doesn't exist
Docs or it doesn't exist -
Introducing Shrubbery
Shrubbery is a collection of utilities for and extensions of Django. Its core feature are: App-local settings ORM extensions: fields, managers & querysets, multiple joins, and arbitrary queryset unions Polymorph relations (a replacement for django.contrib.contenttypes) A tagging app build on top of polymorph relations. I plan to describe most of these in detail in future posts. Meanwhile, there is some documentation. Shrubbery requires Django 1.3. It is available under the MIT License on github. -
Spatial Bookmarking Service goes Open Source
Locidesktop was my coffee shop coding project of last year. I was quite pleased with the results. Locidesktop.com has been happily serving link desktops to some loyal visitors for months now – with no maintenance required on my part (a good thing because I've been busy with other projects). Rather than let the project stagnate while I do other things, I have released it as open source with the hope that other Python/Django developers will pick it up and add new features. I had never really anticipated that anyone other than myself would see the code, so it is lacking in comments and documentations, but there are some nice features that may be of interest. For instance, there's a system to expose a REST API that factors out a lot of Python bioler-plate code and corresponding javascript code exposes the desktop functionality to the browser. There's also a pretty powerful caching system that makes rendering a desktop blindingly fast. I may have gone overboard with that, given my traffic rates. But I guess it is best to have more capacity than you need. If you want to look through the code or fork the project, it is available on Github: … -
Spatial Bookmarking Service goes Open Source
Locidesktop was my coffee shop coding project of last year. I was quite pleased with the results. Locidesktop.com has been happily serving link desktops to some loyal visitors for months now – with no maintenance required on my part (a good thing because I've been busy with other projects). Rather than let the project stagnate while I do other things, I have released it as open source with the hope that other Python/Django developers will pick it up and add new features. I had never really anticipated that anyone other than myself would see the code, so it is lacking in comments and documentations, but there are some nice features that may be of interest. For instance, there's a system to expose a REST API that factors out a lot of Python bioler-plate code and corresponding javascript code exposes the desktop functionality to the browser. There's also a pretty powerful caching system that makes rendering a desktop blindingly fast. I may have gone overboard with that, given my traffic rates. But I guess it is best to have more capacity than you need. If you want to look through the code or fork the project, it is available on Github: … -
Spatial Bookmarking Service goes Open Source
Locidesktop was my coffee shop coding project of last year. I was quite pleased with the results. Locidesktop.com has been happily serving link desktops to some loyal visitors for months now – with no maintenance required on my part (a good thing because I've been busy with other projects). Rather than let the project stagnate while I do other things, I have released it as open source with the hope that other Python/Django developers will pick it up and add new features. I had never really anticipated that anyone other than myself would see the code, so it is lacking in comments and documentations, but there are some nice features that may be of interest. For instance, there's a system to expose a REST API that factors out a lot of Python bioler-plate code and corresponding javascript code exposes the desktop functionality to the browser. There's also a pretty powerful caching system that makes rendering a desktop blindingly fast. I may have gone overboard with that, given my traffic rates. But I guess it is best to have more capacity than you need. If you want to look through the code or fork the project, it is available on Github: … -
Stupid Template Languages
For years I've been absolutely certain that I really prefer stupid template languages any time I'm generating HTML. The less the template language can do the better. Since I spend most of my time coding in Python you might assume this applies just to Python, but I think it also applies to anything where you have the power to readily mix HTML generation and code.The biggest annoyance I have with smart template languages (Mako, Genshi, Jinja2, PHP, Perl, ColdFusion, etc) is that you have the capability to mix core business logic with your end views, hence violating the rules of Model-View-Controller architecture. While the web can be hard to match to MVC, in general you aren't supposed to do that sort of thing. I've made the mistake of putting core logic in the wrong places in the past, but I'm proud to say I've gotten good at avoiding that particular mistake.I don't work in a vacuum.I often work on projects crafted by others, some who decided for arcane/brilliant/idiotic reasons to mix the kernel of their applications in template function/macros. This is only possible in Smart Template Languages! If they were using a Stupid Template Language they would have been forced put their kernel code in … -
LinkShare Pixel Tracking template tag for usage with Satchmo
I've implemented LinkShare Pixel Tracking for Satchmo-based stores — Django Snippet #2314. Very simple template tag which use info from current order and generate Pixel Tracking image link. -
Django forms ChoiceField and custom HTML output…
… or what to do in case that you need a special design for your choice fields The problem: Few posts ago I talked(wrote) about Django forms ChoiceField and with dynamic values and now it is time to take a look at the front end and how we display these values to the user. I [...]
