First you need to add a remote branch to your repository that points to the original repo you forked from.

git remote add --track [branch to track] [name to call it][user]/[repo].git

You will want to replace ‘[branch to track]’ with the branch you want to track in the remote repo. In most cases this will be ‘development’, although you could replace it with edge or any other branch. You should also replace ‘name to call it’ is what you the remote will be called.

To verify the remote repository was added run

git remote

You should see the new remote repo, in this case named ‘[name to call it]’, along with any other remote repositories you may have previously added.

Now we can fetch all the changes from the fork’s code base.

git fetch [name to call it]

This will create a new remote branch called ‘[name to call it]/[branch to track]’. Now we are ready to merge the code from the remote repository.

git merge [name to call it]/[branch to track]

I have been using shared web hosting services for several years now. As an early adopter of ASP.NET MVC – as far back as the first CTP – I needed to research several that met my requirements and beta-phase experimentation. One of my most popular blog posts was actually my recommendation for cheap shared hosting. Since then, I have been running several other sites and figured it was time to graduate to a Virtual Private Server (VPS).

I considered using a cloud solution, but I don’t think that kind of scaling will be necessary at this point.  It is also fairly expensive and may fluctuate depending on usage.  So I opted to use a fixed price VPS host.  There are many, many offering available but the most economical which still provide a full feature set, and the one I ultimately choose was  Like I mentioned in my original shared hosting post, I wouldn’t post about a hosting company unless they really impressed me.  That is still true here.  I believe they have the best VPS hosting out there for any Windows-based projects.  I think a lot of it has to do with the fact that their main focus is VPS.

Their starter package costs a very reasonable $17.99 a month for a Windows 2008 Server and includes full root, remote desktop access, support, backups etc.  They also have promotions from time to time and I believe they currently have 50% off the first month.  Check them out:


Thought this would be useful to some and for me to reference on future projects.

SELECT @SEARCHSTRING = 'some string'
case when sysobjects.xtype = 'P' then 'Stored Proc'
when sysobjects.xtype = 'TF' then 'Function'
when sysobjects.xtype = 'TR' then 'Trigger'
end as [Object Type]
FROM sysobjects,syscomments
AND sysobjects.type in ('P','TF','TR')
AND sysobjects.category = 0

Most agile practitioners have heard about the importance of having your scrum teams in a shared, co-located space. The team collaboration and high-level of communication that co-location provides is a large success factor for agile projects. But what if you live in the real world and your team is geographically distributed. Although it certainly poses unique challenges, you can still provide your team with a collaborative experience by implementing some simple practices.

The Tele-Window

If you have the bandwidth for it, I highly recommend setting up a high quality webcam conferencing solution to provide a window into each location’s department. This should provide ample face-time with your team members and provide a great venue for impromptu meetings. You can glance over at the “window” and see if team members are chatting. You can chime in or they can call out to you when they see you back at your desk. This window also comes in handy for the next tip, the roll-away scrum board.

Roll-away Scrum Boards

Depending on how many scrum teams you have, you can roll scrum boards within the viewport of your tele-window just before the daily standup for that project. At the end of the daily standup, you can take a screenshot of the scrum board and post it on a team wiki or other web-based tool.

Virtual Pair-Programming

As a big advocate of XP practices, I cannot overstate how important it is to have at least some pair-programming sessions with other team members.  Although difficult, it is possible to have a decent pair-programming session with geographically distributed team members.  If you’re on a Mac, you can use iChat to share the screen with your partner.  Make sure you’ve got some voice communication so you can decide who is driving and when.  Two people moving the mouse in all different directions simultaneouly is rather annoying.  On Windows, you can use the Windows Remote Assistance, Microsoft SharedView or download a third-party tool.

The most important factor to ensure success of your agile development projects in communication with your team members. When your team is geographically distributed you’ll find challenges in your execution. Make sure to be innovative and use the technology available to you in order to foster high levels of collaboration.

In a previous post, we looked at how to consume a live streaming API from Twitter.  That was great and all, but you’re not going to become the next Twitter by consuming content — you need to have your own live streaming API.  In this post we’ll look at how to create a basic streaming API that others can open a streaming connection to and get real-time updates.

So, what groundbreaking web service will we be exposing to the masses?  We’ll be streaming the web server’s current datetime!  Ingenious, I know!  Hopefully, you’ll be able to adapt this to a slightly more engaging experience.

To start, let’s just take an ASP.NET MVC project and code the default controller action.  We clear all the headers of the response and add the “application/json” header.  Since we won’t be returning a view in the traditional sense of ASP.NET MVC, we don’t have to create an actual view.  We’ll just pause the thread for 1 second and then return the current timestamp for as long as the service is running.

On the consumer side, we’ll just refactor the code we had in the previous post to connect to the URL of the project we just created.  I’m running in on the local development machine so your port will likely be different.

You’ll notice we added some exception handling logic in case we lose our connection to our streaming API.  In this case, we’ll just keep trying to re-connect to the stream.  I’ll show you a sample of this in the last part of the post.

Once we have all the bits in place, we run the ASP.NET MVC application first so it is ready to start handling requests.  Then, we create multiple instances of our consumer console application to simulate multiple clients connecting to the streaming API.  You’ll end up seeing something like this:

To simulate what would happen on the consumer side if there was a broken connection or other exception on the server side, I killed the local development server for a few seconds and then restarted it.  Below you can see that we recovered after a few exception handling loops.

Of course, this post was just intended to provide a possible option for implementing a streaming API with ASP.NET MVC.  For a more realistic scenario you would likely have a queue listener around our Thread.Sleep() code.  As messages are picked up from the queue, you could stream it out and immediately start listening for the next message on the queue.

In a follow-up post, I will demo this same concept using Node.js.

Hope this helps.