In the spirit of discovery and process, I set out to ask 3 front–end developers to share their procedures when making stuff for the Web. We’ll start with the initial set up of their local development environment and end with deploying the final product. A special thanks to @andyunleash, @zakkain and @ChrisVanPatten for opening up the curtain and sharing their secrets.

Table of Contents ✪ Quick Links

• Featured Developers

  • Gray Ghost Visuals (Dennis Gaebel)
  • Andy Howells
  • Zachary Kain
  • Chris Van Patten

• Tools & More

  • Learn about Tooling
  • Tools Of The Trade

Yours Truly

When I develop locally I’m using one thing – MAMP, the free version. I start with all my projects placed in my httpd directory which can be found under /Library/WebServer/share/httpd on Mac. This allows me to use the local web server address 192.168.1.100 to view my projects. I started using this approach because when Adobe Shadow (now Edge Inspect) was released it only worked with actual IP addresses instead of localhost:8888. Since all my project folders are under httpd I use the 192.168.1.100 IP address to scan for the project I wanna work on and then get to it. I can also jump to that IP address on my laptop running Windows 7 to test IE 7-9.

When I’m actually in the trenches coding projects, I’m primarily using Codekit and Sublime Text 2. After I’ve tinkered for a bit, I’ll deploy to a private viewing platform on a live server. I usually deploy a few different ways depending on the situation/context. One way is to set up a sub–domain or folder on my personal server (or an agreed dev server for client work) and upload my files to that destination. Another approach is to use Koding and call it a day. I find Koding to be quite powerful and extremely simple. It’s a really great platform that gives developers the tools they require directly in the cloud (i.e. Terminal, Git, Ruby, Apache, MySQL). Anytime I need to make a project live or test for development, I just say to a client “Go to http://grayghostvisuals.koding.com/<projectname>.” Works like a charm! After I’ve decided where I want things to go, I’ll upload my files using Fetch SFTP (because it’s secure) combined with its remote/local mirroring capabilities. I just say to Fetch “Mirror my project’s local folder against my live server folder and delete and duplicates” and all my files appear magically on the other side.

Since most of my projects use WordPress, requiring an environment that runs PHP and My SQL is important. I can usually get a consistent result on my local environment against the actual live server environment. I don’t use Ruby, nor do I work on Ruby based projects, so having a server with that capability is meaningless for my needs at this time.

I know it may not be the fanciest of workflows, but it works for me right now based on the project size I take on. I know I’ve left out many other bits in my workflow like applications, browser extensions, managing dependencies, favorite web services, but I wanted to keep it light and discuss mainly the local development and deployment tactics. I’ll save the other items previously mentioned for a future discussion. Suggestions for my workflow? Think you’ve got a tip for me that will make my life way cooler, easier? Please share your awesomeness with me.

Check out my tools on Setapp

http://www.setapp.me/users/grayghostvisuals

Andy Howells » Southampton, UK

My development setup is pretty brisk, but covers all the needs I have for front–end development and tinkering with PHP. Mamp Pro is definitely worth the cash, I originally started out using MAMP’s free version but quickly upgraded for the extra functionality and the better GUI for managing services.

Pro–tip for MAMP Pro, if you want to access your sites via mobile/tablet on your local network/wifi – add custom aliases, like below, one replicating your chosen domain and one using .*.xip.io. Then if you open that in your other devices, replacing * for your server machine’s IP Address it will direct to your chosen domain so you can preview and assess. This also helps if you’re using Adobe Shadow (aka Inspect now because of Edge). Note that if you’re using a CMS/Wordpress for example, you’ll need to edit your site/WP URL’s to reflect the URL you’re using to access it, so in this case, mine would be unleashV4.192.xxx.xxx.xxx.xip.io.

In terms of my code editor I love Sublime Text 2 with Zen Coding and Sass. The ability to add plugins of your choosing and fully customise your coding experience is the main draw for me. Snippets also come in super handy, however, I also use CodeBox for managing snippets – you can save, index and search them in a nice app and a dropdown from the menu bar – it’s much easier than having to remember what your snippet starter was so you can just type in the tags you’ve added and quickly find it and copy it over to Sublime.

I mentioned briefly above about using Sass – this is my chosen pre–processor for CSS and being able to shorthand my code is super efficient and allows you to use variables, and create mixins to further speed up the development process. Adobe shadow as aforementioned is super handy for inspecting on mobile/tablet devices – you need to download the app on your chosen device to get it going and combine it with Google Chrome for the best experience. Speaking of which, Google Chrome is in my opinion the best browser to develop in, thanks mostly to the superb inspector.

In terms of uploading and managing code, I combine the power of GitTower (which manages version control aspects of my coding) with BeanStalk which allows us to have our repositories hosted and automatically push our changes and commits to dev, staging and live server environments. Our development server is a meaty virtual server that is accessible via one of our domains, we usually set our customers up on their own subdomain there during the draft stages and use a simple HTPassword protect to block access from prying eyes! On the odd occasion we need to use FTP – which nowadays is pretty rare – I either utilise the application Flow, a simple FTP client for drag and drop from Finder, or every now and then FileZilla (a hangover from my old Windows days, can’t seem to give it up!).

Company

http://unleash-it.co.uk

Twitter

@andyunleash

Zachary Kain » Ontario, Canada

I try to keep my workflow as simple as possible, but there’s a lot of tweaking going on behind the scenes. The first layer is a set of dotfiles which keep all my hotkeys, terminal settings (I use iTerm2) and commands backed up and present across machines. I recently switched from a 15–inch MacBook Pro to a MacBook Air, and the dotfiles save tons of time getting up and running.

The critical component to my workflow is my favorite text editor, Sublime Text 2. Its real power comes from plugins: GIT Integration, Nettuts+ Fetch and SFTP. These plugins together let me not only pull down files and resources quickly, but deploy projects easily either through Git (which I use hand–in–hand with Github) or FTP, usually depending on the client.

On the coding side, my most valuable tools are Zen Coding (now Emmett) + Sass. Sass makes CSS ridiculously powerful, and Zen Coding keeps writing markup from becoming a chore. I do all my prototyping and mock–ups with code in the browser, and Zen Coding combined with a CSS pre–processor makes that far easier than working in Illustrator. I use Mountain Lion’s default Apache server rather than MAMP (mostly because I don’t want the extra bloat on my 128GB SSD), and Sequel Pro to manage my local databases.

When I’m ready to deploy I use Forklift to push & update files over FTP; it’s kind of disorganized but I still drag folders from my ~/Sites directory (my localhost root containing folders for each project) to the live server. For testing my work with PHP I alias sites.dev to 127.0.0.1 in my hosts file so I can just browse to sites.dev/projectName to see the relevant project. This plays well with previewing designs to clients; I use either localtunnel or showoff.io to create a public link to my localhost, and send that link to clients. This isn’t always reliable, so for some projects I maintain a mirror of their live server on my own hosting. I’m trying to streamline that workflow because keeping the local copy, client server and my personal mirror in sync gets to be really confusing. On top of that, if I have to make quick little changes or bugfixes, I’ll use Sublime Text 2’s SFTP plugin to edit the files live and then copy those changes to my local version.

The only missing pieces now are a handful of helper-apps, most of which can be found on the Mac App Store. Characters is a phenomenal menubar app for copy-pasting unicode characters, iA Writer is my writing app of choice, and I couldn’t live without Alfred, which is hands-down the best launcher application out there.

Company

http://amperedesign.com

Twitter

@zakkain

Setapp

http://setapp.me/users/zakkain

Chris Van Patten » Buffalo, New York

At Van Patten Media, we use a “Frankenstein’s monster”–esque combination of tools and utilities to handle local development and deployment. It took a lot of work to set up, but the results mean smooth multi-stage development and easy deployment between multiple servers.

We primarily work with WordPress, so we built our process around it. In fact, we open sourced it as a framework called “wpframe“, which in turn makes use of

• Vagrant
• Capistrano
• Puppet
• and other neat tools.

Starting a wpframe project just involves a few git commands and takes less than a minute. After running those commands and editing your wpframe project’s config files, you simply run the command vagrant up in your terminal.

Within minutes, you’ll have a ready to install WordPress website—everything short of setting site name and admin login! You don’t even need to enter database credentials. And you thought the WordPress install process couldn’t be faster!

We use Vagrant because it means our local sites are running on an almost exact copy of our remote server. MAMP or similar software often use different versions of PHP and MySQL compared to our production server (and never include the advanced caching software we use). With Vagrant we know that what we develop on is identical to the production environment, meaning we can kill bugs quicker and save more time.

Once we’re ready to share a project with clients, we deploy it to staging. We use Capistrano, a wonderful Ruby utility to help this process. We just run cap staging deploy:setup and then cap staging deploy and within a few minutes the website is installed on the remote server–all we do is enter a password! We have to separately import the database from your dev site, but that’s an easy process too, as we have a Python script that handles the task.

Using Capistrano means that if we make a mistake, it’s painless to fix. Running cap staging rollback will revert to the previously deployed version of a particular website.

Once everything is good to go in the staging site, we run cap production deploy:setup and cap production deploy. Once you import the database from your staging site (again, a painless task with the Python script I mentioned before), it’s boom goes the dynamite. The site is running quickly and painlessly on the remote server and visible to the world!

After that, the process continues sort of like the circle of life. We develop in a local Vagrant copy, then push to staging to give clients a look, then push to production when it’s ready to go live. The process is definitely more involved than what others do (editing live on the server, for instance) but it means that we have mitigated the risk of breaking client sites, and forced ourselves to be more deliberate and meticulous in our work.

NOTE: Chris wrote a more in depth article June 6, 2012 if you’d like to read further about his tools and workflow. http://chrisvanpatten.com/blog/2012/06/dev-setup

Company

http://vanpattenmedia.com

Twitter

@ChrisVanPatten

Personal Blog

http://chrisvanpatten.com