Yesterday we moved Autofac over to GitHub.

I’m cool with that. There’s a lot of momentum behind Git and GitHub in the source control community and I understand that. Nick Blumhardt’s post on the Autofac forum and the linked Eric Raymond post in the Emacs developer list hit close to home for me – I wish Mercurial had “won,” but Git’s fine, too. I don’t feel super strongly about it.*

In moving, we got a lot of really nice and supportive tweets and posts and it’s been a nice welcoming party. That’s cool.

Then there have been some puzzling ones, though, and here’s where I switch out of my “Autofac project coordinator person” hat and into my “I’m just a dev” hat:

Again, I’m not picking on these folks personally, because I respect them and their skills. I’ve seen a few of these and I know (hope?) they won’t take it personally that I grabbed theirs out of the bunch. What I want to address is more my puzzlement around the sentiment I see here:

Why is source control, or a particular source control system, such a barrier?

In a world where the polyglot programmer is becoming more the norm than the exception; where it’s pretty common that a single developer can work in more than one environment, on more than one OS, and/or in more than one language… I have a difficult time understanding why version control systems don’t also fit into that bucket.

I get that folks might have a personal preference. I’m a Sublime Text guy, not Notepad++. I’m a CodeRush guy, not ReSharper. That’s not to say I can’t use those other tools, just that I have a preference and I’m more productive when using my preference.

When I see something like “It’s been fun to get in the codebase and look around,” though, and the [implied] reason that was somehow possible now when it wasn’t before is because of a switch from Mercurial/Google Code to Git/GitHub?

That doesn’t make sense to me.

When I see a project that sparks my interest and makes me think I could make use of it, I don’t really care what version control system they use.** There’s a bit of a “when in Rome” for me there. I mean, honestly, once I pull the NuGet package (or gem, or whatever) down and start using it, and I go to their site to learn more… I don’t really lose interest if they’re hosting their source in some source control system or with a host I don’t prefer. I don’t know of an open source site that doesn’t let you browse the source through a web interface anymore, so even if I wanted to dig into the code a little, it’s not like I have to install any new tools. The “issues” systems on most open source hosting sites are roughly the same, too, so there’s no trouble if I want to file a defect or enhancement request.

Sure, there are some things about GitHub that make certain aspects of open source easier, but it’s primarily around contribution. I concede that pull requests are nice – I’ve made a few, and I’ve taken a few.*** That said, there are some well established conventions around things like patch files (remember those, kids?) that have worked for a long time.

Having a different mechanism of contribution has also never really stopped me. Have you let it stop you? Why?

I guess I look at these other systems more as an opportunity to learn than as a barrier. Just like I have to learn about your coding conventions in your project, your project’s style, the right way to fix the issue I found (or add the enhancement) before I can contribute, the version control may be one of those things, too. It’s not really that big of a deal, especially considering there’s really only Mercurial, Git, and Subversion out there in the open source world and you’ve covered the 99% case.

Don’t get me wrong. I think removing friction is great. Making easy jobs easy and hard jobs possible is awesome. GitHub has been great at that, and I applaud them for it. I just don’t think folks should let source control be a barrier. Add the skills to your portfolio. Sharpen the saw. Have a preference, but don’t let it shackle you.

* All that said, I can’t remember a time when I had more trouble with trivial crap like line endings with any source control system other than Git. And until fairly recently, setting up a decent, working Git environment in Windows (where I spend most of my time) wasn’t as straightforward as all that. Obviously my experiences may differ from yours.

** Except TFS version control. Anything beyond even the simplest operations is a ridiculous pain. “Workspaces?” Really? Still? It’s VSS with “big boy” pants.

*** And, as we all know, pull requests aren’t Git, they’re GitHub (or the host) because they’re workflow items, not source control specific. BitBucket has pull requests for Mercurial.

For reasons I won’t get into, we recently ended up with a scenario in MVC where we needed to use RenderAction to get some data into a view. Some of the data was exposed via async calls to services.

The challenge is that RenderAction doesn’t support asynchronous controller actions. To accomplish the task, we ended up with a synchronous controller action that used Task.Run to get data from certain async calls. And, yeah, I know that’s not really the greatest thing in the world but there wasn’t a great way around that.

That landed us with a new challenge: HttpContext.Current was null in the Task.Run action but not in the partial view the controller action returned.

Normally that wouldn’t bother me, a service call not having a web request context, but due to a certain chain of logic (again, which I won’t get into) we had a call to DependencyResolver.Current in the asynchronous action. We’re using Autofac, which creates a lifetime scope per web request, but without any request context – explosions.

In the end, we had two solutions.

The first solution manually set the call context in the asynchronous task.

var context = System.Web.HttpContext.Current;
return Task.Run(() =>
  {
    CallContext.HostContext = context;
    return this.AsyncCallThatReturnsTask();
  }).Result;

That worked in some simple cases, but for some reason it didn’t stick in certain chained async/await calls down the stack.

The second solution was to rewrite certain things to be synchronous and only make async calls on things that don’t need HttpContext. That’s sort of a cop-out, but we couldn’t really find a way around it without getting… really, really deep. This is where we actually ended up.

I have a feeling there is something more that could be done by cloning bits of the current SynchronizationContext and/or ExecutionContext, setting up a custom TaskFactory, and firing up the async calls through that, but given the problem we’re solving is sort of a one-off and the high risk of deadlock or something crazy breaking under load…  it wasn’t worth diving that deep.

It would be nice if MVC would support asynchronous RenderAction calls, though.

Record year this year despite Halloween being on a weekday. The weather was pretty nice, which I’m guessing made it more amenable to be out, but otherwise I’m not sure why we got such a boost. We even shut down half an hour early - at 8:00p instead of 8:30p - to get Phoenix to bed. (We had a couple of kids knock after we shut the lights off, so you see those in that final time block.)

Cumulative data:

I added support to generate a “VS2013 Developer Prompt Here” to the Command Prompt Here Generator, so if you’re looking for that, there you go.

I’ve been using NDepend for a while – since version 2.7 – and each release is always noticeably better than the last. Version 4 last year brought with it some of the best stuff with CQLinq and seemed to focus a lot on enhancing the internals and technical usefulness. The latest version, version 5, focuses on the UI and the general user experience.

The NDepend site actually has a great overview of the new features, and Patrick Smacchia has a sort of case study explaining the UI enhancements, so I suggest you check those out.

The UI enhancements are immediately apparent when you fire up the application.

Everything is a lot cleaner and more modern feeling. You don’t realize how much of an impact that has on it until you’re actually using it.

Things are generally much easier to find and figuring out “what to do next” after running analysis isn’t nearly as challenging as it used to be. My complaint from version 4 about the UI being a bit confusing is pretty much gone. The updated menus combined with the dashboard screen (see below) have pretty well solved that issue.

The two coolest improvements that immediately caught my eye were the new dashboard and the update to the HTML report format.

On running the analysis, you are now presented with a dashboard screen that has several metrics and trend graphs. Particularly from a long-term reporting standpoint, these trend graphs are fantastic. You can track how the application is changing over time and very easily communicate that in a visual format. (My screen shot below doesn’t show trends because I only ran it once but you see where they’d go and so on.)

You can customize that dashboard to your heart’s content – every graph has a little set of editing buttons that let you customize and the definitions for those are all stored along with the project.

The HTML report is now also much cleaner. It offers the same great level of detail, but the presentation is such that it’s not all on One Gigantic Page.

The navigation menu on the side slides out when you mouseover and that’s how you get to the detailed info.

One really cool internal enhancement is that you can define what JustMyCode means so your queries over JustMyCode are more precise. You do this by prefixing your query with notmycode like:

notmycode
from a in Application.Assemblies where
!a.NameLike("Foo")
select new { a, a.NbILInstructions }

That way when you query over JustMyCode you get a more specific set of results:

// This will behave based on your definition of JustMyCode
warnif count > 0 from t in JustMyCode.Types where
t.NbLinesOfCode > 500
orderby t.NbLinesOfCode descending
select new { t, t.NbLinesOfCode }

Really slick.

I mentioned to Patrick that it would be nice to be able to define “named code sets” in a similar fashion and reuse those in other queries. In my case, I have a fairly large application, but some of the application assemblies that I want analyzed shouldn’t be counted against the application in coverage analysis. There’s no way to exclude full assemblies from coverage reporting easily because there are several queries that define the metrics – you’d have to copy/paste the “where” clauses across all of them and keep them in sync. Instead, it’d be cool if you could do something similar to the JustMyCode thing where you could define a named set of code (e.g., the set of assemblies on which I want coverage analysis) and then reuse that named set in coverage queries – update the definition once, all the coverage queries get updated.

My number one issue with NDepend still persists to version 5 – you still can’t use environment variables in framework folder paths. Just as in version 4, this is sort of a showstopper when it comes to running NDepend in server farms as part of your build process where the Windows folder and Program Files folder are potentially not on the same drive on every server.

Regardless, NDepend 5 is definitely worth the upgrade. It’s clean and modern, much easier to use, the reports are easier to navigate, and it remains one of the more valuable tools in my toolbox. Head over to NDepend and check it out. The base of overview videos and documentation has been constantly growing so you can actually see it in action doing pretty much anything.

Full disclosure: I got a free personal license from Patrick at NDepend. However, we have also purchased several licenses at work and make use of it to great benefit.