I have loved the Philadelphia region since I took my first interview trip down here in May of 2003, right after I graduated from Penn State. And I never thought I would be leaving, but 11 years after that first interview trip back in 2003 I found myself facing a very difficult decision.

Philadelphia has given so much to me, I received my first professional job here, met my wife here, bought my first house here, had my two kids here, bought my second house here, received my Microsoft MVP here, had tons of support from friends, family, and especially professional support from Bill Wolff and everybody at PhillyDotNet. Given these roots I had put down, and the great admiration I have for the city, the people, and the friends I have made here. The job just proved to alluring to pass up.

At this point in this post you are probably saying "stop babbling and tell us what the job is." Well the job that I am going to be taking on and moving to Seattle to pursue is a job with Amazon.com as a Software Development Manager in charge of the Windows and Mac Desktop applications for Amazon Cloud Drive.

If you don't know what the Amazon Cloud Drive is, it can best be described as a hard drive in the cloud that allows users to enjoy, save and share their most cherished digital assets. It is in the same class of applications as Dropbox, Microsoft OneDrive, Google Drive, or the recently announced Apple iCloud Drive. It is currently a very hot area of tech to be in right now.

To me the most alluring part of this wasn't working at Amazon.com, it was working on a product that operated at the scale of Amazon, and will reach millions of users across all their devices, Kindle, Fire TV, Fire Phone, iPhone, iPad, Android, Mac, and Windows desktops.

Me finding and then getting this job, is essentially like finding my personal Holy Grail. It is an exciting time, with an exciting opportunity to create an application that will help millions of users around the world share their most presious pictures with their loved ones, access there music collection from any computer, and even share a file or two with anybody they want.

It is also going to be a crazy time, because I have to move 2 young kids, 2 cats, and my wife to Seattle. Buy a new house, try to sell my current houses in Philly, and make sure this all goes off as smoothly as possible while starting a new job.

If the next time you see me and all my hair has turned grey and fallen out you will know why.

Note: Any helpful tips about Seattle and the best place to live are going to be greatly appreciated by me and my family. Assuming the market price is reasonable of course.

The latest article about Caddio is a writeup from SportTechie, and my favorite quote from the and music to my ears is this paragraph I pulled from the article:

Though just developed, the Caddio app has revolutionized the golf game for aspiring and novice golfers. By allowing golfers to take on each course with the power of crowdsourced knowledge a valuable digital community has been created that will continue to gain accuracy and legitimacy as more golfers contribute to the platform.

If you are a golfer or just an enthusiest, and want to check Caddio out, you can download the app by visiting the Apple App Store. If you are an Android user, be on the look out for the app this summer in the Google Play and Amazon App stores.

If interested here are a couple more screenshots:

Update: Phil Haack has started a petition to get the steps I outlined below into an easy installer. Please support it with your votes.

Over the past week I have read a couple articles about the pain of "headless" build servers in .NET. First from Maarten Balliauw and then from Phil Haack both of them had suggestions about how to accomplish setting up a build server without installing Visual Studio. But their suggestions were more of a long term problem that could be fixed with NuGet and required much work from Microsoft and the community.

I agree and fully support their long term goals, but I want to give you some short term solutions that I have found to work today if you don't like installing Visual Studio on your build server.

Note: This won't solve all build problems, but it solves many of the build problems I had with building PCL (Portable Class Libraries) on a build server.

The first step, and this one you can't really get around is that you need to install the .NET frameworks you care about.

The second step is to install some "necessary" preliminary tools. (I don't know if these are actually required given the steps below, but if anybody wants to skip over this step when giving this method a shot, I would appreciate the thumbs up or down on this step.)

• MSBuild Tools 2013
• Portable Class Library Tools 2 make sure to use the /buildmachine command when installing
• Update: .NET Framework Developer Pack (thanks to (Eric Williams)[https://twitter.com/MotoWilliams] for this)

One thing that I have seen recommended by others is the Portal Class Library Reference Assemblies don't bother with this. I can't tell you how pointless this installer is. It actually "installs", and I use that term loosely, a zip file in your programs directory. Yes you read that right, Microsoft makes you download an installer for a zip file that they don't even both unzipping. Tip for Microsoft just provide the zip file and save developers a bunch of steps.

The third step and the key to getting everything to build the same on the build server as your local machine is this very simple step. Copy the following directories from your development machine to your build server perserving the directory location:

• C:\Program Files (x86)\MSBuild
• C:\Program Files (x86)\Reference Assemblies

Note: I prefer to zip up the directories prior to copying them to the build server, because it makes the process faster and less error prone. Then when they are on my build server, I just unzip the directories into the correct path.

Conclusion

Between those two directories MSBuild and Reference Assemblies you have most everything you need to complete any build that Visual Studio can do by it self. And the above steps while simple, but not obvious, provide a nice clean build server that doesn't require Visual Studio to opperate.

The only issue with this method is that, once and a while, usually after a new SDK version is released, you will have to re-do step three to make sure your build and development environments are in sync.

Hopefully the detailed explaination of a path forward that Phil provided will make the above steps unnessisary in the future.

This post has been a long time in the making. Actually that is sort of a lie, I completely forgot that I promised a 4 part series until my friend Jon Galloway decided to mention consensus in his BUILD 2014 presentation.

As part of my 4 part series in creating the app I described in my prior posts, I am going to be creating an online planning poker application for distributed teams using AngularJS, SignalR, and TypeScript. In case you missed the prior posts in the series here they are:

1. SignalR + TypeScript
2. AngularJS + TypeScript
3. SignalR + AngularJS

As we saw with SignalR + TypeScript it is rather trivial to define the interfaces for the SignalR client in TypeScript, and by doing this it makes sure that your JavaScript code never suffers from the development angst that happens when as action methods change in your SignalR hub.

Then we saw that AngularJS + TypeScript was even more straight forward than SignalR + TypeScript because you didn't have to define and keep in sync an interface that represented your server infrastruture. The only interface you had to define was the $scope interface that was inherited from ng.IScope. All the other code was pretty much straight AngularJS both for the HTML template and the TypeScript code.

After putting everything we learned in to practice, combining SignalR + AngularJS was just a matter of wiring what we had already learned about in SignalR + TypeScript and AngularJS + TypeScript together.

SingalR + AngularJS + TypeScript

You can imagin we have already done most of the leg work here, so combining all three together should be pretty straight forward at this point. The full source of the TypeScript can be found here but a good example of what we are dealing with is the joinRoom method in the TypeScript code, it combines everything we have been talking about pretty concisely.

private joinRoom(room: PokerRoom = this.room) : JQueryPromise {  
    this.$location.path("/rooms/" + encodeURIComponent(room.Name));

    var that = this;
    return this._poker.server.joinRoom(room).done(function (data) {
        that.$scope.room = data;

        var me = that.me;
        data.Cards.forEach(function (card) {
            if (card.User.Email === me.Email)
                that.$scope.myCard = card;
        });

        that.$scope.$apply();
    });
}

Conclusion

Hopefully you have learned as much as I have from creating this app. I came into this fully expecting that bringing together TypeScript, AngularJS, and SignalR would be a nightmare. But after diving in, I found the experience quite a bit easier and less frustrating than I expected it to be.

Here is what the app looks like running in a couple browsers.

If you want to explore and play with this web app yourself you can visit consensus.azurewebsites.net or if you perfer to download and run the code yourself, you can find it here for your forking needs github.com/nberardi/consensus.

Best of luck! Contact me with questions.

Note: to run the code click the Results tab

Tell me what you think, and what needs to be improved upon. I am completely open to suggestions about this new feature.

Update: Just a couple of questions regarding the embedded view:

• Should I allow the code to stay editable so that people can play with it when embedded or should it be static.
• Is the header tab bar too pronounced?
• Would it be better if I hit it under they hovered over the code?

1. SignalR + TypeScript
2. AngularJS + TypeScript

As we have seen in the prior posts when working with TypeScript is that most of the work is around strongly typing the already defined contracts in SignalR and AngularJS. However a part of the integration we haven't yet discussed is how SignalR and AngularJS play together, and as we are about to see they play together rather nicely.

From the last post you were given the following example of an AngularJS controller, and in this post we are going to expand that controller to include SignalR support.

var app = angular.module("consensus", []);  
app.controller("PokerRoomCtrl", function ($scope) {  
    $scope.allCardsShowing = false;

    $scope.showAllCards = function (show) {
        $scope.allCardsShowing = show;
    };
});

To limit the footprint of our example, I have eliminated everything except the show all cards feature. Don't worry the full app will be brought together in full functionality next post, this is just to further the goal of looking at how AngularJS and SignalR can work together.

Given the above code the first thing that we need to do to implement SignalR is to instantiate our proxy in the controller.

var poker = $.connection.poker;

Nothing to it, standard SignalR. Now comes the integration with SignalR, in our example from above the showAllCards function hanging off the controller's $scope needs to send an indicator to our SignalR server. The purpose of this indicator is to allow the team lead to send an indication, in the form of a boolean value, to every-bodies browsers telling them to show the cards.

$scope.showAllCards = function (show) {  
    poker.server.showAllCards(show);
};

In the above code instead of just showing the local cards like the original example from above, we are sending the value of the show variable to the SignalR server to be broadcast to every participant in the room. To receive this broadcasted message we need to hook up our client method to change the $scope.allCardsShowing variable.

poker.client.showAllCards = function (show) {  
    $scope.allCardsShowing = show;
    $scope.$apply();
};

The above method receives the message sent from the SignalR server, on all the team members browsers, and changes the $scope.allCardsShowing variable to the value passed from the server. The only different from this method and the original version, from above, is the use of $scope.$apply();. $scope.$apply(); needs to be called to trigger a context refresh of the AngularJS $scope since the call originated from SignalR which is outside of AngularJS.

After we put everything together, our original example has only slightly changed to accommodate SignalR.

var app = angular.module("consensus", []);  
app.controller("PokerRoomCtrl", function ($scope) {  
    var poker = $.connection.poker;

    $scope.allCardsShowing = false;

    poker.client.showAllCards = function (show) {
        $scope.allCardsShowing = show;
        $scope.$apply();
    };

    $scope.showAllCards = function (show) {
        poker.server.showAllCards(show);
    };
});

We now have AngularJS events that will broadcast intentions out to every browser that is participating in the room. In the next post I will bring AngularJS, SignalR, and TypeScript together to show the final application.

Conclusion

As you can see getting AngularJS and SignalR working together is a lot more straight forward than any other combination we have looked at so far.

There is no source code to post this time, everything will be brought together in the final 2 posts in the series, and the full project will be available for viewing on GitHub.

1. Bringing it all together

1. SignalR + TypeScript

In this second post, I am planning to continue putting the puzzle pieces together with AngularJS and TypeScript, using the strengths of both technologies to make a harmonious solution. To get started we are first going to need to make sure we have the TypeScript definition for AngularJS added to our project, and to do this you need to run the following on NuGet.

Install-Package angularjs.TypeScript.DefinitelyTyped

If you have never used AngularJS before, you may want to familiarize yourself with the AngularJS basics. In our app we are going to have the following application and controller.

• ng-app="consensus"
• ng-controller="PokerRoomCtrl"

Typically you would have controller code that looks like this:

var app = angular.module("consensus", []);  
app.controller("PokerRoomCtrl", function ($scope) {  
    $scope.room = {
        Name: "our room",
        Topic: "our topic",
        Users: [{ ... users ... }],
        Cards: [{ ... cards ... }]
    };

    $scope.myCard = {
        Value: "",
    };

    $scope.$watch("room.Name", function (value) {
        if (!value) return;
        $location.path("/rooms/" + encodeURIComponent(value));
    });

    $scope.allCardsShowing = false;

    $scope.myCardValueChanged = function () {
        alert("Card changed to " + $scope.myCard.Value);
    };

    $scope.showAllCards = function (show) {
        $scope.allCardsShowing = show;
    };
});

But it has the same strong typing problem that SignalR had when it came to TypeScript. But luckily for us with a little adjustment to the above code it is very easy to get TypeScript to play nice and actually benefit your AngularJS code.

As with SignalR, it is necessary to create an interface that will strongly type our code. In the case of SignalR we had to create a strongly typed client and server interface to interface with the backend server. As you probably already know, everything in AngularJS is based on a primary parameter called $scope, and that won't change when using TypeScript, however we are going to strongly type it, and for out example it will look something like this with our scope interface extending ng.IScope.

export interface IPokerRoomScope extends ng.IScope {  
    myCardValueChanged();
    showAllCards(show: boolean);

    allCardsShowing: bool;

    room: PokerRoom;
    myCard: PokerCard;
}

Now that we have our scope defined lets see how creating a controller for AngularJS is effected when doing it in TypeScript. In AngularJS the typical controller looks something like this:

function PokerRoomCtrl ($scope) {  
    ...
}

Instead of creating a function as defined above we are going to create a class with a constructor that takes $scope in TypeScript:

export class PokerRoomCtrl {  
    constructor(private $scope: IPokerRoomScope) {
        ...
    }
}

As you can see they are very familiar in structure, however they look even more closely related when you take a look at the JavaScript that is generated from TypeScript.

var PokerRoomCtrl = (function () {  
    function PokerRoomCtrl ($scope) {
        this.$scope = $scope;
        ...
    }
    return PokerRoomCtrl;
})();

To AngularJS the reference controller I showed above and the TypeScript generated controller are essentially the same thing in JavaScript, which is why AngularJS and TypeScript work together without too much hassle.

The $scope parameter is a dependency of the controller that is injected. You can read more about AngularJS and dependency injection here. The reason I bring this up, is because once you understand how AngularJS injects dependency into your controller, you'll realize that minimizers destroy AngularJS's ability to do dependency injection. And exceptions like this will be generated in your JavaScript console in the browser.

Error: Unknown provider: XProvider <- x<="" pre="">

Because it is common place to minify JavaScript code, it is highly recommended that you specify an $inject property in your code. You can read more about the $inject property here. To do the same in TypeScript you simply have to add the following to your controller class.

// protect the injection from minification  
static $inject = ['$scope'];

The last recommendation for working with AngularJS and TypeScript is for you to define the controller class in the AngularJS app, which you may remember from the original example.  TO define the controller class in the AngularJS app you do the following:

var app = angular.module("consensus", []);  
app.controller("PokerRoomCtrl", PokerRoomCtrl);

Putting this in your TypeScript code is more of a convenience than a necessity. If you don't have this app controller definition, you will have to fully reference your controller class on the page, which will include the full namespace of your TypeScript module plus the class name.  Instead of me having to reference Consensus.PokerRoomCtrl as the controller name, I can simply just use PokerRoomCtrl or whatever other name you give the controller when referencing it in the AngularJS app.

Conclusion
  

As you can see getting AngularJS and TypeScript working together is a lot more straight forward than SignalR and TypeScript.  

There is no source code to post this time, everything will be brought together in the final 2 posts in the series, and the full project will be available for viewing on GitHub.

  
    
SignalR + AngularJS
    
Bringing it all together

In this first post, I would like to talk about bringing SignalR and TypeScript together to create a solution that follows the best practices of both frameworks. To get started we are first going to need to make sure we have the TypeScript definition for SignalR added to our project, and to do this you need to run the following on NuGet.

Install-Package signalr.TypeScript.DefinitelyTyped

If you have never used SignalR before, you may want to familiarize yourself with the SignalR basics.  In the app we have the following client and server endpoints.

(each row shows a server call and a resulting client call that is broadcast to all users in the planning poker room)

Typically you would make calls like this:

var poker = $.connection.poker;  
poker.client.userChanged = function (user) {  
    console.log("user " + user.Name + " changed");
};
$.connection.hub.start().done(function () {
    $("#join").click(function () {
         poker.server.joinRoom({ Name: $("#roomName").val() }, { Name: $("#userName").val() }).done(function(room) {
             console.log("joined " + room.Name + " room and " + room.Users.length + " are present");
         });
     });
});

The only problem with this approach is that TypeScript knows nothing about the custom proxy that was generated at $.connection.poker, so it will throw errors and not allow the compilation of the code to continue. There are ways to get around this by not using the generated proxy as described in the guide I linked to earlier, but that is not type safe and really doesn't take advantage of any of the benefits that TypeScript's type safety offers. Lets do it the right way, and to do it the right way to gain the type safety we need to define our client and server interfaces to TypeScript.

The first thing we need to do is tell TypeScript about our generated proxy called poker.

interface SignalR {  
    poker: HubProxy;
}

You do that by extending the SignalR type interface in your typescript file. Note that this extension of SignalR has to be done out side of the module namespace. Next lets extend client and server extensions off of the HubProxy interface. This will provide us with interfaces to define our methods for the endpoints we talked about earlier in the table above.

interface HubProxy {  
    client: IPokerRoomClient;
    server: IPokerRoomServer;
}

This extends HubProxy in a similar way that we extended the SignalR interface by just adding additional properties to an already existing interface. The last thing we need to do is define the endpoint methods for our client and server. Which you can find here.

interface IPokerRoomClient {  
    userChanged(user: Consensus.PokerUser);
    userRemoved(user: Consensus.PokerUser);

    resetRoom(room: Consensus.PokerRoom);
    showAllCards(show: boolean);
    roomTopicChanged(topic: string);
    cardChanged(card: Consensus.PokerCard);
}

interface IPokerRoomServer {  
    join(user: Consensus.PokerUser): JQueryPromise;
    joinRoom(room: Consensus.PokerRoom): JQueryPromise;
    leaveRoom(room: Consensus.PokerRoom, user: Consensus.PokerUser): JQueryPromise;

    resetRoom(room: Consensus.PokerRoom): JQueryPromise;
    showAllCards(room: Consensus.PokerRoom, show: boolean): JQueryPromise;
    changeRoomTopic(room: Consensus.PokerRoom, topic: string): JQueryPromise;
    changedCard(room: Consensus.PokerRoom, value: string): JQueryPromise;
}

The above interfaces define the type safe endpoint methods for both the client and server side of SignalR. A couple new types were defined in the above code for types we haven't yet talked about. These are object types that match exactly what is used on the server side.

module Consensus {  
    export class PokerUser {
        public Name: string;
        public Email: string;
        public Disconnected: string;
    }

    export class PokerRoom {
        public Name: string;
        public Topic: string;
        public Users: PokerUser[];
        public Cards: PokerCard[];
    }

    export class PokerCard {
        public User: PokerUser;
        public Value: string;
    }
}

These types will make more sense when we actually walk through the server side code, but for now here they are. You can see all this put together here: consensus.pokerRoom.ts. Next lets go over the C# equivalents of the above.

namespace Consensus.Models  
{
    public class PokerUser
    {
        public string Name { get; set; }
        public string Email { get; set; }

        public DateTimeOffset? Disconnected { get; set; }
    }

    public class PokerRoom
    {
        public PokerRoom()
        {
            Users = new List();
            Cards = new List();
        }

        public string Name { get; set; }
        public string Topic { get; set; }

        public virtual ICollection Users { get; set; } 
        public virtual ICollection Cards { get; set; } 
    }

    public class PokerCard
    {
        public PokerUser User { get; set; }
        public string Value { get; set; }
    }
}

The above are one-to-one matches of their TypeScript counter part. Having a one-to-one match isn't necessary for everything to work, but it makes life easier. The rest of the code for this post is creating working hub methods for SignalR, which I am going to briefly cover to bring our original JavaScript example in for a full loop. I am just doing this for completeness because there are many other articles on the web that deal with the topic of creating SignalR hub methods, including the article I originally referenced above.

public PokerRoom JoinRoom(PokerRoom room)  
{
    var user = _users.Where(x => x.Key == Context.ConnectionId).Select(x => x.Value).FirstOrDefault();

    if (user == null)
        throw new Exception("No user with this connection Id has joined yet.");

    _logger.Info("{0} joined {1} room", user.Email, room.Name);

    room = _rooms.FirstOrDefault(x => x.Name == room.Name) ?? room;

    if (!_rooms.Contains(room))
        _rooms.Add(room);

    if (room.Users.All(x => x.Email != user.Email)) {
        room.Users.Add(user);
    }

    // tell the people in this room that you've joined
    Clients.Group(room.Name).userChanged(user);

    Groups.Add(Context.ConnectionId, room.Name);

    return room;
}

From the original endpoint table this hub method covers the 2nd row after the header for the joinRoom / userChanged server and client methods. If you would like to view the rest of the methods for this hub, you can see all this put together here: Poker.cs.

Conclusion

As you can see getting SignalR and TypeScript working together isn't as straight forward as other frameworks like jQuery because the auto proxy generation. Ultimately TypeScript may seem like a pain to setup initially because of the little extra work you have to do at the beginning of a project to define your proxy interfaces. However in the end you have a type safe interface for your client and server endpoint methods, which will save you time in the long run.

If you would like to view all the source for this post, you can find it here at the GitHub Gist I setup. https://gist.github.com/nberardi/5904129. Best of luck and stay tuned for the next 3 posts in the series.

1. AngularJS + TypeScript
2. SignalR + AngularJS
3. Bringing it all together

If you are not familiar with planning poker, you can learn more here, the general premise is this:

The reason to use Planning poker is to avoid the influence of the other participants. If a number is spoken, it can sound like a suggestion and influence the other participants' sizing. Planning poker should force people to think independently and propose their numbers simultaneously. This is accomplished by requiring that all participants show their card at the same time.

• A Moderator, who will not play, chairs the meeting.

• The Product Manager provides a short overview. The team is given an opportunity to ask questions and discuss to clarify assumptions and risks. A summary of the discussion is recorded by the Project Manager.

• Each individual lays a card face down representing their estimate. Units used vary - they can be days duration, ideal days or story points. During discussion, numbers must not be mentioned at all in relation to feature size to avoid anchoring.

• Everyone calls their cards simultaneously by turning them over.

• People with high estimates and low estimates are given a soap box to offer their justification for their estimate and then discussion continues.

• Repeat the estimation process until a consensus is reached. The developer who was likely to own the deliverable has a large portion of the "consensus vote", although the Moderator can negotiate the consensus.

• An egg timer is used to ensure that discussion is structured; the Moderator or the Project Manager may at any point turn over the egg timer and when it runs out all discussion must cease and another round of poker is played. The structure in the conversation is re-introduced by the soap boxes.

Now that you have a basic understanding of what planning poker consists of, the parts of the procedure that I am going to build an application for are specifically choosing the cards, and showing them.

Why did I choose AngularJS, SignalR, and TypeScript over other similar technologies?

No reason in particular, I have been using AngularJS, SignalR, and TypeScript for quite a while now, but I had never used any of them in conjunction with each other.  As a fun exercise to see how easy or painful it would be to use all 3 in the same project I decided to create this poker planning tool, which I called Consensus.

Where can I find a working copy?

You can find a working copy of the Consensus software at: http://consensus.azurewebsites.net/

Break down of future posts:

I am going to break this application into a 4 part series of blog posts, that deals with integrating just two components at a time. I believe this is the best approach, because not only does a combination of two of these technologies expand how relative the post will be to the audience, over all three technologies at the same time. But it also breaks up a very long topic into 4 easily digestible posts, instead of just throwing it together in one large post that is too long for anybody but the most die-hard to care about reading.

1. SignalR + TypeScript
2. AngularJS + TypeScript
3. SignalR + AngularJS
4. Bringing it all together

Stay tuned the posts should start rolling out soon.

Last year was my first year being involved in the Microsoft MVP program.  Over the past year, I have met many great developers through the MVP program and at the Summit, and  I am happy to say that my MVP for ASP.NET/IIS has been renewed for a 2nd year.

This is part 1 of a two part interview that we had with the founders of the Glimpse Project, Nik Molnar and Anthony van der Horn.  The reason for two podcast releases is that we had such a great conversation with them, it was very tough to find any bad parts of the interview, plus there were essentially two podcasts.  One about Glimpse and how it came about, and the other about the industry of open source.  In the first podcast, Nik and Anthony talk to us about what it was like to start Glimpse and what it takes to create a successful open source project.

If you are not familiar with Glimpse, it is an Open Source platform that aims to change the way we think about diagnostics and the frameworks we interact with. After releasing Glimpse at Mix11, Glimpse has become a tool that is used daily by tens of thousands of developers around the world. It is intended for developers who want to use a a client side diagnostics tool for the server side of their applications. It is often referred to as Firebug for the server.

Podcast: http://seriouslyopen.com/glimpse-with-nik-molnar-and-anthony-van-der-hoorn
Download: http://traffic.libsyn.com/seriouslyopen/2-glimpse-nik-molnar-anthony-van-der-hoorn.mp3
iTunes: https://itunes.apple.com/us/podcast/seriously-open/id636361747

To talk about and promote Open Source .NET software development to encourage more participation.

It occurred to us while we were talking about the setup of the podcast, such as name, logo, topics, etc, that we should just record it.  And make this podcast process as open as possible, just like a real open source project.  We decided on the podcast that we had the following outstanding issues for the podcast that we needed pull requests from the community for:

1. Name Should be available both in .com and twitter
2. Logo Dependent on #1 being done.
3. Intro and exit music.
4. A 3rd podcast member.

If you can help us out with any of these issues will we take your suggestion seriously and incorporate them in.  The obvious outstanding and persistent issue that we will always be willing to accept is new hot .NET Open Source projects that you would like us to interview the founders of.

Without any more setup, here is our first podcast in hopes of many more if it is well received.

Please use the commenting in my blog to leave any feedback, as we get the above issues resolved we will try and find a better home for what we are doing.

I am writing this post, because even after one year I am getting very passionate comments on one side of the issue or not, people don't seem to take a middle road on the strong naming issue. If you don't believe me take a look at the comments.

Lucky for us, most developers who choose to strongly name their assemblies now are using a versioning mechanism that reduces the chances of breaking referencing assemblies in NuGet.  This "new" versioning technique is actually a non-technique.  Let me explain, instead of changing the version of the assembly with each release, you leave the version of the assembly set, until it is necessary to communicate a major release.

Lets look at JSON.NET again as our standard bearer.  Mostly do to the fact that it is the most widely used strongly named assembly in NuGet.  Since I last wrote my post almost a year ago, 11 releases have been made, however none of those releases caused breaking changes for any of the NuGet packages that referenced a 4.5.x version when built.  You may ask, "So what changed?"  As I alluded to previously the answer is "Nothing."  NuGet still functions as it did a year ago.  Strong naming still functions as it did a year ago.  .NET assemblies still function the same as they did a year ago.  The strongly named version of Newtonsoft.Json.dll did change either across those 11 releases, it has remained constant at 4.5.0.0.  And that last thing is exactly what was needed to settle down all the referencing problems in NuGet.

As I talked about in my previous post the main difference between strongly named assemblies and plain assemblies is that when you strongly name an assembly the versions have to match for any referencing assembly, for plain assemblies there is no requirement.  If you put out a new release of a strongly named assembly and don't change the version, the assemblies that reference it don't know the difference and are happy to keep using it.

At the time when I posted my previous post, I hadn't realized that James Newton-King had changed the policy to what I had described above, which is commonly referred to as SemVer.  He pointed this out to me in the comments.

FYI I discussed strong naming a couple of weeks ago –http://james.newtonking.com/archive/2012/03/20/json-net-4-5-release-1-iso-dates-async-metro-build.aspx No one seems to have read it.

He was right I didn't read it and that was a failure on my part.  The only reason I bring this up and mention him in this post, is because while I don't owe him an apology for speaking my opinion, I do have to apologize for using his project as an example of a wider spread problem in the industry at that time.  Projects like JSON.NET are often surrogate children to their owners, and to call out another person's child in such a public way isn't fair, so I apologize for that.

My stance on Strong Naming assemblies has softened a little over the past year, mostly due to the fact that it isn't causing me as much greif as it use to.  I still think it is a plague on .NET developers, unwittingly forced down on high from a VP who read a white paper from 2001.  However, I typically take the stance of, if it doesn't effect or slow down me, I am going to stay hands off on what other people do.  And right now that is the case.

In honor of the Microsoft MVP Summit going on in Seattle right now, we are offering every person who signs up this week, 5 hours of complimentary compute time for running all your CRON jobs. Signup here: http://executify.com/signup After you sign up for your account be sure to checkout our documentation on creating your first CRON job in Executify.

When it gets to the point of out right copying of whole files it becomes a different story all together.  And that is what I am addressing today.  I should start out by saying that Datastax is a great contributor to open source software, and has provided the Cassandra community with a great amount of free docs and tools, and is one of the primary drivers behind recommending the FluentCassandra library to clients.  I wish that is where we could leave it.

One of their developers decided to take some shortcuts and started copying FluentCassandra without attribution and passing the work off has his own. Everybody has deadlines and I understand that, but it takes a certain kid of malevolence and disdain for open source software, to out right copy certain parts of a competing code bases code for the expediency of getting your own out to market.

The developer who did this, Pawel Kaplanski, contributed a couple issues and some minor code that ultimately had to be rewritten to FluentCassandra back in September 2012.  You can see that he does work for Datastax here and that the only thing he has done for open source software ever to contribute a few minor things to FluentCassandra over a 3 day period in September. (side note: I would hope that a company like Datastax who loves open source software, would hire developers who love open source software, however that doesn't appear to be the case with Pawel who seems to only troll for code to make his day job easier)

Pawel was first introduced to me back in September by Michael Figuiere. In the email Michael was explaining to me that Pawel was going to be helping me out on FluentCassandra while working on their own client library.  Which was wonderful news for me, because I always appreciate help, I thought this was a win-win for everybody involved. But as you can see from the above Github interactions, Pawel didn't quite live up to his end of the bargain, and as I will show next in seemed to only be a win for Pawel.

So lets get down to the dirty stuff.  Which I have started to track in an issue on FluentCassandra.  The first and most egregious copying of code, and the part of FluentCassandra that has literally taken many many weeks of my time, over the past year, in tweaking and getting just right is the LINQ Expression Evaluator.

As you can see in this picture the white spaces in the indicator on the left hand side is code that was copied.  These pieces of code contain the exact method names, program code, positions, and everything, so it is undoubtedly copied as a whole and then tweaked for his own needs.  This is just lazy and dishonest.

There are others too, notice any similarities here:

https://github.com/datastax/csharp-driver/blob/28d8958873f55727bf515cf97b32c9cbfa31af9f/Cassandra.Data.Linq/CqlQueryEvaluator.cs
https://github.com/datastax/csharp-driver/blob/28d8958873f55727bf515cf97b32c9cbfa31af9f/Cassandra/GuidGenerator.cs
https://github.com/datastax/csharp-driver/blob/28d8958873f55727bf515cf97b32c9cbfa31af9f/Cassandra/GuidVersion.cs
https://github.com/datastax/csharp-driver/blob/28d8958873f55727bf515cf97b32c9cbfa31af9f/Cassandra/DateTimePrecise.cs

No attribution at all for our hard work:

https://github.com/managedfusion/fluentcassandra/blob/master/src/Linq/CqlQueryEvaluator.cs
https://github.com/managedfusion/fluentcassandra/blob/master/src/GuidGenerator.cs
https://github.com/managedfusion/fluentcassandra/blob/master/src/GuidVersion.cs
https://github.com/managedfusion/fluentcassandra/blob/2c77dfca83891a9559e14a2b58797095c0486050/src/System/DateTimePrecise.cs

The last one is the most interesting because it dates when he copied the FluentCassandra source code as somewhere between August 25 and September 6.  Which line up nicely to his 3 days that he looked at FluentCassandra.  I know this date range because I removed DateTimePrecise from the code base on September 6 because it had a nasty bug in it.

To be clear I am just very irritated that Datastax promised some help to FluentCassandra and the only help we seem to have gotten was a developer who decided to steal our code and not contribute anything back.  And the two bugs that Pawel opened on FluentCassandra were bugs that he fixed in his own copy of the source code, but couldn't be bothered to contribute back to FluentCassandra.  That takes a real set of brass ones to be that blatant.

There is one bright spot and really all that I ask for, developer kcieslinski does actually attribute FluentCassandrawhen he copied the BigDecimal code.

That simple one line is all that I ever ask for.