Programming is fun. I love programming! Ever since I changed my career from programming to database work, I’ve still occasionally dabbled in my former craft. As such, I believe I can say this with a fair amount of accuracy: programmers don’t understand databases. This isn’t something small, either; there’s a fundamental misunderstanding at play. Unless the coder happens to work primarily with graphics, bulk set-based transformations are not something they’ll generally work with.
Well, maybe I spoke too soon about Drupal. Why? Well… it’s 2010 guys, stop with the ID links. I know there’s a plugin that overcomes this shortcoming, but all the internal links, including edits, redirects, and so on, won’t use the aliases you define. No, foo.bar.com/node/123423 is not a valid url. It requires approximately ten minutes to add a table column for a ‘slug’ to look up the appropriate entry, but Drupal refuses to compromise.
A while ago, I decided to use Pylons to rebuild my site. I even went so far as to name the engine “BonePyl”, which just narrowly edged out “BonesAW” for “Bones’ Awesome Weblog”. While doing this, I’ve obviously had to orient myself with the API, which meant buying The Definitive Guide to Pylons and copious scouring of the web for secondary documentation on SQL Alchemy and FormEncode. It’s a lot to bite off, and I’m having trouble chewing, but considering my current site is a bunch of PHP I threw together back in 1999, I’m obviously in no hurry.
There’s a lot of debate in application development circles over various sundries such as column naming schemes and framework implementation details. Well, I’d like to clear all that up.
See, there are more application frameworks than grains of sand on the entire planet Earth, and each one of them has a different philosophy and API for creating database objects. Rails, Django, Turbogears, Zope, Zoop, Drupal, Catalyst, Nitro, Nuke… holy fucking Christ, stop it already!
