Restoring an old bkf backup file on macOS or Windows 10 (/8/7)

I recently realised I had a load of old projects and data sitting in a lovely 100GB bkf file – generated by the ntbackup program that used to ship with Windows XP and Windows 2008 – but no way to access them.

Microsoft released a restore-only version for 2008 R2 / Windows 7, but there was no version of ntbackup I could find that would run on Windows 10.

There were loads of blog and StackExchange posts but generally pointing to dodgy (and since dead) downloads of ntbackup.exe. I could install Windows XP on a VM, or launch a Windows 2008 R2 instance in Azure/AWS and transfer the files up there, but those felt like a lot of hassle.

Fortunately I found a C based utility on GitHub called mtftar which converts an MTF stream into a TAR based stream, and someone has generously updated it to compile on both Windows and macOS. Great!

I have Ubuntu running under the Windows subsystem for Linux, so with build-essential already installed via apt-get, I ran:

> git clone https://github.com/sjmurdoch/mtftar
> cd mtftar
> make
> ./mtftar -?

Which lists out the various supported command line arguments. I went for

./mtftar < Backup.bkf | tar xvf -

which extracted the bkf archive straight onto the file system in the same directory. The same commands work on macOS, if you prefer to run there.

Retro-fitting remote working

I wrote my last post about remote working on my way to Gran Canara almost 4 years ago. It was the first time I had attempted to work remotely from the team based in London, and the reality was – remote working was really hard!

We aren’t a “remote-first” company, and I knew working with the team when they weren’t used to having to deal with a remote team member was going to be challenging.

Even a slightly flaky internet connection became massively frustrating during calls. Reverse engineering context from discussions that were happening ‘offline’ was a constant challenge. And trying to engage the team in the work I was doing from Gran Canara.

On the plus side, there were no time-zone differences, I met some awesome people, we redesigned the FundApps branding, and I was living one minute from the beach!

However, the challenges of growing a team in person in London were enough that I hadn’t really attempted it since.

How does it look now?

Roll forward several years, and FundApps has grown from 8 to approaching 50, has offices in London and New York, with remote workers in Toronto, Darlington and Auckland.

Now, whether we like it or not, we have to get good at this! It’s still hard, but we’re inching closer to this being a better experience:

  • A decent video conferencing set up. Sounds obvious, but it took us much experimentation to find something that worked for us. We’re now using Zoom and a proper speakerphone that works over USB too. If someone has a dodgy connection, they can join the call by phone instead.
  • If there’s one remote person in a meeting, then everyone joins a call from their desks. We don’t do this for everything yet, but it does level the playing field significantly.
  • Face to face time is invaluable, particularly for new starters. Our remote workers had the advantage of having worked in our office for some time – they knew the team, and the culture. Our recent recruits in New York didn’t have that luxury though, and so making the time for them to visit London, and their colleagues visiting New York to build those relationships have been super valuable.
  • Increase signal to noise. We’re trying to separate discussion from actual decisions so it’s easier to keep track of what’s going on – we’ve had some success using dedicated project channels in Slack (for chat), while ensuring core decisions are recorded more explicitly in GitHub or Google Docs.
  • Preferring async communication, if you have team members working on different time zones – try finding a time that works for folks in Canada, London and New Zealand for a call!

Simple catch-all AWS budgets

We got caught out recently by significantly high usage of AWS CloudWatch, and realised we’d been spending $1000/month more than expected. After tracking down the cause (one of the team had turned on detailed instance monitoring) – I wanted to ensure we had a bit more of a heads up next time. We had budgets set for all the major services, but not the ‘small’/insigificiant ones.

The really simple (and in hindsight, obvious!) solution was just to create a ‘catch all’ budget for all the services we didn’t have a seperate budget for, even if we’re not currently using them:

I’d probably move this to terraform next, but this works well for us so far.

BeyondCorp proxy possibilities on AWS, Google Cloud, Azure

It appears there’s now another tool in the arsenal for those looking at implementing BeyondCorp style security model, with the arrival of OIDC authentication support in AWS’s application load balancer. It adds to a growing list of possiblities, at least for HTTP-based services. Who needs VPN anyway?

The options I’m aware of now include:

  • Bitly’s oAuth2 proxy – a simple open source reverse proxy with OAuth support, written in Go
  • Amazon Application load balancer – will allow you to offload authentication to a seperate IdP, and then passes claims via HTTP headers to the proxied application.
  • Google Identity-aware proxy – though this only works if the services you are securing live within the Google cloud
  • Azure AD application proxy – Microsoft’s answer to the zero-trust model, with a lightweight proxy that sits within your internal network enabling outbound connectivity to the proxy rather than inbound.
  • CloudFlare access – hosted reverse-proxy with support for major identity providers like Azure AD and Okta
  • ScaleFT – commercial zero-trust platform for securing HTTP based web and SSH based server access, with a high entry cost (starts at $500/month)
  • Pritunl Zero – a freemium SaaS service offering HTTP and SSH based proxying.
  • DuoBeyond

Any others I’m missing? Would love to hear of folks experiences of these.

Not ready to #DeleteFacebook? Here’s some baby steps…

I admit it. I still haven’t taken the plunge to #DeleteFacebook. I can’t remember the last time I posted anything on it, but friends still invite me to events and send me messages via Messenger. Likewise, I haven’t brought myself to using VPN as standard, or Tor for that matter!

That said, here’s some things you might like to try, that have stuck for me. Let me know what else I’m missing!

Use Firefox, and enable first-party isolation. This isolates cookies so that only the site which you were accessing when the cookie was ‘dropped’ can access it, making it harder for folks like Google and Facebook to track you across multiple sites. If you can’t quite quit the Google Chrome habit, try installing the Privacy Badger extension instead.

Switch to DuckDuckGo for your search. If you’re giving Google everything you’re searching for, you’re just making it easy. While you’re at it, review your Google privacy settings.

Consider changing your DNS to 1.1.1.1. It’s not perfect — you’re trusting CloudFlare rather than your ISP or other DNS provider with your privacy, but it seems like the best of a bad set of options for now. Limitations in other aspects of internet protocols like SNI, and the fact IP addresses themselves can identify the site you’re accessing means this will unlikely to be completely anonymous for the immediate future.

Consider disabling Facebook Platform. The horse has definitely bolted the stable door, but at the very least it’s worth reminding yourself exactly who your data has already been shared with…

Unfollow all your Facebook friends. This does nothing for your privacy, but wonders for your time. My feed is empty — but I can still check up on individual friends when I think of them, and they can still invite me to events.

Are there other habits you’ve successfully changed to increase your privacy online? Would love to hear them!

Exploding cows in Minecraft…

Last weekend I was at Womad festival, helping kids fire exploding cows from catapults in Minecraft. Not my usual line of work as CTO, or typical festival experience for that matter!

I was volunteering with Devoxx4Kids who organise events worldwide where children can develop computer games, program robots and also have an introduction to electronics. CERN had invited Devoxx4Kids to take part in the workshops happening at the Physics Pavilion.

We ran 3 packed out workshops across the weekend, with children ranging from about aged 6 to 13. While there was a whole range of knowledge levels, almost everyone was familiar with Scratch — and they most definitely knew far more about Minecraft than me!

Warm up before a session!

The workshops involved writing some Java using Minecraft Forge and Eclipse in order to introduce a catapult into the Minecraft world, understand the impact of angles on how far the catapult could fire, and ultimately throw some surprisingly explosive animals!

As volunteers, we were split around 50:50 between those that had a technical background or not — it wasn’t about showing off our own technical knowledge — more asking questions and helping the children stay on track with the activity. A particular shout out to Cesar and Dan, whose hard work meant the rest of us could just turn up on the day!

It was humbling to see how well our attendees all tackled the challenge — their thoughtfulness on variable names for their animal of choice, and somewhat more destructively, delight at changing how big an explosion to create when it landed!

While it was only a small taster, hopefully it reinforced the realisation (for both parents and children!) that by coding they can actively change the world they experience in these games, and perhaps continue to grow an interest in technology.

This document has been composed with the free HTML edior. Click here to give it a try.

Licensing SQL Server in AWS? It’s up to twice as expensive as Azure or Rackspace Cloud.

… and regardless of cloud provider, it’s (probably) costing you 2x what it would on dedicated kit. So AWS could be costing you 4x what it would cost to license on dedicated hardware.

Disclaimer: I am certainly not a SQL Server licensing expert, nor that much of a cloud expert. The purpose of this post is to hopefully prove that I am, in fact, wrong. Please help with this!

Anyone that’s ever head to deal with SQL Server licensing (or indeed any kind of Microsoft licensing) knows what a minefield it is. In the public cloud, all your worries go away (ahem) and you can just wrap the license fee in the monthly cost via the hosting providers “service provider license agreement” with Microsoft.

Looking into it further, however, I realised there are actually big discrepancies between how much the different cloud providers charged you for licensing SQL Server itself.

Microsoft Azure: $75–80/core/month
Rackspace Cloud: around $100/core/month
AWS: anything from $136 to a $236/core/month

In other words, your costs to license SQL Server could be 2x higher than Azure or Rackspace Cloud, and 4x higher moving to AWS cloud from dedicated hosting (see dedicated vs cloud).

At the moment, I have no good explanation for this. I’m still waiting for a response from AWS, and I’m hoping that I’m missing something here.

To head off the obvious — I realise there are databases with more cloud-friendly licensing. Unfortunately real life gets in the way, so we’re stuck with SQL Server until we can migrate away from it.

AWS, Rackspace Cloud & Azure compared

If you’ve got this far, I’m assuming you want some detail, so here goes.

Assumptions

  • I am ignoring platform as a service offerings entirely (so SQL Azure, RDS you’re out)
  • I am only looking at SQL Server Standard
  • I am only considering SQL licensing costs, not the cost of the underlying hardware. For cloud providers that don’t explicitly state a licensing cost (only Azure does this), I’m going to take the cost of a Windows VM with SQL Server on it and subtract the cost of a Windows VM.
  • SQL Server is licensed per core, so I’m going to group these calculations by core
  • I’m just looking at monthly pricing with no commitment, as that’s how we’re currently paying for our dedicated kit too.
  • Rackspace has different UK pricing in GBP, but I’ve spot checked the numbers and there was no material difference from their USD pricing, so we’re just going with that.
  • I am looking at prices for Europe-based data centres, in USD. I haven’t checked but I don’t expect this varies significantly from the US
  • I am assuming 730 hours in a month

Data sources

I have taken the prices from these locations: http://www.rackspace.com/cloud/public-pricing http://azure.microsoft.com/en-gb/pricing/details/virtual-machines/#Windows, http://azure.microsoft.com/en-gb/pricing/details/virtual-machines/#Sql, and http://aws.amazon.com/ec2/pricing/ (as of 22 Jan 2015).

Medium isn’t the best place for displaying tabular data, so I’ve included an image below, and you can download the spreadsheet here.

Azure is the cheapest, working out around $75–80 per core (regardless of VM, as they list their SQL prices separately). I’m assuming this is essentially cost price, as I’ve been told elsewhere that a 4 core license via the SPLA scheme is generally $300/month. Not surprising, given it’s Microsoft licensing their own product.

Rackspace Cloud is more expensive, but very consistent, working out between $100 per core (regardless of VM), so a 25% markup. As a note of comparison, on our dedicated kit, we pay £420/month for a 6 core license, which works out at £70/$106 USD so this is consistent.

AWS is the big surprise here, with prices ranging anything from $136 at it’s cheapest to $236 (m series followed by r series, followed by c series). That’s a whopping 70%-195% markup.

Cloud vs Dedicated

I mentioned earlier another price differential moving to cloud. Regardless of which cloud provider you’re using, SQL Server will (probably) cost you 2x what you’re paying for dedicated kit. That’s because SQL Server licensing ignores hyper threaded cores (PDF) on dedicated kit, but not on virtualized kit, assuming you are only licensing the VM and not the host itself. So if you’re running in a virtualized environment with hyperthreading turned on (Azure, AWS, Rackspace Cloud, for instance), you have two virtual cores for each real processing core, and so you’ll need to pay for twice the number of cores to get the (vaguely) equivalent performance.

Wrapping up

Like I said at the start, I’m no licensing expert, but given the already painful SQL licensing costs, seeing the huge differences we’d be paying in AWS vs other cloud providers is a hard pill to swallow. Please let me know if you spot any mistakes in my calculations!

It would certainly push us away from SQL Server even faster than we were planning, but in the meantime… would be interested to hear any insights as to why there are such big variations and such a huge markup at AWS!

Starting a remote working journey

Today I head to Gran Canaria for a month. Not for holiday, but to work. I’ll be leaving my friends and work colleagues back in London, whilst trying to convince them that this isn’t all about sitting on a beach and surfing all day long.

I’ve always read with admiration and a fair dose of jealousy the stories from various digital nomads around the web. Free to go where they will, work as they please. And yet I’ve never felt able to take the plunge.

While I’m only dipping a toe in to start, this is as much a company challenge as a personal one. At FundApps, we’ve grown to a team of 8 so far, all based in London. We want to foster a great place to work, and realise creating a remote-working friendly environment is a big pull for many people (as it is for ourselves). We’re also planning to expand into the US, and so we know we’ll *have* to soon deal with the practicalities of asynchronous working with a remote team in a different timezone.

We’ve grown as a clustered, centralized unit based in London without having to address these kinds of questions up front — so we’re now having to retrofit a remote-friendly culture. Working from home a day or two a week is pretty easy, when there’s still enough in person interaction to cover up any cracks in your approach to remote working. But when you take away that regular in-person contact, all that effortless information you pick up in the office fades away.

How do you make sure everyone knows what’s going on? Feels included? Feels part of a coherent company culture? How do you keep learning and sharing knowledge? How do you hire and interview? On a personal level, how does the reality stack up? How do you replace the personal contact that you’d normally have in the office with colleagues?

I know to do this well will be hard, especially with the rest of the team still being a core coherent unit back in London. But I’m hoping this will be an opportunity to learn a lot — and share the experience, both from a personal standpoint, and as a startup founder.

Onwards! I have a flight to catch.

PS I would love to hear your own thoughts. Do you care about remote working? What have you tried? What’s worked or not? Or what’s putting you off, or holding you back from trying it — either personally or at your company?

Integrating NDepend metrics into your Build using F# Make & TeamCity

NDepend is an analysis tool giving you all kinds of code quality metrics, but also tools to drill down into dependencies, and query and enforce rules over your code base.

There’s a version that integrates with Visual Studio, but there’s also a version that runs on the console to generate static reports, and enforce any code rules you might have written.

I wanted to see how easy it would be to combine all of this and use NDepend to generate actionable reports and metrics on our code base – not just now, but how it shifts over time.

To do this, you need to

  1. Run your unit tests via a code coverage tool, such as dotCover. This has a command line version bundled with TeamCity which you are free to use directly.
  2. Run NDepend with your code coverage files and NDepend project file
  3. Store NDepend metrics from build-to-build so it can track trends over time

I’ve covered step 1 in my previous post on generating coverage reports using dotCover . I recommend you read that first!

We can then extend this code to feed the code coverage output into NDepend.

Downloading your dependencies

I’ve already covered this in the previous post I mentioned, so using the same helper method, we can also download our NDepend executables from a HTTP endpoint, and ensure we have the appropriate license key.

<pre>Target "EnsureDependencies" (fun _ ->
    ensureToolIsDownloaded "dotCover" "https://YourLocalDotCoverDownloadUrl/dotCoverConsoleRunner.2.6.608.466.zip"
    ensureToolIsDownloaded "nDepend" "https://YourLocalDotCoverDownloadUrl/NDepend_5.2.1.8320.zip"
    CopyFile (toolsDir @@ "ndepend" @@ "NDependProLicense.xml") (toolsDir @@ "NDependProLicense.xml")
)

Generating the NDepend coverage file

Before running NDepend itself, we also need to generate a coverage file in the correct format. I’ve simply added another step to the “TestCoverage” target I defined previously:

DotCoverReport (fun p -> { p with
Source = artifactsDir @@ "DotCover.snapshot"
Output = artifactsDir @@ "DotCover.xml"
ReportType = DotCoverReportType.NDependXml })

Generating the NDepend report

Now we can go and run NDepend itself. You’ll need to have already generated a sensible NDepend project file, which means the command line arguments are pretty straightforward:

Target "NDepend" (fun _ ->

NDepend (fun p -> { p with
ProjectFile = currentDirectory @@ "Rapptr.ndproj"
CoverageFiles = [artifactsDir @@ "DotCover.xml" ]
})
)

I’m using an extension I haven’t yet submitted to F# Make yet, but you can find the code here, and just reference it at the top of your F# make script using

#load @"ndepend.fsx"
open Fake.NDepend

After adding a dependency between the NDepend and EnsureDependencies target, then we’re all good to go!

Recording NDepend trends using TeamCity

To take this one step further, and store historical trends with NDepend, we need to persist a metrics folder across analysis runs. This could be a shared network drive, but in our case we actually just “cheat” and use TeamCity’s artifacts mechanism.

Each time our build runs, we store the NDepend output as an artifact – and restore the artifacts from the previous successful build the next time we run. Before this was a bit of a pain but as of TeamCity 8.1 you can now reference your own artifacts to allow for incremental-style builds.

In our NDepend configuration in TeamCity, ensure the artifacts path (under general settings for that build configuration) includes the NDepend output. For instance

artifacts/NDepend/** => NDepend.zip

go to Dependencies, and add a new artifact dependency. Select the same configuration in the drop down (so it’s self referencing), and select “Last Finished Build”. Then add a rule to extract the artifacts and place them to the same location that NDepend will run in the build, for instance

NDepend.zip!** => artifacts/NDepend

TeamCity Report tabs

Finally, you can configure TeamCity to display an NDepend report tab for the build. Just go to “Report tabs” in the project (not build configuration) settings, and add NDepend using the start page “ndepend.zip!NDependReport.html” (for instance).

Hope that helps someone!

Code coverage using dotCover and F# make

I’ve previously depended a little too much on TeamCity to construct our build process, but have been increasingly shifting everything to our build scripts (and therefore source control).

We’ve been using F# make – an awesome cross platform build automation tool like make & rake.

As an aside (before you ask): The dotCover support in TeamCity is already excellent – as you’d expect – but if you want to use these coverage files elsewhere (NDepend, say), then you can’t use the out-of-the-box options very easily.

Downloading your dependencies

We’re using NUnit and MSpec to run our tests, and so in order to run said tests, we need to ensure we have the test runners available. Rather than committing them to source control, we can use F# make’s support for restoring NuGet packages.

RestorePackageId (fun p -> { p with OutputPath = "tools"; ExcludeVersion = true; Version = Some (new Version("2.6.3")) }) "NUnit.Runners"

DotCover is a little trickier, as there’s no NuGet package available (the command line exe is bundled with TeamCity). So, we use the following helper and create an F# make target called “EnsureDependencies” to download our dotCover and NDepend executables from a HTTP endpoint:

let ensureToolIsDownloaded toolName downloadUrl =
    if not (TestDir (toolsDir @@ toolName)) then
        let downloadFileName = Path.GetFileName(downloadUrl)
        trace ("Downloading " + downloadFileName + " from " + downloadUrl)
        let webClient = new System.Net.WebClient()
        webClient.DownloadFile(downloadUrl, toolsDir @@ downloadFileName)
        Unzip (toolsDir @@ toolName) (toolsDir @@ downloadFileName)

Target "EnsureDependencies" (fun _ ->
    ensureToolIsDownloaded "dotCover" "https://YourLocalDotCoverDownloadUrl/dotCoverConsoleRunner.2.6.608.466.zip"
    <code>RestorePackageId (fun p -> { p with OutputPath = "tools"; ExcludeVersion = true; Version = Some (new Version("2.6.3")) }) "NUnit.Runners"

Generating the coverage reports

Next up is creating a target to actually run our tests and generate the coverage reports. We’re using the DotCover extensions in F# Make that I contributed a little while back. As mentioned, we’re using NUnit and MSpec which adds a little more complexity – as we must generate each coverage file separately, and then combine them.

Target "TestCoverage" (fun _ ->

  let filters = "-:*.Tests;" # exclude test assemblies from coverage stats
  # run NUnit tests via dotCover
  !! testAssemblies
      |> DotCoverNUnit (fun p -> { p with
                                      Output = artifactsDir @@ "NUnitDotCover.snapshot"
                                      Filters = filters }) nunitOptions
  # run the MSpec tests via dotCover
  !! testAssemblies
      |> DotCoverMSpec (fun p -> { p with
                                      Output = artifactsDir @@ "MSpecDotCover.snapshot"
                                      Filters = filters }) mSpecOptions
  # merge the code coverage files
  DotCoverMerge (fun p -> { p with
                                Source = [artifactsDir @@ "NUnitDotCover.snapshot";artifactsDir @@ "MSpecDotCover.snapshot"]
                                Output = artifactsDir @@ "DotCover.snapshot" })
  # generate a HTML report
  # you could also generate other report types here (such as NDepend)
  DotCoverReport (fun p -> { p with
                                Source = artifactsDir @@ "DotCover.snapshot"
                                Output = artifactsDir @@ "DotCover.htm"
                                ReportType = DotCoverReportType.Html })
)

All that’s left is to define the dependency hierarchy in F# make:

"EnsureDependencies"
==> "TestCoverage"

And off you go – calling your build script with the “TestCoverage” target should run all your tests and generate the coverage reports.