stevenkuhn.net

myLeagueTracker - Requirements and Initial Domain Design

Steven — Tue, 27 Jul 2010 15:30:00 GMT

This is an ongoing series on the development of myLeagueTracker: an ASP.NET MVC web application that helps manage online FPS gaming leagues. You can read my first post on this project to get more background information.

The first step to building an application that will manage online gaming leagues is was to come up with a list of basic requirements that it should perform. I thought of a few requirements that would get development started, but certainly not an exhaustive list:

Manage games and leagues for a particular game.
Manage seasons for a league, teams for a season, and players on each team.
Create matches between teams and coordinate schedules, maps, and results for each match
Track wins, loses, ties for each team for any given season
Ability to view past season’s teams, scores, and players

While there are more things I want to add, I want to start small and iteratively add functionality over time. Using those requirements, I came up with the following domain designs:

As you can see, each one of those classes derives from a abstract base class called Entity<int>. Using concepts I learned after reading a couple books about Domain-driven design, each class in the model above is not defined solely by its attributes (definition of a Value Object) but instead by its identity (the basic definition of Entity). The code sample below shows that the entity base class and underlying interface contain an Id property which is used to compare equality between two objects of the same entity type.

public interface IEntity { }

public interface IEntity<T> : IEntity
{
	T Id { get; }
}

public abstract class Entity<T> : ObjectBase, IEntity<T>
{
	public T Id { get; private set; }
}

You may wonder what is the purpose of ObjectBase. For now it has no implementation, but my next post will cover the details on making it provide the primary facilitation for comparing equality of both entities and value objects. Additional posts will also discuss the concepts of persistence with nHibernate, domain model validation with Data Annotations, unit testing, and the implementation of the UI layer involving ASP.NET MVC 2 and jQuery.

Feel free to leave questions and comments! :)

myLeagueTracker - My Personal ASP.NET MVC Development Series

Steven — Sun, 22 Nov 2009 16:00:00 GMT

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!

Migrated from Drupal to GitHub Pages

Steven — Thu, 27 Aug 2009 15:00:00 GMT

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!