Ghost was never really set up to run on Azure though, and there's always been a number of hoops to jump through to make that work. My original solution was a fork of Ghost's code and the default theme with the tweaks I needed to get it running and add Disqus and such to the theme. I had this set up to auto-deploy from Git to an Azure webapp... but of course, over time, I fell behind updating from the upstream repo and my blog grew dusty.

What I wanted instead was a more lightweight approach: I didn't want the hassle of repos or manual code updates. A containerised solution made sense, but I didn't want to have to deal with managing docker hosting infrastructure either. What would have been ideal was a simple container deployment, with storage mapped out to the cloud so the data is properly persistent.

Say hello to Container Instances

Container instances are a relatively recent addition to Azure's service. They allow for lightweight containerised deployments with the bare minimum of configuration. In my case, I could deploy docker containers necessary for my blog hosting with just a couple of files and minimal configuration: all of the deployed containers are straight from the public registry, and configured through mapped volumes and environment variables. Future updates will be straightforward since I can simply redeploy the configuration to pick up the latest, updated, images.

The deployment can be specified as JSON or YAML - I used the latter as was more lightweight. I also needed a simple Nginx config, and a few Azure file shares for the data persistence.

Annoyances first

So, bad news up front. The first big issue I ran into was that, for unknown reason, the Ghost container doesn't like writing its database to an Azure file share. It can create an empty database, but the migrations always throw a MigrationsAreLockedError and I couldn't get around that (either with MySql or SqlLite). I dug around this for a while to no avail, and eventually settled on running a dedicated MySql container, which worked fine with the mapped file share.

The other problems I ran into all have one root cause: Azure file shares don't support links. Ghost's theme handling relies on creating links to function (at least in the Docker container). The same goes for Certbot, but more on that later. The solution to these is, unfortunately, to leave some non-critical data (like my blog's theme) in volatile storage on the container.

Prerequisites

The first step is to create a storage account in Azure and add some file shares to it:

• one for the nginx config
• one for the MySql database
• one for the Ghost image files

You'll need the account name and key for accessing the shares; you can find those under "Access keys" in the storage account's settings in the Azure portal. You'll also need a way of pushing files to the shares - either the Azure Storage Explorer or the Azure CLI.

Nginx is going to need a config file for the site. A simple one will forward all of the public HTTP traffic to the Ghost container's port, and looks like this:

server {
  listen 80 default_server;
  listen [::]:80 default_server;
  server_name puzey.net *.puzey.net;

  location / {
    proxy_pass http://127.0.0.1:2368;
    proxy_set_header    Host                $http_host;
    proxy_set_header    X-Real-IP           $remote_addr;
    proxy_set_header    X-Forwarded-For     $proxy_add_x_forwarded_for;
  }
}

You can see that the Ghost container will be addressed as localhost, as are all containers in the group, but on its own mapped port, which is not available publicly. This file should go in the nginx file share.

The deployment file

Now, we need the container instance Yaml file. I'll go through this in stages - but everything in this section should be in a single file.

First, some boilerplate:

apiVersion: '2018-10-01'
tags: null
type: Microsoft.ContainerInstance/containerGroups
location: southuk
name: your-container-name

You can set the tags, location (i.e. the Azure region) and name to whatever suits you.

Next, we'll define our Azure file shares as volumes, and configure the public network profile:

properties:
  osType: Linux
  ipAddress:
    dnsNameLabel: someDnsName
    type: Public
    ports:
    - protocol: tcp
      port: 80
  volumes:
    - name: nginxconfig-volume
      azureFile:
        sharename: nginx-share
        storageAccountName: myAccountName
        storageAccountKey: myAccountKey
    - name: ghostdata-volume
      azureFile:
        sharename: mysql-data-share
        storageAccountName: myAccountName
        storageAccountKey: myAccountKey
    - name: ghostimages-volume
      azureFile:
        sharename: ghost-images-share
        storageAccountName: myAccountName
        storageAccountKey: myAccountKey

Setting the dnsNameLabel makes your site available at a url of the form someDnsName.uksouth.azurecontainer.io , which can be useful since subsequent redeployments might not reuse the same IP address. The details three volumes should match those of the storage account.

Now, we can define the containers. These are nested within the properties key, so be careful with the indenting if you're copying directly from the post. The first container will be the MySql database:

  containers:
  - name: mysql
    properties:
      environmentVariables:
      - name: MYSQL_ROOT_PASSWORD
        value: this_is_required_but_will_be_overwritten
      - name: MYSQL_RANDOM_ROOT_PASSWORD
        value: yes
      - name: MYSQL_USER
        value: some_other_user
      - name: MYSQL_PASSWORD
        value: some_other_password
      - name: MYSQL_DATABASE
        value: some_database_name
      image: docker.io/mysql:5.7
      ports:
      - port: 3306
        protocol: tcp
      resources:
        requests:
          cpu: 0.5
          memoryInGb: 0.5
      volumeMounts:
      - mountPath: /var/lib/mysql
        name: ghostdata-volume

Note that listing port 3306 in the definition maps that port to localhost for other containers in this file, without exposing it publicly. (Only the ports specified earlier are public). The Azure file share is mounted here so that the database writes into persistent storage, instead of keeping all our data within the container. Specifying the MYSQL_DATABASE environment variable means that the specified database will be created, with the defined user as admin.

We need Ghost itself, configured to use the MySql database:

  - name: ghost
    properties:
      environmentVariables:
      - name: url
        value: http://your_url_here
      - name: database__client
        value: mysql
      - name: database__connection__host
        value: localhost
      - name: database__connection__port
        value: 3306
      - name: database__connection__user
        value: your_db_user
      - name: database__connection__password
        value: your_db_password
      - name: database__connection__database
        value: your_db
      image: docker.io/ghost:3.0-alpine
      ports:
      - port: 2368
        protocol: tcp
      resources:
        requests:
          cpu: 0.5
          memoryInGb: 0.5
      volumeMounts:
      - mountPath: /var/lib/ghost/content/images
        name: ghostimages-volume

There are a few things to note here.

• If you make the URL https: here (regardless of whether Nginx is set up to serve it), the Ghost container seems to get in a tizzy because it can't serve over SSL itself, and nothing works. The solution to this looks to be using Nginx to redirect, but this would mean every link on the blog is http: and then returns a redirect, which is horrible. That's not the only problem with SSL anyway, so it's moot (see later!).
• The database user obviously should match whatever is configured for the MySql container.
• The Azure file share is mounted so that any images uploaded to the blog are written to persistent storage outside of the container.

Finally, we need an Nginx instance to serve everything:

  - name: nginx
    properties:
      command:
      - /bin/sh
      - -c
      - while :; do sleep 6h & wait $$!; echo Reloading nginx config; nginx -s reload; done & echo nginx starting; nginx -g "daemon off;"
      image: docker.io/nginx:mainline-alpine
      resources:
        requests:
          cpu: 0.5
          memoryInGb: 0.5
      ports:
      - port: 80
        protocol: tcp
      volumeMounts:
      - mountPath: /etc/nginx/conf.d/
        name: nginxconfig-volume

Here, we map in the Azure file share that contains the config file. This means Nginx will actually serve the file. The port 80 exposed here is also exposed publicly, so the outside world can request the site over HTTP and Nginx will handle it.

The fiddly-looking command property means that Nginx will reload its configuration every 6 hours. That means that if the site configuration needs updating at any point, that can be done by simply uploading a new .conf file to the Azure share, and Nginx will pick it up at the next reload - rather than having to restart the container.

A note on resources

Each container has to specify a CPU and memory resource request. The sum of all these requests is what will be allocated to the container group as a whole, but each container can grow beyond its individual requested amount. So, with the definitions above, Azure will allocate 1.5 CPUs and 1.5Gb of memory to the cluster, and if Nginx and Ghost only use 0.1Gb each, MySql can fill the remaining 1.3Gb.

These resource requests will also be the major factor in the resource charge, so it's worth bearing this in mind!

Deploying

Deploying the whole thing using the Azure CLI is a doddle:

az container create --file .\my-def.yaml --resource-group some_group

Make sure that the resource group name is one that already exists (or create one before running the above).

Initially on deployment you'll likely see that the Ghost container falls over and is restarted once or twice, while the MySql server spins up, but you should then see it running cleanly. The Azure portal lets you view the status and logs of each container in the group and (where possible) you can also launch a shell in the container to poke about if there are any issues.

What about HTTPS?

My earlier hosting was a standard Azure WebApp, and I had set up the Let's Encrypt Azure Extension in order to handle SSL. This was working nicely (and I still use it for the other sites that I host)... but this isn't an option with Container Instances.

There's an obvious solution though: Let's Encrypt provide CertBot, which is a nice black-box dollop of cleverness that takes care of it all for you. There's even an official Docker image for it that should help in situations like this.

So, here's the theory: the CertBot container calls Let's Encrypt and request certificates for a configured list of domains. In order to authenticate, it has to serve back some challenge files from the domain in question, which LE will request over HTTP. (The alternative is DNS validation, but this would require me to hook things up outside of my container deployment, and I'm trying to avoid that.)

This is accomplished via another couple of file shares, mapped into both to the CertBot container and the Nginx container. This allows the challenge files and certificates that CertBot uses to be served by Nginx, requiring only a simple tweak to the .conf file and the deployment YAML.

The problem is that once Certbot has the certificates, it uses a symlink to point at the latest requested cert. (This lets it keep a history of issued certs, but have the "live" one always at the same place.) Since the directory in question is mapped to the Azure file share, the link fails. I can get the certificates for my domain, I just can't serve them automatically.

I'll be looking into this again at some point in the future, but for now I'd rather my blog was live and updated without HTTPS than languishing further while I figure it out.

Thoughts and feedback welcome!

This is the problem I was faced with when building The Signal From Tolva. The builds would take hours and it was the OC bake causing issues.

I should pause to explain what I was doing in full. I value automation: it reduces risk, reduces effort, and makes it simpler for anyone to run a given process if the need arises. (In practise I run all of the builds, but the scripts I created mean that anyone could run a build if needs be. Always reduce the bus factor.)

A good build process should be consistent, fast, and assume as little as possible. In practise, the latter means that for things like occlusion culling (where the data you build with should be based on the latest state of the game), you want a fresh bake to run as part of the build process. If you don't do that, you risk building with out-of-date occlusion data (which could lead to objects popping in and out of visibility for no apparent reason) or with no occlusion culling at all. Neither of these are good news, so the build bakes every time.

The problem was that, after a couple of builds, the process slowed to a crawl. Unity would hang for 2+ hours, and the IDE log was always in the same place: at the end of the occlusion bake, after the line INFO: Checking cache... was written. Nothing else was output during the hang and, after the delay, the build would complete as normal.

Even asking a Unity dev about this yielded no results: it's middleware, and apparently nobody knew. So I delved deeper with SysInternals Procmon and worked out that the OC bake builds a cache of files every time it runs.

This cache sits under Library/Occlusion in the project folder, and (on my machine after a handful of builds) had hundreds of thousands of files in it. Presumably these were stale cache data from previous bakes; it's not clear what the process is doing checking a cache after it completes, but I had a hunch that scanning 500k files wasn't going to be a fast process.

The solution from this point was as obvious as you'd expect: the build script now deletes that folder before it runs the OC bake (the first time it ran, it took half an hour just to delete all those files!). Our automated build runs in a few minutes, as it should. And I get two hours' extra work done on build days!

It seems I just took part in my first ever game jam and, to my surprise, I made something actually playable.

Thanks in huge part to the artistic and audio wizardry of John Roberts and Nick Dymond, the screenie above was actually only the halfway point and totally fails to capture the madness of what was, in the end, a "who-can-do-random-combos-fastest" game.

We started off with loftier ambitions that included cats, but for once common sense prevailed over scope-creep and we managed to polish the core idea to something that has kept a few people playing for the last couple of days.

Being the *ahem* professional that I am, I pushed the game code and assets thorugh Git, and you can check out the game itself, all of the code and assets, and the occasionally spurious commit history in the repo here. It's a game written in Unity3d (v5.3 for those interested); it's local 2-player only, and requires two XBox controllers to play.

(If someone really wants to patch it for cross-platform or controller capability then please be my guest! ;-))

All in all, this was a fantastic weekend, and I look forward to my second jam with some anticipation!

So, today's useful snippet, after too long debugging a related issue: if you have an Awake() method on a MonoBehaviour in Unity, and that method throws an exception that isn't handled, the component in question will be automatically disabled. on startup.

It turns out that tracking down why something has been disabled or enabled in Unity is quite tricky - even if you add the OnDisable() method to the component, there's no callstack or passed-in information that lets you work out what happened.

A story of how fixing warnings broke all my code. It's all very well obsoleting this stuff, but you have to make sure it's still compatible...

At some point during the 4.x cycle, Unity switched the way that a GameObject is activated and deactivated in a scene at runtime. Previously, there was a boolean .active property, and a method called SetActiveRecursively() that could be used. This leads to some confusion: if I set a.active = false then what is the state of a child of a? Assuming that all children of a are automatically disabled too, what's the purpose of SetActiveRecursively()?

The recent change obsoletes the original members and adds a single place to change state: the SetActive() method. This new method sets the state only on the current GameObject but, as expected, all descendant objects are automatically disabled. Two readonly properties can be queried to examine the active state of a GameObject: activeSelf will return the value set through SetActive(), where activeInHierarchy will return true only if the GameObject and all of its parents are enabled. It's possible therefore for activeSelf to be true even though activeInHierarchy is false - when a parent object has been disabled - and in this case the GameObject is disabled in the scene.

This is a Good Thing: it makes the API much clearer and more intuitive. However, it's not quite backward compatible, as I found out after tidying up some code.

I'd addressed some compiler warnings by replacing some obsolete SetActiveRecursively() calls with SetActive(). Suddenly, things went awry: runtime errors spewing through the console. My "quick tidy-up" had broken everything! What had happened is that SetActive() isn't a drop-in replacement for SetActiveRecursively(), even though the compiler warning suggests the switch.

When you call SetActive(), the change in value doesn't take place until the end of the current frame. With the old methods, the change would happen immediately. This coul be a hugely important distinction because, in my case, the following line of code was a call to GetComponentInChildren - which explicitly only returns components from active GameObjects. The call was returning nothing, because the object wasn't going to be active until the end of the frame.

The available solutions were to introduce a frame's delay (which gives a whole slew of new problems), switch the call to GetComponentsInChildren (which has an override that will include results from inactive objects, but that can get messy in a complex scene), or continue using the obsolete call. For the sake of not breaking existing code, I had to stick with the obsolete call.

This highlights why backward compatibility in an API can be massively important - and why it's doubly important to have the behaviours of a public API well-documented: subtle changes can have huge effects!

One of the issues that you can run into when developing with Unity is that logging is quite expensive. It's entirely possible, if you're trying to log a verbose amount of processing for one reason or another, you can end up crippling the framerate of your game. There are performance investigations I've done in Unity that have ended up with the logging being the most expensive portion of the code!

The problem with this is that it's often painful to remove and reinstate logging code repeatedly: logging is useful, so you don't necessarily want to remove the code, but you can't have a performant build with it still in place.

With that in mind, I've just published this Gist on Github. It's a first-pass for something that will reduce the performance impact of logging in game builds, and make it easier to control. Here's the code - read on for the details:

This code makes less logging calls when compiled as a release build, because the Verbose methods are removed at compile time. They simply don't exist in your builds.

This class also integrates string.Format capability into the logging methods' signature.* This brings another speed advantage: if the logging method isn't called, the string.Format isn't evaluated at all. It's surprising how much CPU time you can spend on string manipulation for strings that aren't going to be logged: this code prevents that waste.

The plan going forward is to add code so that the standard Message call is only handled (on release builds) when a command-line parameter is present. This means that, for a typical build, you'd only log warnings and errors. Imagine how much log output - and thus performance - this could be saving...

To go with this, I'd recommend a more advanced console than the one built in to Unity. I use Editor Console Pro, which gives me custom highlighting, filtering and more detailed call stacks. It has the occasional glitch, but the ability to quickly search and filter logs for the things I'm interested in can save so much time that it's easily forgiven then occasional hiccup.

I hope this proves a useful tool - please leave a comment if you find this helpful, or if you have any questions!

* If you're "adding" strings together instead of using string.Format then you really need to change that!

Or: why micro-optimising games code often helps.

I was part of a conversation on Twitter that started with a question about the relative performance of calling .GetComponent<T>() vs having a public field assigned in the inspector. I linked back to my earlier post that includes a profiling script for Unity prefabs.

In a followup to those tweets, I was asked "should I care about optimising this code if it's 0.001% of my CPU budget?" My response was "generally no," but that conversation leads me to note this more subtle point about the performance of games code.

If you're from a typical "business" programming background, writing data processing and big websites and such, you learn specific things about optimisation. Don't do it prematurely: there's no point optimising what isn't slow. Don't micro-optimise: saving a millisecond on one line of code isn't worth it when there are minutes to be saved elsewhere. The first point is still absolutely true in games but, for the second point, what constitutes "micro-optimisation" is a very different beast.

The reason for this is that most code will run in the main game loop, which runs every frame. Much code will also be run multiple times within your scene. This makes trivial wins potentially huge in terms of performance.

As an example, let's say we have a particular game agent (an NPC) and that agent has a piece of code (an AI logic routine). Assume there are 20 agents active, and our game currently runs at a paltry 20fps. This piece of logic is already running 400 times per second. That is a huge factor that makes any gain an order of magnitude better than it seems.

Imagine we can shave half a millisecond off the execution time of that code. It doesn't seem like much... except we've saved that 20 times per frame, and our frame is currently taking 50ms to complete. We've just chopped 10ms - twenty percent - off the frame time. That takes the FPS from 20 to 25, with what could be a one-line change.

The beauty of this is that the faster a game already runs, the more these tiny optimisations help, because they represent a larger percentage of the frame's CPU time. If we're running at 30fps to start with (as opposed to 20), shaving off that same half millisecond would take us up to just under 43fps.

The basic approach to optimising doesn't change: profile first, and the attack whatever the worst offender is. The difference with games code is that, often, the worst offender is a tiny piece of code that just happens to be running hundreds of times a second.

That one-line micro-fix can make a massive difference.

NOTE: This post is a direct copy of a reply I made on Facebook a little while back, to a friend who was panicking about the new Facebook messaging app based on this overreactive piece.

Lots of alternatives to FB exist (Google+, MySpace, MSN, etc.), but none are as widely used, and ultimately they all have pretty much the same privacy rights. The price we pay for being able to use all this stuff for free (and it is an immense amount of technology & resource that powers a platform like Facebook) is that to a greater or lesser extent we are the product - they make their money from what they learn about us, and the advertising revenue that information can generate. The article/petition is an overreaction to a minimal change in the situation that has existed for years with Facebook's T&Cs (Snopes' response is much more reasonable!).

I would rest assured that the app will not make calls or take photos without your permission (there would be a much bigger uproar than this if it did!) - but it has to request permission to use the camera/your contact list/etc in order to function usefully. The emotions experiment that James mentioned is no different to what every commercial website in the world does: an experiment with new features that shows one thing to 50% of users and something else to the rest, to see what produces the desired result. This testing (called A/B testing, see here http://en.wikipedia.org/wiki/A/B_testing ) is commonplace but, when Facebook/Twitter/etc. do it, it generates panic.

Ultimately, anything you put on a shared service like Facebook or Twitter or otherwise is to some extent "no longer yours" - but most privacy is an illusion these days anyway. If you use a credit/debit card, store loyalty card, mobile phone, any website at all (even without signing in), you are already being tracked, and this isn't really any different.

Facebook have access to everything you post on the site, but they're not "reading it" in that there's no person staring at your every status or photo - but they are almost certainly running a program that scans all your statuses and reports "hey, we should show this person more nappy adverts because they're always talking about babies," and automatically analyses photos for obvious obscenities, and suchlike.

I would say: carry on using what you're using, be aware of the privacy settings (i.e. make sure you know who you're sharing with), and ask a friendly geek if you have any deeper concerns. Most stories like this are panic-mongering - and often they're doing it because it's the most likely thing to get you to click their link, and earn them some advertising revenue. Cynical, I know, but true.

Last week at work I ran a short brown bag session at work on Unity3d. Whilst my office job (with a HR/payroll systems provider) doesn't have much use for 3d games technology, my team were all very enthusiastic to get an overview of games development .

I covered at breakneck pace some of Unity's basic functionality, and how/where you can add your own code to get things running. Starting from scratch and using the stock asset bundles, I put together a quick (and boxy!) FPS scene with a working gun and destroyable barrels.

I did practise-run for this in a Bitbucket repo that is publicly available here. The code there is almost exactly what we ended up with in the session in less than an hour. Right now it's provided without documentation, but if people are interested then I could sanitise my brief notes into something vaguely useful...

I've been pretty quiet on the musical front of late, but I have three gigs with three different bands coming up and - in an unexpected twist - these are open to public consumption! So, feast your eyes on this list and then, if something takes your fancy, come feast your ears too!

• Doctor Chocolate @ The Thunderbolt, Bristol, Friday July 25th. 9-piece party band playing a mix of tunes from the '60s to the '10s. I used to play regularly, but this is a rare dep appearance for me (and an even rarer public gig from the Chocs!). £5 on the door.
• Mango Factory @ The Old Duke, Bristol, Saturday July 26th. Currently my main gig, this is a fantastic mix of funky tunes with a bit of latin influence thrown in. Addictive horn lines, soaring vocals, and lots of grooves - all original tunes that you can't help but dance to. Come on down and hear me playing my favourite music! Free entry.
• Monkey Chuckle @ Be.In, Bristol, Saturday August 9th. Described by Craig Charles as having "superb tight arrangements and a real sense of urgency, all you need a great funk band to be," I'll be depping a couple of gigs with Monkey Chuckle in the near future. Come catch the first one and find out whether I can keep up with them!

The Mangos are playing again on August 30th at The Old Firehouse in Exeter (home of excellent pizza!), and on September 19th at the Grain Barge in Bristol. I also have a second dep gig with Monkey Chuckle on August 23rd at the Landmark Theatre in Ilfracombe.

So, plenty to choose from - please come along!

I've just enabled Disqus comments on the site: now this at least has a chance of being a two-way conversation!

It was a trivially easy thing to get set up, made even more so by the provision of specific instructions for getting Disqus running on Ghost. I'm not sure I can add much here other than to say that I'm very mmuch liking all the software I'm running here!

Over the next few weeks I'll slowly pull the site into some semblance of designed order... keep watching!

Over the last couple of days at work, my Git started to play up: every time I tried to interact with the remote repo (for a fetch, push or pull), I got error messages like this:

Failed to erase credential: Element not found

fatal: Authentication failed for https://rhubarb.custard

This continued to happen after a machine restart, and affected everything from git-bash to Posh-git to SourceTree.

It turned out that I had Git Extensions installed, which includes a credential helper. I hadn't realised, but that helper was remembering my login for the Git repo, so I didn't need to enter it each time. Somehow, the helper had apparently got snarled up and wasn't working correctly.

It's enabled through the following lines in the .gitconfig file:

[credential]
  helper = !\"C:/Program Files (x86)/GitExtensions/GitCredentialWinStore/git-credential-winstore.exe\"

I removed those lines from my .gitconfig and ran a fetch: I had to enter my credentials, but it worked! I then readded the same lines, and fetched again, and my Git was back working just as before.

Hopefully this might help someone else with the same problem - despite lots of search hits, there was no advice that referred to problems with an existing repo.

As part of my ongoing involvement with Big Robot I've been doing a bit of work recently on working out "how best to do things" in Unity3d. Some of the output of that might turn up in a later post, but, since this is my first post in a looong time, I thought I'd break myself in gently.

Part of what I've been looking at is what I'd call "general performance issues;" that is, "how should I write a typical bit of code in the most performant way?" Rather than testing by gut, I wanted some reusable code that would help me get genuine results, and so I created a class that would let me profile code running in a scene at a prefab level.

The way it's intended to be used is this:

1. create a scene, and add a single gameObject
2. add the benchmarking component to the gameObject
3. drag a prefab from your project into "Prefab Under Test" in the inspector
4. run the scene (or run a build, if you want more real-world results)

What you'll see is a long pause, and then console output with the test results; something like this:

PERFTEST: initialise 0.04875484s; run 1.685191s (59.34047 FPS).
UnityEngine.Debug:Log(Object)

The test creates a large number of your prefab, and measures two things: the "first-frame" time (which includes the time taken to call Awake, Start and the first Update for every instance), and the time taken for a configurable number of frames to render (which measures just your Update calls).

There's a short (configurable) delay on starting, which ensures that no other startup code is getting in the way of the benchmark, and the instance count and frame count are configurable so that you don't choke your IDE on too many instances.

I've put this on a public Gist in case it's useful. Most likely I'm going to add support to test multiple prefabs in succession, for comparitive testing, but I'm not sure how much of a factor execution order might be in such a test - so for now it's left for each prefab to be profiled as a separate run.

The code in full:

I was poking around my rapidly-filling SSD, wondering exactly what was taking up all the space on my C: drive, when I noticed that the c:\programdata folder was over 2GB in size. That’s not necessarily unusual, except that I’m careful to redirect most applications that would use it to a different drive.

When I looked in more detail, I found that almost all of that 2GB was in one place: C:\ProgramData\Microsoft Visual Studio\10.0\TraceDebugging

That’s where Visual Studio stores its Intellitrace dump files – and it seems it’s not cleaning up after itself! Some of the files were over a year old, and I’m pretty confident there’s no useful debugging to be done with them now ;-)

The VS options allow a maximum size per recording, but it seems they’ll let the overall folder grow without limit. Worth knowing – and worth keeping an eye on if you’re short of disc!