This will be an ongoing series on the development of myLeagueTracker: an ASP.NET MVC web application that helps manage online First-person shooter (FPS) gaming leagues. As this is my first ASP.NET MVC application, this is a learning opportunity for me, and I hope that you find it helpful.
Introduction
I am an avid computer gamer. Years ago a friend introduced me to Doom and I was hooked. Later it was Quake, Unreal Tournament, Team Fortress Classic, and Counter-Strike. Normally I would play online with a few friends in public servers. It wasn’t until Valve released Team Fortress 2 two years ago that I joined an online community and started playing in a semi-competitive league. Each week, teams of 6 or 7 players would be matched up to do battle with one another. It’s a fun experience involving wits and constantly changing strategies.
The league uses spreadsheets to track and manage players, matches, maps played, and schedules. Of course, there had to be a better solution than a manual process like this. After searching for and finding no available open-source league management tool, I decided to write my own. I wanted to learn more about ASP.NET MVC, TDD (Test-driven development), and DDD (Domain-driven Design) anyway, so I thought this would be the perfect opportunity to learn something as well as provide something valuable to other gamers and developers alike.
About myLeagueTracker
This morning I posted my first post on a new blog for myLeagueTracker, a web application that will help FPS gaming communities manage their leagues. The introduction from that post says it well:
myLeagueTracker is an open-source ASP.NET MVC application currently in development which aims to provide tracking and management of the numerous facets in online First-person shooter gaming leagues. With the ability to handle multiple leagues across any FPS game, myLeagueTracker will help bring versatile league management to gamers who want to concentrate on gaming and not trying to design their own system. Since I am a gamer myself, I hope to provide a system for gamers that is both flexible and easy to use.
Development Series
Development on myLeagueTracker is currently underway and I will continually work on it when I have the opportunity outside of my normal employment obligations. With that in mind, this is the first post in a continuing series about the programming aspects I am dealing with on this project. All the source code I write is licensed under the Apache License, Version 2.0 and is currently available at myLeagueTracker’s GitHub project site. I want these posts and this project to be resource to you as well as a learning experience for me. I will also be posting entries on the blog for myLeagueTracker which will contain general development progress and support posts geared more towards gamers that wish to use this tool. As always, feel free to send me feedback on either site as I am open to suggestions, comments, and questions. Thanks and enjoy!
Last night I officially moved stevenkuhn.net from my Linode-hosted Drupal site over to GitHub Pages. Drupal is cool to set up and for more complicated sites it makes tasks easier to accomplish. However, for my simple technical blog, I found that certain simple things (such as attaching images to posts) were unnecessarily complicated. Yes, other systems are more geared for blogging (like WordPress), but after seeing GitHub Pages, I wanted to try a new approach.
Unlike Drupal, WordPress, or other dynamically driven CMS/blogging engines out there, GitHub Pages serves only static html pages. There is no database. There is no server-side environment running like PHP or ASP.NET. While on the surface it may seem pretty insane not to use a dynamic site since static pages are exactly that, but that’s where the beauty of Jekyll comes in. What is Jekyll? A brief overview from Jekyll’s readme file:
Jekyll is a simple, blog aware, static site generator. It takes a template directory (representing the raw form of a website), runs it through Textile or Markdown and Liquid converters, and spits out a complete, static website suitable for serving with Apache or your favorite web server. This is also the engine behind GitHub Pages, which you can use to host your project’s page or blog right here from GitHub.
I’m not going to dive into the details of Jekyll because there are numerous sites that explain it already. However, a few advantages I like about Jekyll are:
- No caching system is needed since there is no database.
- No longer tied to a WYSIWYG textbox. I’m free to write my posts in any text editor of my choosing.
- Offline support. Running Jekyll locally will run a local webserver which can be used to view changes without being connected to the internet.
- Complete control over the html. I like to be able to change the html easily without messing around with php templates (as I did with Drupal).
- Static pages can look and act dynamically with the various javascript libraries and APIs available.
So far I’m impressed with how the site has turned out. My next plans are to add my twitter feed, an archive section, and paging support for the front page. The source of my blog is available on GitHub; feel free to take a look!
A while back I read a blog post by Dan Rigsby about why you should not use C# using statements on a WCF service proxy class even though it implements IDisposable. Basically it comes down to the Dispose() method calls Close() which can throw an exception preventing the service proxy from being disposed properly. The solution by Dan Rigsby involving a wrapper class and another solution by Erwyn van der Meer (which provides a helper class that you can derive from) both allow you to use the using statement and still properly dispose of the proxy.
I wrote an extension method below will dispose a service proxy properly, but it doesn’t require you to change that proxy in any way. By providing an extension method around ICommunicationObject, any WCF class that dervives from it (ClientBase, ServiceHostBase, etc.) will have this method available as well.
public static class ICommunicationObjectExtensions
{
public static void TryCloseOrAbort(this ICommunicationObject obj)
{
if (obj != null)
{
if (obj.State != CommunicationState.Faulted &&
obj.State != CommunicationState.Closed)
{
try { obj.Close(); }
catch (CommunicationObjectFaultedException)
{ obj.Abort(); }
catch (TimeoutException)
{ obj.Abort(); }
catch (Exception)
{
obj.Abort();
throw;
}
}
else
obj.Abort();
}
}
}
With that method in place, all you you have to do is call TryCloseOrAbort() in a try-finally block to make sure it is called even if an exception is thrown.
// Example usage:
// assume MyServiceClient is a WCF service proxy class
var client = new MyServiceClient();
try { client.MyServiceMethod(); }
finally { client.TryCloseOrAbort(); }
