Remodeling Four Kitchens: A look inside our new brand
With the additions of Advomatic and Manatí, we’ve had an exciting few years at Four Kitchens. While we’ve remained fundamentally the same organization, we’ve also been evolving into something new. It’s time for our brand to catch up.Learn more
A more modern, sustainable approach to higher ed websites with YaleSites
A higher ed website is a product, not a project. Learn about Yale’s sustainable approach to digital development and how your team can do the same.Learn more
News and insights from the Web Chefs
Filter by topic
Filter by type
Case study: Big gains from small changes
One of our clients came to us with a performance issue on their Drupal 6 multi-site installation. Views were taking ages to save, the admin pages seemed unnecessarily sluggish, and clearing the cache put the site in danger of going down. They reported that the issue was most noticeable in their state-of-the-art hosting environment, yet was not reproducible on a local copy of the site -- a baffling scenario as their 8 web heads and 2 database servers were mostly idle while the site struggled along.
The CAP theorem is like physics to airplanes: Every database must design around it
Back in 2000, Eric Brewer introduced the CAP theorem, an explanation of inherent tradeoffs in distributed database design. In short: you can't have it all. (Okay, so there's some debate about that, but alternative theories generally introduce other caveats.)
Anticipage: scalable pagination, especially for ACLs
Pagination is one of the hardest problems for web applications supporting access-control lists (ACLs). Drupal and Pressflow support ACLs through the node access system.
Giving schema back its good name
For modern applications, the word "schema" has become synonymous with the tables, columns, constraints, indexes, and foreign keys in a relational database management system. A typical relational schema affects physical concerns (like record layout on disk) and logical concerns (like the cascading deletion of records in related tables).
Improvements to the Materialized View API
The Materialized View API (related posts) provides resources for pre-aggregation and indexing of data for use in complex queries. It does this by managing denormalized tables based on data living elsewhere in the database (and possibly elsewhere). As such, materialized views (MVs) must be populated and updated using large amounts of data. As users change data on the site, MVs must be intelligently updated to avoid complete (read: very slow) rebuilds. Part of performing these intelligent updates is calculating how user changes to data affect MVs in use. Until now, these updates had limitations in scalability and capability.
David’s epic presentation megapost
UPDATE 2009-06-08: You can download these slide decks (and more!) from our Presentations page. --The Web Chefs DrupalCamp Stockholm 2009 Is Drupal secure: the Drupal project's responses to the web's most common software vulnerabilities Scalable Drupal infrastructure: a guide to planning, deploying, and scaling big websites Drupalcon DC 2009 Building infrastructure you can scale, monitor, and maintain The next 10 Years: the future of application scalability and responsiveness
Making the web a better place to teach, learn, and advocate starts here...
When you subscribe to our newsletter!