Yes, this is yet another rant about how people incorrectly dismiss state-of-art databases. (Famous people have done it, why shouldn’t I?) It’s amazing how much the Web 2.0 crowd abhors relational databases. Some people have declared real SQL-based databases dead, while some have proclaimed them to be as not cool any more. Amazon’s SimpleDB, Google’s BigTable and Apache’s CouchDB are trendy, bloggable ideas that to be honest, are ideal for very specific, specialized scenarios. Most of the other use cases, and that comprises 95 out of a 100 web startups can do just fine with a memcached + Postgres setup, but there seems to be a constant attitude of “nooooo if we don’t write our code like google they will never buy us…!” that just doesn’t seem to go away, spreading like a malignant cancer throughout the web development community. The constant argument is “scaling to thousands of machines”, and “machines are cheap”. What about the argument “I just spent an entire day implementing the equivalent of a join and group by using my glorified key-value-pair library”? And what about the mantra “smaller code that does more”?

Jon Holland (who shares his name with the father of genetic algorithms) performs a simple analysis which points out a probable cause: People are just too stupid to properly use declarative query languages, and hence would rather roll their own reinvention of the data management wheel, congratulating themselves on having solved the “scaling” problem because their code is ten times simpler. It’s also a hundred times less useful, but that fact is quickly shoved under the rug.

It’s not that all Web-related / Open Source code is terrible. If you look at Drupal code, you’ll notice the amount of sane coding that goes on inside the system. JOINs used where needed, caching / throttling assumed as part of core, and the schema allows for flexibility to do fun stuff. (Not to say I don’t have a bone to pick with Drupal core devs; the whole “views” and “workflow” ideas are soon going to snowball into the reinvention of Postgres’s ADTs; all written in PHP running on top of a database layer abstracted Postgres setup.)

If Drupal can do this, why can’t everyone else? Dear Web 2.0, I have a humble request. Pick up the Cow book if you have access to a library, or attend a database course in your school. I don’t care if you use an RDBMS after that, but at least you’ll reinvent the whole thing in a proper way.

I strongly urge all Drupal developers to read through this paper on Postgres. This is a 15 year old design document from PostgreSQL’s predecessor, but there are many gems in this which apply directly to where (I think) Drupal is headed. I intended to write this up properly as an informal presentation, but it came up on #drupal today, so thought I might as well share it with everyone.

My town uses my code : the Ann Arbor District Library uses Drupal for their web interface, including my captcha module!

Frustrated with the never-ending betas of the imminent Drupal 4.7, I have decided to switch to a better project, Drup.us.

Today, I woke up and decided that I will give my drupal modules away, in the hope that they will be better maintained. If you’re a Drupal developer who would like to take over the Captcha, TextImage and Similar modules, please contact me. Note, I’m not unmaintaining them, I’m only looking for a person who has more time and energy than me to work out the kinks and make the modules work for every Drupal version and not bloat the features and prefers to make things more efficient. If I do not find such a person, I’ll just keep sporadically maintaining them like I was. Interested? Just send me your drupal.org username, and what module you’d like to take over.

Russell Beattie figures out MySpace, in component terms. Funny how every sentence of his reminded me of a specific Drupal module that provides that feature.

Then of course, we’re not counting the sentences that talk about hotties and risque photographs. I don’t think there’s a module (yet) to provide that.

The Yahoo! UI people just opened up their widget library, complete with graded browser support. Hmm. Maybe we would use the calendar widget for the Drupal archive.

Recent versions of Drupal have the oh-so-cool feature that allows you to host many websites off a single Drupal codebase. The coolest part about this is that you can share some tables accross multiple websites; which means you can do things like have a single username/password table accross all the websites. This can easily be done, as specified in the settings.php comments as:

Now here’s an important thing to note: The first table you have to share is the sequences table. This is the table that handles all the id counters, so if you don’t share this one, something like this can happen:

[you shared only the users table]

1. User 1 signs up on Site A, gets user id#1
2. User 2 signs up on Site A, gets user id#2
3. User 3 signs up on Site B, gets user id#....? The correct answer is not 3!

This happens because you didn’t share sequences… Site B uses it’s own sequence generator to render a duplicate userid… which the user table would not accept, and this would go on till the Site B sequence catches up with the Site A sequence, and then things would be normal. The code quality in user.module helps protect the user table from data corruption, but you will have many signups disappear into thin air with a set up like this. Hence, all you need to do is share the sequences table along with the users… and you’re all set!

Btw, hello Planet people!

FINALLY finished the captcha.module for drupal. This is ONLY a first draft, lots of improvements to happen. Features:
* ability to protect any drupal form
* captcha API – make your own challenge response! (math and image are included in package)

(use cvs checkout to get)

Was only tweaking things for a website I’ve been setting up, and ended up submitting a core patch to Drupal! Let’s see what the Bryght people think about it.