More Than You Care To Know About Me…

July 11, 2008

Randy tagged me with this meme so here goes…

What I was doing ten years ago

I had always believed that I was supposed to become a doctor; an orthopedic surgeon, specifically. But in 1998, I realized that it was not what was in my heart and I had to go a different direction. Unfortunately, at that time, the direction didn’t much matter to me so long as it was away from medical school. I was working at a buddy’s ISP (Internet Service Provider) and slinging drinks at a local bar. It was fun for a time and I am where I am today because of my experiences but I can’t say that I always made the best decisions. I’m just thankful that I had my family and friends around for support and that they were there when I was ready to move my life in a more positive direction.

Five snacks I enjoy

  1. Granola
  2. Starburst jelly beans
  3. Mixed nuts (but not the cheap crap with all those peanuts)
  4. Salt & Vinegar Kettle Chips
  5. Whatever is closest to my keyboard

Five things on my to-do list today

(This one is a really hard one for me since I have my to-do list split into contexts - I’m a GTD guy, what can I say)

  1. Call Lewisville Shoe Repair re: boot resole
  2. Call Adam Keys re: lunch next week
  3. Hang up all tools over workbench
  4. Upload starting codebase to Google Code for presentation
  5. Locate host service for CodeRush screencasts

Five favorite recipes

  1. Italian Egg Scramble
  2. Man-Mac
  3. Sausage & Peppers
  4. Genius - 1% inspiration, 99% perspiration
  5. Thermite - sorry, not handing this one out

Five jobs I have had

  1. Bag boy at country club
  2. Graphic artist and typesetter at college newspaper
  3. Skiptrace
  4. Veterinary technician
  5. Grocery clerk

Five bad habits

  1. Talking to myself a little too loud
  2. Snore (like it’s my job)
  3. Monitor touching when explaining/reading code
  4. Knowing I’m right
  5. Reminding people around me of #4

All the places I’ve lived

  1. Chicago, IL
  2. Louisville, KY
  3. San Antonio, TX
  4. Medina, OH
  5. Hillsborough, NJ
  6. Oxford, OH
  7. Denton, TX
  8. Flower Mound, TX

Five Random Things

  1. I sweat like a person twice my weight.
  2. I placed at state in 8th grade Science Olympiad.
  3. I went by the name “Michael” for a while.
  4. I collect antique fountain pens.
  5. Nutmeg is toxic if injected intravenously.

Five people I’m tagging

  1. Tom Opgenorth
  2. Brett Bim
  3. Chris Koenig
  4. Jason Portnoy
  5. Joe Ocampo

Announcement: NDDNUG - Refactoring To Patterns

July 6, 2008

On Wednesday, July 9th, I’ll be giving a talk at the North Dallas .NET User Group called “Refactoring to Patterns (Not the Book)”. It’s not going to be some dry, academic talk with and bunch of UML and “Hello World” examples but an example using “real world” code like what you and I work with in our every day lives. The main patterns we’ll focus on for this web application are Model-View-Presenter and Adapter. My intent is to show the things that I’ve discovered in journey towards better, more maintainable code and provide ways to apply that knowledge in a realistic fashion. This is going to be a code intensive talk and, hopefully, a very interactive one.

Here’s the sign up form - I hope to see you there.

UPDATE: Here’s a link to the Google Code repository that contains both a start and end copy of the solution so you can see and try the refactoring that was demonstrated.


David O’Hara is a Principal with Improving Enterprises in Dallas, Texas.


Reducing Unit Testing Friction…

June 26, 2008

Gears.jpgIt doesn’t matter if you’re a TDD purist or a test-as-you-go guy, having a quick way to execute the tests that you’ve created is critical to them actually getting run as regularly as they need to be. To that end, here is the current setup that I’m using to make this as easy as possible.

Everyone knows that I’m a sucker for a new tool but this tool has been with me for quite a while and I’m skeptical that anything will be able to replace it. TestDriven.Net is the foundation of a great workflow when it comes to unit testing and it’s truly worth the small amount that Jaime asks for his efforts. He’s a great guy and it’s a great tool - go buy it and install it immediately.
So now that you have it installed, there a couple of settings in Visual Studio that help make that test/code/test cycle even tighter.

Keyboard shortcuts

Once you have TestDriven installed, you’ll notice some extra options in the context menus when you right-click on class files, projects and even in code. These will allow you to run tests in various fashions but I’m a lazy man and I hate moving my fingers off the keyboard so I’ve added a few shortcuts to Visual Studio. In the options menu for “Keyboard”, I bind Control-1 to “TestDriven.NET.RunTests”, Control-2 to “TestDriven.NET.ReRunWithDefault”, and Control-3 to “TestDriven.NET.ReRunWithDebugger”. The way this helps me is that I am able to use Control-1 to execute the test that the cursor currently resides in (if you’re in between tests or on the fixture itself, it will run all in that fixture). If it doesn’t pass, I can hop over to the code that’s being tested, make the changes and then just press Control-2 to see if the test passes. No back and forth between the two. The last shortcut is helpful because it allows me to set a breakpoint where I am (using F9 of course) and rerun the test so that it will hit that breakpoint. Again, no back and forth.

Output window

Every time you execute a test, the tool bar will give you a quick look at the status but the output window will be your friend when things don’t quite execute as planned. All the output gets piped here but you don’t need it in your face so be sure that the “Show Output window when build starts” is unchecked but also be sure that you have it collapsed just below your code file. output window.jpg This way if you do have need to see what is in the output, you can just press Control-Alt-O and it will pop up with focus. (Pressing Escape will cause it to hide again and leave us in our code.)

I still haven’t quite figured out how to bind to the “Run All Tests” so if you have a suggestion, I’d love to hear it. However, I do still find it helpful that a “Run All Tests” will execute again when using the rerun shortcuts and I use that quite a bit right before commits. (If you’re not religious about running ALL tests before a commit, I hereby grant your co-workers permission to knee-cap you.)

Because unit tests only provide benefit when they are actually run, we need to do everything that we can to tighten the code/test loop and make executing the right thing at the rightht time as easy as possible.


David O’Hara is a Principal Consultant with Improving Enterprises in Dallas, Texas.


Random Rant…

May 5, 2008

Apparently in NYC it is the implicit responsibility of the second person in line at a red light to immediately honk their horn when the light turns green so as to remind the first person in line that it is their turn to go. Having been the second person previously, subsequent drivers (usually numbers 3 thru 5 or so) are often concerned that this person may not be aware of this responsibility or is simply in need of assistance. So they take it upon themselves to also gently remind those in front of them of their responsibility by utilizing their horns. Who knew NYC was so full of concerned and considerate driver??


Project Structure In The SCM…

April 29, 2008

As a follow-on to the last post Self-Monitoring Build System, I figured I’d discuss the way I manage my projects and their dependencies. I believe it’s important to have a self-contained project that allows “time to login screen” to remain as small as possible. I do this by packaging the source, libraries, tools, basically everything under a single space within the SCM. This puts the control and responsibility for managing dependencies where I feel it should be; in the IDE so that, ultimately, it’s in the developer’s hands rather than in the SCM itself. Plus, it makes sure that the build server will always have what it needs to build the project without needed extra installs. If you keep the build server clean, you won’t be in a pinch should it take a dirt nap. (You ARE using VMs for your build servers aren’t you??) Keep in mind that when I’m saying “project”, I’m referring to a project in the sense of a product or system in the enterprise which is probably comprised of at least 1 Visual Studio solution and a few ancillary things.

The Setup

In an effort to keep things practical and concrete, here’s how I usually set things up. To start with I have a common project which contains a basic “template” build script and the tools that I like to use - NCover, NUnit, MbUnit, NAnt, ILMerge, Simian, etc. Now, all subsequent projects will be branched from this common project. This allows you to manage which version of the tools each project is running as well as easing the push to move a project to the latest and the places you have to check in that new version. Side note: There has been a recent discussion on the altdotnet group regarding svn setup and it has been interesting to see the discussion. However, this configuration assumes that you’re using a single repository because…well…that’s the only way I’ve worked thus far. If you’ve got an idea on how to make it work with multiples, I’d like to hear about it.


David O’Hara is a Senior Consultant with Improving Enterprises in Dallas, Texas.