Tag: Django
Why you should run for the DSF Board, and my goals for the DSF in 2025
If we had $1,000,000…
Talking about Django's history and future on Django Chat
TIL: Django Model Fields With Attributes
I wanted to make a model field where the underlying data is a string, but the field on model instances exposes more attributes. Specifically, a MarkdownField:
class Document(models.Model):
text = MarkdownField()
that exposes a way to get at its content as both HTML and source Markdown:
>>> doc = Document(text="hello, *world*")
>>> doc.text
"hello, *world*"
>>> doc.text.html
"hello, <strong>world</strong>"
This is not too uncommon in Django-land – for example, Django’s built-in FileFields work this way. Surprisingly, the pattern for accomplishing this doesn’t seem to be documented anywhere (that I can find), so here we go.
Volunteer Responsibility Amnesty Day
Articles for r2c: Not all attacks are equal: understanding and preventing DoS in web applications
Articles for r2c: Preventing SQL Injection in Django
Django's new governance model
Starting today, Django has a new governance model. Previously, a small “core team” made most decisions, including electing a Technical Board to own decisions about each release. Now, the “core team” is gone; all power rests with the Technical Board. Anyone who’s made substantial contributions to Django is now eligible to run, and the board is now elected by the DSF Membership at large. You can read more about the change in today’s announcement, and if you want to full details they’re in DEP 10.
Django Under the Hood 2016 Highlights
Videos from Django Under the Hood 2016 are up - check ’em out! As usual, the conference was amazing and the content was fantastic. I really enjoyed all the talks, and they’re all worth your time to talk. Three in particular stood out to me as exceptional highlights:
Ana’s talk on Testing in Django is the single best talk on effective testing of Django apps I’ve ever seen. I really like her technique of explaining Django’s testing APIs by looking at how they changed over time: it does a great job of explaining what problems particular APIs solve, and why you’d use them. Most testing talks don’t do a great job talking about use cases; Ana’s breaks the mold.
So you want a new admin?
Django’s admin site is about 12 years old. It started circa early 2004 as an internal CMS at the Lawrence Journal-World, was released as part of Django in 2005, and has been chugging away ever since. There’s been some substantial re-writes along the way – magic-removal, new forms, the flat theme – but for the most part the admin’s stayed pretty much the same for that entire time. The interface, functionality, and CRUD-oriented workflow haven’t really changed since those early years at the Journal-World.
Retiring as BDFLs
Adrian broke the news: today, he and I are retiring as BDFLs, transitioning to a truly community-run project.
Adrian wrote a bit about the history of the BDFL term and our roles wearing that hat. Go check out his writing for that, and for some of his personal thoughts. Here, I’ll just add a few things of my own:
For me, this has been a long time coming – I’ve been thinking about this for at least a year. In many ways, I this is a similar to a lot of the changes we’ve made over the years: it’s a formalization, and a naming, of what’s already happened. It’s clear to me I don’t have the sort of day-to-day involvement that I once had, and I can’t remember the last time I’ve had to make the sort of dictatorial decisions that the title implies.
Getting features into Django
Getting new features into Django isn’t easy. It’s that way for a reason — I spoke recently about why conservatism is a virtue — but it does happen. I’d like to do a better job explaining how we decide what goes in and what goes out, so here’s a lightly adapted version of something I posted on the mailing list this evening. It’s three things I look for when I’m trying to determine whether something is “right” for Django or not:
Measuring the Django Community: The Django community in 2012
In 2007, and again in 2009, I made an attempt to measure the size of the Django community. By popular request — okay, a couple people asked for it, whatever — let’s do this thing again.
Users
In 2007 and 2009, I shared three ways of looking at how many people are using Django: hits to the website, downloads of the Django tarball, and sites listed as “using Django.”
So, here’s an overview of users, some notes on interpreting these numbers follow:
Is there a market for paid Django apps?
Here’s a thought that’s been rummaging around in my brain for some time now: is there a market for commercial, closed-source Django apps?
Suppose someone released a high-quality, well-documented, well-supported Django app… under a commercial license. Assume of course that this app does something you actually need, and that the commercial license isn’t odious. Would you pay for a Django app?
I think I would. I have no qualms about paying for good software: in the last month I bought some backup software (Arq), started using a commercial ticket tracker (Pivotal) and time tracker (Freckle). In all cases, free/libre alternatives existed, but the paid versions were easier, slicker, faster, or in some sense “better.” Enough so that they justified their prices (to me). I think if Haystack (to pick an arbitrary example) was commercial (and reasonably priced) I’d pay for it — the time required to build an alternative would almost certainly cost me more.
Django classes: deployment, ecosystem
(Cross-posted from the Revsys blog; I think folks here might be interested, too.)
Next month I’ll be teaching two new one-day classes, both of which evolved from common questions we get at Revsys. Each class is going to be offered twice, once in LA and once in Boston.
For the impatient here are some links and quick info:
- Django Deployment Workshop - Los Angeles - December 6, 2010.
- Django Deployment Workshop - Boston - December 10, 2010.
- The Best of the Django Ecosystem - Los Angeles - December 7, 2010.
- The Best of the Django Ecosystem - Boston - December 9, 2010.
For more details on each class, read on…
Django gotcha: concrete inheritance
Since 1.0, Django’s supported model inheritance. It’s a neat feature, and can go a long way towards increasing flexibility in your modeling options.
However, model inheritance also offers a really excellent opportunity to shoot yourself in the foot: concrete (multi-table) inheritance. If you’re using concrete inheritance, Django creates implicit joins back to the parent table on nearly every query. This can completely devastate your database’s performance.
To refresh, if you’ve got models like:
What's your favorite Django app?
On Twitter, I asked, “what’s your favorite third-party Django app?” Eight hours later, I’ve got about 50 replies.
I meant the question to be fairly open-ended – I deliberately didn’t clarify what I meant by “favorite” – and I’m not that popular, so this is by no means an accurate sample of the Django community. Still, the answers are a bit interesting, so let’s take a look:
The winners
The favorite was… (drumroll please)… South. By a landslide, actually: about a third of the folks who responded chose South. I’m not particularly surprised: schema migration is a problem most users face, and Django doesn’t have anything in core to handle it. But that’s another show.
util
D’oh:
django/contrib/admin/util.py
django/contrib/admindocs/utils.py
django/contrib/comments/views/utils.py
django/contrib/formtools/utils.py
django/contrib/gis/db/backends/util.py
django/contrib/gis/tests/utils.py
django/contrib/localflavor/it/util.py
django/contrib/localflavor/se/utils.py
django/contrib/localflavor/uy/util.py
django/contrib/messages/utils.py
django/core/files/utils.py
django/core/mail/utils.py
django/db/backends/util.py
django/db/utils.py
django/forms/util.py
django/http/utils.py
django/test/utils.py
tests/regressiontests/forms/util.py
Dynamic form generation
I had the pleasure of being on a forms panel at PyCon 2010 chaired by Brandon Craig Rhodes. To get a stable baseline, Brandon asked each of us to provide code showing how each forms toolkit might tackle a problem:
Imagine that someone has already written a form with your forms library. The form looks something like this:
New username: __________ Password: __________ Repeat password: __________ [Submit]
Now, someone from Marketing comes along and announces that the developers must add some additional questions to the form - and the number of extra questions is not determined until runtime! They give you a
get_questions(request)
function that looks up a profile they cook up for each person browsing the site, and returns a list of strings like one of these:
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.
Measuring the Django Community: The Django community in 2009
In March of 2007, I attempted to measure the size of Django’s community. That March turned out to be a major inflection point in Django’s growth: the release of 0.96 brought a lot of new features – testing and the new forms library being the critical ones – and those in turn brought in a lot of new users. Growth since then has been at a much faster pace.
So I thought it’d be interesting to review the same metrics I used back then. I was quite curious to see what’s changed, and by how much.
Thank you, Rails
It’s fashionable, or perhaps inevitable, for tech communities to trash their competition. The Emacs folks like to mock vi users; Windows folk look down on us Mac users (and Linux users mock us both); and everyone likes to mock PHP despite PHP’s dominance in the web world. We geeks make arguing over minor technical points into a kind of art.
This is all pretty understandable: it’s easy to define community in terms of what we’re not. A common enemy focuses and drives us. Competition can take a positive form: when it’s friendly and constructive both communities benefit.
Django Master Class, October 16
I’m pleased to announce that I’m teaming up with Steve Holden and Holden Web to teach a one-day Django Master Class. The class’ll be in Washington, DC on October 16th, 2009. I’ll be covering a grab-bag of advanced Django tricks, including AJAX, REST, schema migration, testing, caching, code quality, and more. Hopefully there’ll be something there for everything.
For more info or to sign up, head on over to Holden Web
Reminder: Django Training
A quick reminder: if you’re thinking of coming to me week-long Django course in Kansas City next month, today’s the last day to sign up at early-bird pricing. The price goes up by $500 tomorrow.
It’s shaping up to be a blast – why not join us?
Django Training
I’m pleased to announce that I’ll be teaching a week-long introductory Django course in Kansas City, September 21st - 25th.
Teaching’s folks how to use Django is one of my favorite things to do – in fact, I’m in San Jose right now gearing up for a tutorial at OSCON tomorrow – so it seemed a natural thing to make it an aspect of my business.
So, if you need to learn Django, why not come spend a week in Kansas City with me? It’ll be a blast.
Django internals: authentication
Django’s session and authentication frameworks are designed to Just Work™, and can seem pretty magical. Like the rest of Django, though, these parts aren’t magic — just Python. So let’s take a look at the internals of sessions and authentication and see how the whole thing works.
Our journey begins with the session
middleware.
You’ll see that the process_request
method
is pretty simple: it looks up the session engine
setting,
looks for a session key in the request’s cookies, and then sets
request.session
to a SessionStore
instance.
Looking for a Django developer?
Need an experienced Python/Django developer?
A good friend of mine is looking for a new gig. He’s employed currently and wants to keep his search on the D/L, so I’m putting the word out on his behalf. I can vouch for this mysterious individual: I’d hire him myself in a heartbeat if I could. He’s got years of Django and Python experience, and a killer work ethic.
So if you’ve got a space on your team and would like to fill it with
someone awesome let me know (jacob @ this domain
) and I’ll put you two
in touch.
Developing Django apps with zc.buildout
Developing a Django app with zc.buildout
Over the weekend I put together django-shorturls, the latest in a series of small plugable Django apps I’ve written.
This time, though, I used zc.buildout and djangorecipe to build, test, package, and distribute the app, and (with the exception of a few annoyances) it’s an exceedingly civilized way to develop an app.
In the interest of helping improve Buildout’s still-nascent documentation, I documented my steps along the way.
What is django.contrib?
Since it comes up a lot, I thought I’d spend a bit of time writing up my
thoughts on what django.contrib
really is, and what including a
package in it really means.
The following is just my personal opinion – really; that’s why this is posted here instead of over in the official Django documentation. However, most of the core team discussed this topic at length at DjangoCon, so I’m fairly sure there’s consensus over the rough outline.
PyCon Braindump
PyCon 2008 Brain Dump
There are some great roundups of the content at PyCon out there; this isn’t one of them. See, I have this notebook (Moleskine FTW!) I carry with me everywhere, and now it’s chock-full of note from PyCon; this is a braindump.
Django 1.0 will support Python 2.3, but later releases likely will not. We’ll need to start working on moving to Python 3.0, and that means slowly dropping other Python versions until we reach 2.6 and can start using 2to3.
Sailing on…
Almost four years ago, Adrian posted about a job opening at this little newspaper in the middle of the country. He wrote that
World Online is […] one of the most innovative online-news operations in the world. Our main sites […] have garnered an impressive batch of industry awards – and tremendous industry attention – over the past few years.
[…]
We strive for innovation, nimble development and the use of best practices. We have a near-religious focus on doing things the right way – clean URLs, CSS, separation of content from presentation, accessibility, solid application design, etc.
A picture is worth a thousand words
Arc only supports Ascii. MzScheme, which the current version of Arc compiles to, has some more advanced plan for dealing with characters. But it would probably have taken me a couple days to figure out how to interact with it, and I don’t want to spend even one day dealing with character sets. Character sets are a black hole. I realize that supporting only Ascii is uninternational to a point that’s almost offensive […] But the kind of people who would be offended by that wouldn’t like Arc anyway.”
Django Book Update
A quick update on the Django Book:
Adrian and I wrapped up the last few bits last week, and the book went to the printer on Friday. It should start shipping to bookstores around the second week of December. There’s still a fair amount of work that needs to be done on the website, so I can’t put the final version of the book up just yet. However, the final book will be available online around the same time as the dead tree version.
Django projects
I’ve always thought that the sign of a healthy Open Source project is a vibrant ecosystem around that project. That’s why I’ve been thrilled to see that there are a bunch of cool third-party Django add-ons popping up. I thought I’d take a few minutes and give a shout out to some of my favorites.
django-openid
OpenID evangelist and Alpha Geek Extraordinare Simon Willison wrote this set of tools which lets your Django application become an OpenID consumer.
Django Internships at the Journal-World
I’m extremely excited to announce our new internship program here in Lawrence. Starting this summer we’re going to be hiring interns to join our kick-ass team and learn the ropes.
If you’re a student, or if you’re trying to break into the world of next-generation web development, I can’t think of a better place to get started. You’ll get to spend up to six months developing cool toys (in Django, of course), live in one of the coolest towns in the country, and learn web development from the best.
Measuring the Django Community: Circles of Django (2007)
So here’s a question I get asked a lot: “How big is Django’s community?”
Anyone who works in open source knows that it’s basically impossible to know the size of any open source community. It’s easy with commercial programs – just look at the sales numbers – but since F/OSS is freely (and widely) available, there’s almost no way to know how many people are using your project.
Still, the tie-wearing enterprisy business folks ask these types of questions, and it’s useful to have an answer ready. What follows is a slightly adapted version of my standard answer.
Pronouncement
So it seems the BDFL Pronounced that Django is the Python web framework.
Obviously this makes me pretty damn happy. I’m sure this will help people trying to choose a web framework come to Django, and I think they’ll like what they find. Personally, I think Django’s the best tool to develop web sites – but of course I think that.
However, I want to make sure everyone has read Kevin Dangoor’s thoughts on the announcement. Kevin’s an awesome guy, a great programmer, and although I disagree with a few details here and there [1], the general gist is spot on.
"Show-stoppers"
Lately a large number of questions posted to django-users have included phrases like “this is a show-stopper” or “this is critical”. I think it’s worth my time to point out that this is a lousy method of getting developers to do what you want. It’s the online equivalent of threatening to take your ball and go home, and is about as effective.
I understand the impulse perfectly: there’s the fear that we won’t take you seriously if you don’t tell us just how important this is.
Digg dugg
My last entry about my dog eating my DSlite hit Digg (screenshot), Reddit (screenshot), and a couple of other big-traffic sites over the weekend.
Pretty cool, but the coolest part is that my server — a single commodity Linux box that cost less than $3,000, running about 15 other sites — didn’t even hiccup.
Reason #4453 to use Django? It’s fast. Crazy fast.
Oh, and to all the Diggers who suggested that I should kill my dog? Fuck you and the horse you rode in on.
Improved text image view
I just found this in my django-ego-feed: 23 excuses: Simple Django View for Dynamic Text Replacement
I’ve been using something similar to generate the titles for the site (look at the title above for an example), so I’m pretty familiar with the technique.
Andrew’s code over there is pretty good, but I’ve got a few improvements he and you might be interested in:
The business to writing to a temp file is ugly and will break as soon as you get two simultaneous requests. The right way to do this is by remembering that an
HTTPResponse
exposes a file-like interface, so you can write the image directly to it:
Django OSCON shirts
I’m about to print up some Django shirts to take to OSCON next month – got any ideas?
We gotta move pretty fast (we’re going to try to get an order in to the printer this week) so if you’ve got any hot ideas (or designs, for that matter) send ’em to me!
I’ll mail anyone who gives an idea or a design one of the final shirts, but otherwise please don’t ask about “ordering” or otherwise “getting” one. If there are any left after OSCON I’ll make an announcement then, but this are intended for OSCON promotions.
Django propaganda
Some Django propaganda:
Video killed the radio star
The talk I gave last week at Google is now up on Google Video. I covered similar ground to what Adrian talked about at Snakes and Rubies so if you haven’t seen that one, watch it, too.
Django for non-programmers
My friend and colleague Jeff Croft launched his new website built with Django. Jeff has followed it up the launch with an introduction to Django for non-programmers that’s required reading for anything thinking about switching to Django.
Django meetup in Palo Alto
Update
Ack – I mistyped the date on this page! The meetup will be Thursday, April 27th (not Wednesday as this originally said). Hopefully that still works for anyone planning to come…
Later this month, I’m speaking at the MySQL Users Conference in Santa Clara, and I’ll be in town the whole week.
I suspect there’s a good number of Django users living in the Bay Area (ha), and I’d like to meet as many of them as I can. Therefore, I propose that y’all let me buy you dinner. The details:
Merquery
Brian Beck just announced that he’s beginning work on Merquery, a full-text indexer and search engine specifically designed for developers using RAD frameworks like Django.
I’m so excited about this I can barely contain myself. Right now
Ellington ships with a search engine built
on top of Swish-E. It’s pretty cool, and I’ve
been debating cleaning it up and rolling it into django.contrib
.
However it has a number of major flaws that limit its usefulness:
Django stuff at Pycon
For anyone looking for the Django stuff I showed off at PyCon:
Template + Cache = Crazy Delicious
Here’s a simple class for a template tag that caches its output (with apologies to Chris Parnell and Andy Samberg):
from django.core import template
from django.core.cache import cache
from django.conf.settings import DEBUG
class CachedNode(template.Node):
"""
Cached template node.
Subclasses should define the methods
get_cache_key() and get_content() instead of the
standard render() method. Subclasses may also
define the class attribute cache_timeout to
override the default cache timeout of ten minutes.
"""
cache_timeout = 600
def render(self, context):
if DEBUG:
return self.get_content(context)
key = self.get_cache_key(context)
content = cache.get(key)
if not content:
content = self.get_content(context)
cache.set(key, content, self.cache_timeout)
return content
def get_cache_key(self, context):
raise NotImplementedError
def get_content(self, context):
raise NotImplementedError
Why you should use Django
Inspired by Guido van Rossum’s plea to be taught web frameworks here are (in no particular order) ten reasons why he — and you — should use Django.
1. Django works — right now
Don’t be fooled by the fact that Django’s first release was in July. It’s been under heavy use for over two years, and I’m confident saying it has no show-stopping bugs.
I’m tired of hearing that that SomeAwesomeFramework™ will be “great when it’s finished”. Django is finished, now — all the changes we’re making in the run up to 1.0 involve stabilizing APIs and improving the cleanliness of the internal code.
Done
Yes, the Snakes and Rubies videos are now online.
No, they’re not perfect.
No, I’m not going to wait for FCP to re-render any more.
I’ll write a post-mortem after I’ve gotten some sleep; now go watch Adrian kick major ass.
Django, meet Dojo
After hearing some rave reviews of Dojo on django-dev, I finally got around to checking it out today. Here are my thoughts (with an obvious focus towards) using Dojo with Django).
The good
Dojo is extremely powerful. With very little code I was able to make a really nice drag-and-drop reorderable table, complete with nice zebra striping and add/remove row buttons. (Wilson and I are working on a new kick-ass interface for Django’s “edit_inline” admin views, if anyone cares.)
Django performance tips
Django handles lots of traffic with ease; Django sites have survived slashdottings, farkings, and more. Here are some notes on how we tweak our servers to get that type of high performance.
Use a separate media server
Django deliberately doesn’t serve media for you, and it’s designed that way to save you from yourself. If you try to serve media from the same Apache instance that’s serving Django, you’re going to absolutely kill performance. Apache reuses processes between each request, so once a process caches all the code and libraries for Django, those stick around in memory. If you aren’t using that process to service a Django request, all the memory overhead is wasted.
What can Django learn from Rails?
One of the questions asked at Snakes & Rubies was about what Django could learn from Rails (and vice versa). Once I finish wrestling Final Cut Pro to the ground you’ll be able to see how Adrian and David answered the question, but in the meantime it got me thinking about some cool features of Rails that are worth ripping off… er… being inspired by:
find_or_create
convenience methods. Pretty simple, so expect to see a similar method in Django pretty soon.
Private Dancer?
As I was going over some notes on our internal wiki, I ran across a list of rejected names for the framework that become Django:
- brazos
- superglue
- bodhisattva
- webbing
- boidae
- bohdi
- skoro
- consolidata
- piston
- physique
- silhouette
- valance
- anson
- The Python Web Framework (PWF)
- Tornado Publishing System
- Web Type Framework
- Pypeline
- super magic machine
- magic machine
- private dancer
- “the CMS”
- The Give-a-Damn machine
- boltdozer
- banister
- garbonzo
- Simon
- fizgig
- palmy
- cogent
- pith
- pithy
- pyth
- pythy
- festoon
- poeks
- lavalier
- clerisy
- bandwidth
- django
Django and Rails
Sam Newman just posted a comparison of Django and Rails which is extremely balanced and fair, and a very good read. I’ve obviously got a few bits of feedback, so here goes:
Background
As a framework Rails has been around for little over a year, whereas as a framework in its own right django has only been public for around two months.
Actually, Django’s been in use internally for over two years, although we only got the buy-in from management to release it as open-source two months ago. So Django’s actually very stable and mature; a 1.0 release is more a matter of responding to community needs than fixing bugs.