23 things from 2023 - Part 1: Development

calendar Dec 31, 2023 · 6 min read · 2023 Retrospective Development Git Android

This is part of my round up of 23 things from 2023. The index is here.

1. Git Worktrees

I work on multiple branches of the Unity source code concurrently, for example:

  • New feature A for trunk version
  • Refactoring B of some other code in trunk version
  • Bugfix C in trunk version
  • Back port of bugfix C to Unity 2022 LTS

Switching between branches takes a long time; getting all data from the server (editor, engine, platforms, tools, tests, docs, etc) is quick compared to the time it takes to build the executables, tools and all the internal assets.

Multiple checkouts of the repo allows multiple pre-built versions co-exist on the drive, and is what I was doing - but it’s messy – without care it duplicates Git metadata unnecessarily, and things like merging commits between branches doesn’t work easily.

Git worktrees are a neat solution to the problems. I won’t go into detail here since there are already plenty of good explanations on the web.

2. Git branch naming trick

This goes hand in hand with Git Worktrees when you have a few branches that represent related work.

For example, say I’m working on improvements for Optimized Frame Pacing for Android, Git allows slashes as valid characters in branch names, so I might have these branches:

1* Android/frame-pacing/docs
2* Android/frame-pacing/tests
3* Android/frame-pacing/code

Similar branch names are nice for keeping related work together when listing branches for the repo, but isn’t that big a deal on its own – until you consider what happens with those slashes on disk when using worktrees:

1C:\MySrc/Worktrees/Android/frame-pacing/docs/
2C:\MySrc/Worktrees/Android/frame-pacing/tests/
3C:\MySrc/Worktrees/Android/frame-pacing/code/

The local files for the branches become hierarchically organised on the drive, which is great for reducing the mental load of working on related things.

3. Windows Terminal

I use Windows as my main development OS. Using command line tools is often quicker than using a mouse-based UI to get many codery things done.

For too long I used CMD.EXE after moving on from DOS, then more recently PowerShell and occasionally Cygwin. But swapping between them is a pain, and they each have usability flaws.

Microsoft’s Windows Terminal has some great usability improvements, including obvious basic things like multiple tabs – and the ability to have a different type of shell in each.

https://apps.microsoft.com/detail/9N0DX20HK701

4. Debugging Android crashes with AOSP

In 2023 I did some work with the Android Game Development Kit

Amongst other things, I helped track down a crash that our users reported - frustratingly, not one that can be reproduced locally so I only had the callstack and logs from the user rather than a debuggable test app.

The crash was deep inside an internal AGDK library function, a few levels down the callstack from the last piece of Unity code.

With closed platforms like games consoles or even Windows PC you have to just guess what's happening inside those internal functions (or maybe disasseble the relevant EXE/DLL around the point of the crash) which is pretty tedious (though often still quicker than replies to a support ticket or forum post).

For Android, much of the core OS and libraries are open source (hopefully not news to you if you do Android dev!)

To diagnose the crash I cloned the source code and had a good look to understand what was happening under the hood https://android.googlesource.com/platform/frameworks/opt/gamesdk/

But Google didn't stop there with the openness:

Caveat: Phone OEMs, SoC vendors, Carriers, etc tend to have a bunch of closed-source stuff on the device - so not every Android crash is so straightforward to diagnose.

5. Parsec

My main work machine is a desktop Windows PC. It has a powerful CPU, DX12 capable graphics card, and has other development hardware connected to it.

It’s great, but it’s in my home office, which is away from everything else in the house.

Sometimes I like to work in a different room in the house (warmer, human company, waiting by the door for a delivery, etc), but my aging Macbook isn't as useful as my desktop.

Remote desktop software which can also capture from the GPU is the solution. I tried a few such as Microsoft’s RDP and Google’s Chrome offerings, but in the end settled on Parsec: https://parsec.app/

Graphics intensive things like games, at a high frame rate is a particular speciality of Parsec, which makes it perfect for my needs. I can now happily work on graphics code from any computer in the house.

It helps that Parsec is a Unity company, but that wasn’t my reason for going with it.

6. Hugo

I use the Hugo https://gohugo.io/ static site generator to convert from a bunch of text in markdown format via a theme into the site you see here.

I know enough HTML and JavaScript to do it myself, but life’s too short to code it by hand every time I want to put some words and pictures online.

7. AWS Amplify

In the past I’ve hosted with web hosts that didn’t give much control over the finer details of things like their CDN – so in a bid to learn some more AWS, I went to the other end of the spectrum and self-hosted on AWS with my own S3 bucket, CloudFront, Route53, etc.

It was a lot of fiddling but taught me a lot about the AWS ecosystem in the process. What I didn’t have set up was a CI/CD process – so site updates were manually pushed – I think that contributed to me not updating my site very often.

Enter AWS Amplify. https://aws.amazon.com/amplify

It provides an all in one pre-configured web back end and front end for sites and web apps – it provides post commit hooks for GitHub to make CI/CD seamless and it takes away a lot of the management overhead of the mechanics of a site – whilst still having the ability to fiddle.

What’s more, I was sold by the promise it can recognise a Hugo site and automatically pre-configure itself: https://gohugo.io/hosting-and-deployment/hosting-on-aws-amplify/

Or at least that’s the theory, but the above tutorial is true if you’re using standard Hugo and a simple theme.

The theme I used requires Hugo Extended and requires Go to be available on the instance used to build the site. There’s a lot of outdated or misleading information about how to solve this, which was pretty frustrating – but now it’s set up, I’m pretty happy with it.

For anyone else who has similar problems, here’s my set up.

In Build Image Settings:

  • Amazon Linux:2023
  • Live Package Updates set to latest for Hugo

Then my Amplify.yml:

  • Get the version of Go I need
  • Install Go, removing any previous install
  • Ensure sub-module for my theme are initialised and updated
  • Ensure Go is available on the path
  • Build the site
 1version: 1
 2frontend:
 3  phases:
 4    preBuild: 
 5      commands: 
 6        - wget --no-verbose https://go.dev/dl/go1.21.5.linux-amd64.tar.gz
 7        - sudo rm -rf /usr/local/go 
 8        - sudo tar -C /usr/local -xzf go1.21.5.linux-amd64.tar.gz
 9        
10    build:
11      commands:
12        - git submodule init
13        - git submodule update --init --recursive --depth 1
14        - export PATH=$PATH:/usr/local/go/bin
15        - hugo 
16
17  artifacts:
18    # IMPORTANT - Please verify your build output directory
19    baseDirectory: public
20    files:
21      - '**/*'
22  cache:
23    paths: []