If you've done any signifigant development with Drupal, you're probably (deeply) familiar with a little function called dpm(). I think it stands for Drupal Print Message. If you aren't familiar, dpm() is available through the Devel module and it's a great tool to dive into any Drupal code you might be working with. You can examine available variables, the node object, etc. It even prints out in a nice compact bundle in the 'Messages' area.
We like to use our own site to experiment with different technologies. CDN's are nothing new, and Metal Toad has projects running on competing systems including Akamai and Level 3. Still, I think Amazon Cloudfront is an interesting offering and I wanted to give it a spin. Here's my review of the service after setting it up with Drupal:
Let's say you inherit a Drupal site and the modules folder looks like this:
And being an organized dev, you'd rather it look like this:
So you create a 'contrib', 'custom' and maybe a 'features' folder for good measure and move everything around.
Then your site blows up and starts giving you errors all over the place.
If you've felt yourself stagnating as a programmer recently, I have a cure for you. That's right, a ticket out of the back room or cubicle you've been stuck in for the past few years, into an exciting world that is changing daily. The secret is joining an open source community.
This is a step-by-step path to making more money AND having more fun at the same time. It may not always be easy, but doing something worthwhile almost never is. Here's how:
After years of building and publishing on them, I'd love to say I knew CMS frameworks like Drupal and WordPress would be this huge. In truth they got this popular because of their great open-source communities; both of which I'm trying to participate and contribute to more. Why? Because closed platforms like SquareSpace and Adobe's content platform are rushing ahead without having to worry about backward compatibility like WordPress and Drupal does. These newer, closed systems insulate users from the backend and abstract away many of the same complexities WordPress.org and WordPress.com solved. They can push forward faster with newer, cleaner, “from-scratch” user-experiences because they don't need to maintain compatibility like "the big PHP" CMS's.
When we in the Drupal community talk about scalability, it's most often in terms of handling high numbers of visitors. An equally important dimension, that to our detriment we often overlook, is scaling with larger datasets.
One of the biggest problems I see is a pattern of loading all of a module's data at once, regardless of size. Two examples:
On any given month, Metal Toad Media will distribute the work for 25-30 different clients across 10 different development resources. The majority of our work comes from fixed-bid contracts, but we also have a number of time & materials maintenance contracts to fill in the gaps. We've tried many different software solutions over the years to coordinate this work, but we've settled on using our own set of customized Google spreadsheets to do our long-term resource planning and short-term work allocation in a very dynamic and agile fashion.