I don't know how many people recommended this book to me, but it seems like every smart developer I know has said something about it at some point. So I finally ordered a copy (there were none to be had on the shelves of ANY local books stores). I've only just started it, but in the preface alone he has talked about some of the things that I already do wrong. He talks about not being able to "let go of a particular design aspect in the interest of time" and I find myself there often.

Everyone who recommended it said that it changed the way they think about designing software solutions and I doubt I'll be any different. I will be starting a series chronicling my reading of the book and my thoughts for all of my readers (both of them) to enhance, criticize, etc.

Happy coding!

~Lee

As I try and learn about all the available productivity features of R#, I will post what I learn here... for posterity and for anyone who might find it useful.

Alt+Insert is used to generate code in the text editor window. If you are in the text editor, it will bring up a context menu to allow you to generate ctors, members and properties. If you highlight a place in the Solution Explorer and hit Alt+Insert, it will bring up a context menu for generating a class, interface or struct in that folder of the solution.

Another quick little tip for TDD people. This isn't really a R# built-in kb shortcut, but it seems to be a common one. In order to run unit tests based on your current context (if your mouse is in a test it will run that single test, if your mouse in in the fixture, it will run all tests in the fixture), you can map Ctrl+T to do that.

on the Visual Studio Menu -> Tools -> Options -> Environment -> Keyboard

in the scrolling list, look for: Resharper.UnitTest_ContextRun

On the Use new shortcut in: drop down choose Text Editor. Put you mouse in the "Press shortcut keys" test box and type hit the ctrl key and the T at the same time. Ctrl+T should appear in the text box. Click Assign button.

Viola! It is very sweet. Thanks Troy and Dru!

~Lee

When testing, I find that it is important to be cognizant of what you’re testing. I’ve seen (and done) tests where I was using my IoC container to inject a dependency. You may think, “That’s the way it will work in the real world.” The problem is, it may have nothing to do with the System Under Test (SUT). So, you’re test might fail because something went wrong with your IoC container or configuration and have nothing to do with your SUT failing at all.

The important thing to remember is test what you are trying to test and nothing more. Remove any other failure points within a test other that the SUT, then you can be sure a failure means a failure with your SUT and not something else.

~Lee

While traditional syntax for asserts is fairly easy to understand (once you get used to reading it), it doesn’t read as close to English as I’d like. So I have taken to using the Assert.That syntax for a lot of my assertions. This makes an assert like this:

   1: Assert.AreEqual(5, SUT.Items.count);

Read like this:

   1: Assert.That(SUT.Items.Count, Is.EqualTo(5));

To me, the second assert reads a lot more like plain English.

~Lee

Now with more reflective imagey goodness!

The new theme is a work in progress. I am porting Carl Mason's SummerFruit theme for Wordpress. I've got most of the major stuff, I just need to get the comments and contact form styled.

~Lee

Today is the 5th birthday of GeeksWithBlogs.net. I have only been blogging here for about 6 months, but I am really digging the community and all the awesome bloggers who blog on GWB.

A HUGE thanks to Jeff Julian and John Alexander for making GWB possible and for all that they do in the community as a whole. You guys rock! Here's to another five kick-ass years!

Some of the awesome GWB blogs I've enjoyed:

Chris Williams

D'arcy Lussier

Theo Moore

Dru Sellers

Rob Reynolds

Becky Isserman

~Lee

Well, the first iteration of my new project finished yesterday and the retrospective went well, for our first. Troy led the retrospective and tried to keep us on track with the things he’d done before in retrospectives. It was my first retrospective on a professional project, so I thought I’d share our process.

First, Troy hit the whiteboard with three columns: Start Doing, Stop Doing, Keep Doing. These are pretty self-explanatory but I’ll touch briefly on each anyway.

• Start Doing – Things that we see as a possibility for improvement. (e.g. Pairing through a problem, Lunch-n-Learns for new component suite, etc)
• Stop Doing – Things we saw that caused problems or waste. (e.g. pulling stories out of order,  getting bogged down in YAGNI)
• Keep Doing – Things that seemed to work well. (e.g. Daily stand-ups, solid user story writing)

Our list was pretty small, but we only wanted to take an hour for the ENTIRE retrospective, so we had to keep focused.

Then, we each grabbed a different color whiteboard marker and put our mark beside things we thought were the most important in those categories. We were able to vote for three things in the start doing column and two things in the stop doing column (the keep doing is just .. keep doing ‘em…).

Finally, for the things that got the most votes, we talked about action items to ensure we started doing the “Start Doing”s and we put that list up.

Mostly what we discovered is we needed to really push the Agile principles. We need to interact more. We found ourselves getting caught in the “I’ll grab a story, go sit at my desk and work on it” scenario and didn’t pair very much at all. We discussed how, when having a problem with something, pair-programming not only gets a second pair of eyes on the problem, it can help to curb getting sucked into YAGNI, and helps to spread the knowledge around.

We will also be adopting a more BDD approach to User Stories and testing by adding scenarios to our stories. This will help to kick start the TDD process, keep the TDD focused on behavior & interaction and not units & testing, and it will help us to focus on the powerful questions for the system.

We will also start doing some Lunch and Learns, where we will be watching training videos on the Telerik RadControls for ASP.NET Ajax to familiarize ourselves with using the components in the suite.

All in all, I have to say it was one of the most productive hours I’ve ever spent in a meeting. :0)

Til next time… Lee