Cloud Folders Increase Productivity

Being a web developer, I usually use several different computers on different operating systems across the lifetime of any project. Personally, I have 5 computers plus one server: Access to a Vista PC, a Windows 7 virtualized installation, my main Mandriva Linux desktop, a Eee 701 PC with Eeebuntu, a Mandriva Linux laptop, and a FreeBSD development server.

Moving files from one computer to the next used to be a time-consuming and ultimately prohibitive process. If I wanted to, say, take a break from working on my PC and work at the Red Brick Cafe for a few hours, I’d have to download my work files to a USB memory card then export the MySQL database and do the same transfer again to the USB memory card.

Or, I could burn a CD. Of course, how does one get the updated files back off the laptop and onto the PC when arriving back at home? This arduous process basically meant that freedom of choice in the work environment was severely hampered and was often more trouble than it was worth. But not any more.

Enter Dropbox.

Dropbox is a free service that is basically a shared folder in the cloud. It makes sharing files amongst any computer, whether it be Mac, Linux, or Windows, easy as drag and drop. And I really mean that. I love things that speed up my work processes because the less time I spend in administration mode the more time I can accomplish tasks in programming mode. Dropbox exemplifies this manifesto.

Any file you put in the Dropbox folder on a computer will instantly be available on any computer that install Dropbox on. Even better, revisions are kept so if you make a mistake with a file and don’t have backups, you can pull the file in question from the archives to restore it. What makes Dropbox different from any other revision or archiving setup is that this is all done without any administration by the user. Literally if you drag a file into the folder, all this stuff is done for you. No committing changes, no crazy hoops to jump through.

Oh, and the 2GB storage starter account is completely free. It’s the one I use daily. I don’t even think I’ve hit 25% capacity yet.

Source Control – svn + ssh (subversion to the rescue!)

There comes a point in any developer’s life where he/she must work with one or more people on the same project. What’s the correct procedure? How is this done? There are a number of different ways. Some good, some bad.

The Bad: You may have a method in place where only one person can be working on a file at one time. You have to notify the other developers that the file is free when you’re done with it. They download the latest copy every time and so do you so as to not overwrite the work that was just completed.

Some of you may say “Well, why is this bad? We’ve done this for months! It’s worked out pretty well so far!” There are a number of different answers to this question, which I’m going to deal with right now.

This is a bad method because time is money and this method is much, much slower. What is a programmer to do while he or she is waiting for the file to be free for editing? Read blogs?

Time is money.

If the company had source control, both programmers could essentially be working on the same file at the same time. I say essentially because technically they both have their own versions of it and the source control program (Subversion is the one I would like to write about today) will merge their changes together intelligently. Oh wait, this isn’t good. Now you won’t have time to read my blog because you’ll be working!

The second reason the “one person, one file, one time” method is bad is because it’s extremely risky for accidentally deleting work and wasting hours of productivity. As a developer, you should be constantly using and building work methods that prevent failure at any level you are involved with.

How would you feel if you worked on a function for two hours, then because someone overwrote the file with their copy all your work was lost? The reverse is also true: How would you feel if when you saved your work you accidentally overwrote a day’s worth of work and changes?

Time is money. Again.

“But before you save your file you can make a backup of the original file!” I hear you saying, way in the back. Of course you could, but how far do you want to take that methodology? Will you remember every time? Will everyone who works on the project remember, every time? What if it’s a one-line fix? “Oh, I’ll just log in quickly and fix that typo.” and the like are sentences that run shivers down my spine when thinking about using this method.

So the person logs in and fixes the typo. Because it was a small fix, they never checked to see if anyone was working on the file. So now we’ve got two changes that need to be merged somehow. I’m sure that person will be wondering the next day why the typo has reappeared after you save your file!

Okay. So what’s the solution then, smarty-pants?

The good: The solution is source control. It’s not new. It’s been tested and proven multiple times in the computing industry and there are some big players that use it. There are a multitude of different kinds that do some different things, but to the layman the simplest way to look at it is to use a common source control program called Subversion. Everyone’s heard of it, a ton of people use it. Nerds of different flavors will tell you there are better ones out there, and that may be true, but Subversion works. For a lot of folks.

The concept is simple: A project is set up in the Subversion software. Two programmers “check out” (think of checking out at a grocery store) a copy of the project on their computer or development server and work completely independently.

Programmer “Jane” and “Jack” are both working on the same project. Jane is building a module not related to Jack but in a few cases they may modify the same files. That’s no cause for concern, deliberation, or communication. They happily keep on working until their particular task is complete.

Jane finishes first and “checks in” her work by “committing” her work to the Subversion server. Everything goes as planned and her work is then “committed” to the main project files. Jack finishes his work a few minutes later and attempts to check in his work. Uh-oh! Jack’s copy of the project is slightly out-of-date! No big deal, he issues the “svn update” command and all of the files Jane edited are updated on Jack’s computer. Any changes to the files that they both worked on are merged automatically.

After he has updated his copy of the project he commits his files and goes home for the day.

Wow! Sounds great. But what happens if Jack deletes parts of the source code that Jane edited?

This sort of thing is called a conflict. They’re pretty rare and in most cases you can resolve the conflict in a few minutes. When you edit a file that is marked “in conflict” by Subversion, it shows the added and removed portions. You can make adjustments based on which is correct and issue the “svn resolve” command to consider the issue resolved then commit the correct version.

Cool beans. How do I start?

First, you install Subversion on your server. Programmers will connect to this machine, “check out” a copy of the project, and begin work. In most cases, installing Subversion takes less than 10 minutes. You should check with your particular Operating System documentation to see how to install Subversion, but in Mandriva Linux you can do it through the command-line with this command (logged in as root):

# urpmi subversion

After installing Subversion, you will need to pick a spot on your hard drive where you want your project files to be located. For me, that’s almost always /home/svn. Change directory to your project directory and type:

# svnadmin create <projectname>

This will create a directory and place the important Subversion bits inside it for this all to function. Make sure the directory (and all subdirectories) are writeable by the group of users that will be working on the project by first first changing the ownership to a particular user and group with this command (run as root):

# chown -R user:devgroup <projectname>

This command makes the project directory and any directory inside of it owned by user and associated with the devgroup group. After this you will need to set the permissions on the directory so that the devgroup has read, write, and execute access to this directory. We do that by executing this command (run as root):

# chmod -R 775 <projectname>

Great! Our project is ready to roll. Note that this assumes you have ssh enabled on this server (very likely by in Linux, FreeBSD, and in fact most others *nix variants).

Next, we’ll need to check out a copy of our project. Stay tuned for that tutorial, coming soon!