Michael C. Kennedy's Weblog

Webcast: Building Modern Apps in ASP.NET WebForms

Michael Kennedy — Fri, 06 Nov 2009 04:20:00 GMT

At DevelopMentor we have been running a bunch of free webcasts. Last month it was TDD and Agile. This month we are running 4 webcasts celebrating the announcements around .NET 4.0, Visual Studio 2010, and PDC 2009.

Join me Monday, November 23rd and register here:

http://bit.ly/aspwebforms

We’ll talk about integrating ASP.NET’s routing infrastructure into existing an ASP.NET WebForms application. This allows you to build SEO websites with URLs like

http://dotnet.ubbuzz.com/tag/.NET+4.0

while still taking advantage of all the productivity features of WebForms such as post-backs, controls, UpdatePanel, and so on.

We have room for a couple hundred more attendees so please register and be part of the fun. I promise lots of demos and somedisdainful comments about PowerPoint!

Share it with your friends (social, virtual, real, and other types) using the widgets below!

ASP.NET MVC: What’s that, you’d rather hear about ASP.NET MVC, not this creaky old WebForms stuff? That’s Brock Allen’s talk: http://bit.ly/intromvc

WF 4: Is WF 4 and visual programming your thing? Check out Maurice de Beijer’s WF 4 talk: http://bit.ly/meetwf4

New Parallel Extensions your thing: Check out Andy Clymer’s PFX talk. (link to follow soon).

Cheers,
Michael

All content copyright Michael C. Kennedy. All information, source code, and especially tools are provided as is and on a "use at your own risk" basis.

TDD Space Invaders Video and Downloads

Michael Kennedy — Thu, 05 Nov 2009 07:17:00 GMT

Recently Llewellyn Falco and I did a webcast for DevelopMentor where we demonstrated some TDD techniques and introduced Approval Tests. We let the audience choose our project and they chose Space Invaders. It was all great fun. Now the videos and MP3 streams are online and available for download.

Be sure to check out the write-up we did afterward where we talked about the tools and gave you a chance to try it for yourself:

TDD Space Invaders Write-up

You can also watch two other, higher level agile webcasts by Bill Nazzaro here:

Agile Webcasts at DevelopMentor

Cheers!
Michael

All content copyright Michael C. Kennedy. All information, source code, and especially tools are provided as is and on a "use at your own risk" basis.

TDD Invades Space Invaders

Michael Kennedy — Wed, 28 Oct 2009 21:13:21 GMT

A joint post by Llewellyn Falco and Michael Kennedy

[Update: Get the videos and additional downloads for this webcast.]

As a follow-up to our "Avoiding 5 Common Pitfalls in Unit Testing" article we did a webcast where we took a problem from the audience and solved it live and unrehearsed on stage. These kinds of performances are always a risk but that's part of what makes them fun.

Of course, the question is could we have done it better? Here's your chance to try it for yourself (details below).

The Problem:

Our viewers chose to have us build the game Space Invaders. The first thing we had to do to sketch out a basic scenario we could implement. We started with a picture to remind what Space Invaders even was:

This was too big of a scenario for us to tackle in the allotted 40 minutes for programming. So then we started by creating a simpler scenario which we sketched out on the "whiteboard":

Click for full size image.

Flushing Out the Scenario:

In doing this, a couple of things were revealed about the game.

First, we wanted to make the tank and aliens all be the same size so we could put them on a grid. But then we saw that our bullet wouldn't fit that story, so we introduced the idea of relative sizes. We also realized that even though we drew the block, it was too complex for the first scenario and it would have to wait.

Notice that as we started writing the scenario in English, there are mistakes, irrelevancies, and problems with the order. This is OK. The thing to remember is that all of this was done for the sole purpose of creating a recipe for a scenario we could test. That scenario is the following:

[TestMethod]
public void TestSimpleKill()
{
   // 1. Create a 15x10 board.
   // 2. Place a 3x2 tank at 1x8.
   // 3. Place a 2x2 alien at 7x3 heading west.
   // 4. tank shoots
   // 5. advance 4 turns
   // 6. not won
   // 7. advance
   // 8. win
}

Now that we had the recipe, we could go about writing the code.

Here's your chance to play at home!

Set your timer to 40 minutes.
Create a new test project.
Paste that method above.
Translate the comments into code.

If you believe there's a better process, we invite you to try that as well.

We made it to step 4 during our presentation (download code below) and estimate another 15 minutes would have had the whole scenario done, tested, and well-factored.

Stories vs. Requirements (stories win):

We'd like to point out a couple of things about the story. First, it was quick to write the story. We did it in 5 minutes. Second, it translates well to code because it has behavior and objects working together. Let's compare that to the requirements that this story flushed-out.

Need a board
Boards should have width & height
Boards contain game objects
Game objects have a witdth, height
Game objects have the ability to move each turn
Aliens move either left or right each turn
Bullets move either up or down each turn
Bullets are 1x1
Tanks are 3x2
Aliens are 2x2
The game is not won until all the aliens are killed
The game is won if alll the aliens are killed
An Alien is killed if it is hit by a bullet
Tanks can fire
Firing with a tank creates a bullet going up from the space directly above the tank

Now we want to point out that this requirements doc is much hard to understand than our story. For example, if you were to add more requirements (e.g. an alien also shoots) is that easy to determine whether we have complete requirements? It also takes much more effort to create and especially to tell if it is complete. People aren't made to handle requirement documents well but we are story-telling machines. We embrace this in our coding techniques.

We'd also like to mention some of the tools discussed at the end.

For remote collaboration we use:

Skype (audio / video)
VNC for screen keyboard sharing
RDP (windows remote desktop) -- requires Windows 2003/2008 server for pairing.

Source Control:
TortoiseSVN
TortoiseGit

Developer Tools:
Resharper
CodeRush

Testing Tools:
MsTest (in Visual Studio Professional and up)
NUnit
NCover
TortioseDiff
Approvals Tests
Approvals Tests CodeRush add-in
Rhino Mock
TypeMock

If you try this scenario yourself, please leave a comment about your experience.

Download the code and slides from the webcast here:

Code: TddWithLlewellynAndMichael.zip
Slides dmtdd.pdf

Cheers -- Michael and Llewellyn

All content copyright Michael C. Kennedy. All information, source code, and especially tools are provided as is and on a "use at your own risk" basis.

Attend My Live, Free TDD Webinar with Llewellyn Falco and Myself at 10am Tomorrow!

Michael Kennedy — Mon, 26 Oct 2009 23:29:46 GMT

[Update: See the follow-up post here: TDD Invades Space Invaders]

Tuesday, October 27, 2009 at 10am Pacific time Llewellyn Falco and I will be giving a live, unscripted, and no safety-net demonstration of Test Driven Development (TDD) as part of the DevelopMentor webinar series (this particular series is a 3-part series on Agile development).

We already have a bunch of attendees registered. But we have room for as many of you who are interested in agile and TDD. Sign up here:

http://bit.ly/dm-tdd-m-and-l

In addition to core TDD techniques, you will see how an amazing technique and set of tools designed by Llewellyn called Approval Tests makes writing tests as simple as verifying an image or text file. Tired of writing 50 lines of test code for every 50 lines of production code but you still want the power of TDD? You need to learn more about Approvals and we'll demo that live tomorrow!

I hope to see you all online. Feel free to help me get the word out by tweeting this or shouting it (see icons below).

Cheers, Michael.

All content copyright Michael C. Kennedy. All information, source code, and especially tools are provided as is and on a "use at your own risk" basis.

Boot to VHD Screencast

Michael Kennedy — Tue, 20 Oct 2009 04:50:49 GMT

WARNING: This is some advanced stuff. It's not that hard, but you can break things that are hard to fix. So, there is no warranty express or implied. Windows 7 or Windows 2008 Server R2 are required.

Have you heard of the new feature in Windows 7 and Server 2008 R2 called Boot to VHD? It is amazing! But it's one of those concepts that people hear about and think "hmm, interesting." But when people see it in action it's "OMG, I must have this!"

I recently had that experience myself and enough people asked me about it that I decided to do a quick (15 min) screencast how to setup a native boot to virtual hard drives.

If you want a great overview and step-by-step instructions, check out Scott Hanselman's blog post:

Less Virtual, More Machine - Windows 7 and the magic of Boot to VHD

If you want to see boot to VHD in action, then check out the video here:

Download Screencast: BootToVhdKennedyWalkthrough.zip (339 MB)

All content copyright Michael C. Kennedy. All information, source code, and especially tools are provided as is and on a "use at your own risk" basis.

Article: Avoiding 5 Common Pitfalls in Unit Testing

Michael Kennedy — Sat, 08 Aug 2009 00:40:13 GMT

Llewellyn Falco and I recently wrote an article for DevelopMentor's Developments newsletter entitled Avoiding 5 Common Pitfalls in Unit Testing.

You can read it at the DevelopMentor website:

http://www.develop.com/testingpitfalls

I've republished here for my readers. Enjoy!

[Update: We have also done a webcast demonstrating some of these ideas, which we wrote up here:
http://www.michaelckennedy.net/blog/2009/10/28/TDDInvadesSpaceInvaders.aspx]

Avoiding 5 Common Pitfalls in Unit Testing

by Llewellyn Falco and Michael Kennedy

When I started out with unit tests, I was enthralled with the promise of ease and security that they would bring to my projects. In practice, however, the theory of sustainable software through unit tests started to break down. This difficulty continued to build up, until I finally threw my head back in anger and declared that

"Unit Tests have become more trouble than they are worth."

So we stopped. Not all once, but over the months our unit tests died a quiet death. When tests would stop working, we just ignored them. When new features were reported, they were developed without unit testing. At first, it seemed great. We were able to move without the baggage of maintaining the old tests! But soon all the original problems of having a system without tests came back to us. Things keep breaking, deadlines were increasingly pushed back. Releases came with an extraordinary amount of stress, late nights & weekends. The final straw came when we were forced to rush out an immediate update, and ended up taking down the company for 2 days straight. Our new motto became:

"Unit Testing: you're damned if you do, you're damned if you don't."

In the end, we decided that despite the hardship caused by maintaining unit tests, it just wasn't feasible to operate without them. So we started down the road to re-incorporate testing into our software development process. As the months went by, however, we discovered that the hardships we remembered had not returned. Looking back, we realized that we had made many mistakes the first time around. The second time around we were smarter. So you, too, can enjoy the benefits of unit tests here are the 5 major pitfalls we encountered the first time around, and how you can avoid them.

Pitfall #1: Tests are hard to maintain.

Because tests were only there to service and support the production code, they became second class citizens. We would spend time carefully choosing method names, refactoring our code to keep our classes and methods small, and so on. But we never applied these same principles to our test code.

As a side-effect of adding back the old tests, we reviewed and cleaned them up with the same level of scrutiny we gave to our "real" code. Suddenly the tests were easier to maintain. While this should not be a surprise to anyone, it wasn't util this moment that we realized why they had been so hard to maintain in the first place:

Our tests were hard to maintain because we weren't maintaining them.

Solution: Going forward, we expect the same quality of code (or higher) in the unit tests as we do for our production code. That means

We remove duplication
We carefully consider method names
We create convenience functions for testing features
We keep our methods short
We code-review our unit tests

Pitfall #2: Tests are lot of work to write.

We found that in order to test even simple things we would have to write lots of code to setup and execute the scenario. Even something simple like "create a new user, and receive welcome email" would turn into 40-50 lines of step by step instructions.

Not only was this a pain to write the 1st time, it became a nightmare to maintain. Little changes would mean re-reading those functions to detect if the test was failing because we broke something, or simply because we had changed something. Once that was discovered, we would then have to update the now out of sync test code.

The solution we actually found may surprise you. We found that writing out our tests in English and then translating each line into 1 line of code naturally created the appropriate levels of abstraction and readability.

For example, let's consider testing the following scenario:

Who are you receiving the most email from?

Create you - the user
Mike sends you 3 emails
Mary sends you 4 emails
Joan sends you 2 emails
Verify your greatest "emailer" is Mary

This will naturally lead us to write the following test method and helper method:

[TestFixture]
public class AccountTests
{
    private MockMailServer mockMailServer = new MockMailServer();

    [Test]
    public void WhoAreYouReceivingTheMostEmailFrom()
    {
        User you = User.CreateNew( "you" );
        User mike = SendEmailHelper( CreateUser( "mike" ), you, 3 );
        User mary = SendEmailHelper( CreateUser( "mary" ), you, 4 );
        User joan = SendEmailHelper( CreateUser( "joan" ), you, 2 );

        Assert.AreEqual( mary, you.GetGreatestEmailer() );
    }

    private User SendEmailHelper(User from, User to, int quantity)
    {
        for ( int i = 0; i < quantity; i++ )
        {
            EMail mail = new EMail()
            {
                To = to, 
                From = from, 
                Body = "Sample",
                Subject = "test"
            };

            mail.SetFormat( Formats.Html );
            mockMailServer.Send( mail );
        }
        return from;
     }

Notice that to a programmer, the lines of code in the WhoAreYouReceivingTheMostEmailFrom test are as easy to read as the lines of English were. We were naturally motivated to create the "SendEmailHelper" function because that was required by one-to-one correlation between the lines of English and the lines of test code. However, without that helper, our test would have become an unreadable rat's nest. This also naturally removes some duplication, increases maintainability, and allows for some reuse of the test convenience functions. This won't be the only test that requires us to send email; for example, we may want to test that we can find out to whom you sent the most email.

Let's compare this to how our tests would look if we had just hacked out the scenario:

[Test]
  public void WhoAreYouReceivingTheMostEmailFrom()
  {
      User you = User.CreateNew("you");
      User mike = CreateUser("mike");
      for (int i = 0; i < 3; i++)
      {
          EMail mail = new EMail{To = you,From = mike, Body = "Sample", Subject = "test"};
          mail.SetFormat(Formats.Html);
          mockMailServer.Send(mail);
      }
      
      User mary = CreateUser("mary");
      for (int i = 0; i < 4; i++)
      {
          EMail mail1 = new EMail{To = you,From = mary,Body = "Sample",Subject = "test"};
          mail1.SetFormat(Formats.Html);
          mockMailServer.Send(mail1);
      }
          
      User joan = CreateUser("joan");
      for (int i = 0; i < 6; i++)
      {
          EMail mail2 = new EMail {To = you, From = joan,Body = "Sample",Subject = "test"};
          mail2.SetFormat(Formats.Html);
          mockMailServer.Send(mail2);
      }
      
      Assert.AreEqual(mary, you.GetGreatestEmailer());
      }

Because we wrote the first version in English it's also easier to detect a mistake. You may have noticed that the second example had a typo at line 31, making Joan the biggest emailer. In general long methods have the disadvantage of obscuring intent. Unfortunately the 'follow a script' aspect of testing lends itself to writing long methods. By writing the tests in English and then doing a 1-to-1 conversion to code we can counter this vulnerability.

Write the tests in English before you code them.

Pitfall #3: Adding a new feature breaks a lot of tests that I then need to adjust.

I always dreaded adding new features because I knew it meant the existing tests were going to complain about the changes. It seemed like the tests themselves were resisting change to my system, rather than supporting it. As I made changes and the tests broke, I was always trying to figure out if those changes were "expected" because of the new feature, or unintended bugs I had introduced into my software.

Nowadays, we always prep the system for the new feature. This allows us to isolate 'expected' changes from unintended bugs. Furthermore, once we have finished prepping for the new feature, we find it extremely easy to actually add that new feature. Best of all, if the unit test breaks now, we know it's because of unexpected side effects of our changes.

This 'prepping' period falls under the title of 'refactoring' and requires the simple rule that during this stage you do not change the behavior, only the implementation. This sounds straight forward and simple, but in practice it requires a great deal of discipline.

Personally, I still find it a challenge to NOT fix a bug discovered during refactoring. I have to force myself to leave it alone and wait until I have finished refactoring before changing (Fixing) this behavior, but this discpline has paid off many, many times.

During this period, the support provided by your unit test suite really shines. Those tests allow me to rework my code with confidence. Afterwards the architecture in place has been custom designed to support the addition of this particular new feature, thus making its implementation quite straightforward. In our experience the 'prepping' work tends to actually take more time than we spend adding the actual feature itself, but the total time to implement is much less.

By spliting the work into two phases, we can emphasize the fact that the unit tests are supporting the existing system allowing its architecture to evolve so that extending it does not become increasingly difficult.

Before I would ask myself "How can I add this new feature?" Now I ask "How can I make it so this new feature will be easy to add?"

Prep the system for the new feature first.

Pitfall #4: When I change something a whole bunch of tests break even though I haven't broken the system.

There are many ways to solve the same problem. In the past, we tended to test a specific implementation of a solution instead of testing that we had a solution. Because we were focused on the specifics of implementation, changes to our solutions kept breaking our tests, even though we still had a valid solution. Moreover, because the tests were closely tied to implementation, rediscovering the intent and separating it in the tests became cumbersome. As we became more proficient at writing tests in English, we were able to create unit tests that described the expected behavior. This conveys a higher level of intent, and made the tests much less brittle.

Let's look at an example:

[Test]
  public void TestGatewayCallSuccessful()
  {
      var gateway = new Gateway {Mask = "ExampleCode.*"};
      var enviroment = new Dictionary
(); enviroment.Add("path", "ExampleCode.HelloWorld"); string result
= gateway.ExecuteRequest(enviroment); Assert.IsTrue(result.Contains("Hello World"));
} [Test] public void TestGatewayBlocksInvalidMasks() { Assert.IsFalse(Gateway.IsValidForMask(
"Example.*", "ExampleCode.HelloWorld")); Assert.IsFalse(Gateway.IsValidForMask(
"ExampleCode.*.Extras.*", "ExampleCode.HelloWorld")); Assert.IsTrue(Gateway.IsValidForMask(
"ExampleCode.*", "ExampleCode.HelloWorld")); }

In this example, we wrote our second test TestGatewayBlocksInvalidMasks so we could easily test a few examples to make sure our implementation was correct. In doing so we exposed a method IsValidForMask, which was an implementation detail and was only made public in order to make testing easy and intentional. We did this because actually executing something to get the failure was much more involved as evidenced by the first test (TestGatewayCallSuccessful).

Let's take a look at the specific solution we've come up with:

public class Gateway : IRunner
  {
      public string Mask { get; set; }
      
      public String ExecuteRequest(Dictionary
environment) { string path = environment["path"]; AssertValidClass(path);
IRunner instance = (IRunner)Activator.CreateInstance(Type.GetType(path)); return instance.ExecuteRequest(environment);
} private void AssertValidClass(string path) { if (!IsValidForMask(Mask, path)) {
throw new Exception(String.Format( "Invalid Path '{0}' for Mask '{1}'",
path, Mask)); } } internal static bool IsValidForMask(String mask, String path) {
mask = mask.Replace(".", "\\.").Replace("*", ".*");
Regex regex = new Regex(mask); return regex.IsMatch(path); } }

As we can see, even though we are only creating this gateway once each time a call to ExecuteRequest is made we have to recreate the regex expression (line 31 & 32). It would be nice to do this just once. Let's take a look at a more efficient solution:

public class Gateway : IRunner
  {
      private string mask;
      private Regex regex;
      
      public string Mask
      {
         get { return mask; }
         set
         {
            mask = value;
            regex = new Regex( mask.Replace( ".", "\\." ).Replace( "*", ".*" ) );
         }
      }
      
      public String ExecuteRequest(Dictionary
environment) { string path = environment["path"]; AssertValidClass(path);
IRunner instance = (IRunner) Activator.CreateInstance(Type.GetType(path)); return
instance.ExecuteRequest(environment); } private void AssertValidClass(string path)
{ if (!regex.IsMatch(path)) { throw new Exception(String.Format("Invalid Path
'{0}' for Mask '{1}'", path, Mask)); } } }

Unfortunately this refactoring breaks the first set of tests. Notice that the function we are calling no longer even exists. However, let's look at what happens if we write our tests for the behavior rather than the implementation:

[TestFixture]
  public class GatewayBehaviorTests
  {
     [Test]
     private void TestGatewayCallSuccessful()
     {
         string result = Run("ExampleCode.*", "ExampleCode.HelloWorld");
         Assert.IsTrue(result.Contains("Hello World"));
      }
      
      [Test]
      public void TestGatewayBlocksInvalidMasks()
      {
          AssertValidForMask(false, "Example.*", "ExampleCode.HelloWorld");
          AssertValidForMask(false, "ExampleCode.*.Extras.*", "ExampleCode.HelloWorld");
          AssertValidForMask(true, "ExampleCode.*", "ExampleCode.HelloWorld");
      }
      
      private static String Run(string mask, string path)
      {
          var gateway = new OptimizedGateway {Mask = mask};
          var enviroment = new Dictionary
(); enviroment.Add("path", path); string result = gateway.ExecuteRequest(enviroment);
return result; } private void AssertValidForMask( bool exceptionExpected, string mask,
string path) { Exception found = null; try { Run(mask, path); } catch (Exception ex)
{ found = ex; } Assert.AreEqual(exceptionExpected, found == null); } }

There are a few things to notice now:

This test not only works for the new code, but the old code as well. This is because the behavior has not changed, just the implementation.
We have not sacrificed readability or clarity of intent. In fact the first test TestGatewayCallSuccessful has actually gained readability.
There is the introduction of helper methods in the unit test. We find that this is a side effect of writing tests for readability and intention.

In the end, we realized there is a particular code smell for this problem.

If a different implementation of a solution requires different tests, you are testing to the wrong level.

Pitfall #5: There are just too many possibilities to test

When we first began unit testing, we felt that we had to test as many inputs as possible because we believed the purpose of the unit tests was to ensure complete quality of our code. What we have learned is that the world is not black and white, and neither is testing. It is not the case that we either have verified code or unverified code. There are levels of protection. In fact there is a level at which you get diminishing returns from new inputs and, surprisingly, that number is often very small.

For example: Imagine the following scenarios :

Scenario 1
You have a method public int doSomething(int a, int b) {/.../}) Does this method work? Will it blow up if I run it? On a scale of 1-10 what is your confidence level?	Confidence Level 2: In our case, our confidence started out at 2. All we know is that it compiled. Any number of things could be wrong..
Scenario 2
Now, assume you have an invocation of the method doSomething(2,3); When you run this, it does not crash although you have no way to check its result. What's your confidence level now?	Confidence Level 6: As soon as it's been executed, our confidence jumps up to a 6. We know that most bugs come from incorrect wiring, or null pointers, and so on. Now we know it's not blowing up, but still don't really know that it's working
Scenario 3
Now imagine that you have a test assertEquals(8, doSomething(2,3)); This test passes. What's your confidence level now?	Confidence Level 8: Just a single confirmation pulls us all the way up to a confidence level of 8. Notice that we are still just at 1 test case. A few more and we'll be in the 9's, but how many more cases would you need to say with absolute confidence that this works? (hint: 2^32 * 2^32).

Tests are like seatbelts: just because they won't guarantee your survival in all crashes, it doesn't mean you shouldn't wear them. Take the extreme case of a motorcycle helmet. You are only protecting a small part of your body, but you are significantly improving the odds of survival if something goes wrong.

A general rule of thumb for the number of cases to tests is "3 is a big number".

Test the happy path
Test an edge case
Test an error case, if you have one

Start with the happy path. If you still are worried, try an edge case. Wait until a problem presents itself before you test further.

Spend your time where it counts.

All content copyright Michael C. Kennedy. All information, source code, and especially tools are provided as is and on a "use at your own risk" basis.

Article: Building a Twitter Application in .NET

Michael Kennedy — Fri, 07 Aug 2009 20:22:02 GMT

I recently wrote an article for DevelopMentor's Developments newsletter entitled Building a Twitter Application in .NET.

You can read it at the DevelopMentor website:

http://www.develop.com/twitternetapps

I've republished here for my readers. Enjoy!

Building a Twitter Application in .NET

by Michael Kennedy (@mkennedy)
http://www.michaelckennedy.net

Twitter has become one of the web's hottest properties. It is a central part of mainstream news programs such as CNN's Anderson Cooper 360, congressional debates, and talk shows. In fact, it grew at a rate of 1400% this past year [bit.ly/jG9BG].

If your company wants to interact with your customers in a modern and engaging experience, you need to be on Twitter. In fact, if you have customers that really like or dislike you, they are probably talking about you on Twitter. You should be part of that conversation.

In this article, we will explore how to build a rich interactive experience on Twitter that goes beyond just creating a new Twitter account. We will build a .NET application that uses the Twitter API (a free service) alongside other cool technologies such as the WCF REST Starter Kit [http://bit.ly/v8mBb] and LINQ to fully leverage the Twitter experience.

Whether you want to build a community around your brand or you want to build the next real-time, social community website like .NET Developer Buzz [http://dotnet.ubbuzz.com/], this article will cover the technologies required to get the job done.

If you want to download the sample application to follow along, you can get it here:
http://www.michaelckennedy.com/Samples/SampleStatusUpdater.zip

While you're at it, be sure to follow DevelopMentor on Twitter:
http://twitter.com/dm_the_company

Let's Start Small

I will show you how to fully leverage the Twitter API, but many tasks can be accomplished using simpler tools and you may be better starting there. Let's look at a few things that we can do without the Twitter API.

Case 1. You want to display your latest Twitter messages on your website.

Your tweets[1], as they're called, can be consumed as a simple RSS feed. So you may want to simply pull this feed into your website rather than digging into the Twitter API and consuming custom XML or JSON formats. An example of consuming Twitter in this fashion can be found on my website's front page [http://www.michaelckennedy.net/].

To get your RSS feed, just visit your profile page and get the RSS tweet link, e.g. "RSS feed of mkennedy's tweets" [http://bit.ly/guhZU]

[1] Tweet - these are what the individual messages sent on Twitter are called. If the name sounds weird, I'm sure you'll get used to it. Remember that there was a time when Google was just a noun.

Case 2. You want to watch and manage multiple accounts at the same time.

Most Twitter clients only support a single user. But there are a couple of good tools that allow you to manage multiple accounts. My current favorite is one called bDule and you can get for free at http://www.sobees.com/bdule.

Beyond the Small

There are times when you want to do more than simply syndicate your Twitter stream. Let me give you an example. At DevelopMentor, we have had many instructors on Twitter talking about their own interests. But we didn't have a corporate Twitter presence. We decided to create our corporate presence by pulling all our instructors individual tweets and rebroadcasting them from our DevelopMentor Twitter account: @dm_the_company

We wanted to keep a sense of the original instructor who wrote the message, so we append on an attribution. For example:

"Software Transactional Memory is released! (via @mkennedy)

and we wanted to do this in a flexible way. In short, we needed more functionality than Twitter provides.

There are actually three services that do this sort of thing and they looked promising.

http://www.connecttweet.com/
http://www.grouptweet.com/
http://cotweet.com/

But in the end, nothing completely matched our requirements. So we decided to write our own application to publish everyone's tweets under the DevelopMentor banner. There are few simple steps involved as well as a lot of details we won't go into yet.

Take a list of Twitter accounts and download everyone's statuses.
Determine which messages we haven't seen before.
Publish these new statuses under our corporate account.

We can actually implement a simplistic version of this by continuing to use the public RSS feeds of the individual accounts in conjunction with a very handy Twitter API wrapper called TwitterooCore which you can find at http://rareedge.com/twitteroo/blog/.

The Twitter API

In practice, there is simply data missing from the RSS feed that we require as well as features missing from the Twitteroo Core that move us deeper into the Twitter API. One thing you may well miss is the ability to tie together conversations. For example if Bob says "hello" and Jerry says in reply "@bob Back at you!" Twitter tracks that Jerry replied to Bob and publishes this link in the stream. To get access to these types of features and many other optimizations, you'll need to use the REST-based Twitter API.

The Twitter API is documented at http://apiwiki.Twitter.com/

There you can do things like get the users tweets, if their tweets are public, by requesting:

http://twitter.com/statuses/user_timeline.xml?screen_name=mkennedy

What you get back to dependent on the requested format. Here we're asking for XML (user_timeline.xml) but we can also get JSON, RSS, or ATOM.

Similarly, we can update our status by making a POST request to:

http://twitter.com/statuses/update.xml

Here again we have the four possible formats: XML, JSON, RSS, ATOM. However this time we're using a form post for the request to update the user status which is then in-turn returned as XML.

Great, we have this cool REST API based on loosely-typed GETs and POSTs. Should we program against it using fundamental .NET types such as WebRequest, WebClient, and similar classes? We could. But WebRequest is so .NET 1.0 (circa 2001). There is a much newer API on the verge of release from Microsoft: The REST Starter Kit [http://bit.ly/1IF3Ji].

While this toolkit is generally geared towards building to RESTful WCF services, there's also a great set of classes for building REST clients. We will use these classes to write our application. Let's take a look at how we can use the Twitter API to write are simple application.

The REST Starter Kit

Part 1 - Getting the users of tweets.

We need to download the users messages as XML and convert them to .NET objects that we can consume our application. This is really straightforward because the REST Starter Kit as a cool feature to Visual Studio: "Paste XML as Types". This feature will take an XML file and auto-generate types based on the inferred XML schema. In our case, the XML file we will use is returned from the user timeline.

http://twitter.com/statuses/user_timeline.xml?screen_name=mkennedy

Open a link in a web browser, choose view source, and copy some XML. Then go to Visual Studio, choose edit, Paste XML as Types. Of course you must have the REST Starter Kit installed for this to work.[2]

[2] In my experience I ran into some errors deserializing the response from Twitter. See the The Real World Intrudes section at the end of the article if you run into difficulties.

After generating our status related types, we can use the HttpClient class to download the statuses.

Listing 1.

private static void GetStatuses(IEnumerable
userNames) { XmlSerializer serl = new XmlSerializer(typeof (statuses)); serl.UnknownElement
+= delegate { }; foreach (string name in userNames) { string url = string.Format(
"http://twitter.com/statuses/user_timeline.xml?screen_name={0}", name); HttpClient
client = new HttpClient(url); HttpResponseMessage response = client.Get(); response.EnsureStatusIsSuccessful();
string contents = response.Content.ReadAsString(); Stream stream = new MemoryStream(Encoding.UTF8.GetBytes(contents));
statuses userStatuses = (statuses) serl.Deserialize(stream); if ( userStatuses.status.Length
> 0 ) { Console.WriteLine( "@{0}'s latest tweet: {1}", name,userStatuses.status[0].text
); } Console.WriteLine(); } }

There are two main things happening in this code. We're using the HttpClient class to download the web content associated with the given user's timeline. Then we're using the XmlSerializer in conjunction with the auto-generated XML-serializable types from the "Paste XML as Types" command. That's all there is to it. The REST Starter Kit does most of the work for us.

Part 2 - Checking for New Messages

Now that we have all the statuses, we need to find the ones that we haven't broadcasted from our main account and send them along to step 3. We won't go into detail on how to track that. But you can imagine a simple database that facilitates a LINQ to SQL query like this:

Listing 2.

public StatusUpdate[] FindRebroadcastableStatuses(StatusUpdate[] updates)
{
    return
        (from up in updates
         let neverPosted = up.User.LastPostBroadcasted == null
         let afterPostDate = up.Time > up.User.LastPostBroadcasted
         where neverPosted || afterPostDate
         select up).ToArray();
}

Part 3 - Publishing the Statuses

Now that we've gathered the statuses of our various users, it's time to rebroadcast them to our community. We're going back to the Twitter API to update our status. Again will use the HttpClient class and following the RESTful principle of using POST to add new items to a given URI. We will do an HTTP POST to our status to add a new message to the account.

Listing 3.

private void UpdateStatus(string newStatus, long? replyToId)
{
    string url = "https://twitter.com/statuses/update.xml";

    HttpClient client = new HttpClient( url );
    client.TransportSettings.Credentials = 
        new NetworkCredential( twitterUser, password );

    HttpUrlEncodedForm form = new HttpUrlEncodedForm();
    form.Add( "status", newStatus );
    if ( replyToId != null )
    {
        form.Add( "in_reply_to_status_id", replyToId.ToString() );
    }

    HttpContent content = form.CreateHttpContent();

    HttpResponseMessage message = client.Post( "", content );
    message.EnsureStatusIsSuccessful();
}

This time we create an HTML form using the HttpUrlEncodedForm class. We set the status field to our new status. If this status as a response to a previous tweet then we add the in_reply_to_status_id so Twitter knows to add a "in reply to..." tag to the tweet.

And there you have it. Working with the Twitter REST API is really quite straightforward. If you use the REST Starter Kit it's downright easy.

The Real World Intrudes

But wait a minute. This is reality and building bulletproof applications is never that simple. There are at least five significant gotchas you have to address in practice when working with Twitter and the REST Starter Kit.

1. There will be times when Twitter is unavailable. You have to be ready for crashes and other types of randomness.

Twitter is one of those sites that can barely handle the traffic it is receiving. With its 1400% growth, this isn't getting much better. So you must program defensively and assume that many of your API requests will fail.

2. The Twitter API is a free service. By default, you are limited to a small number of requests per hour. Many of the limits are around 150 API calls / hour. You may need to carefully design your application to work within the limits. Some applications simply need more data than this permits. For example, .NET Dev Buzz [http://dotnet.ubbuzz.com/] has to track thousands of users. In that case, you will have to get your application white listed with Twitter. You can do that here:

http://twitter.com/help/request_whitelisting

3. The date-time format used by the Twitter API is not directly parseable in .NET. The format returned is in the format "Fri Feb 01 18:18:08 +0000 2008". But if we change this to "Fri Feb 01 +0000 2008 18:18:08" it is parsable. So you might need to adjust these date-time values.

4. You will get 417 error codes when you try to talk to Twitter using the default configuration. The fix is not immediately apparent, but it is very simple. So if you see the following error:

System.ArgumentOutOfRangeException: ExpectationFailed (417) is not one of the following: OK (200), Created (201), Accepted (202), NonAuthoritativeInformation (203), NoContent (204), ResetContent (205), PartialContent (206) at Microsoft.Http.HttpMessageExtensions.EnsuRESTatusIs()

Just to set the following property: ServicePointManager.Expect100Continue = false;

5. "Paste XML as Types" doesn't entirely work. For some reason, certain messages from Twitter are not deserializable to the types generated with this command. My experience was that I didn't actually care about the data causing the problem. So I just removed that part of the generated type. You may have to subscribe to the XmlSerializer error events to prevent exceptions.

Conclusions

I hope you now have a greater appreciation for what you can do with Twitter and how it can help you build your brand or build engaging applications. We've used the REST Starter Kit to make it easy to consume the Twitter API. You've even seen some of the odd things that can go wrong and how to fix them. Don't forget to download the sample application here:

http://www.michaelckennedy.com/Samples/SampleStatusUpdater.zip

Now get out there and build something cool.

All content copyright Michael C. Kennedy. All information, source code, and especially tools are provided as is and on a "use at your own risk" basis.

Keep up with DevelopMentor on Twitter

Michael Kennedy — Thu, 23 Jul 2009 22:42:04 GMT

You may know that I work for DevelopMentor where I'm an instructor in the .NET curriculum (among other cool things I do there). You probably also know I'm kind of loopy for Twitter as evidenced by my Twitter page and .NET community site driven by Twitter:

http://twitter.com/mkennedy
http://dotnet.ubbuzz.com/

Today those two things came together in a big way. Introducing DevelopMentor's Twitter presence:

@dm_the_company
http://twitter.com/dm_the_company

I encourage you get out there and follow us! Here you will see all the combined Twitter messages of most of the DevelopMentor instructors as well as a couple of messages from DevelopMentor itself. You'll get the chance to keep on top of the world as viewed by some of the smartest people I've had the chance to work with: the DM instructors! You'll see which instructor posted any given message with an attribution at the end (either "via @marksm" or ^MS depending on the available space).

I'm excited about this not just because I think it is cool and useful (and has to do with Twitter :) ), but over the last few days I'm the guy who wrote the back-end systems to make this all go. It was a short but fun project. It's a real testament to .NET that this was mostly written an hour.

After you follow @dm_the_company you might want to interact with some of the instructors directly. Here's our Twitter accounts in a single place for your reference:

http://twitter.com/bmaso
http://twitter.com/danamiga
http://twitter.com/jason_diamond
http://twitter.com/jplane
http://twitter.com/markblomsma
http://twitter.com/marksm
http://twitter.com/mauricedb
http://twitter.com/mkennedy
http://twitter.com/nielsberglund
http://twitter.com/richardblewett
http://twitter.com/tonysneed
http://twitter.com/wallacekelly

I hope you enjoy the conversations we're bound to have on Twitter. Come be part of it.

Signed: @mkennedy

All content copyright Michael C. Kennedy. All information, source code, and especially tools are provided as is and on a "use at your own risk" basis.

Gmail New Mail Notifications for Windows 7

Michael Kennedy — Sat, 11 Jul 2009 05:44:21 GMT

[Update: Renamed this tool from Gmailer to Gmail 7 due to pre-exiting product name conflicts]

I've been using Windows 7 as my sole operating system since Beta 1 in January. I'm completely loving it and I was pleased to see how many apps worked seamlessly on it. One that didn't and I really miss is Gmail Notifier. No matter how I try, I always get this:

It's insane to me that $130B company can't provide any more than this outdated tool for this job, but I digress...

I've looked and looked for a replacement and they are either no longer online, are crappy applications, and so on. Finally I decided to take matters into my own hands. Introducing a clean, simple, unobtrusive, and free Gmail notification application that works on Windows 7 - Gmail 7:

Gmail 7 simply runs in your tray and plays the Windows new mail sound when mail comes in to your Gmail account.

New Mail:

No New Mail:

That's pretty unobtrusive right? Your account info is encrypted and stored in your user profile and all network access uses SSL.

Download all 41 KB of Gmail 7 here: Gmail7.zip

Requires .NET 2.0 (built into Vista and Windows 7)

Just extract the folder to its final resting place and run it - select "Launch at login" if you want that.

It even comes with some cool ways to view your email by double-clicking the tray icon.

Also thanks goes to Ryan Cook for use of his Gmail C# tools as the basis for part of my project.

All content copyright Michael C. Kennedy. All information, source code, and especially tools are provided as is and on a "use at your own risk" basis.

ASP.NET Routing in Windows Azure Using WebForms

Michael Kennedy — Wed, 27 May 2009 21:53:18 GMT

I'm a huge fan of ASP.NET Routing. It gained popularity as the part of ASP.NET MVC which channels requests for a given URL to the right controller action. In a wise move, Microsoft moved the routing infrastructure out of ASP.NET MVC and into its own assembly with the release of .NET 3.5 SP1.

With ASP.NET Routing you can construct search engine optimized and human friendly URLs such as these:

http://dotnet.ubbuzz.com/tag/everything
http://dotnet.ubbuzz.com/tag/Azure
http://dotnet.ubbuzz.com/user/codinghorror

Here part of the URL (tag or user) selects the page and part of the URL (everything or codinghorror) are effectively query parameters to the page.

This is well documented in the ASP.NET MVC world running on your server - you can't get anything done without it in MVC. But what about Windows Azure? What if you don't want ASP.NET MVC? What if you're a traditional type of person and want all the goodness that comes with what is now called ASP.NET WebForms (aka "normal ASP.NET")?

In this brief post, I'll cover how to use ASP.NET routing and ASP.NET WebForms in Azure. The sample project can be downloaded if you want to follow along. Phil Haack has written a good post on using routing alongside ASP.NET WebForms so I won't cover too much background information.

http://haacked.com/archive/2008/03/11/using-routing-with-webforms.aspx

How does this change for Azure?

The short answer is that it doesn't. If you get routing working for IIS 7 in your web app, you can effectively deploy it to Azure. But the steps always felt convoluted to me when reading others' write-ups on this. So let's run through converting a Windows Azure Web Role (essentially a "stock" ASP.NET WebForms app) to use routing in Azure.

First you'll need the Azure SDK and Visual Studio tools:

http://www.microsoft.com/azure/windowsazurefordevelopers/default.aspx

Next, create a new solution in Visual Studio by choosing Cloud Service->Web and Worker Cloud Service.
Add a new Global.asax file to your web role project.
Add a reference to System.Web.Routing and System.Web.Abstractions in your web role project.

Define a custom class that derives from IRouteHandler which will map URL parameters into the HttpContext for use in your pages:

internal class CustomRoute : IRouteHandler
{
    public CustomRoute(string virtualPath)
    {
        VirtualPath = virtualPath;
    }

    public string VirtualPath { get; private set; }

    public IHttpHandler GetHttpHandler(RequestContext requestContext)
    {
        foreach ( var aux in requestContext.RouteData.Values )
        {
            HttpContext.Current.Items[aux.Key] = aux.Value;
        }

        return BuildManager.CreateInstanceFromVirtualPath(
                   VirtualPath, typeof( Page ) ) as IHttpHandler;
    }
}

protected void Application_Start(object sender, EventArgs e)
{
    RouteTable.Routes.Add( "ShowName",
           new Route(
            "naming/show/{name}",
            new CustomRoute( "~/ShowName.aspx" )
            ) );

    RouteTable.Routes.Add( "CreateAccount",
           new Route(
            "account/begin",
            new CustomRoute( "~/Account.aspx" )
            ) );

    RouteTable.Routes.Add( "Home",
           new Route(
            "home",
            new CustomRoute( "~/Default.aspx" )
            ) );
}

Now if you run your app, you might expect the routing infrastructure to work. Inside the ASP.NET Dev Server (aka cassini) this will likely work. But in the Azure Development Fabric you'll see this:

The problem is you need to tell IIS 7.5 to get out of the way and let the request get to ASP.NET.

We'll define a class to short-circuit the IIS validation

class Iis7RoutingHandler : UrlRoutingHandler
{
    protected override void VerifyAndProcessRequest(
        IHttpHandler httpHandler, HttpContextBase httpContext)
    {
    }
}

Modify the web.config by adding a handler and module to the system.webServer section:
```

... 
```
Finally, we need to recover the data passed to the page. For example, in the sample project we have:

route: /naming/show/{name}
example: /naming/show/michael-kennedy

How will our page access the value of name? Recall that our custom route stashes the values in HttpContext.Current.Items. We'll just pull them back out as follows in our Page_Load method of our ASPX class:
```
LabelName.Text = (string)HttpContext.Current.Items["name"];
```

That's it! You can see our routes working in our WebForms app running in Azure (well, technically the screenshot is the dev fabric - but it works in the cloud as well):

Download the source and try it for yourself: AzureRoutingSample.zip (136 KB)

All content copyright Michael C. Kennedy. All information, source code, and especially tools are provided as is and on a "use at your own risk" basis.