Chris Holmes Online

For a while now, my employer has maintained an opening for a talented software developer. They have not advertised the position very heavily because (a) we live in an area that is not rich with developers and (b) our small, Agile team has chugged along fairly well without this extra person.

That all changed today when a colleague – and friend – opted for greener pastures. He’s returning to the company where he started his career as an intern, a place he is particularly fond of, and I cannot blame him for taking a job that more closely fulfills his professional and personal desires. I wish him all the best.

Still, our small team of developers just shrunk by one, and we need to fill the gap.

In a larger city this would not be a problem. We’d just advertise the position and the resumes would pour in. But our location is our biggest hurdle when it comes to attracting talented developers. We simply can’t pull from as large a pool as a city like Austin, Texas can.

So where do I work? Nez Perce County, a small county government in north-central Idaho. As one might imagine, it is not exactly a mecca for software development talent. But that hasn’t stopped us from trying. People we talk to are always surprised to learn that our tiny little IT shop in Idaho is practicing Agile techniques. Yet that is exactly what we’re doing.

We subscribe to Agile practices, Extreme Programming in particular, and we drink from the TDD fountain. We use Continuous Integration, unit tests, acceptance tests, and frequent customer feedback along with short iterations to write quality, maintainable code and deliver business value to our customers (which, incidentally, includes us, since we are also taxpayers; we’re our own bosses in manner of speaking).

We work in an open environment and every developer has two monitors at their workstation. We work closely together as a team and have an on-site customer to help provide rapid feedback.

What We’re Looking For

We realize that we’re a bit handicapped by our geography. We’re not going to see a lot of great resumes. So it’s important for us to identify candidates that have the capacity to learn and possess a passion for software development. Ideally, candidates for our shop would have the following qualifications:

• Knowledge of Object Oriented design and principles
• Knowledge/Experience with C# .Net, or a similar object-oriented language (Java, C++)
• Database experience
• Willingness to learn

Bonus points for knowledge/experience with any of the following: Gang of Four design patterns, Unit Testing, IoC, CAB and/or SQL Server.

More information about the position, including benefits and pay, can be gathered by contacting my boss, Randy Buttenhoff, via the Nez Perce County IT web page.

Occasionally this question pops up on the CAB message boards: How do I prevent my application from closing if the user has unsaved changes?

Turns out that there’s a very simple pattern you can utilize to handle this situation. It’s called the Notification Pattern. Jeremy Miller, .Net guru, has a very good blog post on this pattern. He uses it to illustrate a standard way to handle validation on domain objects, but it’s a valuable pattern in other cases too, as I’ll show.

As Martin Fowler writes in his article, the Notification Pattern can be as simple as “a collection of strings which are error messages that the domain generates while it’s doing its work.” This is, in fact, how simple our implementation is where I work. A collection of strings, nothing more. You can use something else besides strings – a rich object with many properties and a public interface – if you like. But for this demonstration I’ll stick to strings.

The easiest way to implement this in CAB is with a Service class. All that is required is an event and a method to call to get notifications. The interface to the service basically looks like this:

public delegate void ApplicationClosingEventHandler(List notifications);

public interface INotificationService
{
   event ApplicationClosingEventHandler ApplicationClosing;
   List GetNotifications();
}

And the Service itself:

public class NotificationService : INotificationService
{
   public virtual event ApplicationClosingEventHandler ApplicationClosing;

   public virtual List GetNotifications()
   {
      List notifications = new List();

      if (ApplicationClosing != null)
      {
         foreach (ApplicationClosingEventHandler handler in ApplicationClosing.GetInvocationList())
         {
            handler.Invoke(_unsavedChangesNotifications);
         }
      }
      return notifications ;
   }
}

WorkItems, Presenters and other classes that know about the dirty state of their models can take a dependency on this Service and subscribe to the ApplicationClosing event. When the event is fired, their handler adds a notification to the list, if it needs to.

public MyPresenter : Presenter
{
   private INotificationService _notificationService; 

   public MyPresenter([ServiceDependency] INotificationService notificationService)
   {
      _notificationService = notificationService;
      _notificationService.ApplicationClosing += new ApplicationClosingEventHandler(AppClosingHandler);
   }

   private void AppClosingHandler(List notifications)
   {
      if(myModelIsDirty)
         notifications.Add("My object is dirty");
   }
}

The next step is to hook the whole thing into the Shell.Closing event. Back in the ShellApplication class, typically in the AfterShellCreated override, you can wire up to the Shell.Closing event:

public override AfterShellCreated()
{
   base.AfterShellCreated();

   Shell.Closing += new CancelEventHandler(Shell_Closing);
}

In your handler, you can query the INotificationService and get any notifications. If the notification list is empty, you can safely exit the application. Otherwise, pop a MessageBox and alert them.

private void Shell_Closing(object sender, CancelEventArgs ee)
{
   INotificationService notificationService = RootWorkItem.Services.Get();

   List notifications = notificationService.GetNotifications();

   if(notifications.Count > 0)
   {
      e.Cancel = true;
      // Alert the user
   }
}

That’s it. Simple, right? The nice thing about this pattern is that even with simple notifications, like strings, you can still give the user some very useful information on where unsaved changes exist. In our application, for instance, we let the user know which module and “use case” (very broad term here) contains the unsaved changes, so they can find those unsaved changes faster and make the save.

The Notification Pattern is one of the simplest, yet most useful, patterns that you’ll run into in any application, not just CAB. Now go forth and prevent your users from losing data when they close your app!

“So what do you guys think: Ancient Mayan temple off the beaten path?” – Jeff

Conventional wisdom says the beaten path exists for a reason: it’s safe. But conventional wisdom isn’t much of a match for a group of young travelers who wish to avoid “tourist traps” while on vacation. And so, with little reservation, best friends Amy (Jena Malone) and Stacy (Laura Ramsey) head off to an ancient Mayan temple at the urging of their boyfriends, Jeff (Jonathan Tucker) and Eric (Shawn Ashmore).

The group has been intrigued by a foreigner named Mathias whose brother, Henrich, has gone to the temple with his archaeologist girlfriend. Neither has returned, but Mathias quips that it’s probably because they’re having so much “fun”. At an old Mayan Temple. In the middle of nowhere.

Queue scary music here.

Amy gets cold feet when the group comes to an apparent dead end, only to find that the trail has been concealed with bushes. A couple of silent, young children show up several yards away in a creek bed to manufacture tension because apparently young children are scary. Amy’s intuition is to turn around and go back to the cushy confines of the hotel and pool. Why her boyfriend Jeff prefers visit dusty old ruins instead of jumping her bones at the hotel is a mystery.

No sooner does the group arrive at the foot of the ruins than some gruff looking “natives” arrive, complete with horses, guns, bows and arrows. They seem very threatening from the word “go.” A language barrier prevents either side from being able to explain themselves, and soon thereafter things turn bad. Pretty soon the tourists find themselves atop the ruins, unable to leave thanks to the folks with bows and guns.

To reveal what happens next would spoil the surprise of “The Ruins.” It is sufficient to say that it is probably what you did not see coming. In a way, “The Ruins” can thank recent horror films like “The Descent” and “28 Days Later” for priming its audience. Viewers will likely enter “The Ruins” thinking they have an idea of what to expect. They will be wrong.

Like “The Descent”, “The Ruins” doesn’t play any dirty tricks with its audience. It stays faithful to the rules it establishes early on. But unlike “The Descent”, the film only works because of a bit of manufactured drama, namely, the “natives”, who serve to keep the tourists trapped in their predicament. The film justifies this mechanism logically, but even so it still feels forced and mechanical, and detracts from the overall quality of the movie.

Still, “The Ruins” works. It achieves what it sets out to achieve and does so with a fairly creative horror device. It’s not as good as “The Descent” or “28 Days Later”, but it deserves a seat at the table.

Two years ago I lamented the loss of powertabs.net. The MPA, stick fully inserted in ass, took action against the best and most popular guitar tab site on the internet. It was a disappointing move from an organization that clearly didn’t understand what they were dealing with. They saw copy write infringement where non existed.

Fortunately, a bit later, powertabs.net was freed from the bonds of stupidity, and allow to operate again. For the past year and a half I’ve been happily downloading tabs of songs (I’ll reveal more on this in a later post).

Well, a couple days ago I noticed comments coming through on my nearly two-year-old post; comments that seemed to indicate it was shut down again.

Turns out, it’s true. In another incredibly unfortunate move, the MPA has managed to shut down powertabs.net yet again.

This is, simply put, a travesty. It shows a completely lack of comprehension in what tabs are, who creates them, and why.

Web sites like powertabs.net exist for two basic reasons:

• Musicians, guitar players in particular, want to know how to play a song correctly.
• “Official” tab books are almost always horribly inaccurate.

In order to play a song correctly then, guitar players and other musicians – the very gifted ones – transcribe the songs themselves. And then, so the rest of us poor saps don’t suffer, they share those tabs.

I’ve tried tabbing songs myself. I’m very bad at it. I don’t have perfect pitch; I don’t hear the nuances very well. But I know when I hear inaccuracies. I know when the transcription is wrong. And a good portion of tab books are just awful.

If tab books were as accurate as the many transcriptions I’ve downloaded from powertabs.net, I’d happily buy them. I buy CD’s, I buy DVD’s, I download songs off iTunes. I have a very low tolerance for people who pirate software and music. I have no problem spending money to get accurate transcriptions. Most musicians I know have some amount of money, otherwise they couldn’t afford their instruments and equipment. This isn’t about money, no matter what the MPA claims.

This is about the big guy putting his thumb on the little guy. This is about the MPA exerting control – throwing their weight around.

What the MPA doesn’t understand is that musicians love music. They want to play music, perform music, and share music. They want to play their favorite music – they want to learn other people’s stuff so they can be exposed to new ideas – they want to expose other people to songs they’ve never heard. They want to push themselves to get better as musicians. They want to be inspired. Learning other people’s songs is how we accomplish this. Learning them accurately is where powertabs comes in.

I don’t often rail against corporations, artists or anyone else who tries to protect their intellectual property or their work. But this is a mistake. It’s a mistake because the MPA just doesn’t understand. All they’re doing with this move is making a lot of musicians – they very lifeblood of their industry – angry and hurt. They’re killing their biggest fans.

It’s disappointing.