Simplify Your Code

DependenciesThe rise of package managers like nuget and npm have made taking on external dependencies into your project easier.  Because of this ease, it seems more developers are often adding external dependencies to their project without much thought on the complexity they may be adding.  I suggest you can simplify your code by limiting external dependencies.

Frameworks

Some frameworks are going to be the foundation to parts of your application.  ASP.NET MVC for example, could be the base framework for your UI.   However, it should not be the foundation of your application.  You should view it as the HTTP interface to your application.  Robert “Uncle Bob” Martin has a talk Architecture: The Lost Years which addresses this point.    Developers have been using MVC frameworks as top level architecture which represent the entire application rather than the delivery mechanism.

Dependencies

In recent years and the rise of pushing more to the client side, the front-end development space is full of SomeLibrary.js.

Take Durandal as an example for developing SPA applications.  It is built on top of jQuery, Knockout, RequireJS.  In order to developer a SPA app with Durandal, you are at a minimum taking on 4 dependencies.  Odds are very good you will be adding more dependencies such as Bootstrap, Breeze, Moment, etc.   I’m a fan of Durandal and Rob Eisenberg, which is why I’m really excited to see Aurelia.

You may be saying to yourself: “Who cares!  These are all popular and mature open source libraries!”.  Yes they are, but that doesn’t mean they are bug-free and simple.  They may also move at a pace that is quicker than your own release cycle which can lead to you constantly trying to stay current.

Any external dependency you rely on is now your code and your problem.

How do you explain to a customer or boss of a when you discover a bug that is causing an issue your application?  Do you think they care that you didn’t write it?  It’s your problem.

What Smells?

Code SmellAutomapper is a good example of a popular dependency that can hide a code smell.  If you have a lot of DTO’s that you are mapping through different layers, I can see why you would want to use automapper.  It would be really annoying to have to write all the simple mapping code from one DTO to another.  Hiding smells by using automapper isn’t necessairly the answer.  I would rather the question be asked “Why are we mapping X -> Y -> Z?  Do we really need 3 DTO’s before getting serialized to the client?”

Limiting your external dependencies can simplify your code.  I’m not saying to ditch all your dependencies and to never use anything external.  What I’m saying is be very diligent and understand the dependency, how it works and the problem it solves.

Do you really have the problem that dependency solves?  If so, why do you have that problem?

Visual Studio Online Check-In Policies

Visual Studio Online Check-In Policies

Want to produce better code and more efficient development group? Start using Visual Studio Online check-in policies within your team project.

Check-in Policies are rules you can define at a Visual Studio Online team project which are enforced when a developer attempts to check-in their source code.

Note: You must be using Team Foundation Version Control (TFVC) with your project in order to use the check-in policies.  Although VSO now supports Git as a version control system for your team project, check-in policies are not supported.

One of the main reasons I started using check-in policies was to enforce associated work items to a changeset.  Having all changsets associated to work enabled me to automate the creation of a change lot during the build process.  If you are looking for better way to visualize your Visual Studio Online work items, take a look at my LeanKit Visual Studio Online Integration blog post.

Source Control Settings

From the Team Explorer, access the settings menu and select Source Control under the Team Project heading.

Visual Studio Online Check-In Policies

 

Under the Check-in Policy tab, click the Add button to select the policy you want to add.

Visual Studio Online Check-In Policies

Without any extension or power tools, Visual Studio Online provides four team project check-in policies that you can specify:

Builds
Requires that the latest build was successful for each affected continuous integration build definition.

Changeset Comments Policy
Requires the developer to provide comments with the check-in.  These comments will be associated with the changeset.

Code Analysis
Requires the developer to run Code Analysis from Visual Studio prior to check-in.

Work Items
Requires the developer to associate at least one work item with the check- in.

Code Review Policy

There is a great policy written by Colin Dembovsky (@colindembovsky) on Visual Studio Gallery that provides Code Review Policy.

Once the extension is installed you will now have a new option available to add.

Visual Studio Online Check-In Policies

Visual Studio Online Check-In Policies

 

Once this policy is added, you will be unable to check-in until a Code Review has been requested, closed, and has no “Needs Work” response.

CheckIn5

Integrate LeanKit and Visual Studio Online

Integrate LeanKit and Visual Studio Online

LeanKit and Visual Studio Online are both two great tools.  Why not use them both?  Here is a guide to integrate LeanKit and Visual Studio Online.

Although Visual Studio Online (and Team Foundation Server) provide a task board  to visualize work items and flow, I prefer to use the fully customized Kanban board by LeanKit.  Thankfully, I found out that LeanKit has created an Integration Service, which is available on GitHub.

My goal is to manage all work items within LeanKit, however I want to be able to associate Visual Studio Online Work Items to changesets (during checking) within Visual Studio.  (LeanKit/VSO ChangeLog how-to coming soon!)

Overall the installation and configuration is fairly straightforward. However, there were a couple hiccups I encountered along the way that inspired this how-to.  I also wanted to point out that main contributor to the integration service, David Neal (@reverentgeek), was very helpful in answering questions via Twitter.  Check out the source code if you’re interested, pretty nice code.

Integration Service Installation

  1. Download the latest zip/executables from LeanKit’s website here.
  2. Follow the installation guide provided by LeanKit.

Although LeanKit provides a bit of an overview on the configuration, follow these steps specifically for connecting to Visual Studio online (or Team Foundation Server).

Visual Studio  Online – Alternate Authentication Credentials

Before you configure the integration service, you must enable alternate authentication credentials to your Visual Studio account profile.  This allows you to specify a username/password the integration service can use to connect to Visual Studio Online Web Service.

When in Visual Studio Online, access your account profile to enable the alternate authentication credentials.

VSO Alternate Authentication Creds

 LeanKit – Board Settings

In your LeanKit board settings, go to the Card ID Settings section.  Here you will want to make sure that you are using the external card ID.  Do not select the auto-increment card ID setting because we want the Card ID to be the same as the Visual Studio Online Work Item #.

LeanKit Card ID Settings

Configure Integration Service

After installation, browse to http://localhost:8090 to access the web interface.  Specify your LeanKit account and credentials.

LeanKit Integration

Next, specify your Visual Studio Online account and alternate access credentials.

LeanKit Integration

The integration service is very configurable in terms of mapping LeanKit Cards to VSO Work Items and different status.  Select the LeanKit board and the Visual Studio Online Project you would like to create a mapping for.

LeanKit Integration Mapping

In the Selection tab, you will want to select the VSO Work Item States and Types that will be mapped to LeanKit.

LeanKit Mapping

The Lanes and States tab will be populated with the swim lanes and columns from your Kanban board.  Select a column or lane and then select an available state to map.  The intent here is to specify if the LeanKit card moves to that column/lane it will be updated in VSO with the mapped State.  If you define multiple states, only the first matching state will be used.

In the example below, I’ve mapped the Backlog column  to the New and To Do VSO states.

LeanKitVSO-Step5

In the Card Type tab, specify which LeanKit card types you want to map to which VSO Work Items.

LeanKit Integration Card Types

In the Options tab, specify how you want the integration service to sync.  It can sync changes bi-directional, however for my usage, I only want to push changes from LeanKit to VSO.  As mentioned above, I only want to use LeanKit for managing work items, however I want them to be in VSO so I can associate work items to changesets.

LeanKit Integration Options

Be sure to click the save button if you haven’t already.  What may not be obvious at this point is that you need to Activate your new configuration.  Click on the Activation tab, then click on the big red Activate Now button.

LeanKit Integration Activate

That’s it!

I’ve created a LeanKit Defect Card in my Product Backlog and the Integration Service has created the Bug work item in VSO.

LeanKit Test

LeanKit Test