Chris Holmes Online

I had no intentions of writing any sort of review for this film. It is over a year old now, and it is not relevant to the current release schedule. I try and only write reviews of films that are currently open. But this film arrived via NetFlix and I pushed it into the DVD player like any other.

And then something happened…

This is a rare film that touched me in a rare way. So rare that I can only recall one other film even coming close to having the same impact on me. (Which film was that? I’ll make you wait until the end.)

“The Fountain” is a film that is difficult to describe. In fact, I’d say it’s impossible; pure folly. It can’t be done without the description sounding completely and utterly ridiculous.

“The Fountain” is the rarest of films. It is ambitious, beautiful, multi-layered, and difficult to follow on the first viewing. It is a rich story with more elements than you will grasp upon the first glimpse. And therein lies its power: it is such a deep, complex, layered piece of work that words do not even begin to do it justice. It requires the visuals (and repeated viewings) for full appreciation to take effect. In fact, it requires even more than that: it requires conversation. It requires debate with other people who have seen it. Then, and only then, can it really be appreciated for what it is.

To say that “The Fountain” doesn’t follow the conventions typical of most films is an understatement. Is it a science fiction story? Yes, but not as you know science fiction. Is it a love story? Yes, it is that too, but not as you know love stories. “The Fountain” is something else entirely.

I said describing it is pure folly. It is, but I have to begin somewhere.

“The Fountain” is the story of Tom (Hugh Jackman) and Izzy (Rachel Weisz). Izzy is dying; she has a brain tumor. Tom is her husband. He also happens to be a research doctor who is trying to find a cure for the tumor. His experiments on monkeys have lead to an amazing discovery. Trapped inside the bark of a tree seems to be a way to stop aging…

But that is only one story, and already I have misrepresented what “The Fountain” is. It is not the story of Tom and Izzy. It is actually three different stories about Tom and Izzy, in three different time periods, told together in one film. That there are three stories inside this film is enough to confuse some viewers. That director Darren Aronofsky cuts back and forth between all three stories without warning, using techniques that purposely blur the differences, makes it even more difficult. But that is part of the art of the film.

The other two stories take place in different times. The second story – and the one the film opens with – is the story of Tomas the conquistador searching for the biblical “Tree of Life” hidden among the Aztec empire in a lost temple. Tomas has been sent there by the Spanish queen, Isabelle, during a time of great trouble in the Spanish empire. This story is a fiction, however, and Aronofsky doesn’t let us flounder in confusion too long before revealing to us that it is the work of Izzy, who is writing a book called “The Fountain”. There are parallels between the fiction of “The Fountain” and Izzy’s real world, as Tom discovers when he reads her manuscript.

Then there is a the third Tom. Tom Creo, traveling through space 500 years in the future, in a spaceship that looks like a glass bubble. The ship contains only a tree, Tom, and Tom’s ghosts. Tom passes time in the bubble ship by doing Tai Chi, giving himself tatoos, and conversing with his ghosts. He stays alive by eating from the bark of the tree… Is this story a fiction or real? This is part of the debate of the film…

I’ve described the three stories, and as I thought would happen I’ve done nothing to convey the power of this film. I am convinced it cannot be done with the written word.

The power of “The Fountain” comes not from the three individual stories, but from how they are woven together by Aronofsky to create the larger fabric. All three stories work on their own in small, specific ways, but woven together they achieve something entirely new, and you begin to see themes overlap and ideas emerge, and then the power of the whole story begins to take hold and you realize that there is a lot more going on than what seemed to be at first. By the end of the film you’re not 100% sure what you just saw, but you know there’s more to it, and you’ll want to discover what else is out there.

The movie does not explain everything. It is not a film for the dull or slow of mind. It does not lead you down a singular path. Some portions of the story are open to interpretation by the end credits. But “The Fountain” is not really about clear cut answers. It is about impact; it is about creating emotion in the audience, and given the right audience member, it does this very well.

I should mention one other thing: “The Fountain” has some of the most jaw-dropping beautiful special effects I’ve ever seen on film. The budget for “The Fountain” was small, so to create the effects they used a technique called “micro-photography”. I do not know what that is or what it entails, only that it created imagery like I have never seen before.

I wrote at the beginning of this review that I’ve never been this affected by a film before, except once. There was another science fiction love story that I’ve seen that had a similar impact, but not nearly as great as “The Fountain.” That film was Steven Soderbergh’s “Solaris.”

“Solaris” had some powerful ideas, and I left that film feeling quietly giddy; happy that a director had created a love story with that much thought and depth, without all the cliches and predictability of similar stories. But I did not ponder on it nearly as long as I did with “The Fountain”. With “The Fountain”, I turned off the DVD player and went to bed, and for the next two days I couldn’t get it out of my head. I thought about every aspect of it, every idea, every theme, every moment, every visual, and when I finally felt like I had digested it fully, I felt in awe. The only thing I could think was, “I’ve never seen anything like this.”

“The Fountain” is not a perfect film. Some of the transitions between the stories make it overly difficult to follow, and some of the obscurity simply isn’t necessary. Fifteen minutes into it I thought for sure I was seeing a total bomb. But while it may not be a great film, it is a powerful one. The themes and ideas in it are strong and thought provoking, and the love between these two people is of a magnitude that is incredibly rare. You will leave this film thinking that every man should be lucky enough to have an Izzy, and every woman should be lucky enough to have a Tom.

And if you’re really fortunate, you’ll leave this film with your head spinning, your brain fully engaged, and your senses overloaded. And you’ll be happy.

Recently at work I was asked to review some code with a coworker who was concerned with the way her code look. It didn’t seem “right” to her, and she wanted to me to look at it and see if there was a better way.

The code had unit tests and FitNesse tests and the code coverage statistics revealed that it was covered 99%. It was a complex piece of business logic and it did what it was supposed to do according to the tests; they all passed. But still, my coworker didn’t feel like she had written it as well as it could be written.

“It seems too procedural,” she said. So I took a look.

It was a single class that consisted of one method; it’s job was to perform calculations on some values on a given business object. The method consisted of 433 lines of code. Sure, it was broken up into smaller private methods that were a bit more descriptive, but it was still 433 lines of code for a single method call. And there were comments littered throughout the code informing the reader of what it was actually doing. See, despite the dozen or so private methods that had descriptive names, you still couldn’t follow it by just reading the code. It was too complex, a by-product of the code being procedural.

The length and complexity of the code wasn’t the only smell. The unit tests gave off their own oder as well. Some of the unit tests were as many as 30-40 lines of setup code; tons and tons of mocks just to test one path through the code.

To my coworker’s credit she recognized the deficiencies in her code. She knew it was too procedural, she knew the tests were too big and required too much setup, and she knew that the entire solution needed to be more object oriented.

She just wasn’t quite certain how to get there.

We started refactoring by first asking the question: What is this method doing? What is its responsibility? At first glance, it looked like it was supposed to do one thing. But when I prodded my coworker further we both realized it was actually doing six different things. Six different things in one method; that was too much work.

So we left her code behind and started with a new concrete implementation of the main class, implementing the interface that the original class implemented. We began by asking questions about what each responsibility inside that giant method call was, and what might a class look like that would implement just that single responsibility. The outer class and the single method call would then become a simple coordinator between all the smaller classes.

When we finally started coding, we creating those classes, test first. Each little class got its own test fixture and group of unit tests. The logic in the 433 line of code method started to get pushed off into he smaller objects. Since they were small classes responsible for a single responsibility, the code that got pushed off actually became smaller. There was less to do – less branching – so the result was a tight unit of code that did one thing and did it well.

Slowly, piece by piece, bit by bit, the giant 433 line method got broken up and reformed into a new method that called the tiny classes where appropriate.

We didn’t finish the entire refactoring that day, but we were well on our way to a much better design. And the process was a great learning tool. My coworker got to see how procedural code could be turned into an object oriented design, and how certain small classes could be reused in the larger algorithm.

At the end of the day my coworker turned to me and said, “So I guess if a method is larger than my screen, I need to rethink it, huh?”

And I thought: that’s a great rule of thumb. It is one that I have followed for quite some time in a sort of instinctive way. If I find myself writing a method that ends up being larger than my screen in Visual Studio, I know there’s a chance to refactor to a better design. Methods shouldn’t be that big.

When we left work that day I felt a great sense of accomplishment, and I know my coworker did too. She learned a lot, and our code quality improved significantly. The FitNesse tests will still pass when we complete the refactoring, so the end result won’t have changed much. But a big win still occurred: our design was better and would be much more maintainable moving forward.

I am not your average music listener. I’m a guitar player, and that skews my opinion on music quite a bit.

I like to think of my music listening history in terms of B.G. and A.G.

Before Guitar and After Guitar.

Before I learned to play the guitar, I just listened to whatever was on the radio. Whatever was popular is what I listened to, and I fell into lockstep with the rest of the world like all the other sheep.

After I learned to play the guitar I started seeking out more diverse music to challenge my own abilities. I was looking for music that was difficult play; music that contained elevated musicianship and technical excellence. Music that was not confined by the stringent requirements for radio-friendly circulation. This is when I discovered Dream Theater and progressive rock. Rush, Yes, Enchant and a host of other progressive bands soon followed, and I quickly fell away from mainstream music. I turned off my radio and turned on my CD player, and never really looked back.

Progressive rock was the music that grabbed my heart and mind at the same time. It challenged me as a listener and a musician. It is the most diverse, complex, rich and rewarding music for me to listen to.

But that doesn’t mean that a more mainstream tune can’t strike a chord deep within me and resonate. I still have a lot of favorite mainstream music in my library: Where The Streets Have No Name, by U2, for instance. But in order for a “pop” tune to grab me, it has to be exceptional; it has to have something special.

When you fall away from mainstream music like I did, it can be difficult to find new music that you like to listen to. Progressive rock, for instance, due to the complexity and the length of the songs (frequently 8-10+ minutes in length) doesn’t get a lot of radio play. So discovering new music can be challenging.

Enter Pandora.

Pandora is a unique kind of internet radio station. You select a song or artist, and Pandora starts playing music that has the same qualities as that song or artist. Each time a song plays you can give it a thumbs up or thumbs down (or stay neutral and not do anything). A thumbs down causes Pandora to stop playing that song immediately, and try not to play others like it. A thumbs up and Pandora will try to find more songs and artists with those same qualities.

Because progressive rock is so diverse it contains many different qualities, from metal to rock, jazz to punk, classical to blues. So giving thumbs up to a few progressive rock tunes can give Pandora a lot of leeway to find matches (or so it seems). I’ve had some really interesting suggestions come across my radio station; some good, some bad. Quite often Pandora will suggest more “mainstream” (I hesitate to use the term “pop”) music songs to me. Most of the time I just pass, but then this song came across my radio station, and I stopped dead in my tracks:

Click here if YouTube gives you an error message.

The song is “Roses” by the band RPLW. I had never heard of them before. You probably haven’t either. But that doesn’t change the sheer jaw-dropping greatness of this tune.

This is simply the best pop/mainstream song I’ve heard in a decade. It is from their 2005 album, and it’s a shame that it didn’t get any pub/circulation. I can’t think of any song to land on the radio in the last decade that I’d rather here more than this song.

With a new season of American Idol underway, I had to post this. This is what pop music should aspire to be. If everything were this good I think I could turn my radio back on.

What if?

This is the question that famed author Stephen King asks to spark the ideas for his stories. What if an author was kidnapped by his most devoted fan? What if pets came back from the dead? What if a virus developed by the military got loose and killed 99.9% of the Earth’s population?

What if?

Cloverfield asks this question too, maybe as well as any Stephen King novel ever did. Although King had nothing to do with the creation of this film or its story (it is from the mind of up-and-coming J.J. Abrams, creator of Alias and Lost), Cloverfield is definitely from the same neighborhood that King’s creative mind lives in.

What if a giant creature attacked Manhattan? What if you were there? What if you had a video camera?

There’s a word for what Cloverfield is, and that word is creative. It’s also derivative, but derivative film has never been done this well. It is not that we haven’t seen this sort of thing before; we have, just not like this. We’ve seen giant monsters before (Godzilla) we’ve seen hand-held cameras used to tell a story (Blair Witch Project) and we’ve seen humans running in terror (28 Days Later). But we’ve never seen it done quite this way, or quite this well.

The camera isn’t just a means to view the events in Cloverfield. It is a character in the film all to itself. It is the one constant in the chaos from beginning to end. It is also possibly the best use of a video camera prop in any film to date.

Yes, this does have a drawback: The camera shakes. This is very much a home video of human beings dealing with an unbelievable, terrifying disaster that their minds can barely comprehend. And that means shaky camera shots: flashes of people running, darkness, feet, legs, rubble – everything you might expect from people who are pumped full of fear, adrenaline and shock as they run for their lives.

But unlike the intentionally shaky camera in the recent Bourne films, this works. It works because director Matt Reeves knows when to give us a big, juicy bite of the action; he knows when to give us the payoff. He has an uncanny sense of just how long to withhold the obvious camera angle from the audience while he builds the yearning, and then he knows exactly when to give them just what they’re craving.

Cloverfield is not a deep story. It doesn’t have time. There are no convoluted plots, amazing heroics or slapstick comedy. It is very much an answer to the question of “what if?” Abrams and Reeves don’t waste time with story elements that don’t fit. Instead, they ask the question “What if a monster attacked Manhattan and you were there to witness it with a video camera?”

And then they answer it. And boy, is it a great answer.

Pay special attention to the very last scene – watch the ocean very carefully…

Recently, I started looking at ways to implement a feature in our application that we’ve had on the back burner for a while: saving settings.

As an example, one portion of our application utilizes dock window panels. The reason for these dock panels is to give the user more flexibility to layout the screens as they choose. However, customizable screens are pretty pointless if the user has to re-organize their application every time they open it. In order for customization to work, the settings need to be saved between uses of the application.

We use Infragistics controls for our docking panels. I wasn’t exactly sure how easy or difficult it would be to save those settings, so I fired up Google and found this article on the Infragistics website.

I’m going to quote the relevant part here, and let you see what the folks at Infragistics have to say about this:

In a standard Windows Forms application where all of the user interface components and events are accessible from within the application, we would normally handle the main form’s FormClosing event and in this event, we can simply call the DockManager.SaveAsXML( ) method to save it easily. Due to the nature of working with CAB and the nested SmartParts and Workitems, it is not so simple to handle this situation in the same way.

Actually, it is. I’ll get to that in a minute after you read their recommended approach, which I find unacceptable:

To handle this scenario, we can listen to the events fired by the UltraDockWorkspace whenever we make a change to its controls and then we can save the Layout. This means that whenever we pin, dock, float or resize any of the controls, we will be saving the Layout. This should not raise any concerns because it does not happen so often. If you are saving the layout as a stream and writing it to a remote database somewhere, then this may introduce some performance related issues, so as an alternative, you can always save to a file on disk and when the application closes, you can stream the file to the database just once.

This is over-complicating the solution and trying to dismiss performance as a non-issue. That’s just wasteful, in my opinion, when there are better, simpler solutions to be had.

The truth is that it is actually very simple to handle this in CAB with an EventBroker event.

First, in the ShellApplication class, subscribe to the Shell’s ApplicationClosing event. Just the old fashioned way – wire that puppy up with += and get an event handler established. Inside that event handler you fire an EventBroker event, like so:

RootWorkItem.EventTopics[EventTopicNames.ApplicationClosing]
   .Fire(this, new EventArgs(), RootWorkItem, PublicationScope.Global);

You don’t need to declare an EventPublication – just fire the event through the RootWorkItem.

Now you can subscribe to this event anywhere you like: Presenter, WorkItem, View, doesn’t matter. Using a plain old EventSubscription, you can know when the application is closing and do something with your settings. All we’ve done here is Chain of Responsibility – we’ve taken an event and propagated it further down the line, until the classes that really care about it can answer it and do their work.

Now your WorkItems/Presenters/Views know when the application is closing, so they can write their settings to anything you like: a file, a service, whatever. I think a good idea is to provide a SettingsService here, and simply make calls like this:

[EventSubscription(EventTopicNames.ApplicationClosing, ThreadOption.UserInterface)]
public void OnApplicationClosing(object sender, EventArgs e)
{
   settingsService.SaveSomeWorkspacesSettings(SomeWorkspace.SaveAsXml());
}

The SettingsService can deal with the implementation details of saving to a file, or a DB, or wherever.

This solution seems much better to me than the guidance on Infragistics website. There’s no need to hook into any control events or write settings to disk/database more than one time. Just write them out when the application closes, as you would for a non-CAB application.