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 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:
- 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.
- 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 installin 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 installto get caught up.
$ 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.
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:
- Structure: Perfect for giving clients a visual of their site and allowing them to easily add and manipulate site content and hierarchy.
- Stash: Takes template partials and embeds to a new level. We’ve barely tapped the surface with this addon and we’ll continue to keep learning.
- Wygwam: Best WYSIWYG editor so clients can easily change content and see the final result.
- Zoo Flexible Admin: Simplifies the client experience as they administrate content and settings for the site.
- Focus Lab LLC’s EE Master Config: Most refined config setup to make multi-server projects a snap.
- Nerdery CP Theme: We aren’t satisfied with the default ExpressionEngine CP theme so this smooths the rough edges. It removes the pink, fixes some button UI, etc.
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.
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:
- config.local.php: Local database connection
- config.dev.php: Development database connection
- config.prod.php: Production database connection
- and any other miscellaneous connections for staging servers, etc.
/_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.
/_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:
_ee.scss: Used for ExpressionEngine styles like user messages, WYSIWYG styling, and “no entry result” messages.
_form.scss: Standard form element styles.
_normalize.scss: Normalize by Nicolas Gallagher. Rather than use a hard “reset” we normalize all the browser defaults to a consistent style.
_pager.scss: Styles for the Reusser Design “Pager” plugin. Enables Ajax-pagination on ExpressionEngine content.
_print.scss: Print stylesheet provided by HTML5 Boilerplate.
_smallest.scss: We’re pushing to a mobile-first approach for responsive design. Loading the smallest stylesheets first makes for a faster-loading site. Big thanks to the guys at Sparkbox and the Build Responsively Workshop for this method of development.
_update_browser.scss: A simple message that notifies IE 8 users and lower that their browser is not supported. We’re taking the Google approach on browser support (supporting the latest version and one back). If it’s good enough for the behemoth of the internet, it’s good enough for us.
styles.scss: We @import everything into this stylesheet so everything gets compiled and minified here on-the-fly.
/_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.