Archive for March, 2008

Django and Rails

Monday, March 31st, 2008

I’ve been using Django to build my latest scratch-an-itch project, and had been thinking about writing up a comparison of Django and Rails.

Ben Askins and Alan Green saved me the trouble.

Their presentation (which requires the latest Flash plugin) is a decent, balanced summary of the similarities and differences between the two frameworks. It’s 100 pages, but is paced for speed (and it’s a fine model for how to do compare/contrast presentations).

The only bit I’d add is that Django favors parallel development to a greater extent than Rails. With Django, you get to a clean separation between code and templates sooner, so that UI designers can be working on presentation while coding continues. And Django’s out-of-the-box admin interface supports lets people start doing data entry pretty much as soon as you’ve built your data models. Django doesn’t yet have migrations, though, so there’s more emphasis on getting your data model right up front.

Maybe one more bit: Rails has built-in support for AJAX and visual-effects, with several books that cover that support in depth. Django is JavaScript toolkit neutral, shiping with no built-in toolkit support (or no lock-in, if you want to think of it that way). For a sizeable project, I doubt this will be an issue, but for smaller projects this can give Rails an advantage.

If you’ve already chosen one of these frameworks, it may be worth your time to check out the other. There are good ideas in both.

Posted in Recommendations, Technical Stuff | No Comments »

Ajax Security

Tuesday, March 18th, 2008

A security podcast I listened to during today’s commute caused part of my anatomy to retract in between a few chuckles. In Technometria: Ajax Security, Phil Windley, past CTO of the state of Utah, interviews Billy Hoffman, co-author of Ajax Security, on the subject of Web 2.0 security. In a presentation that avoided the usual doom, gloom, and “buy my services” approach, Billy detailed several exploits, both white- and black-hat; some funny, and a few that weren’t. Among the “how could developers be so stupid” exploits (hint: don’t write your own encryption algorithms) were a few that now have me double-checking code that I was fairly convinced was secure.

If you’re deploying Web-2.0ish stuff, even if it’s only using Flash on the client side, this one may be worth a listen.

Posted in Recommendations, Technical Stuff | No Comments »

Bit in the ass by a typo

Sunday, March 16th, 2008

One of my common typos bit me in the ass tonight.

As part of a fiendish plan to learn new technologies by actually building stuff with them instead of just reading about building stuff with them, I’d set myself the weekend goal of putting up an internet-facing Django application using lighthttpd and FastCGI instead of the usual (and recommended) Apache/mod_python combination. I’d tried out FastCGI once with Rails, and was using lighthttpd elsewhere to serve up static content, but had never used them together. (And to mix things up some more, SQLite3 instead of MySQL on the back end, but that’s not part of tonight’s problem.)

Two hours in, after an install hiccup and a few minor problems, “hello world” was working. A short time later, simple dynamic content (from a single table) was being served up. Except the Django admin interface didn’t quite look right. It wasn’t getting styled. Firebug confirmed that the HTML looked O.K., but firebug wasn’t seeing any CSS. Typing in the relative URL of the admin style sheet got me to the style sheet, so the path through FastCGI wasn’t the problem. But the page wasn’t getting styled. WTF!?! Clearing the browser cache didn’t help, nor did restarting firefox. Uh… Uh…

In the middle of asking for help on the #django IRC channel, I spotted the problem.

While fleshing out lighthttpd.conf, I’d speculatively added some missing mime types. If I’d been pair programming, my pair might have asked “are you sure you need to do that yet?” and I’d have had to agree ‘no’, and would now be writing about something else. Instead, with nobody there to stop me, I’d added 

  ".js" => "application/x-javascript",
  ".css" => "test/css",

and the door down the rabbit hole was opened.

Do you see the problem? I didn’t, even after staring at it a half-dozen times, because I know what I’d meant to type. But what I’d actually typed was 

  ".css" => "test/css",

which caused style sheets to be served up with an almost correct mime type. The sad thing is that I’ve made this typo before in similar contexts. It may be that too much testing has warped my muscle memory.

Posted in Technical Stuff | No Comments »

A less obvious benefit of Iterations

Thursday, March 13th, 2008

In Tiny projects keep it new, Jason Fried of 37 Signals talks about the cycle of waning interest as long projects lumber on (”No one likes being stuck on a project that never seems to end”), and the power of small projects to keep motivation up by presenting frequent fresh starts.

On the surface, this is one of the benefits of the Agile practice of breaking work into iterations/sprints/episodes. Every few weeks, the team gets a start fresh. Now this isn’t quite true, as many who have been on Agile projects for more than a year will tell you: Runs of iterations with similar themes can get monotonous. Still, the cadence of doing work in discrete iterations, and the frequent customer feedback this enables, can help team members stay engaged for much longer than they might on a long waterfall project. And iterations provide natural stopping points for rotating developers between teams, which keeps things fresh by spreading knowledge around.

Iterations have another, less obvious, benefit: They reduce the opportunity for people to get dangerously ahead of the rest of the team by latching on to interesting technical bits that appear somewhere out ahead on the project roadmap. I’ve seen this happen over and over in long waterfall projects. Someone sees a technical challenge that will have to be solved eventually, rationalizes that starting on it now will “reduce risk”, and then pours time, effort, love, and raw ego into the problem, making architectural decisions that the rest of the team comes to feel constrained by and resentful of later. And if the project makes a mid-course adjustment, the “risk reducing” cherry-picked work can end up being expensive waste.

Posted in Agile, Management | No Comments »