Where I say goodbye to New Zealand, hello to Japan, and hello to Pocari Sweat

I flew out of Wellington on 20th of July, 2016, in the middle of a bitter winter, for a two week adventure around Japan (Tokyo -> Takayama -> Kanazawa -> Hiroshima -> Kyoto), followed by four weeks in Thailand (Bangkok -> Chiang Mai -> Koh Phangan -> Koh Tao). This was the longest trip I’ve been on as an adult, and was also my first time solo traveling outside of New Zealand.


Traveling light on a six week trip around Japan and Thailand, in 2016


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.



Creating comparison charts for stocks with FSharp Charting, Deedle and Yahoo Finance


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]5) over a three year period from 2011-1-1 to 2014-1-1.



A Basic Stock Trading Backtesting System for F# using Ta-Lib and FSharp.Data


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:

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. Feel free to get in touch and send through any improvements, questions or corrections.



NullReferenceException when model binding strings after upgrading from ASP.NET MVC 1 to ASP.NET MVC 2


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:



ASP.NET MVC - issues with binding a non-sequential list with the default model binder


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" />



Database version management and figuring out which scripts need to be run when deploying the latest version of your web app


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.



A JIRA issue tracking FAQ for a small team


This post is intended as a living document that will evolve and grow over time. If there’s something you think I missed or would like something clarified, please feel free to leave a comment.

Who should be reading this FAQ?

Managers, developers, testers, anybody working or contributing on a software project.

This article is generally JIRA specific, however concepts will carry across into other issue trackers such as BugzillaRedmineTeam Foundation Server (TFS) and Trac just fine.

When should a small team be using an issue tracker such as JIRA?

A young startup may initially get away just fine by working informally and by email, and early in the project you’ll want to have as little administrative burden as possible, however as a project and team matures, there will come a time when having a searchable, persistent audit history of business decisions, fixes (and why they were done) and completed tasks will become invaluable.

This audit history goes hand-in-hand with a good version control commit history.