Whenever I travel, I keep my luggage as light as possible, traveling with carry-on only; everything fits inside a 38 litre backpack, usually with room to spare, and this trip was no exception.

My entire set of luggage, for my 2016, six week trip around Japan and Thailand, weighed about 6kg (14lb). During my trip, I picked up a few more things, which pushed the total weight up to about 7kg, which was still within the carry-on weight allowance.

I travel light because I think it’s by far, the easiest, simplest way to travel; no checked-in luggage, means no lost luggage, no awkwardness with connecting flights (just grab my bag out of the overhad locker, and I’m ready to walk to the connecting flight), no need to wait for the baggage carousel, no dragging around multiple suitcases, easy to get on the bus or train.

Below is a photo all of my luggage, in the “capsule” room, where I slept in Asakusa, Tokyo.

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.

After installing Visual Studio 2012, I found that the open file dialog wasn’t being displayed. I could open projects via Windows explorer, via the recent projects menu, compile, run etc, however neither Open Project or the File->Open->Project/Solution were working.

What was strange about this is that other dialogs such as New Project were working fine.

After much searching and testing, enabling the Tablet PC Input Service fixed the issue. This does not make much sense since I’m not using a tablet pc, however it works for me and may work for you.

To enable the service:

Why would I want to use Mercurial or any other DVCS client with a Subversion repository?

• It lets us keep SVN as our central repository
• Some team members prefer not to use a DVCS for whatever reason so it lets them carry on using SVN without interruption.
• It allows me to work and commit changes (but not push!), search history and switch between branches completely disconnected. I can continue to work during network outages or while traveling when I don’t have connectivity.
• You get full, fast history search.
• Switching between branches is easy and fast.
• Any automated processes which use SVN (i.e. automated builds and deployments) can continue to operate while everyone moves to DVCS.
• It’s much easier to perform merges than regular SVN (via export/import patch queues – which I detail later)

If you are connecting to a SQL server with the SQL profiler and none of your templates are showing up, compare the versions of the SQL profiler you are running and the version of SQL server that you’re connecting to; there is likely a version mismatch.

If this is the case, what’s likely happening here is that you’re connecting to a SQL 10.50 instance with a SQL 10.0 profiler and the profile templates for 10.50 aren’t present.