Drupal 7 release party in Austin

After two and half years of the blood, sweat, and tears of hundreds of developers – Drupal 7’s release is merely days away. To mark the occasion, user groups from all over the world are celebrating as Drupalistas know best – with a party.

But we’re not the only ones – there are now more than 238 300 parties, in over 80 90 countries. This should be proof enough that Drupal enthusiasts all over the world are more than a litttle excited about January 7, 2011.

Vote for web chef offerings at DrupalCon Chicago!

Voting on session proposals for DrupalCon Chicago ends tomorrow, December 23rd. The Four Kitchens’ web chefs have added delectable entrées to the impressive buffet of offerings. From theming to performance, jQuery to hiring developers, we’re serving a little something for everyone. You must be registered to vote, so register today and cast your vote for the sessions you’d like to attend.

Design and UX sessions needed for DrupalCon Chicago

Attention designers, user experience specialist, and interaction designers: DrupalCon Chicago needs you!

The Design/UX track has been very successful at inviting speakers from outside the Drupal community. Now we need those from inside the community to step up! We currently have four confirmed and 19 proposed sessions. This is good, but we can do better.

We’re looking for sessions that address the following topics (and not necessarily in Drupal-specific ways):

  • Principles of design (aesthetics, etc.)
  • Principles UX and interaction design (usability, UI, etc.)
  • Information architecture and knowledge management
  • Typography

The Design/UX track is for artists, usability experts, and site architects — all the people who decide what a site should look like and why. While the Theming track focuses on execution, the Design/UX track is about what happens before anyone touches markup and CSS. This track is about more than Drupal — it’s about building a more attractive, usable, and purpose-driven Web.

Promiscuous stylesheets in Drupal 7

One common practice when using CSS frameworks such as 960 Grid System, Blueprint, or Baseline is to use a CSS reset. Each web browser applies a set of default styles to HTML elements, and these styles vary among browser vendors. A CSS reset is a stylesheet that clears these default styles so that you know what you’re working with as you implement your theme’s CSS.

The caveat with a CSS reset is that it needs to come before all of your other stylesheets. This presents a problem if you want to use a reset in your Drupal theme: all of the theme’s CSS will be added after Drupal’s system CSS and after any modules’ CSS. If your reset is loaded after these, the system and modules’ styles will all be undone, which probably isn’t what you want. Drupal loads theme styles last because, usually, you’re just adding to or overriding the existing styles, not wiping them all clean. It is possible, however, to have Drupal output a stylesheet from your theme before the system and module stylesheets.

Option groups in Drupal forms

One really useful HTML element that doesn’t seem to get much love is optgroup. It allows you to group the items of a select list in a way that may be more meaningful (and more readable) to your users than a long, uninterrupted list. The option group labels themselves can’t be selected, so there’s no need for back end logic to filter them out of your form data.

Drupal’s Form API provides option groups, but it isn’t immediately obvious how to use them. A quick check of the select type and #options attribute in the Form API reference doesn’t provide any clues about option groups, so it’s necessary to dive into Drupal’s source code.

Drop that cron; use Hudson instead

For years, I used cron (sometimes anacron) without asking questions. The method was simple enough, and every project requiring cron-related capabilities documented the setup.

There is a much better way, and it involves Hudson. I introduced “Hudson for cron” as a sidebar at the Drupal Scalability and Performance Workshop a few weeks ago. To my surprise, several of the attendees remarked on their feedback questionnaires that it was one of the most valuable things they picked up that day. So, I’ve decided to write this up for everyone.

Feast your eyes (and votes) on our web chefs' tasty DrupalCon San Francisco session proposals

Vote!

We are still 62 days away from DrupalCon San Francisco 2010, but in order to get truly excited about the event, you’ll want to start thinking about the amazing sessions you’ll attend. Beginning today, attendees are allowed to vote on those sessions they most want to see on the final schedule in April.

This year, Four Kitchens is both sponsoring DrupalCon San Francisco and offering to share our experience and knowledge with the community. If you’d like to see any of the sessions listed below, please vote! (And tell your co-workers, friends, and pets* to vote, too.)

Making Drupal and Pressflow more mundane

Drupal and Pressflow have too much magic in them, and not the good kind. On the recent Facebook webcast introducing HipHop PHP, their PHP-to-C++ converter, they broke down PHP language features into two categories: magic and mundane. The distinction is how well each capability of PHP, a dynamic language, translates to a static language like C++. “Mundane” features translate well to C++ and get a big performance boost in HipHop PHP. “Magic” features are either unsupported, like eval(), or run about as fast as today’s PHP+APC, like call_user_func_array().

Intelligent memcached and APC interaction across a cluster

Anyone experienced with high-performance, scalable PHP development is familiar with APC and memcached. But used alone, they each have serious limitations:

APC

  • Advantages
    • Low latency
    • No need to serialize/unserialize items
    • Scales perfectly with more web servers
  • Disadvantages
    • No enforced consistency across multiple web servers
    • Cache is not shared; each web server must generate each item

memcached

  • Advantages
    • Consistent across multiple web servers
    • Cache is shared across all web servers; items only need to be generated once
  • Disadvantages
    • High latency
    • Requires serializing/unserializing items
    • Easily shards data across multiple web servers, but is still a big, shared cache

Combining the two

Traditionally, application developers simply think about consistency needs. If consistency is unnecessary (or the scope of the application is one web server), APC is great. Otherwise, memcached is the choice. There is, however, a third, hybrid option: use memcached as a coordination system for invalidation with APC as the main item cache. This functions as a loose L1/L2 cache structure. To borrow terminology from multimaster replication systems, memcached stores “tombstone” records.

Pages