Software Development

Fiddler is an awesome tool for debugging web services. For the last 10 years, I’ve been using it virtually every working day for web service debugging in scenarios such as:

• Capturing HTTP requests as they travel through a distributed system, which you have set up on your local development machine.
• Intercepting and modifying HTTP requests, essentially performing a local man-in-the-middle interception. This is particularly useful if want to modify HTTP requests to simulate functionality which isn’t currently present, modify HTTP headers, etc.
• Replaying captured requests - useful if you are debugging the way a web service behaves, given a specific request; capture the request, and replay it as many times as you need in order to debug the error.

If you’re doing any work with web services, Fiddler is definitly worth considering. Setting it up is fairly straightfoward

By default, Fiddler can update your browser proxy to route through the Fiddler proxy, which is, by default on port 8888, and will capture requests between Chrome/Firefox/Safari/etc, and your web app.

What if you’re debugging locally, and want to intercept .NET services which call other web services? i.e. Web Browser -> Web App -> Service1 -> Service2 (the one you want to debug)? This can be done by setting defaultProxy in web.config. In this case, since we want to debug Service2, we’d set defaultProxy in Service2’s web.config file.

i.e.

<configuration>
 <system.net>
  <defaultProxy>
   <proxy bypassonlocal="false" usesystemdefault="true" />
  </defaultProxy>
 </system.net>
</configuration>

With one of the distributed apps I frequently work with, I was setting, and resetting the web.config defaultProxy fairly frequently. To save some effort, I wrote a script to automate the change.

Earlier this evening I installed .NET core preview 2 on Debian Sid, and tried to create a new project via the dotnet new command, only to get a segmention fault error message:

matt@IDSiG:~/git/testproject$ dotnet new console
Segmentation fault

In this instance, the segmentation fault on creation of a new project was is due to .NET Core telemetry being incompatible with version 1.1 of OpenSSL.

Sometimes, when being interviewed for a job as a software developer, you’ll be asked a question such as “write a method that takes an integer as a parameter, and returns it’s factorial.”

For example, the factorial of 3 is represented as “3!”, which is calculated via 321, which equals 6. 4! is 432*1, which is 24, etc.

Putting aside whether these kinds of questions should be asked in an interview, if they’re asking you this, there’s a fairly high likelihood they’re asking for you to show that you understand recursion. If that’s the case, no problem, something like this will calculate the factorial:

let rec factorial n =
    match n with
    | 0 | 1 -> 1
    | n when n > 0 && n <= 12 -> n * factorial (n - 1)
    | _ -> failwith "Parameter n is out of the supported range. Must be between 0 and 12."

This can be run in the F# interactive shell via:

> factorial 3;;
val it : int = 6

But what if they want to find out whether you:

1. Understand recursion, and…
2. Know when you can avoid recursion, and just write simple methods instead.

I recently migrated my mattbutton.com blog away from Wordpress hosting in favor of a static site generated by Hugo, hosted on Amazon S3.

Initially, I hosted the static site via Aerobatic.io, who recently removed their free tier, and started charging $15 per month for hosting with a custom domain.. 50% more than the $10 per month I was previously paying for Hostgator Wordpress hosting. Unless I have certain specific requirements, I can’t justfy that kind of cost to host a static site.

Aerobatic.io are using Amazon S3 and Amazon CloudFront behind the scenes, so I decided to cut out the middle-man, set it up myself, and save nearly $15 per month.

Setting up the S3 bucket to host my site was fine. For the CDN/SSL side of things I initially tried using CloudFront because most of the AWS Hugo Hosting, HowTo guides were using it.

When trying to set up CloudFront via my personal AWS account, I got an error saying a distribution already exists for mattbutton.com. The reason for this error is because Aerobatic.io had already created a CloudFront distribution pointing to their own S3 bucket. CloudFront isn’t an option for me until Aerobatic.io delete their mattbutton.com CloudFront distribution.

I still wanted to use SSL, and had decided on setting up mattbutton.com with it mainly out of interest, partly because Google uses HTTPS as a ranking signal, and partly because Chrome will eventually show a Not Secure warning for all pages served over HTTP.

Since AWS CloudFront wasn’t an option, I decided on using the CloudFlare free plan for SSL and CDN. Everything went well, until I encountered a CloudFlare 502 Bad Gateway error page:

I wasn’t having any luck searching for a solution to this error for this particular error. Fortunately, there’s a simple fix, if you know what you’re looking for, and you’re happy with the trade-offs involved.

When you want to visualize how a stock or portfolio has performed historically relative to the market as a whole, it is useful to create a comparison chart.

This blog shows how to create a line chart to compare two stocks with Deedle, FSharp Charting and F# Data.

In this example, the chart will show the perfomance of ANZ.AX relative to the ASX ALL ORDINARIES index (^AORD) over a three year period from 2011-1-1 to 2014-1-1.

This article is written for the intermediate F# audience who has a basic familiarity of stock trading and technical analysis, and is intended to show the basics of implementing a backtesting system in F#.

If you’re an F# beginner it may not take too long for you to get up to speed on the concepts if you check out a few resources. In particular:

• Try F#
• The CSV Type Provider
• Mastering F# Lists
• and Wikibooks F Sharp Programming/Recursion

The backtesting strategy which you will implement is a simple SMA crossover where the fast line is 10 bars and the slow one 25. When the fast line crosses above the slow line, a buy signal will be triggered, and when the fast line cross below the slow line, a sell signal will be triggered. Only one long position will exist at any time, so the system will not trigger another buy order until after the long position is sold.

When migrating a site from ASP.NET MVC 1 to ASP.NET MVC 2, you can generally follow the instructions in http://www.asp.net/whitepapers/what-is-new-in-aspnet-mvc#_TOC2, taking note of any breaking changes. This will take you most of the way there, however there are a few undocumented issues which you may uncover if you’re migrating a site with a substantial amount of code.

By default, the ASP.NET MVC 1 model binder would initialize strings to string.Empty whereas ASP.NET MVC 2 will initialize strings as NULL. This is an undocumented breaking change and will be a problem if you have a substantial amount of code relying on the original behavior – code that was previously working in production will start throwing NullReferenceException.

To preserve the original MVC 1 model binder behaviour, consider creating default model binder such as the following:

For the ASP.NET MVC default model binder to bind a list successfully, the list must be sequential with unbroken indices.

For the following examples, the server side model will be

public class ItemsModel 
{
    public IList<string> Items { get; set; }
}

Non-sequential form submits when using indexes which don’t start from zero i.e. Item[2], Item[3], etc will result in incomplete form data being loaded by the model binder.

The following will not bind, and will result in the model being NULL:

<input type="text" name="Item[1].Name" value="Item1" />
<input type="text" name="Item[3].Name" value="Item2" />
<input type="text" name="Item[4].Name" value="Item3" />

When you are maintaining multiple web apps across environments it can be difficult to keep track of which scripts need to be run to upgrade the database when it comes time to deploy. If you’re maintaining different versions of web apps across environments when the versions can sometimes be significantly out of sync, the difficulty of determining which update scripts need to be run on deployment can explode.

While there are a ton of approaches to keeping your database under version control, if you want something simple and effective that you can implement with minimal time and effort, consider a DatabaseVersionHistory table in your database.

A database version history table will allow you to see at a glance the state the database is in and by comparing it with the update scripts in source control, you will quickly be able to determine which update scripts need to be run.