Developing on a Cloudy Day

March 12, 2014

“Cloud” is perhaps the new “Web 2.0” in terms of its efficacy as a buzzword. Everything is moving to it, everybody wants it, and quite a few people don’t understand what it means. We better get ready, too. But both terms are actually quite easy to define. Web 2.0 can generally be defined as Internet resources (read: websites) where a significant portion of the content is user-generated. Cloud simply means using a remote computer (usually owned by a corporation) to do some type of work or storage instead of, or in-tandem with, your own computer.

The cloud is not without its problems, however. It is an abstraction of interaction with computers in the sense that it becomes a service, rather than something you “own.” There are many great options for cloud storage, and most offer a free tier with limited space. But people have a lot of stuff (as we’ll discuss below), so many will pay to increase the storage. And it may be worth it, considering that storing content in the cloud means that it is extremely safe from hard drive failure; cloud providers worth their salt always maintain redundant backups. But it also depends on trusting your files to a corporation. It depends on maintaining good security practices. It also usually requires installing non-free software, which some take issue with. Despite these potential pitfalls, the cloud can be a developer’s best friend.

We live in a world of devices, all of which vary wildly in capabilities. As an example, I might own a laptop, Android phone, iPad, and video game console. It’s now not uncommon to find the same application available on most or all of these platforms. Developing for these different platforms, including web development, creates immense implications for both developers and consumers.

15 years ago, a primary technical challenge was optimization. A significant problem back in the day was resources: conserving bandwidth, conserving RAM, conserving CPU cycles. With low-power devices, optimization is still an important component to the art of programming, but today the developer must consider device compatibility foremost. Even if the developer is rollin’ in phat stacks, livin’ on Easy Street and/or has life made in the shade, he or she still will likely have to target no less than 3 discrete platforms and is usually expected to make the experience work equally well within the limitations of each platform.

So, people have lots of stuff. We increasingly expect to be able to access all of our TV shows, pictures, personal videos, and whatever else you might be able to think of, in some form, on all of those things. So, people have lots of things. Because we’ve reached a sufficient level of bandwidth*, the Internet’s ubiquity has lent itself well to syncing our stuff to all of our things.

As a developer, this can be seen as a boon or a bad thing. On one hand, syncing files automagically means that I can begin development on one device and pick up the code on another, perhaps in another physical location. But this creates a problem: development requires the use of tools. These tools usually have configuration files that are imperative to working. Using cloud storage and very simple shell commands, it is quite easy to sync these settings between systems (say OSX and Windows).

To demonstrate, let’s take a look at the file-sharing program, FileZilla. This free and open-source (holla holla git dolla) FTP program is fantastic for fetching and uploading files, a common task for web developers. One of the key configuration aspects is the “Site Manager,” which allows saving FTP connection credentials. Because who wants to remember an array of hosts, passwords, and ports? This is driven by an XML configuration file. According to the FileZilla FAQ, this file is located in ~/.filezilla on good operating systems, and in %appdata%/FileZilla on Windows.

I’ll use the powers of the shell and the cloud to become Captain Planet sync this file between my OSX laptop and Windows desktop. The zero-th step is to make sure FileZilla isn’t running. If it is, it may make changes we don’t expect to the file. The first step is to create a place on Dropbox to store the file. I use Dropbox for many purposes, and I don’t want a dog-gone floating XML file in my root Dropbox folder, so I’ll create a folder inside it called “config” to store the file, using the Terminal rather than Finder because that’s hardcore, bro:

So now we need the file within ~/Dropbox/config and FileZilla obviously won’t be able to find the file if we just move it there. If we just copy it, it won’t be very synced up, will it? If only there were a way for the operating system to combine these operations. Well, thanks to the wizardry of transistors, this is possible! It is known as “symbolic linking,” and is actually a very basic command:

[bash]ln -s ~/.filezilla/sitemanager.xml ~/Dropbox/config/sitemanager.xml[/bash]

This creates a symbolic link, essentially creating a sort-of omnipotent ghost-file that mirrors the original. Changes made to either “version” will stick in both, and it will be accessible from both locations. The key part of the command is the -s flag, which results in the link being “symbolic,” rather than “hard.” For this purpose, we don’t want those.

Now that the file is in the Dropbox, it will show up in the Dropbox folder on the synced Windows machine, with any changes I might make on the Mac side. The next and final step, you might guess, is to create a symbolic link between the Dropbox copy and FileZilla on Windows’ copy. It’s just as straightforward as in Unix-land, surprisingly. The command name is different and no flag is required, unless you want to sync a directory, in which case use /d as a flag on Windows:

[bash]mklink “F:\Dropbox\config\sitemanager.xml” “C:\Users\Chris\AppData\Roaming\FileZilla\sitemanager.xml”[/bash]

Now we have a configuration file accessible by the program on both platforms that is synced between them. If I add or alter credentials on one side, they’ll update on the other. And this isn’t just limited to FileZilla: any development environment can likely be managed this way. Another practical, although more in-depth use-case is to sync Apache configuration between MAMP on OSX and WAMP or XAMPP on Windows.

There is one security consideration, however: Your files are now online (and on the provider’s server), so secure credentials and encryption are essential to prevent snooping eyes. As a double-security-whammy, in this case, the XML file contains FTP passwords in plain-text. Thankfully, the files are stored encrypted by Dropbox and transferred over SSL. This makes the password the weak point. Barring a bad password or malware on your device, the only third party that should be able to get at your files is your friendly federal government agency.

So embrace the cloud! You can still own your files (just kidding NSA lol) and keep them synced. It makes it a lot easier if you use different devices to develop. The time you save dealing with configuration twice can be spent building something better.

*Well, it’s enough bandwidth, but we could really do with more. Thanks to our amazing American infrastructure, being able to upload 75 kilobytes in just one second (while being promised “up to 100”) is commonplace! Bravo!