- Recent
- Popular
- Tags (0)
- Subscribers (5)
- "Syntactic Sugar"November 22
-
It frustrates me when I hear people dismiss the differences between computer languages. There really isn't any difference between languages, the argument goes, because "all Turing complete language differ solely on syntactic sugar."
That's a direct quote from part twelve of Michele Simionato's excellent The Adventures of a Pythonista in Schemeland, but I've got no beef with his articles. Like I say, they've been an excellent introduction to Scheme for me. However, I've seen this particular assertion -- "all programming languages are the same because they're all Turing complete" -- used repeatedly as long as I've been a programmer. It drives me nuts.
Sure, it's true on a technical level. Any computer language we write gets interpreted and compiled down to machine code, so at a practical level a C program with a for(;;) loop and a Python list comprehension might end up with the same values flowing over my registers and the same instructions dropping into the CPU. But this reductionist view of programming completely ignores the incredibly important role that language plays in thought.
The traditional view of languages -- human or computer -- is that they're a tool we use to express thought. But modern literary and linguistic theory holds that it's a two way street: our thought drives our language, but the language
- Typography: Rhythm & ProportionNovember 21
-
Horizontal motion
Anything from 45 to 75 characters is widely regarded as a satisfactory length of line for a single-column page […] The 66-character line […] is widely regarded as ideal (25).
Sabon at 16px has an alphabet length of 203 pixels, or approximately 152 points. To figure out the horizontal measure, I started with Bringhurst's copyfitting table (29), which suggests a line length of 26-28 picas (around 450 pixels) for an optimal 66-character line. I was aiming for multiples of 32px across, so I tried 448px. This looked narrow to my eye, and sure enough it yields (in my prose) an average line length of around 61 characters. I tried 512px next — a nice number for us binary-thinking folk — and that hit the nail on the head at about a 68 character line.
To my eye this still looks very narrow, but I do find it exceptionally nice to read even long blocks of text. I have a bad habit of spurious paragraph breaks when I'm writing something I know will be read digitally; perhaps that bad habit stems from the relatively wide 80-line text editor standard. With luck this narrower column will help me break paragraphs more naturally.
- MinimalismNovember 18
-
I've been working on redoing my website for at least the last year or so... and finally got it done.
I drew obvious inspiration from the minimalism trend (c.f. Bennett, Tomayko, Pilgrim); the simplicity of those sites are quite refreshing. As I was putting the finishing touches on the site, I ran across a roundup of minimalist designs that I think does a great job summing up my attraction to minimalist designs, the article's first three points describe perfectly what I'm trying to do here:
1. Design is focused on the content.
2. Whitespace is the king...
3. Typography is the queen
I actually spent most of my "design" time focused on typography; The Elements of Typographic Style was my bible as I worked on the CSS. I feel pretty happy with the results, and that makes sense: I don't have a iota of design chops, but I can handle the math of page layout and spacing pretty well.
Those using a cutting-edge browser (the latest Safari, or one of the Firefox 3.1 betas) should notice that I took the typography thing pretty far: I'm using CSS3's Web Fonts to include a font that's actually nice lookin
- REST worst practicesNovember 14
-
A few weeks ago, I sent the following in a email to a co-worker asking for input on designing REST APIs in Django. Since then, I've quoted myself a few times; I thought these thoughts would be worth a (slightly edited) public home.
I think the best way to dive in terms of mistakes to avoid. If you poke around you'll find a couple-three different stabs at writing a generic REST API module for Django.
So, with no further ado, some REST "worst practices:"
Conflating models and resources
In the REST world, the resource is key, and it's really tempting to simply look at a Django model and make a direct link between resources and models -- one model, one resource. This fails, though, as soon as you need to provide any sort of aggregated resource, and it really fails with highly denormalized models. Think about a Superhero model: a single GET /heros/superman/ ought to return all his vital stats along with a list of related Power objects, a list of his related Friend objects, etc. So the data associated with a resource might actually come out of a bunch of models. Think select_related(), except arbitrary.
I'd solve this in a similar manner to the way forms work in Django: there's a basic Form, and then a ModelForm; I'd have a Resource and a ModelResource.
- PyCon BraindumpMarch 19
-
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.
You can nest {% regroup %}:
{% regroup issues|dictsort:"client" by client as client_groups %} {% for client_group in client_groups %} <h2>{{ client_group.grouper.name }}</h2> {% regroup client_group.list|dictsort:"category" by category as category_groups %} {% for category_group in category_groups %} <h3>{{ category_group.grouper.name }}</h3> <ul> {% for issue in category_group.list %} <li>{{ issue }}</li> {% endfor %} </ul> {% endfor %} {%