Saturday, May 30, 2009

The Summer Project 2009, Part 4: Tooling Along

The preliminary requirements are in hand, as is a data design. It's time to start putting this thing together. First up, we need a name. Sometimes program names come from marketing departments which have carefully researched the potential customer base, checked with legal to make sure the finely crafted and evocative branding isn't already trademarked or in use, and otherwise fully researched the situation. Mostly though, this doesn't happen until later, and some nutty programmer or manager just makes up a name. Silly acronyms are perennially popular. And so in that spirit, I dub Summer Project 2009 the Electronic Accounts Register. Yes that's right folks, if you are having trouble tracking your money, try sticking it in your EAR. With a name chosen, and a handy catch phrase, the actual writing can begin.

So what do I write it with? Like any craft, programming requires a set of tools. The better the fit between your tools and the task at hand, the easier it will be to accomplish. Unfortunately, it's nearly impossible to talk about programming tools without wading into a bit of a jargon swamp. We might as well get it out of the way.

Virtually all computer programs are written using one or more formally defined programming languages. These languages allow a programmer to control the computer without dealing directly with the streams of numbers that the machine actually uses internally. To be able to use a programming language, tools must be provided to translate the programming language into the stream of numbers the machine understands. These tools are called different things for different languages (compilers, interpreters, translators, and more) but they all work similarly. You feed in the programming language "source code," and the tools "build" the program.

I've chosen to write the application using the Java programming language. Java brings the ability to run on all the major consumer Operating Systems (e.g. Windows or Mac) without needing to rebuild the program for each one. And it has a quite extensive built in library for creating graphical user interfaces. Both of these allow me to keep external dependencies to a minimum. All I will need to develop and test the application is the standard Java software development kit, and all I need to run it is the Java Runtime Environment.

I'm going to be taking a fairly old school approach to writing the code: a simple text editor and command line tools. Most software development these days uses massive programs called Integrated Development Environments that gather a whole host of programming tools into one place. And they are quite nifty, but I'm yearning for something a bit simpler. For an app as small as this one will be I can get away, at least for now, with just sticking my source code files into a directory and running them through the tools manually.

Did I say manually? That's crazy talk. Typing all those commands over and over would be a highly repetitive waste of time. Luckily, programmers tend to be creatively lazy, so there are all sorts of tools out there to automate the process of running a bunch of source code through the things that build programs. I'm going to be using one such tool called rake. Basically, you provide a file that describes how the program is built from the source code, and rake does the typing for you. (And if writing the description file sounds awfully similar to how I've described programming, that's because it is.) Rake also has the ability to check and see what has changed since the last time the program was built and skip rebuilding pieces that don't need to be rebuilt. This can be a huge time saver in large projects. Since we've gone this far without seeing any code, so I'll show you the rake description file for the EAR project as it exists right now.*


task :default => [:build]

task :build => ['Ear.class'] do
end

task :run do
sh 'java Ear'
end

task :clean do
sh 'del *.class'
end

task :rebuild => [:clean, :build] do
end


file 'Category.class' => ['Category.java'] do
sh 'javac Category.java'
end

file 'CategoryValue.class' => ['CategoryValue.java', 'Category.class'] do
sh 'javac CategoryValue.java'
end

file 'Transaction.class' => ['Transaction.java', 'CategoryValue.class'] do
sh 'javac Transaction.java'
end

file 'Account.class' => ['Account.java', 'Transaction.class'] do
sh 'javac Account.java'
end

file 'Portfolio.class' => ['Portfolio.java', 'Account.class'] do
sh 'javac Portfolio.java'
end

file 'Ear.class' => ['Ear.java', 'Portfolio.class'] do
sh 'javac Ear.java'
end


If you stare at it long enough, you might even be able to tell what it's doing. Lines starting with "sh" are commands, just like you would type at a prompt if you were doing stuff manually. The arrow-like marks indicate dependencies. For example, the build task at the top depends on the Ear.class file. The Ear.class file (at the bottom) depends on the Portfolio.class file and the Ear.java file, and so on. As you may have already figured out, the files ending in ".java" are the source code, and the files ending in ".class" are the pieces of the actual program.

At last, with the tool chain in place, it's time to start writing the program.

* A word to my fellow rake users: I know full well the rakefile could be smaller and "simpler," but it sure makes for a straightforward example. Besides, I'm fairly new to rake myself, which means the more verbose version makes more sense to me too.

No comments: