The Unchained Developer- Free Your Workflow and Become Device Agnostic

May 4, 2020

Back in 2011, I was getting frustrated with my aging development machine. It could barely keep up with me, though I resisted getting a new machine because it can be so frustratingly time-consuming to set up a new machine. As I pondered what to do a thought struck me, “you are a WEB developer Ben…. DUH!!” Right, thanks self. The web does not care what device is connected to it. Why couldn’t I also be device agnostic? 

With that in mind, I set off to see if I could truly unchain my development and work from a specific device, and operate from anywhere. Not only was I successful, but I have also been using the same setup for nine years. I have even created patches from my iPhone while riding a city bus to meet a friend for coffee!

If you’ve been pondering the same, I  would like to share how, with a little effort and very little cash, you too can become an unchained developer.

I started out with some strict criteria in mind:

  • Cheap
  • Accessible from anywhere
  • Simple file management
  • Strong security
  • FAST
  • Flexible
  • Ability to tap into other systems
  • Smooth editing experience

Step One – Decouple the development environment

Like many developers, I was running a (M/L)AMP stack on my machine. That meant installing Nginx or Apache, MySQL, PHP, and all other necessary packages directly onto my machine, but what is a web server? Generally, for my work, Nginx or Apache, MySQL, and PHP. It was easy enough to transition those components to a remote machine.

After some research, I selected Digital Ocean as my host of choice. Digital Ocean has been very good to me, over the years. Their offerings are easy to understand and their cost is super cheap. I started with the $5/mo server, and, if your criteria are similar to mine, I recommend you do the same.

When I need more horsepower for running data migrations and other intense processes I simply tell Digital Ocean to temporarily upgrade the machine. In a matter of minutes, I can go from a small, single-core machine to 32 cores and 3,840 gigabytes of RAM! Because Digital Ocean charges by the hour, I can run hefty scripts and only spend a couple of dollars when temporarily upsizing, vs sometimes days of processing data on the smaller machine size. 

The primary limitation I have had to contend with is storage space. Digital Ocean to the rescue again!  They offer a service called “Volumes” that mount directly to the machine. The volume interacts just like an attached hard drive, and you only pay for what you use. Volumes scale up to terabytes in size. I started with a 50 gigabyte volume, at a cost of another $5 per month.

At this point, the hosting cost is $10 per month. For the cost of a coffee and a pastry, I successfully removed my local machine as a barrier for hosting development sites!

Server security

When my laptop was the development environment, the sites and databases were, by default, kept out of the eye of the general public. With the move to the Digital Ocean server came a new concern, security of my client’s data. An unauthorized person stumbling upon one of these sites could have dire legal consequences for both me and the client. 

Digital Ocean provides free firewalls; easy to provision and with a simple UI for management. Using this firewall, I blocked all ports except the web (http, https) and ssh. I went one step further and limited access to only an IP whitelist. This list is manually managed. It does make accessing the server a bit more onerous while traveling, but adding and removing IPs by hand provides a visual indicator that security is tight, and only those machines that need it have access.

Safe on dropped connections

When running a long script locally, it is no big deal to pop open a terminal, start the script, and walk away, trusting it will continue. When running a script via ssh on a remote server you enter a whole new ball game. I needed to have the same confidence that scripts would continue to run whether my connection dropped or not. Enter tmux.

Tmux is an incredibly powerful tool. At its heart, tmux is a terminal multiplexer. Meaning, from a single terminal session, you can create splits into multiple shells, each running its own commands, and different panes. The most important feature to me, however, is that tmux keeps its terminal session running even if you are no longer connected via ssh. That means I can run a command and walk away with confidence it will continue to run. Heck, if I am on a laptop I can turn the laptop off and tmux keeps that command running. 

With tmux, I can even connect from a different device to that same session. That is, in fact, how I was coding from my iPhone while riding a city bus. I had the files open on my laptop in tmux and vim from before I turned off the laptop. I reconnected the ssh session from my phone and BAM, instantly back in the editor, right where I left off.

Another great benefit of running commands on the server is that it consumes zero local resources. That means whether I start the command from my MacBook Pro or my iPhone, it will run without creating a burden on my local device. 

Docker for simplicity

I did not want to get locked into a difficult to manage web server solution and I desired the flexibility to utilize different versions of software, and different types of servers, such as Nginx, Node, and Apache. Docker is a natural fit. It allows me to run client projects in complete isolation of each other.

My preferred way to structure a client project with Docker is:

  • Nginx reverse proxy – Takes care of domain lookups and routing to the proper client site
  • MySQL – I run a new MySQL instance for each client, to prevent information spillage between private client databases.
  • Service 1 (Such as Elasticsearch)
  • Service 2 (Such as Redis)
  • Service N (Whatever else is needed!)
  • Webserver

File management

So far, I have solved the web server side of things. Now I need to get files to the server to develop on. There are three methods typically used:

  • sftp/scp
  • Github/git
  • Direct download

sftp/scp

Both sftp and scp allow you to connect to a remote server to send files. I prefer scp as it is simple and comes with all ssh clients, meaning it is available out of the box on Linux and MacOS. This is the method that I typically use to get local files to the server.

Using scp to transfer a local project to the server is as simple as:

$ scp -r local_project_folder server:/path/to/projects

As a bonus, scp can work in both directions. Call the server first to retrieve files from the remote machine.

Github/git

My preferred method of assessing project code is via a git repository, such as Github. A simple git clone and your files are available on the server. I typically do this via an ssh cli, in fact, I really enjoy the cli so most of my work is done via cli. 

Once the project is pulled from git and all the build tools are installed, you will be able to run composer, npm, grunt, etc., just like you would locally.

Direct download

At times, I may need to download a file directly. Prior to working on a remote server, I would be at the mercy of my internet connection. Let me tell you this, I lived on a boat for nearly four years and the internet was slooooow. If a client sent me a database, it would take all day to download. The Digital Ocean, server has a crazy fast connection and the same download now takes minutes, if that. This saved a ton of time and angst over dropped downloads. The file needed to be on the server anyway, so downloading direct prevented two days’ worth of file transfers!

The wget tool is my go-to tool for downloading due to its simplicity. Curl is also a great option, though. Downloading a file with wget is as simple as:

$ wget https://example.com/file.zip

Smooth editing experience

When it comes down to it, editing text is the primary job of a web developer, therefore, having a smooth editing experience is crucial.

Being a long time Linux guy, and lover of the cli, I naturally turned to vim as my defacto editor. 

Now wait a minute, before you go smirking to Sublime, or VS Code, or whatever the current hotness is, recall that vim has been around for ages. It has a robust plugins system integrating every functionality you can imagine. Not only that, using vim directly on the server frees me from any reliance on a local editor or IDE. I have the freedom and flexibility to really program from any device I desire. I have worked from all sorts of devices: MacBooks, iPhone, iPad, Android tablet, multiple flavors of Windows, and Linux with complete freedom to open a file,  edit, and then reconnect, exactly where I left off from another machine.

A few years back, a buddy scoffed at my “cute little [vim] editor”. He was proud of his Sublime setup. It really was rather nifty. I mocked him right back saying, “vim can do anything Sublime can do, better and faster- and you call yourself a Linux guy….” He laughed it off and we carried on with our projects. The next morning he called, sounding a bit off. “Remember when you made fun of me yesterday for being a ‘Linux guy’ and using Sublime instead of vim?” “Yeeesssssss,” came my hesitant reply, not sure where this was going. “Well,” he angrily spat , “That comment bugged me all day. I decided to pull up vim and prove you wrong! I stayed up all night, trying to prove you wrong and you know what happened? I have a really cool vim setup that is identical to the Sublime setup! I deleted Sublime.”

True story, I swear!

All joking aside though, most editors and IDEs these days do support ssh. It is likely that whatever editor you prefer to use will still be compatible with remote development. Check out the editor support articles for guidance.

That’s it!

And that is really all it took to unchain my development workflow from a single machine and free me up to work anywhere, on anything. I no longer worry about a laptop dying on me. If it goes up in smoke, I can grab my iPad and be back up and running as fast as ssh reconnects. 

Bonus Round – Mobility

I wanted to see how far I could take the unchained approach and continued to push the envelope. To this day, there is nothing I run that requires a specific machine. The “move to the cloud” movement has only made things easier. 

Here are some of the other things that allowed me to become 100% unchained from a single machine:

Communication

  • Webmail, or IMAP connections, via an app
  • Slack facilitates instant team communication. There are apps for everything and a web UI as a fallback
  • IRC. Yes, IRC. The first chat groups I was ever part of were via IRC on the Freenode network, where I am still active today
  • Zoom. Great video conferencing software that requires very little bandwidth to operate

Connectivity

  • In-home wifi
  • On the go, the cell hotspot hits the spot
  • Most coffee shops and many public spaces have free wifi now

Secure connections

  • Use a VPN to prevent traffic snooping
  • SSH tunnels can also be used to route traffic directly to the server

I hope this article has inspired you to become an unchained developer and saved you some time in the process. I love the freedom and stress reduction it has afforded me. If you have a low powered machine that struggles under the weight of your development environment, this could save you big $$$ on an upgrade!

Are you already an unchained developer? What tips and tricks can you share in the comments?

Questions or need help designing your unchained server? I am happy to help you find an answer. Drop me a line on my contact page

Leave a Reply

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