July was a month of talks and travel, including speaking at OSCON and user group talks to DCPHP and PDXPHP.
For those who saw the “Micro Optimize This!” talk, you can download the slides here.
Anyone who has worked with WordPress knows that it’s greatest strength is also one of it’s greatest weaknesses: it’s architecture. The same architecture that makes it easy to include literally hundreds of plugins also makes it slow, resource-intensive and bulky. Unlike Drupal, WordPress doesn’t have a built-in caching mechanism. What is a developer to do?
On Friday, I’ll be presenting a webcast called “Caching for WordPress.” In this webcast, we’ll talk about ways to make WordPress perform better, including aspects of caching from the application perspective and from the content perspective. There will be a discussion of caching plugins available, as well as a discussion of the WordPress API and what it offers by way of caching opportunities.
The ability to turn a website into a large web service is a skill that’s deeply important amongst web application developers, but yet I’ve found it to be somewhat lacking. How is it that this fundamental skill is so often overlooked? Part of it has to do with the fact that many developers work on applications that have a fairly small user base: less than 5,000 users per day, for example. Other times it’s because PHP is so easy to learn that the developers who master it don’t learn the architecture that goes along with it.
In this series, we’ll ask the questions and give a basic set of directions about how to scale a web application from the ground up. We’ll examine how to go from one server to many servers, and what questions to ask and things to look out for. This is not a guide for experts in the subject to hone their skills; rather, this is a beacon for those who have never scaled a website before, and perhaps are being asked to do so, or will be asked to do so fairly soon.