Toni Westbrook dot Com

The Joy of Computer Science and Engineering

If you've ever programmed for an organization with multiple developers, you've most likely used some kind of system to synchronize, combine, and version code. Without a such a tool, changes to the same files amongst two or more people can get very confusing and hard to manage very quickly. However, even if you're just dealing with your own, personal projects, a code repository is still a must.

1 - Versioning

One of the most powerful aspects of subversion is the ability to track changes to your code. I can't count the number of times in the past where I'd make a change to my source and totally botch the program up. And often times, I wouldn't realize the screw up until later on, when it was too late to remember exactly when it had started acting up. With your code versioned (using copious comments), it is easy to look through the history of changes, revert back to a version or just grab the specific lines of code you need.

2 - Multiple Backups

Though it is, of course, possible to manually back up your code, the nice thing about working with a repository is the ease in maintaining backups. First off, if you're actively working on a project, you'll have two copies already - your working copy, and the copy in the repository. And when you backup the repository, you'll be grabbing all your versions and comments at the same time. Combined with having all your repositories in one location that can be easily be grabbed, this makes for an easy to manage solution.

3 - Synchronize Code Between Multiple Computers

Like many people, I have both a desktop and a laptop (well, a netbook), and when at home, I of course prefer the large screen of the desktop. But I also am a fan of enjoying a cup of tea and a little programming at the cafe around the corner from me. Because of that, having code on my netbook is a necessity. Subversion allows me to quickly and easily synchronize my code between both machines, no problem.

4 - Secure Method of Remotely Accessing Code

Related to #3, since SVN can integrate with SSH, it provides a method of securely accessing your code from anywhere in the world. Though I'll normally sync my code to my netbook at home, if I get in a jam and ever need to grab my code from another machine, or if I forget to update my code at home, I have the ability to do so. And since it uses SSH, I simply need to map 1 port on my firewall, no crazy set up required.

5 - Integration With Popular IDEs

With Subversion being so popular, many IDEs and other tools have plugins to integrate the use of a svn repository directly into the program. Visual Studio, Eclipse, Anjuta, and Emacs all have subversion plugins/support. Additionally, Windows, OS X and Linux all have utilities to integrate SVN into the file managers/explorers (E.g. TortoiseSVN for Windows). With all these plugins, it makes using subversion a snap.

So if you haven't already, take a day some weekend and move your source over into Subversion - it'll take a little time depending on how much code you have, but you'll be happy you did in the long run - it's a fantastic tool, whether dealing with 50 developers or just yourself.

WARNING
This borders on a rant - I get into moods where I like to rant, and this is one of them. Treat it accordingly

A (semi) quick thought before I go to bed. There are times in my technology filled life of smart phones, streaming, bluetooth, web 2.0, multitasking, scheduling, interoperability, synchronization, single sign on, and coordination that I honestly just get sick and tired of being efficient all the time. I understand the theory in that by working smarter, not harder, you can get more done - but what's the point?

People have a lot of reasons for being more efficient - one of the major points: getting more done in a shorter amount of time. The theory is that we either don't like doing crap, or there is a reward for doing crap, so we devise ways of doing more crap in less time so we have a bigger reward - this reward being the extra free time we saved from doing the crap quickly, or a payment we received in exchange for doing the crap.

The Fisherman

One of the problems that comes into play is we usually take the time we've saved by being efficient and put it back into activities surrounding the crap again - either working more or devising even better ways of being efficient for work in the future.

My friend Leah had read me a story once, and I'll do my best to only semi-misquote it here. It concerns a business man talking to a guy fishing on a beach. The conversation goes a little something like this:

Businessman: Why don't you go get a job, you lazy fisherman?
Fisherman: Why should I get a job?
Businessman: So you can make it into a career.
Fisherman: Why should I have a career?
Businessman: So you can climb up the ladder, make a lot of money
Fisherman: Why do I need a lot of money?
Businessman: So you can invest it, build up a retirement fund
Fisherman: Why do I need a retirement fund?
Businessman: So you can live out your final days relaxing, fishing on a beach somewhere

Obviously the story leaves out any points of the fisherman having a family, responsibilities, or supporting himself, but the point is still there. The dig here is not against business, but the attitude of the businessman, this "prerequisite of happiness" thing where you're constantly working to get to somewhere that can be reached without doing all that crap in the first place. The bigger paycheck, the larger office, and the faster car always seem more appealing from far away, but when you're actually there, they give no happiness compared to the proverbial sitting on the beach and fishing. And if that truly is the goal, then why not cut out the middle man?

The Driving Force

We live in a nation of bigger, better, faster, compete, win, more, more, more. It's driven into us in a number of ways - we must excel in all that we do. Our country's finances operate on capitalism, and it's a survival of the fittest game. And while this drive pushes us to achieve amazing things and delivers us glory, does it truly make us happier in the long run? Especially considering new abilities are often paired with new issues?

All this is the subject of a much more detailed and lengthy article than I could write, and I'm definitely not arguing against progress. But there are many times in my life when I want to unplug - when I'd rather hand write a letter to a friend than send them a Facebook message, or give them a call on the phone instead of text messaging them. There are times when I don't want to be the fastest or the best, I don't want to be connected wherever I go - I just want some quiet, some peace, and some happiness.

I think what it really comes down to is needing balance - it's something I've been working on quite a bit the last month or so. As odd as it sounds, I need to put more fisherman into my life.

> Open trapdoor
> Go down
> Turn on lantern

I can't count the number of times I typed the sentences above on my faithful Commodore 64 immediately after getting home from school every weekday afternoon. An explanation to the uninitiated: these simple statements were a way of communicating with a style of game known as "interactive fiction", or "text adventure". The particular one that started it all for me was the classic masterpiece known as Zork, where every day I could explore a mysterious underground empire from my room. While the magic of text adventures is an article in itself, after playing Zork once I was completely hooked. Not only did I seek out more adventures to sink my teeth into, I was also lucky enough that my parents purchased a PC for me soon after. From there I discovered the wonder of graphical adventure games, like the Monkey Island series from Lucas Arts and the Kings Quest series from Sierra. From then, and even to this day, I was a complete adventure game junky. No other genre of game could come close to giving me as much enjoyment.

How are adventure games relevant though?

For those who haven’t played an adventure game before, the premise is generally one of accomplishing goals through a series of small tasks. For example, in the popular classic from Lucas Arts, “The Secret of Monkey Island” (spoilers ahead!), at one point in the game it’s necessary to obtain money to purchase a number of items. There isn’t, of course, a pile of money sitting on the ground - that would be too easy. You need to earn it, in this case, from getting paid to get yourself shot out of a cannon at the circus. However, they won’t stick you in the cannon unless you’re wearing a helmet. Guess what? You need to find a helmet, and there is no helmet in the game. There is, however, a cooking pot in the tavern’s kitchen that would fit perfectly on your head. However, you can’t get into the kitchen because the cook won’t let you in…

As you can see, there is a goal (obtain sum of money), and a number of tasks involved in getting there (get into kitchen, get pot, wear it, fire out of cannon). Before you can accomplish a task, there are a number of prerequisite tasks that must be completed first. Each of those tasks has its own set of tasks to complete first, etc. In Computer Science, we call this step-by-step procedure an algorithm.

Algorithms are the heart of programming

Computers, the powerful machines they are, are at their core relatively dumb. They need to be given a list of instructions to follow. They can perform about 4 billion of them a second, but at the end of the day they still need that list of procedures, outlined step-by-step. This is where you, the programmer comes in. Given a goal you wish to accomplish, you must devise a series of steps to lead to that goal, then translate these steps into a language the computer (ultimately) recognizes, such as Visual Basic, C++, or Java.

The same mentality that guides us to get the helmet, to get the cannon, to get the money, is the same process that guides us to be good programmers: to think in steps. A top down approach of taking an overall goal, breaking it into smaller pieces, further dividing each of those pieces into easy steps, until we’ve turned a very large and complex problem into a series of tiny, easy to handle tasks. And sometimes in programming we need to take alternate avenues – just as there is no helmet in Money Island but a cooking pot which makes an excellent substitute, there will be many times in programming where alternative over conventional thinking is necessary to accomplish a goal.

Why adventure games build these skills effectively

The one issue with programming, especially if you’re new to it as I imagine many people reading this article are, is it is a fairly foreign concept. You’re so busy struggling with the syntax of the new language you’re learning that the overall design of the program itself suffers. While this is a necessary part of learning to program, wouldn’t it be great if there were other exercises you could do in the meantime to strengthen your algorithm building skills?

Enter adventure games. They are a great tool to improve your “algorithmic dexterity” as they are enjoyable and usually take place in recognizable situations that you are accustomed to. We all know what a cooking pot is, and we all know we can put it on our head. We know if we turn a lantern on, it’s going to provide light. These are situations we’re used to seeing. However, these common situations put to the extreme focus of step-by-step procedures are what build our instruction-making skills – and adventure games are the absolute masters of requiring this brand of thinking for hours at a time.

So start playing games!

I don’t want to give the wrong impression – learning to program is a lot of hard (but enjoyable!) work, and there are some dry moments when it takes memorization and reading a book/screen. However, when dealing with the flowcharts academia will make you draw out when learning algorithms (a favorite seems to be “Draw out your morning routine!”), or if you’re learning on your own, try supplementing the boring with a little fun. Fire up an adventure game and train your algorithmic brain! Not only will you build a necessary skill, but you’ll also have fun doing it.