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.
This is the second part in my two-part series about Drupal update scripts, specifically focusing on using update scripts for your custom modules as part of your deployment process. You can read the first post about Why You Should Spend the Extra Time to Write Drupal Update Scripts. Now that we know "why" lets talk about "how" and what better way to demonstrate how then look at real-world examples.