jp.hamilton

You Don't Fracking Know C\C++ So Take It Off Your Fracking Resume

First off, they are two completely different languages, so stop grouping them together like that. One might be a subset of the other, but the mindset of each language is completely different.

With that said, I have done 11 interviews for my company this year. Do you know what every applicant had in common? They all have C\C++ on their resume. You know what else they have in common? None of them could code in either language to save their own lives. People, take it off your resume if you don't know it. Please! The qsort program you wrote in school does not qualify you to put C on your resume. That cool binary tree thingy you wrote in your 3rd year of college does not mean you know C++. Out here, we are building big, boring enterprise apps with 10's of thousands of lines of code. Hundreds of classes. Out here there be monsters.

Look, I learned Windows programming in C. I had a gig writing NLM's in C on AIX way back around '96. I wrote COM components in pure C++, not with some mamby pamby ATL wizard. I have worked on very large MFC projects. And you know what? I don't even know this stuff anymore and I am not sure I ever did all that well. It would take me several weeks in either language to get back into the groove. And honestly, I wonder if I could ever do C again. The last time I did anything in C++ was a fairly large MFC project in 2001. I put in hour after hour after hour after hour learning C, then later, C++. I put in the time.

So, do you think I sound like a ranting elitist? I am not. But I am mad, and I don't like anything that harms our profession. You see, there are people who put every language they have ever looked at on their resume (e.g. C\C++). The guy who only knows C or C++, who is most likely an awesome programmer, get's passed over for Mr. Resume Bloat. Mr. Resume Bloat comes in and doesn't know a pointer from a hole in the ground and screws everything up, getting fired in the process. Then the company that hired Mr. Resume Bloat goes to India, because crappy code is cheaper there than it is here. After all, if you are going to get crappy code, you might as well go for the lowest cost crappy code, right? Where does this leave Awesome C\C++ Guy? Yeah. That's right.

Do you know why destructors should be virtual? Do you know the difference between a reference and a pointer? Is the largest block of memory you have ever managed 256 bytes? Dude, you don't know C\C++.

A Programmers Continuing Education is Wrought with Danger

From about 1992 to about 1995, I spent a lot of time learning the Win16 API. From about 1996 to about 2001 or so, I made it a point to become a master of all things COM. I actually read Inside Ole 2 cover to cover. You know, I actually used to write COM components in raw C++ before ATL was released. Hot damn, but I thought I was so cool...man, I was such idiot. I remember when my editor, Ron Petrusha, got back from the PDC 2000 where MS announced .NET (way back when C# was called Cool). He said, "Well, they have this whole new framework...you won't use COM anymore". Needless to say, I just couldn't believe it. 

Looking back, I have to say that I regret spending so much time learning so many things that are irrelevant to me today. 2000 was a moment of great epiphany for me. This is when I really stopped trying to focus on every single "latest and greatest" thing that MS was doing and started focusing on more "portable" things. What I am talking about here are principles, patterns, methodologies, and probably some other stuff I can't think of right now. I am talking about stuff that will be good to know when .NET no longer exists and everyone is programming in FrackPlus on Nar Nar machines. I am talking about knowledge that is good to know, whether you are using Java, C#, or whatever the language of the year happens to be. I am talking about stuff like this. Remember, learning a new technology inside an out will not make you a better programmer. Just because recruiters don't understand this, doesn't mean you don't have to. Spend your time studying the craft and grow as a programmer.

It took me YEARS to figure out that I was doing everything COMPLETELY WRONG. And that is why I am writing this warning to you, my 4 subscribers, so that maybe you will tell your friends. A programmers continuing education is wrought with danger. There is so much going on in computing and so little time for one person to absorb it all. There are little distractions everywhere, that in the long term will prove meaningless. Focus on the stuff that matters.

Driving Time Reclaimed

I always wondered what I would spend my time doing if a) I didn't have to sleep and b) I could reclaim all of the hours I have spent in a car. Well, as far as the former goes, Modafinil looks promising; almost tailor-made for late-night coding. As for the latter, I am making heavy use of audio books and the results, at least to me, are unbelievable. Just take a look at my 2008 reading list.

As of today, April 24th (in case you are traveling back in time from the future), I am just finishing up reading LINQ in Action and Code: The Hidden Language of Computer Hardware and Software. Both of these, of course, are tree-based. With a book like Code, I will take my time with it and read it normally. So far, it is my favorite book this year, so I want to cherish it. Now, with something that is technology-specific like LINQ in Action or Professional WPF Programming, I will speed read it. Technical books contain fluff. I know it, you know it. I like to peruse the table of contents taking note of the chapters that I care nothing about (e.g. Integrating WPF into WinForms). Then I will move through the book reading just as much as I need to in order to comprehend. When I recognize fluff, like a 2 page listing of namespaces used in LINQ, I will skip it. When I see something I already know, I skip it. I will take the time to type in code, however, because I think this is integral to the learning process.

In the audio book department, I am just finishing up the last few chapters of Brave New World, which is read by Michael York...you know Logan, from Logan's Run. I really like how he pronounces khaki as karky. Anyway, it will have taken 4 days to listen to the book by the time I am done. Large books take around 10 days. Oh, I should also point out that I am able to retain much more information when I listen to an audio book. I am certain this is because I can't absorb the material any faster than it is being read. When I read visually, I tend to summarize move through books very quickly...for better or for worse.

Prior to Brave New World, I read (listened to) Pride and Prejudice, and decided to stick with the "classics" for the rest of the year, and possibly beyond. I have essentially decided to pull a Sean Connery, and give myself an education that would make any English major proud. In addition to listening to books in the car, I also listen to them when I workout, so I think that my reading list will be quite large by the time December rolls around.

Testing WinForms

Testing a WinForms application written in a "traditional" manner is just about impossible. In order for events to fire (like Load), ultimately the window needs to be able to process messages, meaning it has to be visible. As you can guess, this is not very conducive to automated unit testing.

If you happen to be reading this, you know there are several free options for unit testing WinForms. But, I am guessing that since you are reading this, you think they suck. And you know what? I think they suck, too. 

You probably also know there are a few very expensive applications that are very difficult to use and require you to hire a full time guy to configure the tool and noodle around with it all day. Not only that, to get it, you need to call a sales person, because the vendor doesn't list a price...or show any screenshots of the tool for that matter. My rule of thumb: If the vendor doesn't list the price, it's not worth the price.

So, what are the alternatives? Well, many of you, like me, use the Model View Presenter pattern. The idea here is that all of the important code ends up in a Presenter class that is easy to test. Throw in a little Rhino Mocks and then it really does become trivial to write tests like "When I select the make of a car, a list of models should be displayed". But even though you can write a million tests like this against the Presenter, at the end of the day your coverage on your Form ends up a big, fat 0%.

Is this ok? Maybe.

I can think of several scenarios that make me think I would want to test my form directly. For one thing, it might be nice to know that my Presenter was being used correctly by the Form. For instance, when the Load event fires, does Presenter.Initialize() get called? When SelectChangeCommitted is raised on my "makes" ComboBox, is Presenter.FetchModels() being called? For that matter, does the "models" combo actually get populated with the data? Does my view subscribe to the Presenter.NotifyUser event ? And so on.

In order to help me do these kinds of tests I created two helper classes. One for testing Forms and Controls and another for testing POCO's.

Form/Control

Form derives from Control, as does every other control in WinForms. As a result, I decided to create a class containing several extension methods for Control. These extension methods allow me to do event-based stuff that is very specific to Forms and Controls. They do not apply to POCO's in which I have defined my own events, but we will talk about that in a minute. The Control extension methods include:

HandlesEvent

HandlesEvent allows me to test whether or not a particular Form event has a handler:

[Test]
public void Form_Handles_Load_Event()
{
    FormTest form = new FormTest();
    Assert.IsTrue(form.HandlesEvent("Load"));   
}

FindControl

FindControl allows me to find an instance of a control on a form. This alleviates the need to make all my controls public. Once I have the control, I can inspect values (like the Text property, for instance) and raise events on it.

[Test]
public void Can_Find_Control()
{
    FormTest form = new FormTest();
    Assert.IsNotNull(form.FindControl<Button>("btnOk"));
}

SubscribesTo

SubscribesTo lets me verify that I am handling events being raised by the specified control.

[Test]
public void Form_Handles_Button_Click_Event()
{
    FormTest form = new FormTest();
    Button btn = form.FindControl<Button>("btnOk");
    Assert.IsTrue(form.SubscribesTo(btn, "Click"));
}

RaiseEvent

RaiseEvent allows me to raise an event on either a Control or Form. In this example, I am just passing null for the event arguments.

[Test]
public void Button_Was_Clicked()
{
    FormTest form = new FormTest();
    Button b = form.FindControl<Button>("btnOk");
    b.RaiseEvent("Click", null, null);
    TextBox t = form.FindControl<TextBox>("txtResult");
    Assert.AreEqual(t.Text, "Complete");
}

POCO's

For POCO's I created a static class containing extension methods on System.Object. These extension methods  include SubscribesTo and RaiseEvent which work just like their analogs above, however, the underlying implementation is different.

Conclusion

To be honest, I do not know if this type of testing is valuable. These types of tests certainly don't help design in any way. However, it is interesting to see how one would determine if an event has subscribers. There is not much out there on this topic. So, from an academic point of view at least, I think the code is interesting.

You can download it here.