I’ve written in the past about some of the tools I use to do everyday development. In the past six months, I’ve updated my workflow to include some new tools, get rid of ones that weren’t effective anymore, and overall upgraded my development chops. Here are a few of the things I use and how I use them.
I learned web development using Dreamweaver, like many others. What started out as a job responsibility to manage the website led me to doing things with Dreamweaver’s drag and drop editor. Eventually this led me to changing the code manually. That led to an intense love of coding and eventually I settled on Coda 2 as my editor of choice. Coda had so many of the tools I needed baked in that it lasted me through 5 years of development. Recently, I’ve been trying other editors and IDEs. Finally, I’ve settled on Atom, an open source editor from GitHub.
Atom is one part editor, one part community. It’s a hackable editor where almost anything you see can be styled, configured, or edited. There’s a thriving community surrounding the application that create style themes, plugins, and tutorials on how to make it do just about anything. Since I do mostly WordPress and front end development, I have several plugins installed to help with that.
If there is one thing that has helped me move from amateur to professional in web development early in my career, it was the idea that development should occur locally and then be deployed to servers. This paradigm is of the utmost importance as it places safeguards into your workflow preventing many of the mistakes, fatal errors, and production level downtime that can plague a site, app, or project.
Since I need PHP and mySQL for WordPress development, I can’t just use files and then view them in browser locally. Over the years I’ve used lots of different types of local environments. I’ve used my MacBook Pro’s base installs of those applications, I’ve used virtual machines like VVV and HGV sitting on top of Vagrant, and I’ve even explored custom setups and Docker boxes.
Currently I use an assortment of the above environments. I have some sites on VVV, a vagrant setup that was created by 10up, but is currently a community maintained project. I also have a few projects on HGV by WP Engine. This is also a Vagrant setup that is heavily linked to how WP Engine’s servers are setup in production. It includes the ability to switch versions of PHP and several other goodies under the hood. But lately, I’ve been testing Pressmatic, a GUI interface sitting on top of a Vagrant setup. It has some very nice features built in like remote tunneling, SSL, and multisite out of the box and all with one click. It also seems far more stable than its other vagrant counterparts and therefore needs less time for me to be in the environment debugging instead of billing clients for code.
Over the course of my career, I’ve written code in everything from HTML, CSS, JS, Gulp, Grunt and more. I’ve written code for apps and frameworks like Angular, React, NPM, and more. In the course of most days, I write a lot of HTML, CSS, JS, and PHP. That’s where I live and breathe most days.
Overall, flexibility is the name of the game. Working with small nonprofits, I get to choose the stack and workflow. This means a LEMP stack, Pressmatic as my local environment, using Gulp to compile scss into CSS, and running everything through PHPCS with the WordPress Core standards turned on.
But other times I work with large, international enterprise level clients. In these cases, they almost always have a workflow that must be followed. These can include deployment procedures using applications like Rundeck. Many times they require accessing servers and applications using VPNs which can limit the local environment solutions available to that project. Learning to be flexible and solve problems quickly and efficiently is one of the best skills a developer can have.
In the next post in this series, I’ll cover deployment processes, QA and testing, and source code management.