Automating your front end development workflow

We all have a workflow. In fact, we all have many of them. Human beings are creatures of habit. In Thinking, Fast and Slow, Nobel laureate Daniel Kahneman describes our use of intuition to remember the steps in our workflows and the order of our workflows. When we wake up, we get out of bed, make our way to the bathroom, brush our teeth, perhaps shower and then make a bowl of oatmeal.

All of this comes naturally and we do it by thinking fast, by retracing the steps we’ve done hundreds of times before. We don’t slow down to think “Should I use the toilet or the sink”. We’ve trained our body to follow a workflow. We can do the same thing with our development workflows by taking some steps to understand how we work. We can then use tools to automate the repetitive tasks.

Looking Inside Our Workflow

Our first option is to use a pen and paper. We can write all the steps we take. This seems a bit archaic though.

Another option is to use Rescue Time

History allows us to see all of the commands we type in the terminal. We also can modify how we save the data slightly in order to generate a nice chart and see when we are most active.

You also could do some user research on yourself and record your screen. You can then go back and identify your pain points. Much like a golfer will videotape themselves in order to see if they have the correct stance, are extending their arms, and following through, you can make sure that you are doing things as efficiently as possible.

Tools To Solve Our Bottlenecks

Not all of these tools will be useful for you, which along with the fact that big changes will make you less efficient,

CSS With a Hint of Programming

Three options that you should check out for CSS Pre-processors are LESS, SASS, and Stylus. These can help you create better

Learn to Love the Command Line

The command line is one of the greatest tools for front end developers. Tools have been built for many years that you can take advantage of. Learning to effectively work on the command line is very possibly the most important thing you can do to improve your efficiency. One thing to keep in mind is:

If you use it more than never, it should have a config

To support this effort, check out the resource Github has put together on Dotfiles. The command line allows you to do a lot of things very quickly. The unix philosophy is that each program should do one thing and communicate effortlessly with each other. This one line of code allows us to take the output of our access log, look for just the URLS being requested and then sort them based on how often they are being requested. Depending on how your access log is set up, this might work out of the box for you

cat access.log | cut -d " " -f 7 | sort | uniq -c | sort -n

The command line also helps us make few mistakes. By using tab completion and typing less, we can reduce our opportunities for small mistakes that slow us down. Two projects that help out with this are AutoJump which makes it easier to type less as you navigate your file system and Auto Completion scripts from Bash It which gives you autocompletion in programs like Git, SSH, Gem, Rake and HomeBrew in a bash shell.

Script Out What You Do

If you are going to do a complex (as in multiple steps) action multiple times, you should script it. I’ve found commander.js to be a helpful tool when writing scripts. It is a node.js library that simplifies script writing.

Put The Control Back in Source Version Control.

After being a proponent of Mercurial for many years, I’ve switched to Git recently. One of the reasons is that Git-SVN has allowed me to always use git, even on projects that use SVN. One of the benefits to Git is that you can use all sorts of hooks to speed up or automate parts of your workflow. You can use the prepare-commit-msg hook to modify the default commit message. Perhaps you want to list all the classes you change when you update your CSS? That can be easy to do with git hooks.

There are also methods available to do things Deploy on push to github or you can have a little bit of fun and take a picture of yourself every commit perhaps?

If You Build It, They Will Come

Build tools save you a lot of time and energy. They automate a process that is hopefully something you do very often, place your code in a different place. Shipping your code is good. The continuous integration server Jenkins is a successor to Hudson. It allows you to set triggers for doing specific tasks, with the most obvious being building to a specific environment. Your triggers can be a commit, a specific time, or a button push (or more with various plugins available. You can run various Build tools.

Grunt is a tasked based build tool that runs in JavaScript.

WP Stack is a WordPress deployment system built on top of Capistrano and also includes a few other tools specifically designed for managing professional WordPress sites.

Forge is a tool designed for improving the speed of developing WordPress themes. It has an opinionated workflow, which might work for you. It allows you to use Sass, LESS, CoffeeScript and Sprockets in your WordPress theme development.

You can also make your own basic script using tools like watch to look for changes. Once watch has fired an event, you can perform any action you want.

Don’t Repeat Your Mistakes, Write Unit Tests

Unit Tests help us by making sure we don’t make the same mistake twice. By making sure that

jasmine, QUnit, and mocha are three different testing tools you can use to write JavaScript unit tests. Check out my talk from WordCamp San Francisco 2011 to learn more about JavaScript Unit Testing.

Compile Time Defines is a concept that will enable you to develop your code in a way that makes unit testing (and also debugging) much easier.

mockjax is a complimentary tool that enables you to override the normal ajax handling in jQuery and thus test ajax functions independently of the backend. It also can come in handy for rapid prototyping.

If you want to write unit test for your php, Nikolay Bachiyski spoke about how Unit Testing Will Change Your Life at WordCamp San Francisco 2011.

Travis CI is a service that allows open source projects to easily run unit tests on every push to github. An example of a WordPress plugin doing this is WP Document Revisions

Put Your Browser To Work For You

Live Reload is tool that has both a Free Command line and a Paid GUI version. It enables you to send a special header that a browser plugin or javascript snippet can detect that will reload the page you are working on automatically. No more going in and refreshing the brother.

dotjs is similar to what grease monkey was. It allows you to write single domain browser extensions (or all domain browser extentions), but does them in a manner that should be easily sharable via github.

sourcemaps make it possible for you to debug concatenated and minified scripts. If you are a web developing Aaron Sorkin fan, you might say that If you haven’t used SourceMaps then you haven’t seen Shakespeare the way it was meant to be done.

phantomjs is a headless browser that you can use for a variety of tasks from scripting the running on unit tests to building the assets for a homepage that millions of people hit monthly.EDIT: Here are four ways that I’ve used PhantomJS to give you some ideas for how you can use it.

Keep Your Code Looking Nice

Code that looks nice and that follows a projects standards is easier to edit later, both by you and by others. There are a number of projects we can use to help us achieve this. The first is Sublime Linter which is a Sublime Text 2 specific linter. If you would prefer an editor agnostic lintor, I am a big fan of Autolint for my JS linting. It gives me growl notifications and lints my files I have it watching every time I save one of them.

If you would prefer a server based linter that runs perhaps as a part of a continuous integration server, Closure Linter is an option from google for doing just that.

For CSS linting, RECESS, CSS Lint, and Closure Stylesheets all do the job reasonably well.

Minimize, Concatenate and Productionify

Two great tools for minimizing and concatenating our javascript files are UglifyJS

and Google Closure Compiler, which use slightly different algorithms. You should check your code against each and, figure out which one gives you the better performance.

Image Optimization

Image optimization can be an important way to save bandwidth which saves you money and can make your site to load faster. OptiPNG, JPEGTran, pngquant, trimage, ImageOptim, imagemin, and Scour for SVG are all tools that will do this for you.

Enhance CSS is a tool that will automatically base64 embed images from your css file. Depending on which browsers you support and where your bottleneck is, this can help you speed up a site, though Sprites might be a better way to speed up the loading of your page. Two projects that automate the generation of sprites areGlue and Sprite Factory. Try them both out and figure out which one works better/faster for your project.

HTML and Other Optimizations

There are also some other optimization tools that you might find beneficial.

htmlcompressor makes your HTML smaller, which can make the download time shorter. confess.js will build an appcache manifest, does simple performance analysis and allows you to list of CSS properties on a page. Inliner is a tool that will bring in all of a pages CSS and JS inline. If you find that HTTP requests are your biggest bottleneck, this tool can help solve your problems.

Now What?

Our workflow is never really complete, it never is going to be perfect, there always are going to be ways to make it better. There are a lot of tools available that can do that. If you find the bottlenecks in your workflow, odds are there is a tool avilable that at least gets you most of the way towards a solution. Find your bottleneck and then find the tool that is your solution.

This post was inspired by a talk I gave at WordCamp Boston 2012. My slides are available on Github. I’ll link to the video of the talk once that is available online.

5 thoughts on “Automating your front end development workflow

  1. h

    “If you use it more then than never, it should have a config”.
    The whole thing was ruined for me, just ruined.

    Reply
  2. Pingback: Things learned from Wordcamp 2012 | Inderpreet Singh

  3. Pingback: WordCamp Boston: Tools to Assist in Automating Your Development Workflow | Oomph

  4. Pingback: dcjq[16] – Tools for Automatting your front end development workflow | aaron.jorb.in

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>