Now that 1.0 is out the door, the Django team has put together a release process document. Looks good to me. Visit site »
E-Flo is at it again with a pair of really, really good screencasts that take you through setting up a Django project from the very beginning. He is building a real live site (a sort of Twitter clone with a twist), walking you through it from step one (you can also download then entire source of the site). The first two episodes cover getting your source control environment set up, getting Django’s settings.py file all configured, and then creating the models. Really, really good stuff here, if you’re looking to learn Django. Visit site »
The good news about this post is that all of the reasons mentioned are either a distaste for bits you can swap out for your favorite (ORM, template language), or things that are planned for Django 1.1 (aggregate support). Well, except for the guy who complained that Django doesn’t allow him to make very much money, since he charges by the hour. :)
A really smart post on the “unsemantic” nature of CSS frameworks that deal with layout, by Darren Jones, who created the Sparkl framework. The best line in the article is this:
Remember [layout class names] don’t add any semantic value, but your page doesn’t lose any semantics by having them either.
This is the point I wish people would remember. Class names aren’t actual semantics, they’re fake semantics. They’re just a way for you to add some useful hooks for scripts and styles to hang on (and possibly for other people to mash with, in the case of something like microformats). Validators, screen readers, browsers, and the like couldn’t give one iota of a damn what your class names are. Likewise, is it really worth getting bent out of shape about too many div and span elements? Remember, these elements were specifically designed to have no meaning. It doesn’t matter if there is one div or five hundred, the net gain is no meaning.
Sure, it makes sense to use less presentational class names whenever you can and to only use as many divs as you need to, but if the aesthetics of your fake semantics and counting div elements starts to overtake getting your design just right, on time and under budget, then I'd say your priorities are out of whack. Visit site »
Probably the single most relevant DjangoCon talk for most Djano developers, this fireside chat with Adrian and Jacob really covers the bases on where the framework will go in the future. As a sidenote, it also is a nice showcase of Jacob and Adrian’s personalities: they’re both really, genuine nice guys who are bright as hell but not at all opposed to criticism or other views (traits, which, in my view, have permeated the entire Django community). I’ve had my arguments with both dudes, but in the end, I love ‘em both. Great guys. Visit site »
I’m quite interested in Cappuccino and Objective-J. Too bad it seems the documentation sucks right now. Visit site »
Now this is interesting: a web “framework” written in Python, released today. Apparently you can use it to develop web sites more quickly and efficiently. I hear it even makes programming “fun.” It’s great to see new projects still coming out on this front.
Oh, what’s that you say? Django’s been available for three years and used in production on major news sites even longer than that? Weird. You would think it would be at 5.0, by now. :)
Seriously — congrats to everyone involved. I’ve been keeping up with the latest revisions, and I know this: the Django I fell in love with a coupe years ago is a total piece of shit compared to 1.0. Visit site »
Comprehensive guide to porting Django .96 apps to Django 1.0. Short version? You’re going to be doing a lot of boring, tedious work. Have fun. Visit site »
Great example of how badass the Django signals framework is. Basically, it lets you inject code upon some event happening, such as an object being saved, deleted, or in this case, a comment being posted. I use signals throughout Savoy, such as to geolocate an object as its saved, and to add a tumblelog object when particular types of content are saved. It’s good stuff. This example also uses Django’s brand-spanking new comments framework. Visit site »
Again from Jeremy’s great live blogging of An Event Apart San Francisco, here’s Eric on CSS frameworks. I’m glad to see someone else broaching this topic, and in general it looks like Eric did a great job of rounding ‘em up. A few bits and responses:
If you’re going to use a framework, it should be yours; one that you’ve created. You can look at existing frameworks for ideas and hack at it. But the professionals in this room are not well served by picking up a framework and using it as-is.
Generally speaking, I agree. I have made great use of Blueprint — but it’s worth nothing that almost all of the basic concepts were created by me (along with Nathan and Christian). As Blueprint has progressed, it’s gotten farther and farther away from what we created, and I’ve been less enthralled by it. The point is: something you created yourself is always going to be more useful to you than something you didn’t.
Four of them use psuedo-namespaced class names beginning with grid- or container- or span- (which you would apply to a div!?).
I’m not sure if the parenthetical is Jeremy or Eric speaking, but this is also worth noting: in the original CSS framework Nathan, Christian, and I created, you were not necessarily supposed to apply those classes to a div. The classes were for any element, and there was no encouragement to liter your markup with extraneous div elements. The original Blueprint retained this philosophy, but later changed it, asking people to always use div elements as columns. I find this to be incredibly wrong, and I always override this Blueprint functionality when I use the framework. If you are going to use a div for every layout column/row/unit/whatever, you may as well just use tables. I hope everyone knows and understands that when I was touting Blueprint, it was before the made the boneheaded decision to require the use of a div element for every column. Visit site »
I’ll be damned if it doesn’t seem like this whole Django 1.0 thing might actually happen. Be sure to read the release notes — there are several backwards incompatible changes (which are annoying, but it’s way better to get them out of the way before 1.0 than after it). Visit site »
GeoDjango is so far over my head that it doesn’t meant much to be, but I hear it’s awesome news, so I figured I’d link it up. :) Visit site »
I found this great writeup of Django’s signals on Twitter today. Signals are an incredibly useful tool in Django, and one that is way under-utilized. I used them a lot back when I wrote the second version of lost-theories.com, and I use them a little bit in the Savoy content publishing framework I’ve written at Blue Flavor. I especially make great use of the pre and post save, and pre and post delete signals. Check ‘em out. Visit site »
Yet another front-end web framework, consisting largely of CSS (but this one also has some JavaScript). I haven’t really looked into it yet, so I can’t really comment on it.
For my tastes, I’ve yet to see the “perfect CSS framework,” (Blueprint’s first release was the closest — since then, it’s moved away from many of my preferences), but I’m really happy to see the concept taking off, since I wrote about it in A List Apart. Despite some negativity from other prominent members of the web standards community, I still really believe in the ideas of code re-use and standardization amongst teams on things like class names and markup conventions.
It still baffles me that some of the same people who go on and on about microformats don’t want to see standardization in class name for other things. Weird. Visit site »
I’m not entirely convinced that Django’s recent popularity has much to do with web standards, nor am I that convinced that Django is “winning” in our community over Rails or other modern frameworks — but, it’s true that Django allows those of us who value web standards to do our thing quite easily, and it’s good to hear that people are noticing that. Visit site »
Nathan Smith talks about the 960 Grid System CSS “framework” (I say in quotes, since that word seems divisive when applied to CSS) he recently released. It all looks very impressive to me, and I’m quite tempted to use it over Blueprint. Blueprint has changed several things since the work Nathan, Christian, and I did at the Lawrence Journal-World, and much of it is not necessarily to my liking (that’s not to say it’s bad — just not now I want it). Nathan’s 960 is a bit closer to what I want, grid-wise (and is a bit lighter weight, as it doesn’t really bother with typography). I’ll definitely be giving it a closer look in the near future. Visit site »
The awesome Nathan Smith has released a CSS framework for grids. It’s very similar to Blueprint, but uses some different naming conventions and a 12 or 16 column default grid, instead of Blueprint’s 24 columns. Looks very useful. Nice work! Visit site »