Dustin Currie's blog

Drupal projects have grown to rely heavily on sitebuilding. Website creators use Drupal modules like Views and CCK to create site architecture. While sitebuilding patterns have become incredibly powerful and time-saving they created a significant deployment problem: How do you deploy new features on a live site? The first, and most obvious problem was that the results of sitebuilding work needed to be exported to code.

Tom got an AWS account this weekend, so I decided to geek out on it.

On Sunday I pulled the trigger and put leveltendesign.com up Amazon's Web Services using Chapter Three's Mercury AMI.

I'll write more about this later, but I just wanted to share this before I leave tonight:

4,000 HTTP requests served in less than 1 second, run on the production server.

root@ip-10-160-59-223:~# ab -c1 -n4000 http://localhost/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/

With W3C Validator module, you can validate markup on all nodes and views in a Drupal site.

I have been on the lookout for several years now for a good tool to validate markup across an entire site. The Drupal module w3c_validator does almost exactly what I want.

Prior to discovering this tool, the extent of my use of markup validation was to pass URLs to the the official W3C validator or open one of several validator plugins for various browsers.

Web site performance is an expansive topic. Like just about any aspect of Web development, a career can be made out of becoming knowledgeable on performance. A career can even be made out of becoming a Drupal performance expert (David Strauss is doing just that). I find for single-server sites there are 4 must-dos for performance. These are the biggest bang-for-the-buck performance improving techniques.

Estimating is one of the more difficult and risky parts of development. A good estimator is valuable, but even more valuable is a team that understands what an estimate is and what an estimate is not.

An estimate is an approximation of the bigness or size of a project; it is not a commitment. I have seen, time and time again, estimates turned into commitments and estimators are then held accountable for their estimates, resulting in long hours for developers, monetary losses for development companies, and angry clients.

By default, views of type Term link to category pages (taxonomy/term/[tid]). I find that category pages are more useful as custom views where you can control fields. You can effectively replace the default category pages with a customized view by following this views recipe. And no programming is needed.

I am currently on a project that requires a 2-level drop down navigation and a sidebar block that displays the pages in the current section. This is not the first or second time I have used this recipe so it's time to share. This block can be used to display other pages in a section.

In an effort to test out Mollom and foster more talk on the blogs, we have enabled anonymous commenting.

LevelTen has a very high page rank in Google and is frequently targeted by link builders. They'll register for an account, write something that takes only a minute to write and then link to a site that is wholly unrelated to anything. The post is always on topic but lazy. I don't think these are bots. We'll find out if Mollom blocks those types of posts.

Please comment away!

I wrote up a doc detailing Drupal related stuff that needs to be done to launch a Drupal site. Here is the info for discussion and anyone who finds this useful.

Drupal provides a clean way of formatting dates any way you want throughout the entire site.

Earlier today, Rachel commented that an upcoming events block on a site we are working on displayed the date in an ugly format. So I changed it and for anyone who is interested, here is the step-by-step process for doing so.

1. Create a date string