Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Dec 23 2011
Dec 23

After DrupalCon London, I was sitting on the banks of the Thames river sipping champagne when I remembered the time I told my friend I was joining the co-op program at Concordia. He launched into a story about his own co-op experience. One day, he had to do "pen testing".

"Ooh, you got to do penetration testing?" I asked. I find computer security interesting, so I was kind of excited. But then I remembered that my friend was a business major and that there is no way he would have been doing penetration testing.

"No, I mean... I was testing pens. My supervisor gave me a ziploc bag full of pens and told me to test each one to make sure it had ink." At that, I got a mouthful of coffee up my nose.

In May, I joined Evolving Web for a co-op work term that was to last eight months, and I am happy to say that my duties have not included testing pens, cold-calling charities to sell them snake-oil SEO packages, or doing Excel data entry.

During my time at Evolving Web, I've helped build real Drupal projects. One of them will be used by friends in the future. I had a real impact on these systems, and I've grown as an engineer by getting thrown head-first into them. Sometimes I made mistakes, but I had great mentorship from the entire team. I'm proud of the work I got done.

I was fortunate enough to travel with the company to New York, Boston, London (UK), and Toronto to Drupal Camps and Cons. At these events, I was introduced to an enthusiastic and friendly community of developers, designers, project managers, and entrepreneurs. For someone who has always had trouble "getting into open source", the warm welcome by the Drupal community meant I could gain the confidence to do real open source work. I also had the privilege to give my talk on custom fields and poutine. The chance to share my knowledge with the community was fun and rewarding.

Me on the road back from Boston with Evolving Webbers Logan and Simone

The Evolving Web team at DrupalCon London

At the code sprints in London and Montreal, I contributed a modest handful of patches to Drupal core and contrib — and I got to do it on company time. Evolving Web takes the community seriously, and I've been constantly encouraged to give back as much as I can. I'm no longer afraid to jump into issue queues and submit patches. For a novice developer, I'd recommend contributing to Drupal as a great way to get used to open source — the people are just too friendly.

As my co-op term draws to an end, and I return to the cold, unforgiving halls of academia, I'll look back on my time at Evolving Web fondly. I hope that other co-op students get a chance to experience what I've experienced, because if you've got to have a co-op job, this is the one to have. I'm happy to say I'll be coming back in the summer.

Dec 21 2011
Dec 21

Today is not your lucky day. The production server went down due to a hard disk error on the VM's host machine. You don't have a high availability setup because running additional servers 24x7 is quite costly. However, you need a new machine quickly.

In this blog post, I will tell you how we deploy brand new production machines in under 20 minutes. First, I'll talk about why it is so important to be able to deploy servers quickly.

Benefits of rapid deployment

  • Better testing environments. If you want to try Memcached out on the site, you want to reproduce the current production environment quickly. You are, after all, just trying it out, and you don't want to lose a day on it. If you can run one command and have the server running, the experiment is much more feasible during your busy work week.
  • Better development environments. If you just hired a new developer, and you want them to fix a minor bug on a site you're maintaining, they shouldn't have to waste time setting up the environment before fixing the bug. They shouldn't need to know about all the legacy baggage the site has, and they shouldn't have to pester you about how to set up every component of the site.
  • Better documentation. Instead of writing extensive documentation on each step of the deployment process, you can write a deployment script. Well-written code can rarely replace good documentation, but this is one case where relying on the code is suitable. With minimal documentation effort, you should be able to roll out of bed and deploy a new copy of your most mission-critical production sites in minutes.

Steps to Rapid deployment

Set up your Chef infrastructure

At Evolving Web, we use Chef, a configuration management tool. With Chef, you manage all your configurations in one git repository, and you write them in Ruby. This lets the Chef server build a new server or update stale configurations automatically. For example, Chef will occasionally add new public keys to our authorized_keys files as the team grows.

With Chef, your site's environment is reproducible and standardized. When you're attempting to reproduce bugs, it's good to know that your development VM is the same as the one running the production server.

Make a site-specific cookbook for launching the site

We use site-specific cookbooks to launch a specific site. This will use a rotating read-only SSH key to pull code and configuration from a git repository. Once Chef builds the site, you can sync a database from backups or the production server.


Write a step by step guide that anyone can read without messing up. This takes clarity and detail. Having a reproducible process for creating the VM makes this much easier; you can document as you build a test VM with VirtualBox on your own desktop. If you find that a certain part of the process doesn't work properly, you'll notice while documenting. You can fix the Chef script and go through the process again. Since it's a short process (especially with VirtualBox templates), it's not a problem to start over.

Test the process with a beginner

Find the newest recruit on the team and send them a link to your documentation page. Tell them to set up a server in 30 minutes. Can they do it without your help? If so, you've succeeded. If not, it's back to the drawing board. Make those docs shine.

Having good documentation for this makes getting new team members up to speed much faster. Passing your deployment process down generation by generation through oral tradition is not how the professionals do it.

You're done!

Now you can rest assured that you can get that site running again with no hassle. The entire development process should be more pleasant too; you can boot up a development VM in half an hour, and make it a clean environment separate from all the experimental hacks you do on your desktop.


Aug 31 2011
Aug 31

You're in a meeting with a client, and you want to go through the specs for a big project. Each spec is a row in a spreadsheet, which is in Google Docs so the management team can edit it collaboratively throughout the meeting. You like the spreadsheet layout because it's well-organized, simple, easy to edit, and hides the distracting technical details from the client. Your development team needs to see this information too, but they prefer to use Redmine; it's a great place to dump gritty technical details.

You need to keep the developers in the loop, so you copy and paste the spreadsheet text into the issue after the meeting. But after a particularly long meeting, you forget to update Redmine, and the developers are now working off out-of-date documentation.

What you need is a Redmine plugin to synchronize your spreadsheet and your Redmine issues. We wrote about our solution in a previous post. Automatically updating an issue page with the changes saves us unnecessary meetings and confusion, so Alex Dergachev and I wrote a plugin called redmine_google_docs. This plugin allows embedding Google Spreadsheets and Google Documents in Redmine wiki pages and issues with simple macros.

Google Spreadsheet Macro

A macro is simply a code that you can place in the text of a Redmine page that will get rendered by Redmine in a special way. For example, {{toc}} will be rendered on a Redmine wiki page as a table of contents.

The Google Spreadsheet macro works similarly, but takes arguments that specify information about the spreadsheet you are embedding. Take a look at this diagram:

Plugin overview

Preparing the Spreadsheet on Google Docs

Before embedding a spreadsheet in Redmine, you must make sure that your team can view the spreadsheet. Google Docs lets you change the "Share" settings of a document using the Share menu in the top right of a document view. Use the Share menu to give your team viewing privileges before attempting to embed it. Otherwise, your team will only see an error message, instead of the spreadsheet.

If your spreadsheet is not publicly viewable, you must be logged into Google Docs in another browser tab to view it in Redmine. Otherwise, instead of a rendered Google spreadsheet, you will get an "access denied" error.

Using the Plugin

The simplest version of the Google Spreadsheet macro has a document key as its first argument. In this example, the document key is the string of characters inside the parentheses, 0ApF8ewDeRUY8dGxxTzdqWmdWSTNXNDdwZU44My13N0E.


Where do you get the document key from? The document key is part of the URL where you view the document. It will be a long string of letters and numbers and should not contain any symbols.

Getting the document key

Once you have the document key, you can insert it in the macro. Use this as a template:

{{googlespreadsheet(insert document key here)}}

Here it is in action, in an issue comment.

In the issue comment

Another common task is to filter the displayed rows. We can do this with our macro:

{{googlespreadsheet(286755fad04869ca523320acce0dc6a4, SELECT * WHERE A='Tavish')}}

Filtering displayed rows

We often set up our spreadsheets with the second column as the related issue number. We can query for a specific issue number like this:

{{googlespreadsheet(286755fad04869ca523320acce0dc6a4, SELECT * WHERE B='5790')}}

Or we can use the googleissue macro, which automatically does this on issue pages. Keep in mind that this will only select rows with the current issue's number in the second column.


Issue query

Two-way Editing

Sometimes developers need to change a specification in the spreadsheet, but they don't want to log into Google Docs to do so. The good news is that you can enable two-way editing on the embedded spreadsheet by adding "/edit" to the document key used in the macro.

For example:


Be warned: it may be a good idea to force your team to edit the document on Google Docs, especially if the document is client-viewable. It is easy to accidentally modify an embedded spreadsheet.

Rostyslav Hulka pointed out in the comments that this doesn't actually work with spreadsheets. See the section below on two-way editing with documents. Thanks for the tip, Rostyslav!

Google Document Macro

While writing this blog post, I used a Redmine issue to track my progress and collect feedback from team members. Instead of just linking to the work-in-progress, I embedded the document itself in the issue. This way, Aran could read the post and comment on it in the same window.

We also use this approach for writing proposals. The proposal's outline is in Redmine and each section is given an issue with an embedded Google Doc. That way, the status of each section is tracked and assigned and even edited through Redmine.

Here's the macro itself. You get the document key from the URL of the document just like with Google Docs spreadsheets.


To use it, you need to first publish the document on Google Docs.

Google Doc publishing

Here's the Google Document macro in action:

Google Doc example

Two-way Editing

Sometimes developers need to edit a document, but they don't want to log into Google Docs to do so. The good news is that you can enable two-way editing on the embedded document by adding ", edit" to the macro argument.

For example:

{{googledoc(286755fad04869ca523320acce0dc6a4, edit)}}

Be warned: it may be a good idea to force your team to edit the document on Google Docs, especially if the document is client-viewable. It is easy to accidentally modify an embedded document.

Final Words

Keeping a team agile involves constant communication. As a project progresses, its integral that all team members remain up-to-date on project specifications. We find these Redmine plugins invaluable for keeping management and development on the same page — literally. If you have a similar technique, or if this solution is helpful to you, let us know in the comments!

Get the Google Spreadsheet plugin here.


About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web