Fiddler is a Web Debugging Proxy which logs all HTTP(S) traffic between your computer and the Internet. Fiddler allows you to inspect all HTTP(S) traffic, set breakpoints, and “fiddle” with incoming or outgoing data.

Download Fiddler from http://www.fiddler2.com/, it’s freeware! It runs on Windows, but can debug traffic originating in any operating system (by making that OS point to Fiddler on Windows as a proxy). Before reading this you should read these articles which provide an overview of Fiddler.

Stubbing network responses

During development with a third party it’s often handy to insulate yourself from any downtime/network problems that might affect your testing. Quite often this involves writing a piece of code to simulate network responses and pointing your app to that. Instead of doing this, turn to Fiddler.

Record and replay

Configure your application to use Fiddler as a proxy (see this for .NET apps, use localhost:8888), then hit your third party endpoint with your application. Fiddler will capture the traffic in the session list. Now, click on the Auto Responder tab and enable Automatic Responses. Drag each row from the session list into the Auto Responder list. Now re-run your app, and instead of connecting to the remote machine, Fiddler will auto-respond for you. (If you are using SSL, read how to decrypt SSL traffic and also in .NET you’ll need to suppress the invalid man-in-the-middle cert that Fiddler uses by returning true in the ServerCertificateValidationCallback

From an interface spec

If you have an interface spec but no endpoint to hit, create a file matching the content you expect to be returned, define a match for the URI, and use your sample file as the response content. See AutoResponder reference for more information.

You can use regex pattern matching for the URI, and you can either respond with a local file, or captured session. With a regex to match the entire host you can make all calls to your network resource respond with a HTTP 403 Denied and ensure your app behaves as expected.

Custom rules to show Akamai cached pages

I’ve used Akamai edge caching on a number of sites over the past few years to improve site performance, and it’s always useful to see which pages are being served from cache, and which aren’t. The easiest way I’ve found to do this is to add a custom rule to Fiddler to highlight requests for me. From Fiddler, choose Rules, Customize Rules. In the Javascript that opens, enter the following code:

With the other field definitions…

	public static RulesOption("Highlight Akamai cache Hits")
	var m_HighlightAkamaiHits: boolean = false;

In the “OnBeforeRequest” method…

	if (m_HighlightAkamaiHits) {
		oSession.oRequest.headers.Add("Pragma", "akamai-x-get-cache-key");
		oSession.oRequest.headers.Add("Pragma", "akamai-x-cache-on");
		oSession.oRequest.headers.Add("Pragma", "akamai-x-cache-remote-on");
		oSession.oRequest.headers.Add("Pragma", "akamai-x-get-true-cache-key");
		oSession.oRequest.headers.Add("Pragma", "akamai-x-check-cacheable");
		oSession.oRequest.headers.Add("Pragma", "akamai-x-get-extracted-values");
		oSession.oRequest.headers.Add("Pragma", "akamai-x-get-nonces");
		oSession.oRequest.headers.Add("Pragma", "akamai-x-get-ssl-client-session-id");
		oSession.oRequest.headers.Add("Pragma", "akamai-x-serial-no");
	}

In the “OnBeforeResponse” method…

	if (m_HighlightAkamaiHits) {
		if (oSession.oResponse.headers.ExistsAndContains("X-Cache","TCP_MEM_HIT")) {
			oSession["ui-customcolumn"] = "HIT";
		} else if (oSession.oResponse.headers.ExistsAndContains("X-Cache","TCP_IMS_HIT")) {
			oSession["ui-customcolumn"] = "HIT";
		}
	}

Now close the Javascript file, and go back to Fiddler. If you made any mistakes in the Javascript, Fiddler will tell you immediately. From the Rules menu you now have a new option – “Highlight Akamai cache Hits”. Enable this, and visit http://www.facebook.com/ in your browser. In Fiddler, you should see the word “HIT” for several of the requests in the “custom” column. You can rearrange the column order to move the custom column if you like.

Add request time

This is a simple new rule but surprisingly handy.

With the other field definitions…

	public static RulesOption("Show response time")
	var m_ShowResponseTime: boolean = false;

Add to either “OnBeforeRequest” or “OnBeforeResponse” method…

	if (m_ShowResponseTime) {
		oSession["ui-customcolumn"] = DateTime.Now.ToString();
	}

Remember when using these rules that when you save the Javascript file, the Rules menu will be reset so any previously enabled rules will need re-enabling.

Fiddler also has a nice set of C# APIs which allow you to embed the fiddler engine directly into your test suite, which makes for a really nice set of integration tests (using the AutoResponder) with only a few lines of code. I’ll go into this in a future post.

I’ve seen a few examples of people trying to mimic the Google Instant search with their own solution. Most of these have just made them “instant” searches by changing

$("#searchButton").click(function(){
  ...perform actual search...
});

to

$("#searchButton").keyup(function(){
  ...perform actual search...
});

My gripe is that Instant doesn’t need to be, and in fact shouldn’t always be, Instant. There are 3 reasons for this

1) A lot of users type looking at their keyboard so Instant just needs to mean “ready when a user looks up from their keyboard to see the result”
2) Browser and network performance can be significantly harmed if you’re issuing complex javascript/ajax/network requests on every single keypress.

The solution? Well, my solution is very simple.

$(document).onready(function(){
   var _timerId = 0;

   $("searchButton").keyup(function(){
      window.clearTimeout(_timerId);
      _timerId = window.setTimeout(function() {
         ...perform actual search...
      }, 170);
   }).keydown(function(){
      window.clearTimeout(_timerId);
   });
});

In this example I set a timer which fires 170ms after the LAST keypress. It’s pretty imperceivable that there’s a delay at all, but it dramatically improves CPU/bandwidth performance of these “Instant” searches, and it still appears to be pretty Instant.

LOGFORMAT (%s - - [%d/%M/%Y:%h:%n:%j %j] "%j %r %j" %c %b "%j" "%B" "%j")

Then I stopped and remembered the database. I found that the table structure and indexes were sub-optimal and after a quick restructure the performance was boosted 400%. This got me wondering why my initial reaction was to dive into the code rather than consider any other options.

One of the Agile principles is Inspect and Adapt. To provide a regular team cadence this usually takes the form of a retrospective every couple of weeks. These sessions discuss the actions which came out from the previous retrospective and the previous couple of weeks work. The team establishes a few important areas of concern and these are discussed in more detail to establish a course of resolution.

Extending this line of thought I ended up wondering why do we do what we do each day? Is it the path of least resistance? Force of habit? Loyalty?

What might a Life Retrospective uncover?

• Would we discover a new route to work which we’d previously discounted for being too long? A new carriage on the train which doesn’t get as busy?
• A new variety of pasta sauce even tastier than our regular? A supermarket own brand for half the price but the same taste?
• Might we find that every day we live with the coffee table getting in the way when we walk into the lounge, but we never try a new layout?
• How much extra happiness could we gleen from running life retrospectives? Who would run it? How frequently would be useful?

Lots of questions and not many answers I’m afraid. Maybe I need a retrospective of this post.