How we use ExpressionEngine, Git, and Ruby gems in our projects

Posted on December 28, 2012

We use many tools to build websites at Reusser Design. Things have drastically changed since the days of editing sites via FTP. Here’s a rundown of what we use, how we use it, and other nuggets of front-end development.

Version Control (Git and Beanstalk)

We started using version control (namely through Beanstalk) a couple years ago. Beanstalk allows us to keep every repo in one place and deploy it to any server environment. We started using Subversion + Versions, but we weren’t satisfied with the workflow. It was tedious compared to our current love: Git.

We love Git. It’s lean, mean, and a cinch to setup. I’ve moved to using the command line for all Git usage, but we sometimes rely on Tower when we’re in a bind and need a GUI.

Using Ruby gems in projects

We never thought of using Ruby gems in projects until Doug Avery showed us a thing or two in his article, Ruby Tools for non-Ruby Projects. You may already be utilizing a Ruby gem in your projects: Sass. When you run Sass, it compiles a .scss document into a .css document on each save. This converts the Sass syntax into browser-readable CSS. So how do you manage an entire project with Ruby gems?


There are numerous gems that can make building websites easier. Some of them minify code, some of them compile, and it’d be nice to run one command to do it all. That’s where Guard comes in. Guard runs a group of rules when a file is modified. For example, a rule could state that Sass documents should compile upon each save. You could also setup a rule that duplicates, compiles, and minifies all .js files within a specific directory. The possibilities of Guard are numerous.

Getting started

Getting started with Ruby gems and Guard is a bit of a process. However, this process enables a great deal of power and efficiencies that are worth learning. You can view the Github repo for our project setup if you’d like to get a quick start.

Here are the necessities for setting up a Ruby-powered project:

  1. Ruby and Bundler must be installed: I won’t go into installation details. There’s a number of great resources on getting these dependencies installed.
  2. Setup a Gemfile document: Your Gemfile works as a dependency list. It essentially says, “these are the tools I need to work on this project”. Running $ bundle install in Terminal will look at the project’s Gemfile and install all the needed gems. Like Doug states in his article, this helps set your team up with everything they need. New members can simply clone the repo and run $ bundle install to get caught up.
  3. Setup a Guardfile document: This is a bit trickier, but this document will run the specified rules in the scenarios you determine. For example, it can compile CoffeeScript to JavaScript on each save.
  4. Run $ guard: When you run this command in the directory of the Guardfile, Guard will be initiated and the rules will be run on file manipulation.

Closing information

Again, feel free to check out the repo for a full setup, but this should get you started with the basics and showcase the power of Ruby in your projects. For more information, check out Doug Avery’s article or do some Googling. Learning comes from doing.


We have an ExpressionEngine boilerplate to help jump-start every project. Nearly every site we create uses:

ExpressionEngine folder structure

This is the structure of our most recent ExpressionEngine projects. We change this frequently. Mainly, because the way we build websites changes as we adapt to more modern techniques like Guard, Compass, etc.

    // Third party EE addons
    // Multi-server configurations
    // Compiled CSS
    // Images used for site design
    // Compiled JS
    // Sass files
    // Stash templates
  assets.yml // Settings for the compiled JS files
  config.rb // Settings for the compiled Sass files
  Gemfile // Lists all ruby gems used in project
  Guardfile // Settings for guard gem

Because the ExpressionEngine directories are self-explanatory, we’re going to dive into the /assets directory further.

Our project setups

/_addons This directory contains all of the ExpressionEngine addons we use. We place them all here so upgrading is easier. Natively, ExpressionEngine places addons within /system/expressionengine/third_party.

/_config Here is where the Focus Lab LLC multi-server environment configurations are set. We have the following files within:

/_css We use Sass on every project. Pre-compilers make your code maintainable, DRY, and easy to minify. Here’s where all of our compiled CSS documents go. We usually compile one minified CSS document to keep HTTP requests at a minimum.

/_img This directory contains all of the images we use when building the design of the site. We’re trying to eliminate the need for this directory as icon fonts become more sophisticated and high resolution displays more accessible.

/_js This is where all of the compiled JavaScript files go. Similar to Sass, we combine all of our JavaScript files and minify them into one single HTTP request. Sometimes we create two minified JS files if the project has a robust admin area. There is no need to always load those scripts for the users not logged in.

/_meta Any “meta” information for the project belongs here. This, typically, is a single humans.txt file that explains the tools used to build the site.

/_scss All of our Sass documents belong here. Here’s our current setup:

/_stash This is where all of our Stash templates go so we can pull in content dynamically, cached, and save on EE resources.

assets.yml This is where we set all of the JS options for Guard/Jammit. We can combine multiple JS files into one, or many, JS files.

config.rb All of the settings for Sass belong here. In here, we can enable or disable minification, set syntax preferences, and more.

/default_site Contains all of our ExpressionEngine templates for the project.

Gemfile The Gemfile works the same as it does in any Rails project. It lists the gems used in the project so a team member can run $ bundle install and install all the needed dependencies (assuming Ruby and the Bundler gem is installed on your machine).

Guardfile Lastly, this lists all of the processes that run as Guard does. We use Compass and Jammit.


This is how we’ve learned (from professionals and experience) to develop websites with the best results. It’s exciting to know this is not set in stone and will continue to adapt as the web does. Although the process can sound complicated, we’re able to build better websites with faster turnaround and a more thorough user experience.

Just keep learning. You’ll never make the web a better place if you aren’t learning, reporting, and putting back into the community. The web is young and we’re just getting started.