Ian Suttle's Blog

Transactions in Integration Tests

Ian Suttle — Thu, 20 Aug 2009 22:36:00 -0800

I was working with some integration tests recently and had an epiphany: Why don't I use transactions in a test to reset data? I'm referring to a case where an integration test does something like write a new row to a database table. If I'm running these tests over and over those rows add up unnecessarily. Wrapping the integration test with something like TransactionScope in .NET makes resetting this data real easy.

Take this hypothetical test in to consideration:

[Test]
public void AddDatabaseRow()
{
DataContext data = new DataContext();

SomeItem item = data.SaveItem(1, "abcd");

Assert.IsNotNull(item, "Return data was null");
Assert.AreEqual(1, item.UserID, "UserID did not match");
}

If I ran this test over and over again I'd have a duplicate table record added over and over again. Sometimes that's not even possible when unique constraints are enforced such as having to have a unique email address. The argument can be made that DataContext should be a mock object and not a live connection I suppose. For argument's sake let's say there's a valid reason for doing an integration test this way:).

Now let's look at a test using a transaction to reset the data when we're done.

[Test]
public void AddDatabaseRow()
{
DataContext data = new DataContext();

using (TransactionScope trans = new TransactionScope())
{

SomeItem item = data.SaveItem(1, "abcd");

Assert.IsNotNull(item, "Return data was null");
Assert.AreEqual(1, item.UserID, "UserID did not match");

}
}

Using TransactionScope here performs a rollback after the assertions have been made and avoids permanently saving the database record to the table.

What do you think about this? Is there a better way to go about achieving the same goal of not committing records often?

Work and Life Balance

Ian Suttle — Sat, 16 May 2009 13:06:49 -0800

CNN.com has an article today called Welcome to the 'weisure' lifestyle. It's about the balance between work and life (leisure in the article)... or the lack thereof more precisely. It's not that people are becoming increasingly chained to their desk at the office but more of their desk is becoming chained to them in life - where ever one goes. It's the Blackberry, iPhone, and other forms of mobile communication that make this possible.

Is this bad? The old dogs might say this is a travesty but personally, I'm digging it. I'm in this category of working while playing. Why? Because it's so darn easy! If I can answer a few emails over the weekend from my phone I have that much less to do during the dreaded Monday morning and the ball keeps rolling instead of coming to a dead halt. Of course, I've an advantage because I love what I do. If you're not passionate about your job then this probably isn't for you. Then again if it's passion you lack go find a new job right now.

Save a Buck and Learn Something New

Ian Suttle — Sun, 03 May 2009 20:00:00 -0800

This is an exciting moment for me. I've been doing software dev for over a decade and I've never ventured in to the electronics aspects of assembly. Sure I've put my own computers together but that became old hat in the late 90s. Today I broke out of my comfort zone and I replaced a capacitor on the main board of my Panasonic DVP642 DVD player. Slim chance but if you have the Panasonic DVP642 with a blinking red light check out this article for how to repair it.

W00t!

I know, lame for most but it's new territory for me. I figured I could either purchase a new DVD player or I could fix mine myself therefore saving a few bucks and more importantly learning something new.

It was easier than I expected although I did make one rookie mistake when I opened the capacitor plastic bag and threw it out of my view... right on to the soldering iron where it instantly melted and smoked up my kitchen counter space.

If you've not repaired an electronics device on your own before give it a shot. It was educational and rewarding.

P.S. If you try this at home and notice your colors no longer work right, ensure you plugged in your cables all the way when reconnecting to your TV :).

ASP.NET MVC Action Filter for Localized Sites

Ian Suttle — Sat, 21 Feb 2009 01:46:00 -0800

Disclaimer: This is my first attempt at creating an ASP.NET MVC Action Filter and was developed using the ASP.NET MVC Release Candidate Refresh 1 release. I doubt things change much on this topic before RTM.

Your mission: to make your site available to multiple cultures and languages by way of ASP.NET MVC localization, globalization, internationalization, or whatever term you prefer to use.

You’re familiar with cultures right? It's the combination of language and country, usually identified in software using ISO culture codes. The ISO culture code for English in the United States is "en-US", "en-CA" for English in Canada, "fr-CA" for French in Canada, and so on.

If you've got or want a site which supports multiple cultures using ASP.NET MVC localization you need to be familiar with setting CultureInfo values for the current thread and UI. The .NET Framework uses this info to do a few key things. First, if you're using resource files the framework knows which to pick up because the resource file name specifies the culture. Secondly the culture is used as a formatter argument for various methods such as ToString(). The culture needs to be set for each page request as it's based on the current thread. For more info on this end of things check out Localization in ASP.NET 2.0 - I found it quite helpful.

Once you know which culture the user's experience should use you'll want to persist that somehow. Maybe it's in a cookie, the session, embedded in the URL, etc. In ASP.NET web forms you might include this detection in a base page or the global.asax for each page load.

ASP.NET MVC provides another nifty trick for handling things on each action call - Action Filters. I thought it'd be interesting to figure out some ways of doing internationalization in ASP.NET MVC so I came up with an ASP.NET MVC action filter to include on a controller class for setting the culture for each action call. Currently it supports keeping the culture in a cookie, the querystring, session state, and the URL path.

Using the filter is simple. Assuming the SetCultureAttribute class is included in your project you decorate a controller class with it. You must set the CultureStore (type of CultureLocation) to indicate where the culture code comes from, and then one or two other properties to provide more hints at getting to the culture code. Here's an example for storing the culture code in the query string. In this example the URL would be expected to include a param called "culture" such as in this URL: "http://localhost/?culture=en-GB".

[HandleError]
[SetCulture(CultureStore = SetCultureAttribute.CultureLocation.QueryString, QueryStringParamName = "culture")]
public class HomeController : Controller
{ ... actions ... }

If stored in session you'd modify the SetCulture properties to something similar to:

[SetCulture(CultureStore = SetCultureAttribute.CultureLocation.Session, SessionParamName = "culture")]

If stored in a cookie you'd modify the SetCulture properties to something similar to:

[SetCulture(CultureStore = SetCultureAttribute.CultureLocation.Cookie, CookieName = "culture")]

If stored in the URL path your actions will need to expect language and country parameters and your route needs to account for the same. For my implementation I modified my default route and assumed the "en-US" culture if nothing else was specified. This code expects a URL formatted like "http://localhost/en/us/home/about". There will be some kinks to work out with this one:

routes.MapRoute(
    "Default",                                              // Route name
    "{language}/{country}/{controller}/{action}/{id}",                           // URL with parameters
    new { controller = "Home", action = "Index", id = "", language = "en", country = "US" } // Parameter defaults
);

Using this updated route you'd modify the SetCulture properties to:

[SetCulture(CultureStore = SetCultureAttribute.CultureLocation.URL, CountryActionParamName = "country", LanguageActionParamName = "language")]

... etc.

Assuming the culture code is found then the thread and UI culture will be automatically set in this fashion:

CultureInfo culture = new CultureInfo (cultureCode);
System.Threading.Thread.CurrentThread.CurrentCulture = culture;
System.Threading.Thread.CurrentThread.CurrentUICulture = culture;

Click here to get the full SetCultureAttribute class. Don't forget to change the namespace to match your own.

Have you any experience with localized sites in ASP.NET MVC? How did you approach this topic?

Git er Done or Do it Right

Ian Suttle — Mon, 09 Feb 2009 00:53:00 -0800

Programmers are paid to create, fix, and innovate. How you go about these tasks comes in two flavors - the quick and dirty method or doing it right. The typical reaction of a programmer is to strike down the quick and dirty route with eyeball laser beams because they want to have the time to do it right. Who can blame them? Nobody wants to write code they're not going to be proud of.

But what about those times when quick and dirty is appropriate? Sure, there are those times such as in prototyping or throwing an idea out there to see if it sticks. Prototyping's the obvious candidate for speedy delivery. You're just proving your theory and, in some universe I've yet to travel to, you'll have time to write it "the right way" if the software is going to stick around or evolve. Now the other reason, the "throwing an idea out there" reason, is different than prototyping. In this case I'm talking about something you plan on releasing to the public. This is sort of a super prototype with polish. It has to look right, and act right, but ya don't have to build it right. Why not? Because the purpose is to just see if it works with real people. Do people use it... is it making money... etc. If all signs point to yes then take the time and do it right.

"Doing it right" provides for lasting benefit. Build a stable foundation for the house that's going to be lived in. I'm not saying to ignore the KISS or YAGNI principles and build everything up front, but I am saying if you're not doing it for the near-term-test, then do whatever it is you REALLY need to do, and do it right. Say it with me... do - it - right. Your yard stick for what "do it right" means is up to you of course. You'll know.

Choosing your method of development is a factor (maybe a major one) in the key to success for your product, business, and team, so think before you act.

How's this work in your organization or with previous employers? Is this something you get to decide? If you're prototyping are you getting to rebuild the software when the time is right?

The Dilemma With Multiple Versions of Source Code

Ian Suttle — Tue, 06 Jan 2009 15:51:00 -0800

We’ve been trying to tackle the topic of how to support multiple versions of software safely. The emphasis has been on ensuring the changes you make to software are the only changes reflected in a build. This is different than your changes being included with other changes done you’re not aware of. Shared libraries are the most obvious examples I can think of. Getting in to that situation introduces loads of risk we have no interest in taking on. Alas, that is the situation we’re in today.

Scenario: Library changes and we need to update an older version

In this scenario consider we have a shared library with a bunch of classes in it. That shared library is included in a web app we released. We label the solution as “My App 1.0.0”. Over time the shared library is modified to the point the it loses backwards compatibility for one reason or another. The modified solution is known as “My App 2.0.0”. Suddenly we come across a bug with the “My App 1.0.0” version which requires emergency resolution in the shared library.

We can’t get latest on that library to apply our fix because latest is now “My App 2.0.0”. If we get from the label “My App 1.0.0” we could make our fix and mark it as “My App 1.0.1”. The problem then is checking that code back in would become “latest” where in reality “My App 2.0.0” should continue to be the latest. Of course, we’d want to apply our fix to “My App 2.0.0” if it still applies.

A proposed solution:

1. Get “My App 1.0.0”
2. Apply fix
3. Check in the code and label solution as “My App 1.0.1”
4. Get “My App 2.0.0”
5. Apply fix
6. Check in the code and label solution as “My App 2.0.0”

Another proposed solution:

1. On release, branch "My App 1.0.0" to a Release area of your repository. The branch would include all libraries necessary to support the application.
2. Continue developing "My App 2.0.0" in the trunk
3. To fix something in "My App 1.0.0" update the branch created earlier and apply a label such as "My App 1.0.1"
4. Merge changes from "My App 1.0.1" in to the trunk where "My App 2.0.0" is being developed

Both options provide a fix to “My App 1.0.0” to be tested and released, applies the fix to “My App 2.0.0”, and leaves “My App 2.0.0” as “latest”. If in the future another fix were needed for “My App 1.0.1”, we’d repeat this process.

How would you normally go about this? Are we making it too complicated or does this sound reasonable? Does the fact that we're using Team Foundation Server for our respository offer any advantages or disadvantages?

IGN Entertainment is Hiring Software Engineers

Ian Suttle — Sat, 29 Nov 2008 15:15:00 -0800

Here at IGN Entertainment we're almost always looking for smart and curious software engineers to join our teams. Whether you're a .NET (C#), Java, or C++ programmer we'd like to hear from you. We prefer a bit of experience and a degree, but if you're one of those natural whiz kids continue reading.

Why might you want to work at IGN? I'm biased of course, but we're absolutely awesome ;). We work on a variety of applications including ecommerce, media, file distribution... we cater to heavy spikes of demand (our page loads are measured in millions to hundreds of millions per month)... we're not afraid of new technology... the gaming industry is always changing... flexible schedules, casual dress, competitive pay, good benefits, blah blah blah.

If you're not repulsed by such awesomeness feel free to contact me!

Betting on Story Points

Ian Suttle — Sat, 15 Nov 2008 00:49:32 -0800

Welcome to part four in our ongoing quest to bring an effective agile development process to IGN Entertainment.

Something we're looking at adding to our agile tool belt is estimating stories using story points. If you're not familiar with story points think of them as an estimation using a relative level of effort/complexity.

When getting started with story points they don't provide you much benefit beyond understanding how one story's effort compares to another i.e. "this story is a 1 and that story is a 13". More on that later. The real value comes as you make your way through numbers of sprints and releases. As you progress you can look back and see how many story points a team can accomplish during a sprint. Naturally, if the team's composition isn't constant the velocity begins to become less accurate. The measurement of story points completed over a given amount of time is referred to as velocity.

Velocity = (Story Points Completed / Iterations)

Example: 50 Story Points Completed / 5 Iterations = a velocity of 10 story points

Velocity is handy as a means of understanding the general capacity of a team. If a team, on average, can accomplish twenty story points per sprint, then you've established a story points budget, and you'd plan for about twenty story points for the next sprint. That might be ten stories or that might be just one story depending on the points associated with the stories. Taking it a bit further, using velocity allows you to estimate a release timeline using some simple math. Consider the following formula to estimate the number of iterations/sprints before a release:

Estimated Iterations = (Story Points / Velocity)

Example: (100 Story Points Remaining / 20 Story Points Velocity) = estimate of 5 iterations

In this example, if an iteration was 2 weeks you'd have a good estimate of being 10 weeks out from release.

There's not a hard-fast rule for how to estimate with story points but we're taking a liking to Planning Poker. The attraction is the estimates are done by the team and not by individuals. Making a game out of it doesn't hurt either :). If people greatly differ in their point estimates the team discusses why and re-estimates until the members of the team are close enough to just take the conservative end of the estimations.

My favorite form of story points uses numbers from what basically equates to a Fibonacci sequence (with some reasonable modifications for ease of use):

The idea is the higher the estimate the more risk/unknown/general the story is. It would seem optimal to have story estimates as far left as possible as they require less effort, are more well defined, and as the major bonus, should allow for a more accurate estimate.

The application of stories points feels very promising to us. Like everything else we add to our process it's not going to be a silver bullet but does fit in with us always looking to incrementally improve.

Have you used story points for estimating? Has your experience been positive or challenging?

Hulu.com is that Cool

Ian Suttle — Sun, 05 Oct 2008 00:44:42 -0800

I've heard of Hulu, but until now I hadn't checked it out. This TV season started a few weeks ago and I've already had DVR mishaps with the Terminator: The Sarah Connor Chronicles and Heroes series and I needed a way to get caught up. Hulu allowed me to search for the episodes I've missed, queue them up, and play them in full screen... my hero.

Google Chart API - Flexible and Free Charting

Ian Suttle — Sun, 28 Sep 2008 15:36:34 -0800

Including charts in your applications often adds value and polish. If you don't have a charting package in your tool belt choosing one can be both confusing and expensive.

If you're in this boat check out Google Charts, which offers free charting with lots of options. And by "free", I mean free... but Google does ask you let them know if you'll be cranking out more than 250,000 charts a day. For you Web 2.0 and cloud junkies this option fits the bill perfectly.

The API is just a combination of URL querystring parameters. Here's a basic example:

This URL: http://chart.apis.google.com/chart?chs=300x100&chd=t:40,40,10,10&cht=p3&chl=Java|.NET|PHP|Ruby+on+Rails

Generates this chart:

Here we add blue as the base color by adding '&chco=0000ff':

http://chart.apis.google.com/chart?chs=300x100&chd=t:40,40,10,10&cht=p3&chl=Java|.NET|PHP|Ruby+on+Rails&chco=0000ff

You can vary the individual colors, chart types, dimensions, etc. Flexible, fast, and free.

Evangelizing Scrum

Ian Suttle — Sat, 09 Aug 2008 20:28:32 -0800

Welcome to part three in our ongoing quest to bring an effective agile development process to IGN Entertainment.

Early on I recognized one piece of criteria critical to us succeeding in bringing Scrum to IGN - everyone had to buy in. This is a change for us and as has been drilled into our noggins for years, most people don't like change. The idea isn't to change for the sake of change of course, but to continually improve our team, processes, communication, and company. I'm sure most people can buy in to that one so we had to show how the change being proposed would accomplish these goals. We're still in adoption phase (it's been about three weeks) but feel it's going really well. Here's how we got to today:

Early Warning

We notified the product and engineering (us) groups we were looking to make some changes to improve how our groups worked together. We committed to introducing the process and let them know we were going to need their help. It wasn't the intent but this got their mouths drooling a bit for new ways to improve. I received numerous emails asking when we were going to "discuss the new process." Slow down people we're workin' on it!

Introduction to Scrum

We held Scrum introduction meetings with multiple product groups to discuss Scrum including key terms, roles, and the flow. We also thought it'd be good to run through a mock sprint but in hindsight that was a bit redundant with the rest of the introduction. We also created a Scrum cheat sheet to hand out so people could leave with some reference material. Lastly we opened the floor for questions. We certainly didn't have all of the answers but expressed our commitment to work through them together.

Working Together

Scrum has distinct roles and criteria to fulfill each piece of its process. The product owner must populate a product backlog and prioritize their items. A sprint planning meeting is held to review the product backlog and assign sprint backlog items with estimates. A daily scrum is held to ask the famous three questions of "what did you do yesterday," "what will you do today," and "is anything blocking you". It goes on and can seem like a lot to rookies like us.

The fact is in the beginning nobody knows how to actually execute on these things so we dove in head first. We were committed to giving this a real go and working together to answer questions and solve problems. We helped create the product backlog, provided access to tools for reviewing and prioritizing, ran the sprint planning meetings, and took the role of getting the answers to whatever needed to be answered. Learning, team building, and communicating at their best.

Delivering the Goods

A new process with magical results and innovative ways of getting things done doesn't mean squat if you don't deliver on your commitments. At the end of our first sprint we did what we promised in a variety of ways. The product group knew exactly what to expect from us, communication was improved through sprint planning and daily scrum meetings, and the work got done. In fact the work got done earlier than expected and we started taking more items before the sprint was over! I guess our estimates were too conservative but better that than too aggressive.

Delivering on your commitments builds trust in both the process and the people.

Marching Ahead

Formally holding a sprint retrospective meeting is another piece of the Scrum process. We did this after our first sprint which revealed a number of things, the most important being to account for everything you have to do using sprint backlog items: coding, code reviews, documentation, deployments, unit testing, meetings, testing, documentation, etc. If it needs to be done, add it!

I'm looking forward to continuing our rollout of Scrum and other agile-esque methods. Each day we invest reveals more clarity and benefits of the processes which is great because day one it didn't all make complete sense :).

Have you worked with Scrum and came across pros or cons you hadn't even considered?

Firefox 3.0 released... and demand is killing Mozilla!

Ian Suttle — Tue, 17 Jun 2008 10:42:00 -0800

Go ahead and try to go to www.GetFirefox.com. I dare you. Insane things will happen like the server won't respond because it's being overloaded. Okay, maybe that's not crazy or insane given the popularity of Firefox, new releases, and open source community backing.

Fileplanet.com has the file available here: http://www.fileplanet.com/187938/180000/fileinfo/Mozilla-FireFox-3.0

My Agile Development Posse

ian suttle — Sat, 14 Jun 2008 23:21:06 -0800

Here Ye! Here Ye!

Welcome to post number two in our ongoing journey to bring an effective agile development process to IGN Entertainment.

There are a few staple tools and practices I feel are essential to an effective agile development process. Some may argue the direct correlation of these to agile development is incorrect... it's perspective.

Source Control

Love it or hate it source control is a biggie. There are a variety of source control systems available to meet the needs of most organizations. A few popular choices include Subversion, Visual SourceSafe, CVS, Team Foundation Server, and Perforce.

I recommend figuring out your source control feature requirements before choosing your flavor. Try a few before committing. Not all of them do branching, merging, changesets, etc, in the same fashion, and once you implement one it's likely not convenient to migrate to another.

Define your source control structure and processes for the team. Should code be organized by library type such as web apps, windows service, class libraries... or should it be organized by subject such as Direct2Drive, Fileplanet, etc? When should you branch vs. label? How do you version your software? If you forgo being organized up front you will pay the price later. For those of you who choose the hard way, it provides you the unique opportunity to write about lessons you've learned later on ;).

Unit Testing

I've been a part of the development community for about ten years now and if there's anything I've picked up on over the past couple of years unit testing is a contender for the most valuable. For those of you who are rookies on the topic or still haven't quite figured out what the hype's about, listen up. Unit testing provides you a certain level of confidence in your code both when you write the code and when you change your code.

Consider a monitor watching a website. Some monitors will watch the site and ensure expected behavior occurs given specific criteria. In this way a unit test is a lot like that monitor. You set up a very specific well-controlled scenario for a unit of your code (see method) and fail the check if the result isn't as expected. Each time you change your code you can rerun your ever-growing library of unit tests and be assured your tests continue to succeed. If a test is busted ya screwed something up. Oh, and as an added benefit, your class design changes to be more modular. That's just a little something extra.

Unit tests frameworks come in a variety of shiny colors. For .NET development NUnit is probably the most used. You can also check out XUnit and MbUnit. Lastly, Microsoft has developed their own framework which they've integrated in to VS2008. Feel free to argue your points but I'm not a fan of the MS Unit Test framework... there's too much auto-generated code for me. The point of unit testing is to know and control your environment. Code generation tastes bad.

TestDriven.Net is a cool add-on to Visual Studio so you can run your NUnit tests (I've not tried with another framework) and get your results in the Output window. It also comes bundled with NCover for code coverage analysis. Really useful.

Drink the kool-aid... it's yummy.

Continuous Integration

Continuous Integration in its most basic form is having your code built often on a scheduled or triggered basis. This is cool because you can know earlier than later if someone's changes are breaking the build (don't be that guy!). The alternative is having a broken build and when you have more than one person working on the code all participants are effected once they have the latest version. That's a waste of time for everyone and is frustrating to say the least. Continuous Integration doesn't prevent this problem but instead is an early warning system. Now add on automated deployments to an environment such as user acceptance testing and there's constantly a fresh view of the application without an engineering making it happen. That's cool.

My team is not using a Continuous Integration solution yet so more to come on this, but if interested, we're checking out Team Foundation Build and JetBrain's TeamCity.

How's This Related to Agile Development?

Admittedly you can run an agile development shop without any of these tools. These things I've discussed are just that... tools, not process. So how are these tools related to agile development? Everything I've discussed works really well with the iterative, always changing nature of agile practices. I'd hate to take on this process unprepared. Give me my armor, sword, and a horse before sending me off in to battle.

Voyage Into an Agile World

Ian Suttle — Fri, 13 Jun 2008 22:49:00 -0800

Here at IGN Entertainment we're making an effort to follow an agile software development path. It's a bit of a new world for us. I'll admit we've described our development process to date as "agile/waterfall" or "quasi agile", neither of which are ultimately efficient. We've been digging into agile techniques for a couple of years and simply hadn't made the commitment. The longer we wait the more clear it is we need to make the move.

Our agile flavor of choice is the all-popular Scrum technique. I'm digging the predictability of feature delivery by defining the sprint backlog up front, having a known schedule for a sprint, open communication and transparency through sprint planning meetings and daily scrums, etc.

I'll continue to post info on our experience as we progress.

Finally, a SelectedItems Option (yaaay)

ian suttle — Wed, 14 May 2008 09:46:18 -0800

If you're like me you've often pondered why controls like CheckBoxList don't provide a way to get a collection of selected items. You've always had the option to iterate the Items collection and evaluate the Selected property, but why should that have to be done over and over again? I want a quick way to get the selected items from a CheckBoxList, ListBox, DropDownList, and RadioButtonList; all items which inherit from ListControl.

The excellent creation of extension methods makes it simple to get the selected items from a ListControl.

using System.Collections.Generic;
using System.Web.UI.WebControls;
 
namespace ListControlExtensions
{
    public static class ListExtensions
    {
        public static List<ListItem> SelectedItems(this ListControl list)
        {
            List<ListItem> items = new List<ListItem>();
            foreach (ListItem item in list.Items)
            {
                if (item.Selected)
                {
                    items.Add(item);
                }
            }
            return items;
        }
    }
}

Have you found an alternative to getting the selected items from a ListControl without looping through the Items collection?