Drupal often makes certain things so easy to do, that we as developers don't take the time to consider the alternatives. Lately I've been giving a lot of thought to the module dependency system and possible alternatives. The main reason for this is that dependencies create a more brittle overall system which in turn makes the code more difficult to maintain and re-use.

Scenario 1

Hey Drupal developers and site administrators! Ever spend your time handling things like block placement and microsite deployments at the request of your content editors?

Hey content editors and managers! Ever wish you could just do this stuff without relying on your developers and administrators--or becoming a de facto site administrator yourself?

This one's for you.

Three of our modules from 2011--co-sponsored by Energy.gov--empower content editors with greater independence and more effective execution tools.

This morning, I happened upon "Wired's Essential Apps for 2011" and quickly found myself frowning. I wasn't frowning because of the Wired editors' decisions about which apps are the best, it was because I was frustrated with a glaring design problem in their article and I suspect I know the reason it looks so bad:

Developers Built it That Way

How many times have the following issues happened on a project you've worked on?

• Notices (or worse) appeared on production because of a PHP version mismatch between a developer's machine and the production web servers.
• A new PHP extension or PECL extension had to be installed on production because it was installed in WAMP or MAMP?
• A team member ran into difficult setting up their local environment and spent many hours stuck on something.
• Team members didn't set up SSL or Varnish on their local machines and issues had to be caught on a dev server.

At the last Drupal Indy User Group meeting, I did a presentation on integrating Openlayers and Apache Solr. In the presentation, I walk you through how to setup and configure the modules necessary to display search results on a map in Drupal 7. This is the same basic process which we used on Energy.gov.

The video is about 45 minutes long, so here is a general outline of the presentation. Be sure to watch the entire video or you will not see how all of the pieces are integrated:

Update: Please see the code at https://gist.github.com/1460818 for a working example with the current bean code base.

In my previous post I talked about how we decided to leverage EntityFieldQUery as an alternative to Views for aggregating lists of content. In this post we'll be looking at how Treehouse created the Bean module to create and place blocks containing these lists of content.

Views is an amazing module. The power it provides to build lists of content from within the UI is amazing. The plugin architecture is complicated but extraordinarily powerful. There are currently 125 Drupal 7 modules that extend the functionality of Views. So why didn't we use it for development of Energy.gov?

It's been an exciting week for us here at Treehouse Agency.  We've been hopping up and down for weeks wanting to tell everyone about our work with Energy.gov, and now that it's finally launched, the response has been exhilarating.

I’ve been waiting a long time to tell you something.

Several months ago, Treehouse was signed on by (Top 100 Federal Prime Contractor) Energy Enterpise Solutions as the development partner for Energy.gov’s massive, eleven-site Drupal relaunch.

Today, I am ecstatic to announce that the platform is live!

This past weekend was CapitalCamp, Washington DC's first DrupalCamp, and Treehouse presented three exciting sessions.

Treehouse CEO, Michael Caccavano, was on a panel with fellow CEOs of web technology companies in Growing a Drupal Agency Beyond the Garage.

Steven Merrill and I talked about guidelines for web performance optimization, techniques for improving front-end performance, and ways to automate the testing and monitoring of front-end functionality in Pages on a Silver Platter: Automated Front-End Testing and Tuning. If you saw this talk, we'd love your feedback! Please leave your quick review here: http://tha.cm/capitalcamp-front-end-testing

Then, Patrick Macom and I presented on Raphaël JS, an interactive drawing library for vector graphics on the web. The session covered the basics of the Raphaël JS API and then moved into integration strategies with Drupal in the talk, "Outside the Garden: Intro to Raphaël JS." If you saw this talk, we'd love your feedback! Please leave your quick review here: http://tha.cm/capitalcamp-raphael