CloudFlare DDNS updates

This blog is hosted on a Raspberry Pi under my TV at home. As is common with this scenario I have a dynamic WAN IP, updating intermittently at the whim of my ISP/router.

After a few attempts I’ve finally got a stable DDNS update that works with CloudFlare (having had trouble with various bits of ddclient+patches etc) in the form of some scripts that call curl against the Api directly. This seems nice and neat, and the scripts can be scheduled using cron.

I’ve posted the scripts used here. I’ll try to keep these updated as the CloudFlare Api changes (as I’ll have to to keep the site running!).

I’ve included the script required to download details of the dns records from CloudFlare, as this is required to get the rec_id value for the dns entry, which is then sent back for the update. My version of the main update script also maintains a simple log file of updates.

The repo is here, the update script is here
and the read script is here

A TinyIoC Bootstrapper

I really like the TinyIoC Inversion of Control Container. It’s nice and straight forward to use, it’s easily portable, and the auto registration feature does 99% of your work for you. In recent projects it has been an ideal choice, either because of the size of the project, or to introduce the concepts of DI to teams that weren’t already familiar with it.

With a little work though we can help it punch a little above its weight.

The sidekick to an IoC container is the Bootstrapper. A good bootstrapper can make DI a simple painless exercise that just works, so I thought I’d share mine. It started life with the DefaultNancyBootstrapper from the Nancy project and evolved from there.

It’s available and documented with examples on GitHub here, so I won’t go into it in depth, but I will cover the main aspects I wanted to solve.

Auto Scanning

The DefaultNancyBootstrapper auto registration takes all types from AppDomain.CurrentDomain.GetAssemblies. In some scenarios though this isn’t great, as it only picks up those assemblies that are already loaded. As the bootstrapping is usually done very early in the life of the application it may easily be that the bootstrapping omits many of the types. Any missed then need to be hooked up manually. I wanted to enhance this scanning to require less help.


The bootstrapping needs to be flexible enough to allow the developer control over which assemblies/types are not scanned, and to pass in extra assemblies for scanning which aren’t available for pickup automatically.


The bootstrapping should be configurable across various layers in a more complex system (so maybe a solution wide base bootstrapper, and then specific overrides for MVC/WebApi/Service projects).

After a few iterations I ended up with a nice lightweight solution, which had the configurability I was looking for.

You can see the whole project here, or jump straight to the bootstrapper class here.