My Favorite Visual Studio 2012 Extensions

Today is the official launch of Visual Studio 2012 so I thought I’d share some of the extensions I’ve been leaning on for the last few months.

Visual Studio 2012 is a great step forward all by lonesome.  The in-the-box enhancements below have been great as our teams and I adopted Visual Studio 2012: 

Great stuff, but there are some Extensions that I just can’t live without.  Here are some of my favorites:


imageChutzpah Test Adapter

Test your javascript along side C# and other code using Jasmine or QUnit with the new Test Explorer.  Continuously test your javascript and, now, coffeescript!  Find out how hereMathew Manela is a stud.  Thank him for this one.


xUnit Test Adapter

Run xUnit tests alongside other test frameworks without feeling the need to go ‘all-in’ on any one framework.



Specflow allows you to create and run BDD style tests right inside Visual Studio.  If you’d like a demonstration of how we use Specflow to enable fast feedback and frequent releases, contact me for a lunch and learn.


Web Essentials 

This extension is so chock full of goodness I couldn’t begin to list the features.  If you’re doing any kind web dev in Visual Studio, you need this extension. It adds coffeescript, LESS, Handlebars, and Mustache support.  Allows you to embedded resources, IE hacks, and vendor specific prefixes.  Stop wasting your time and just get it.



Shameless plug for my extension that allows you to publish code snippets to  This goes along with PsGist which lets you do the same from Powershell.



You might scoff at this one, but I’m a giant fan of VsVim.  Learning Vim exponentially improved my productivity and I’ve been able to integrate that into my Visual Studio use thanks to Jared Parsons.  You rock man!  Thanks.

Lightning Talk: Experiences with Feature Focused Apps Face-to-Face Gatherings

The weekend prior to Agile 2012, hosted a face-to-face gathering of trainers.  These are a mandatory part of being a trainer and it’s a great time.  These are bright and passionate people that really want to make the world of software development better. 

This year as part of the face-to-face meetings, trainers are being asked to present a lightning talk on a topic they are passionate about.  There was everything from Organizational Amnesia (great!) and a Tasty Cupcakes game from Don McGreal.  In all, I think it was the best part of the gathering.

My Talk

For my part, I presented on my experiences this year building what I’ve been calling Feature Focused Apps.  My plan is to continue expanding this talk and the posts that go with it throughout the year.  I’ll be taking it on the road to user groups and CodeMash in January.

I’d love your thoughts on the topic and what you’d like to understand more.  I’ve been negligent in my posts on the topic, but in due time…


Easy Github Code Reviews with diffgist in PsGist

A few minutes ago I merged a pull request from Tim Heuer for a PowerShell command, diffgist (New-DiffGist), based on the gist command in PsGist.  With it you can create a gist from git diff in one go.  Great for quick code reviews and other feedback.

With diffgist there’s a nice –launch option that opens the gist in your default browser.  I tend to send them to the clipboard via | clip, but this is really convenient.  I think I’ll add this to gist also.


Here’s the command help:


Publishes Github Gists of current git diff.

New-DiffGist [[-Name] <String>] [-Description <String>] [-Username <String>] [-Public] [-Launch] [<CommonParameters>]

Publishes files as Owned or Anonymous Github Gists.

-Name <String>
The name to use for the filename of the Gist (minus .diff)

-Description <String>
(optional) The Description of this Gist.

-Username <String>
The Github username which will own this Gist.

-Public [<SwitchParameter>]

-Launch [<SwitchParameter>]
When specified, the default browser will launch to the created Gist URI

————————– EXAMPLE 1 ————————–

C:\PS>diffgist -Description “Hello.js greets all visitors”

Publishing a private Gist

————————– EXAMPLE 2 ————————–

C:\PS>diffgist -Name “Hello” -Description “Hello.js greets all visitors” -Public

Publishing a public Gist

Passive Aggressive Commit Messages

If anyone tries to tell you Twitter is a waste of time, they have the wrong circle of followers.  Today I posted this gist somewhat facetiously asking if the following was an acceptable commit message.

Refactoring done earlier didn’t execute acceptance tests. This makes me wonder why we even have acceptance tests. The acceptance tests (and the bug they surfaced) are fixed. Ugh. Professionalism people. Please.

imageI say somewhat facetiously, because I actually copied it out of my almost submitted commit command. I was really close to sending it and that would have probably been the end of it.  It’s unlikely anyone would have noticed it, especially the person I was directing this passive aggressive comment towards.

Follow My Own Advice

I’ve blogged recently about recognizing signals (here and here).  Obviously, I’m not following my own advice.  I need to go and find out why this person doesn’t care about the acceptance tests and either convince them they are important or find a better way.

Uncomfortable Part

Rather than be passive aggressive in silence, I need to have the discussion.  It’s not going to be comfortable, but I have something we can both agree on: we both want this to be successful.  If we can keep the conversation focused on the success of this project, we can find an understanding.  If I use the same tone in our conversation that I’m using in this commit message, well, it’s not going to go well.

Fortunately, I wear big boy pants (when I go to the office) and I’m willing to get over a little uneasiness for the sake of my creation.  Do it a few times and it gets much easier.

Simple Solution

It turns out this was able to exist in our codebase for a few days, because we aren’t running our acceptance tests as part of the build. I plan to remedy that tomorrow.

Crickets: Messages Are Only Useful If Received

A peer gave me a call today to vent about a meeting that didn’t go well.  He had spent the last few months working on some really cool stuff that should benefit the company quite a bit.  An almost direct bottom line impact.  Doesn’t get much better than that at work.

Unfortunately, the room was filled with crickets during the meeting.  The one person who should have understood the technical details, was puzzled.

“They’re All Idiots”

Often our natural first reaction is to be frustrated and angry that no one “get’s it.”  I mean, this is the right way!  Just look closer.

Unfortunately, this doesn’t help anyone or anything.  It simply puts you in a defensive posture at a time when you need to be offensive.


Crickets are a form of feedback.  The first signal in this conversation was “the last few months.”  That’s too long a feedback loop for anything.  It’s telling you that your message is not appropriate for the audience.

We are a community of specialists.  The crux of actually accomplishing things as a team is communicating successfully across specialties.  This is why analogies are so helpful and common.

ASIDE: We strive to be generalizing-specialists, but we have specialized skills. It’s something that has made the human race successful. Get over it.

THEY’re Telling You Something Stupid

When people choose to attend your meeting, it mean’s they are interested.  If they leave confused or less interested, the problem isn’t with the audience.  The message needs work.  It needs to resonate with the audience and their context.

Here are some things you can do:

Understand Your Audience

Ask around and learn about those who have an influence in the outcome of your presentation.  Understand their knowledge and perspective.  What does success look like for them.  For big points in your topic, ask yourself what might be confusing to this person or that.

Fail Fast 

A “few months” is way to long a feedback loop.  Check in with someone that represents your audience every so often and share your thoughts.  This will help you to learn what works and what doesn’t.  Don’t use the same person too often.  They’ll be building on previous discussions unlike your end audience.

Stay Calm

Don’t get frustrated or defensive during the presentation.  When you see the deer in headlights, start asking questions of the audience.  Find out where the gap is.  After having talked through the content with earlier helpers, you should have more than one way to explain things.