Author: Dave Fancher

Dave Fancher is a Software Engineer at Performance Assessment Network in Carmel, Indiana, a Microsoft MVP for Visual F#, and author of The Book of F# from No Starch Press. He has been building software with the .NET Framework since version 1.1. Dave is active within the Indiana software development community as a member of IndySA, a speaker at user groups throughout the state, and a two-time contributor to Indy GiveCamp. When not writing code he enjoys spending time with his family, watching movies, photography, and gaming on on his Xbox One.

December’s Indy F# Meetup

IndyF#After a successful first meetup in November we wanted to keep the momentum and get the next meetup on the calendar. Our second meeting will be at 7:00 PM on December 16th at Launch Fishers.

In keeping with our plan to alternate between hands-on sessions and the more traditional speaker-led sessions, the December meeting will follow the later format with not one, but two talks! The event will feature me giving an introduction to type providers and Brad Pillow will give an overview of using FunScript to develop single-page applications.

If either of these topics interest you, please swing over to our meetup page and register.

We hope to see you there!

Changing the Default TFS Check-in Action

It’s been a number of years since I worked with TFS. Now that I’m back in that world one of the things that has bitten me is that by default any tasks tied to a check-in are resolved by default. Automatically marking tasks as complete has left me scratching my head in bewilderment as I wondered why a task I’m actively working on was no longer listed under my tasks. I can see the utility of this behavior in some circumstances but I often make incremental check-ins as I work through more complex tasks so clearly I don’t want checking in my changes to automatically close the task.

Since relying on my memory to change the check-in action from Resolve to Associate clearly isn’t adequate here I looked for some way to change the default behavior. I found that there are two ways to achieve this, neither of which are obvious.

The first method is to remove the Microsoft.VSTS.Actions.Checkin action from the work item template. The other method applies only to the client machine but requires a registry edit. Neither option is particularly great but given that the first option requires you to have authorization to modify the template and applies to each user of the template, I opted for the second approach.

To disable the default resolution option you need to locate HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\12.0\TeamFoundation\SourceControl\Behavior\ResolveAsDefaultCheckinAction and change the ResolveAsDefaultCheckinAction value from True to False. After making the change, restart Visual Studio and the Associate should now be selected the next time you try adding a work item to the check-in.

ResolveAsDefaultCheckinAction option

Fun with Code Diagnostic Analyzers

A few days ago I posted an article detailing how to construct a code diagnostic analyzer and code fix provider to detect if..else statements that simply assign a variable or return a value and replace the statements with a conditional operator. You know, the kind of things that code diagnostic analyzers and code fix providers are intended for. As I was developing those components I got to thinking about what kind of fun I could have while abusing the feature. More specifically, I wondered whether could I construct a code diagnostic analyzer such that it would highlight every line of C# code as a warning and recommend using F# instead.

It turns out, it’s actually really easy. The trick is to register a syntax tree action rather than a syntax node action and always report the diagnostic rule at the tree’s root location. For an extra bit of fun, I also set the diagnostic rule’s help link to fsharp.org so that clicking the link in the error list directs the user to that site.

Here’s the analyzer’s code listing in its entirety:

using Microsoft.CodeAnalysis;
using Microsoft.CodeAnalysis.Diagnostics;
using System.Collections.Immutable;

namespace UseFSharpAnalyzer
{
    [DiagnosticAnalyzer(LanguageNames.CSharp)]
    public class UseFSharpAnalyzerAnalyzer : DiagnosticAnalyzer
    {
        internal static DiagnosticDescriptor Rule =
            new DiagnosticDescriptor(
                "UseFSharpAnalyzer",
                "Use F#",
                "You're using C#; Try F# instead!",
                "Language Choice",
                DiagnosticSeverity.Warning,
                isEnabledByDefault: true,
                helpLink: "http://fsharp.org");

        public override ImmutableArray<DiagnosticDescriptor> SupportedDiagnostics { get { return ImmutableArray.Create(Rule); } }

        public override void Initialize(AnalysisContext context)
        {
            context.RegisterSyntaxTreeAction(AnalyzeTree);
        }

        private static void AnalyzeTree(SyntaxTreeAnalysisContext context)
        {
            var rootLocation = context.Tree.GetRoot().GetLocation();
            var diag = Diagnostic.Create(Rule, rootLocation);

            context.ReportDiagnostic(diag);
        }
    }
}

When applied to a C# file, the result is as follows:

Use F# Analyzer

This is clearly an example of what not to do with code analyzers but it was fun to put together and see the result nonetheless. If you’ve thought of any other entertaining uses for code analyzers, I’d love to hear about them!

IndyF#

Indianapolis F# Developers Coding Dojo

There’s a new developer group in town! The inaugural meeting of the Indianapolis F# Developers group is upon us. On Tuesday, November 18th I’ll be leading the group through the Digit Recognizer dojo from Community for F#!

Since I suspect we’ll have some people new to the language, we’ll spend some time talking about some language concepts that are critical to successfully completing the exercise. Make sure you bring a laptop because after the introduction we’ll then split into a few groups (pairs, probably) and work through the problem together. After some time we’ll come back together as a group to talk about the problem and discuss some of the ways that F# lets you focus on the task at hand.

If F#, functional programming, and/or machine learning are of interest to you, please register for the event on our meetup page. We’ll be meeting in the 20 person meeting room at Launch Fishers. The meetup starts at 7:00 PM. We’d love for you to join us!

I Can Analyze Code, And So Can You

Over the past several years, Microsoft has been hard at work on the .NET Compiler Platform (formerly Roslyn). Shipping with Visual Studio 2015 the .NET Compiler Platform includes a complete rewrite of the C# and Visual Basic compilers intended to bring features that developers have come to expect from modern compilers. In addition to the shiny new compilers the .NET Compiler Platform introduces a rich set of APIs that we can harness to build custom code diagnostic analyzers and code fix providers thus allowing us to detect and correct issues in our code.

When trying to decide on a useful demonstration for these features I thought of one of my coding pet peeves: using an if..else statement to conditionally set a variable or return a value. I prefer treating these scenarios as an expression via the conditional (ternary) operator and I often find myself refactoring these patterns in legacy code. It certainly would be nice to automate that process. It turns out that this is exactly the type of task at which diagnostic analyzers and code fix providers excel and we’ll walk through the process of creating such components in this post. (more…)

Recursive AngularJS Directives

It has been a long time since I’ve done any greenfield UI development. Most of my projects over the past several years have involved extending existing Web Forms or ASP.NET MVC apps with some new controls here or there. You can imagine my delight in being able to work on a brand new system with AngularJS as the front-end technology.

I’ve heard a number of good things about AngularJS over the past year or so and have familiarized myself with enough of its core concepts to hold (hopefully) an intelligent conversation about it but this is my first time actually using it on a real project. Given that I still have plenty to learn it didn’t surprise me too much when I encountered my first real roadblock – a recursive directive. (more…)

Talking TypeScript in Fort Wayne

I’ll be back in Fort Wayne on October 15 to talk about TypeScript. If writing JavaScript frustrates you or you just want to be more productive, join NUFW at the Cole Foundation Conference and Training Center to learn how leveraging TypeScript in your existing projects can lead to cleaner and more expressive code.

Please visit the NUFW site for logistics and registration details.

I hope to see you there!