development

Eric Broder Profile Photo

Drupal Quality Assurance with Dev QA Live

One of the things I enjoy about working with CivicActions is the commitment to quality, and one of the best tools in our quality assurance arsenal is the Dev QA Live release process for staging and deploying Drupal sites. We don't just build you a website, we build it and test it and QA it over and over until we know we got it right. And it's not done until it's "done".

Three Causes and Associated Symptoms of a Poorly Conceived Redesign Project

 

"If we don't succeed, we run the risk of failure." Anonymous, often attributed to Dan Quayle

Determining if your website project will be a success or failure is tricky. It's like trying to decide if the pizza you're about to eat will be good or bad (which can be a trick question- when is pizza ever that bad?). 

Drupal Gotchya: Cache_get() Returns Expired Items

cache_get() returns $cache objects even if the cached item is stale (expired). The cached data will not be rebuilt every hour in the following example:
<?php
/**
* Builds complicated data for the monkey grip.
*/
function custom_monkey_grip_data() {
 
// Return the cached data
 
$cache = cache_get('custom:monkey_grip');
  if (!
$cache) {
   
// Some expensive processing to build the data.
   
$data = complicated_recursion_and_loops_on_lots_of_data();
   
   
// Cache the data and rebuild it every hour
   
$expire = time() + (60 * 60);
   
cache_set('custom:monkey_grip', $data, 'cache', $expire);
  }
  else {
   
$data = $cache->data;
  }
  return
$data;
}
?>

What Would chx Do?

Working on Drupal core means that any change you contribute - even the most trivial tweak - is likely to go through multiple levels of review before being applied. Most contributors to core can expect delays of weeks, months, in some cases even years before a patch is accepted--if indeed it ever is accepted. And even if a new feature you contribute to core goes in, you won't get to actually use it for months or years--the typical lag time until a new major version is ready for production use.

So it's no wonder many Drupal developers choose to work instead on contributed modules.

In contrib, if you're developing your own module, you've got a pretty free hand to do whatever you want. You can get a lot of functionality out there relatively quickly. And you won't have anyone breathing down your neck while you code. Want a new feature? Easy: code it up, press that metaphorical "commit" button, and you're set.

So end of story? Put in the occasional minor patch to core, but otherwise stick to the easy world of contrib?

Not quite. Because it turns out that the ease of contrib can also be its greatest pitfall.

Drupal Developer Tips for Getting the Most out of Open Source

I recently suggested that the way we approach new development is the most important factor in determining the long term value of our work. But just how can developers using Drupal make the most of open source by ensuring that participating and contributing is an essential part of our daily workflow? Here are some practical tips that come out of our experience at CivicActions and that can guide you in deciding how to approach new development to get the full benefit of open source. Read on as well for a discussion of patching vs. hacking vs. forking and of how to get attention for your patches.

The Most Important Decision In Developing A Drupal Site: Contributed Vs. Custom Development

When developing in Drupal, should we hack something together that's specific to a site? Or should we instead take the time to do things "right" by improving existing modules or writing our own new modules to contribute to the community? When is one of these options better than the other? How do we decide? It's a key set of questions. All but the most basic projects will require some level of new development. The way we approach this new development is probably the most important factor in determining the long term value of our work, both for us and for our clients.

Writing Extensible Drupal Modules, part 1

This is a repost from my blog First in a 3 part series In the past few months, I've spent a bit of time writing Drupal modules that are designed to have other modules interact with them. In some instances to add content, change configuration, modify display, or participate in module processes. Writing modules that do this turns out to be frighteningly easy. With Drupal, even more so.
Gregory Heller Profile Photo

CivicActions Session Proposals for DrupalCon Barcelona 2007

A number of CivicActioneers (my self included) have proposed sessions for the upcoming DrupalCon in Barcelona (September 19-22). Almost the entire team will be traveling to Spain a week early for our 3rd annual European Fall Retreat, so we'll have plenty of time to polish our sessions and get input from the team. Here is a quick look at the sessions we've proposed:
Syndicate content