Conference Talk Ideas

Command line tools such as git and dotnet are terrific assets for building and publishing your applications. We will investigate how they can be used in different situations:

• Using git commands such as git rev-parse, git clean and git describe to improve a build pipeline
• The versatility of dotnet publish
  • Single binary, ahead-of-time compilation and self-contained builds
  • Add commit ID information
• Utility dotnet sub-commands such as dotnet format or dotnet list package --outdated
• Derive version information from a CHANGELOG.md file, automate release commits and tagging

In the last few years I built Chunkyard, a backup tool which combines full and incremental backups while also including features such as copying and validating backups. Chunkyard does not offer anything new that other open source backup tools miss, but it gave me several opportunities to explore topics such as:

• How backup applications with deduplication work
• Cross platform development in .NET
• Testing new language features
• Limit myself to the standard library (e.g. writing my own CLI parser)
• Create a useful and fast testing suite
• Tinker with build and publish automation
• Do tiny performance experiments

Modern backup tools use techniques such as content addressable storage and content defined chunking to create deduplicated and verifiable backups. We will explore how these techniques work and how they could be applied to other areas such as:

• Version control systems
• Application downloader/updater
• Artifact storage for build pipelines
• Verifiable URLs

Some of us are still doing manual deployments to ship software. Let's have a look at a concrete example of a distributed monolith and what we can do to automate its deployment:

• Implement a "deployment configuration" using a templating language, reusable configuration files and scripts
• Generate a "deployment configuration" using different criteria
• Use a package manager like Chocolatey (Windows)

Gamers know that it's a good idea to click "save" whenever they are about to do something significant, risky or stupid. In the same sense developers should "save" (commit) all the freaking time too:

• Feel the power of resets and interactive rebases
• Use stashes, branches and WIP commits for experiments
• Apply partial staging to reflect and review your work
• Use worktrees for some sweet documentation