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

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.

 

ScreenshotGister

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

 

VsVim

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

Scrum.org Face-to-Face Gatherings

The weekend prior to Agile 2012, Scrum.org hosted a face-to-face gathering of trainers.  These are a mandatory part of being a Scrum.org 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…

 

Headless Javascript Testing with Visual Studio 2012 & Chutzpah Test Adapter

[Update: The amazing @mmanela has fixed the bug in my original video.  Get the latest Chutzpah from VS Extensions.  I’ve re-recorded the video also.]

More often than not, I’ll use the jasmine-node nodejs module for javascript testing.  It provides continuous testing/auto testing and it’s really fast.  To date, there really hasn’t been a good, if any, testing experience for javascript inside-the-box for Visual Studio.

In VS 2010, the Chutzpah extension tacked on jasmine and qunit support by running javascript tests outside of Visual Studio and pushing the results to the output window.  This was a big step forward.

In VS 2012, there is an open model for discovering and executing tests that Chutzpah and others have provided implementations for.  Now you can run NUnit, xUnit, Jasmine, and QUnit tests without 4 different runners.  Much nicer.  It even supports auto/continuous testing, though with an admittedly naive priority scheme compared to NCrunch or Mighty Moose.

Video: Jasmine Tests with Chutzpah in VS 2012

In this video, I’ve walked through a very simple setup using Chutzpah to run Jasmine tests inside Visual Studio 2012 RC.

 

Terrible Exception message building custom Nuget VSIX Extension

Today I was putting together a custom build of the Nuget 2.0 Visual Studio Extension (VSIX).  My client has an extranet where they publish their Nuget feed(s) and it’s behind an authenticated proxy server.  It used to be that the extension would use the VS credentials, but there’s a bug in 2.0.

It’s been fixed in changeset 14dd5c2aa14b.

Pulling the Code

Head over to Codeplex and get your environment setup.  Basically means pulling the source and installing the VS 2010 SDK.

Before we just build the tip of nuget, I want to limit my exposure.  I’m going to head back in time to the 2.0 build and then apply the changeset that fixes my problem.  2.0-public is the git tag for the 2.0 release (it would seem).  So I’m going to check that tag out to a branch called authfix.

git checkout 2.0-public –b authfix

imageNow I have 2.0 on which I can cherry pick the changeset with our fix (14dd5c2aa14b).   Looking at gitk or git log will show me I have 2.0-public with the authfix applied.  I don’t have all the other features that have yet to ship since 2.0, which I don’t want, because I’m not confident in them yet and don’t want that risk yet.

Building Nuget

The Nuget contribution documentation suggests building with build.cmd.  As of 2.0 you need VS 2012 build targets, but if you don’t plan to use 2012 then you don’t actually need those targets.  You want it, but don’t need it.  This client isn’t using 2012 (yet) so I’m building in 2010.

Open Nuget.sln in VS and build it which results in:

Exception has been thrown by the target of an invocation.

image

Awesome.  Very insightful. #facepalm

 

The Real Problem

VS Extension projects deploy the extension on build so that you can debug them in an clean, isolated Visual Studio instance.  I should have remembered this from creating my Gister extension.  Turns out VS fails in this deployment when the extension has otherwise been installed.  Not so clean, but oh well.

 

imageOption A: Uninstall Nuget

Since I’ll be installing this custom build anyway, I went ahead and uninstalled the RTM public build of Nuget 2.0.  This fixed things and my extension can be found in VSExtension\bin\Release.  Double clicking this will install the custom Nuget build.

 

Option B: Stop Deploying on Build

You can actually turn off the deployment of your VSIX on build.  This might not be great for the build, debug story, but for this it worked great.image

Feature Focused Javascript Apps

Common Closure, Not RSI! Common Closure, Not RSI!

Some time last year I started getting really annoyed.  Every time I picked up a new app, I had to open at least three rather busy folders to grok what was going on.  Maybe you’ve heard of them:

Models, Views and Controllers

Yeah, I get it, it’s the de-facto layout for most apps.  I’m all for consistency for the sake of simplicity.  It’s a grand plan.

But my eyes and keyboard are tired of jumping around to find out what the Home page is up to.  Last time I checked, those things that change together, stay together1 2.  I don’t recall the “Those things that look like controllers stay together” principle.  Not even a smidge of alliteration.

I’m glad to see I’m not alone.  Feature frameworks are slowly popping up for Rails mostly, but I suspect ASP.Net won’t be too far behind.  Uncle Bob also seems to have a rant going on the topic as well. You can watch one of his talks on the topic here. Good stuff all around.

My Change to get Feature Focused

In December of 2011, when I picked up a new project I decided to try something new.  Features that made the app useful were going to highlight the app structure.  Instead of folders called Models, Views and Controllers, the first thing you’d see is Chat, Tasking, and Notifications.  Want to add some information to the Chat notifications… guess where you go?  Yup… Chat.

Now most js frameworks don’t subscribe to the Model, View, Controller discovery convention like server frameworks.  Instead, they’re mounds of scripts crumpled into some scripts directory.  Not the framework’s fault, but again, not exactly organized with discipline.

Focusing on Features in Javascript

Here are the weapons I chose to go into battle:

requirejs

Provides dependency definition and resolution. Not crucial for the code, but it made optimizing a loosely coupled JS app into Sweet Apple Pie™.

backbone.routing

‘cause sammyjs had a personality disorder.

knockoutjs

Model Binding for realz.  Backbone.Modelbinding just wasn’t there yet.  I felt like I built a lot of Backbone by the end, but the knockoutjs’ binding is butter.

Home

Our app is all client side; single DOM.  Should you do your app that way… dunno.  For this one, I had index.htm and was done.

image

The only thing of interest is that we’re sourcing require.js and we’ve specified the data-main attribute with a value of bootstrap. This refers to bootstrap.js which is going to get things rolling.

As you can see on the left, the client app is in a src directory under my app’s root of featurefocusedjsapp

Dilemma: I really want to experiment with hosting the server components along side corresponding client components where appropriate.  If you have ideas or experiences here, share them in the comments.

Bootstrap.js Feature Modules

bootstrap.js uses the require.js require function to create a module.  require takes two things, imagean array of dependency module names and a function to be executed once all dependencies are available.

The purpose of bootstrap.js is to kick off the modules of our application.  In many common frameworks, you might start by declaring routes using Sammy, Ember, or Backbone.  We might need that, but I really want to start features.  And that’s where modules come in.

Credits Module

Since our app is so awesome, people will want to know a little about the creators.  Let’s give them some credit.  We’ll start by creating a CreditsModule.js in the Credits feature directory.  Bootstrap will simply call start on our module.

SNAGHTML33857991

We’re using the Reveal Module pattern to expose a start function.  Credits module is going to display some information, so we’ll need a view.  One thing I dislike about many js heavy apps I’ve seen built is the unending list of script templates embedded in one page or another.  The javascript is in one place, but the view is totally disconnected.  If you’re composing this in an optimization/minification step, great.  But those I’ve seen are actually coded in this way.  Churn on those files is very high and I don’t like high churn.

Collocating Views

Instead, I want the creditsview.htm to sit alongside the rest of the credits module.  We want to show this in the main content region of the app, but I don’t want my module coupled to some css selector or jQuery.  So let’s see how we can put this all together:

SNAGHTML339fdbec

Here we use the text.js plugin for requirejs.  This sources the creditsview.htm content, sending the raw string as a parameter to the callback.  We use this view content as a closure in the start function which is, again, exposed as a module using the reveal module pattern.

Check out our awesomeness

image

I’m running this using python –m http.server from the src directory.  This is so convenient I created a serverpy function in my Powershell profile.

 

Perf Sucks!

As you might imagine, this isn’t doing great things for our site resource performance.  Lots of little files are bad for a browser.  Our crazy simple site is bad.

image

Remember how I said requirejs wasn’t crucial.  Everything we’ve done so far could pretty easily have been done by hand.  Here is were requirejs begins to pull it’s weight.

r.js to the rescue

r.js also by James Burke is here to slim things down with it’s optimizer option.  This is going to take our collection of scripts and templates and turn it into a single script resource. 

node r.js –o build.js

Running that command in the root of the repo will show us this:

image

r.js has just walked the dependency tree of bootstrap.js and consolidated it into a directory called build in the repo root.

At first glance this seems wholly unimpressive

image until you open bootstrap.js…

image

Sold.

 

Delete all that working garbage and serve up the build directory.

image

 

What do our downloads look like now?

BEFORE

image

AFTER

image

You can find the code to this point at https://github.com/cromwellryan/featurefocusedjs

 

Next time I’ll talk about features talking to one another.  Then we’ll talk testing pieces of this thing.