Saturday, May 30, 2009

You Didn't Have to Drag Me To Drag Me To Hell

The afternoon is beautiful, sunny, and warm today. Naturally, I went to sit in a dark theater and watch a horror movie. I was interested in Drag Me to Hell both because of its pedigree (written and directed by Sam Raimi of Evil Dead, Darkman, and Spider-Man fame) and because of its rating. It's a PG-13 horror flick. Horror writers who keep to the restrictions of the non-R rating can't fall back on excessive gore, nudity, or constant f-bombing to entertain an audience, they have to stick primarily to actually telling a story. The end results of these attempts usually end up being very good (The Ring, The Others, The Sixth Sense) or very, very bad (The Ring 2, The Grudge, Critters, almost everything the Sci-Fi channel shows on weekends). Happily, Drag me to Hell is one of the good ones.

I've seen the description "old school" in several reviews, and it's pretty appropriate. The movie is deliberately paced and uses the musical score to get the tension up. It's also very campy, but good campy, and more than a little over the top in places. Drag Me never goes quite as nuts as the Evil Dead series, but there are certainly moments that evoke Raimi's old franchise. While the plot is nothing really new (a selfish choice, a gypsy curse, a tormenting demon), and the big twist is very obvious, the way the elements are combined works very well for the film. There's a scene involving a set of dentures that left me both cringing and chuckling. In fact, Drag Me is packed with scenes that have the same effect. And really, what more can you ask of a campy horror movie?

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

task :run do
sh 'java Ear'

task :clean do
sh 'del *.class'

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

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

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

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

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

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

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

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 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.

Sunday, May 24, 2009

Remember to Remember

"True heroism is remarkably sober, very undramatic. It is not the urge to surpass all others at whatever cost, but the urge to serve others at whatever cost."
--Arthur Ashe

To those who have gone before and those who are serving now, one small thank you.

Saturday, May 23, 2009

About That New Terminator Movie

I enjoyed it. Not as much as Star Trek, or Terminator 2, but more than Terminator 3. The trailer gives away the big twist in the movie, not that it's all that shocking to begin with. They've got that over-saturated-gray thing going too much in the wasteland. (Dear movie and video game industries, get a new shtick for ruins now please, this one doesn't look as good as you seem to think it does.) For those that care at all about such things, the movie appears to follow the continuity, such that it is, of the previous movies, completely ignoring The Sarah Connors Chronicles. Lots of action, big robots, nods to the previous movies, and not much else. Like Star Trek, this is a well trod property being done up as a big budget summer action flick. It's entertaining, but ultimately brings nothing new to the table.

The Summer Project 2009, Part 3: Data Design

For the first design pass, I want to simply get a basic representation of the required data and operations to see what they look like together. To start with, we'll need something to manage our accounts. For lack of a better term, call it a Portfolio. The Portfolio should allow us to add a new account and retrieve the existing accounts as a group or by name. We might as well keep the list of categories we are using here too, so we need a way of adding categories and retrieving them. That brings us to the accounts, which have a name and zero or more transactions. It should allow us to rename the account, add a transaction, and (eventually) retrieve transactions by any combination of date range and category. Which brings us to the slightly more complex transaction...

At first glance a transaction's data includes a date, a type (check, electronic transfer, charge, etc.), a number (optional), a payee, a category, a monetary total, and status for voided or reconciled. The tricky bit comes with the monetary total and category. They should probably be represented by one thing because we can't have a monetary amount without assigning it to a category. But it gets even more interesting if we allow split transactions, e.g. multiple category/amount pairs. I can't come up with anything clever to name the category/amount pair, so we'll just say Category/Value for now. Functionally, transactions should allow editing, voiding, and reconciling. Categories will start out as just a name and amounts as just a monetary value.

So the first draft of a simple functional specification broken down by class for the data types might look a little like this (plain font items are data, italics are functionality):

  • Accounts
  • Categories
  • Add account
  • Get all accounts
  • Get account by name
  • Add category
  • Get all categories
  • Name
  • Transactions
  • Rename
  • Add transaction
  • Get all transactions
  • Date
  • Type
  • Number
  • Payee
  • Status
  • Category/Value
  • Note
  • Edit
  • Mark void
  • Mark reconciled
  • Name
  • Rename
  • Category
  • Value
  • Edit
Obviously, this isn't any kind of formal specification, but it does give a nice concise summary of what the data will look like and be expected to do. And since we now have a spec in hand, it must be about time to start actually writing the program.

Sunday, May 17, 2009

The Summer Project 2009, Part 2: Notes on Design Methodology

A great deal of what we call programming is actually breaking down large concepts or problems into smaller ones (a.k.a. decomposition or factoring) and hiding details behind generalization (a.k.a. abstraction). Programmers wield these conceptual weapons against the dread beast complexity, and with our first attempt at requirements in hand we can start to see how they apply in practice. Formally, what we are talking about is how to go from Requirements to Design.

One of the most basic methods we use on initial approach to a problem is to break it down into "things" and "actions." For instance, from our requirements we have several things: account, transaction, category, monetary value, statement, and report. These are the nouns in the language of our problem. The actions are the verbs in that language. Our example has enter, assign, edit, void, reconcile, generate, etc. Notice that the verbs don't really have any meaning without acting on one of the nouns: enter a transaction or generate a report, for example. This is the basic insight behind a style of programming called Object Oriented: every action is tied to the thing being acted upon. (A sentence's verb acts on its object, whence object oriented). You build a program by implementing the objects and their interactions. Most objects have one or more special methods called constructors to create concrete instances of the thing the object describes. To create a transaction, you provide all the necessary data to a transaction constructor which returns an instance of the transaction object with the data you specified stored as fields within the object instance. To add that transaction to a particular account you would tell the account object to add a transaction, passing the transaction object instance to it as part of the command. Object orientation descends from the general theory of imperative programming, a paradigm that describes things via a series of command statements that cause changes to the system.

Of course, the objects and actions view of imperative programming isn't the only way to operate. For example, entity-relationship modeling is how database based systems are constructed, and it descends from the theory of declarative programming. Instead of a program issuing a series of commands to produce the result, the program states the information it wants without regard to how it actually goes about getting it. For example, the form would be similar to this: 'I want the total monetary amount spent under the medical category,' or 'get all transactions from the checking account for the last thirty days.' While this method may sound simpler, it isn't necessarily, and it requires greater infrastructure. (It has to be built on top of something that actually knows how to do the calculations necessary to get the results, usually a relational database management system.)

I can take an educated guess that most of the dedicated applications back in part 0 use the entity-relationship method of looking at the data. But for us at this point, there is no right or wrong choice. Either path will inform how the program is ultimately built. For the purposes of this series, I'm going to start out with the Object Oriented method. Next time, we will actually begin creating a design from our requirements.

Thursday, May 14, 2009

Never Leave a Loaded Limeric Laying Around

There once was a programmer from Nantucket
Who had a very large bit bucket.
He worked for a time
Perfecting his rhyme
But in the end decided, well [The editorial staff would like to apologize for the author's sudden turn. We assume it's the pollen. Or possibly goblins. Whatever it is, it isn't our fault. Nope, we weren't even here.]

Saturday, May 9, 2009

The Summer Project 2009, Part 1: Ye Olde Requirements Gathering

Computers, being machines, do what they are instructed to do, exactly as they are instructed, whether it's what you actually wanted or not. And you can't tell the machine what to do if you can't communicate what you want. Specifically. With every contingency covered. Formally, the task of documenting what software should do (or provide) for the user is called Requirements Gathering. Incorrect or incomplete requirements will lead to a project that doesn't meet its intended need. Overly inclusive or optimistic requirements can lead to epically long schedules and a complete lack of income. Imprecise requirements can lead to bad assumptions and headaches for everyone involved. Requirements gathering is crucial to the success of a software project, and the task goes on from before it is conceived throughout the construction of the software, and often even after a project is complete. It's also a difficult, often thankless task of trying to build a communications bridge between the people who create the software and the people who use it. Neither party tends to have a clear idea of the end goal, especially early in the process. Luckily for me, all the voices I need to hear for this particular project already live in my head.

Now that I've written a whole paragraph about how important requirements are, let me see if I can actually come up with some for my money tracker. Let me see... I need to be able to enter transactions, both coming in and going out, which assign monetary values to descriptive categories. These transactions each belong to a single account, but the categories are the same across all the accounts. There will be more than one account to track. Transactions should be editable, including the ability to void them. I should be able to mark a transaction as reconciled against a statement. Once transactions are marked as reconciled, they should no longer be (easily) editable. I would like to be able to generate reports for a given time period about income vs. outlay and for all the transactions per category across all accounts. That's probably plenty for starters.

I'm intentionally being very informal with these requirements. Sometimes, programmers have the luxury of having a nice, tight, technical set of functional requirements provided to us, but most of the time we don't. Instead, we start with a bit of ambiguity built in, and refine as we go (hopefully with input from all the necessary stakeholders). Next time, I'll look at some ways of figuring out what these requirements mean in the realm of a computer program.

Dracula as it Unfolds

Bram Stoker's Dracula has long been one of my favorite books, and one of the only ones I have ever read that successfully takes the form of a series of letters, journal entries, and doctor's dictations. (Apparently this writing style is technically known as epistolary.) As a result, all the entries are dated, beginning with May the third. A blogger has started posting the book's entries by date in "real time." I think that's a pretty cool idea.

Star Trek Capsule Review

I saw the new Star Trek movie yesterday. For those who might be interested, on the scale of Star Trek movies from V ("What does GOD need with a STARSHIP?", e.g. really bad) to II ("KHAAAAAN!" e.g. awesome), I put it up there with II.

It's going to be interesting to see how Star Trek fans react. It's definitely a different spin on the franchise than the last several TV shows. While the stakes are high, the movie never takes itself too seriously. McCoy and Scotty are played largely as comic relief, as is Chekov, who is there with full on stereotype Russian accent. But the characters are never incompetent, just younger than Star Trek fans will be used to. The reason for that, and the place for this new entry into the Star Trek cannon is explained in a way that perfectly fits into the Star Trek universe. The inspiration for the movie definitely comes from the old series and the movies that flowed from it (especially the previously alluded to Wrath of Khan), and not so much from the Next Generation and its subsequently spawned TV shows. On the whole I think it works better that way.

I have my nitpicks: Much of the movie was shot too close in. Did we really need the bit of Kirk as an angry kid? One scene came off completely contrived, though it had a good payoff. The design work was very uneven; some of the interior ship sets were ludicrous. While most of the Federation ships were given a beautiful retro-future makeover, with the shuttles and the Kelvin being particularly nice, the main enemy ship looked terrible and the new Enterprise was too bulbous in the nacelles for my tastes.

But for every superficial issue I had, there were things thrown in to make fans smile. All the lines that made the characters famous are there. The extreme sports skydiving scene that was so prominent in the trailers was a relatively minor, naturally handled part of the story. There was a green woman for Kirk to canoodle. The Kobiashi Maru. Klingon battle cruisers. Sulu the swordsman. There's even a cooing tribble in one scene for those paying attention.

In the end, this is a different take: a new Star Trek designed as a summer sci-fi action blockbuster. It's an homage, a knowing parody, and a relaunch all in one. Now we get to sit back and see how the box office feels about it.

Headline Hunting

Here's a little gem from the BBC: "Demons 'harmless,' says Vatican." The article is about the movie adaptation of Angels and Demons, but by leaving movie out of the headline, it gives a very different impression, don't you think?

Wednesday, May 6, 2009

Monday, May 4, 2009

Quote of the Moment

"And the skills issue is a red herring; any competent programmer, if given a chance to learn on the job, can become productive in a new software technology within a few weeks."
--Norman Matloff, in a New York Times opinion piece on the state of hiring and careers in computer science.

Saturday, May 2, 2009

The Summer Project 2009, Part 0: Do I Really Need to Do This?

The first question one should ask when confronted with a potential software project is: has someone already done this for me? Under normal circumstances, finding or buying a software solution is always going to be less expensive than developing one. I've got motivation to do this development as a learning exercise, but it never hurts to look at what others have done in the same domain. It's a small part of what business types call market research. To that end, here's a quick survey of the "competitors" for my new money tracking app.

Commercial standalone applications
Examples: Quicken, Microsoft Money
The industry leading solutions, if they can't do what you need you are probably running a small business, and they have a product to help you with that too. I've already explained that these are the basis of what I want, but without all the features I don't use, and maybe some changes for the things I do use. Keeping current with these apps requires repeated monetary expenditure, just as with all commercial software.

Open source standalone apps
Examples: Buddi, GnuCash
Loosly, "Open Source" refers to a type of software license that allows the user to modify the software for their own use. Often these programs are also available free of charge as well. Buddi comes very close to the vision of what I want, but both it and the less user friendly GnuCash use double entry accounting. For my purposes, double entry adds unnecessary complexity to what should be a simple concept.

Web apps
Examples: Mint, Wesabe
Web apps are the coming future that is already here. They can leverage powerful community knowledge and allow access from any machine that can talk to the Internet. And yet... Perhaps I'm a bit of a Luddite, but I don't put my financial information on the web. (Even though I know it's essentially already out there.) Also, I don't trust any web site to still be around in ten years. (Not even my bank, which seems a more reasonable position than it did a few years ago.) One of the best features of maintaining my own records is that I have all the history to look at.

DIY alternatives
Examples: Excel, OO Calc, etc.
Do it yourself bookkeeping using a spreadsheet program is a legitimate solution, but the overhead required to do data analysis can get rough. I don't really have the spreadsheet chops to take advantage of this option. Besides, it puts me right back into being dependent on a program that may change at any time. The largest advantage of this option is the ready and full access to your data.

Honestly, any of these could work, and all have advantages over something I make myself. But stopping now would hardly be educational.

Thoughts on Tomb Raider: Legend and Fallout 3

Tomb Raider: Legend and Fallout 3 are very different games, but that share one thing in common: they both almost worked for me.

Tomb Raider: Legend is probably best compared to Prince of Persia. Both are long running series that have 3D platforming, combat, and puzzle solving elements. Unlike Prince, Legend emphasizes the puzzle solving elements rather than the platforming. Tomb's combat is far better than Prince's, using a more familiar lock-on-target-and-dodge mechanism instead of Prince's button mashing. The environments in Legend are varied and pretty, and the puzzles just confusing enough to slow me down without requiring me to go to GameFAQs for a walkthrough. Tomb runs around eight hours of play time, so it's a bit on the short side. It could have potential replayability due to hidden loot and unlockables, if that's your thing. Lara, the lead character, is given a fair amount of personality (and unlike the Prince, she doesn't sound anachronistic), but the story is weak nearly to the point of being nonsense. Of course, the story is just there as token window dressing anyway. The biggest problem with the game is the one that Prince nailed perfectly: the camera. Throughout Legend, there are camera angles that were perhaps designed to show off the environment rather than facilitate the user's travel through said environment. This leads to numerous occassions where you just have to guess when to jump and hope that everything turns out OK. Naturally, that leads to a fair number of reloads. Legend gave a great first impression that faded somewhat as the game went on. It's a good game, but not a great one. Which brings me to Fallout 3.

I come into Fallout 3 biased in just about every possible way. I love a good computer role playing game, and I love a good post-apocalypse setting. Unfortunately, Fallout 3 is only one of those. The setting of Fallout 3 is right up my alley, and the best aspect of the game is stumbling across something interesting while travelling around its environment. My favorite example was opening up a Vault (think self contained village-sized fallout shelter) to find out, through exploration and a series of hallucinations, that psychotropic gas had been released into its air systems. The Fallout games have a storied history. Fallout 3 does its level best to live up to and expand the world of those games, and I think it succeeds admirably. Unfortunately, the game you have to play to explore that setting is less than fun. The combat system tries to please everyone by blending the turn-based style of the older games in the series with a real-time system. What results from that blend doesn't find the best aspects of either. And the combat happens far too often. The so-called wasteland is filled to bursting with enemies that constantly interrupt the best part of the game, the exploration. The primary plot arc has its highs and lows, and certainly the storytelling makes Legend look embarrising in comparison. Unfortunately, the finale of the game was so poorly handled that it negates a fair amount of goodwill. So much so in fact that the ending is going to be changed in an upcoming batch of downloadable content. Sadly, the art direction comes entirely from the school of oversaturated monochrome. And because it is a console game, there are a fair number of repeating underground and indoor environments that hurt the otherwise reasonably diverse scenery. I put around 25 hours into the game (and I know of at least one person who is over 60 hours in), so it's got depth going for it. Unfortunately, while the setting is brilliant, the writing solid, generally well handled, and even inventive in places, the game you have to play to get at those things never manages to get above mediocre. Personally, I'm hoping that the upcoming Fallout: New Vegas will feature a new game engine, because otherwise, I'll have to stick to my really old school interpretation of post-nuclear Vegas.