Prodspec and Annealing: Intent-based actuation for Google Production
So, at Google I’ve been working for several years on things called “Prodspec & Annealing”. While we started those for one service, it is now used by a very large chunk of Google production. Prodspec takes care of taking any service configuration and massage it into a clean “Prodspec intent”, representing what is the production supposed to look like from the infrastructure perspective. And those bits are then consumed by Annealing, which takes care of updating production to match the intent. The overall pipeline provides us with a safe continuous delivery (CD) system, deploying things from binary versions to switch firmwares.
And I’ve just written about it in Usenix, thanks to the help of Betsy Beyer, and the good folks at ;login: - Laura Nolan and others.
The article is … a bit long :) It goes in depth into what we did, what works for us and the overall architecture and its philosophy.
Mapshot: Factorio mod to create zoomable renders of the game
Mapshot is a Factorio mod and a companion binary creating zoomable maps of a Factorio game. Click on the image for an example:
A simple Lisp interpreter in Go
I’ve written a simple List interpreter in Go - code is available here. It is a toy interpreter, which had a focus on error.
A small html5 fire effect I did a couple of months ago. As many can recognize, it’s the classical demo effect that was popular quite some time ago :)
Doom levels in Minecraft
A small program I wrote, that I forgot to mention here: https://github.com/Palats/wadcraft
It converts Doom level (.wad) to minecraft format (.schematics)
Here is a demonstration of what it does:
Migrating from an IMAP server to Gmail
I started to configure a Google Apps for domains and I want to cleanly migrate existing mails from my server. The wonderful imapsync does all the hard work. However, to have a clean migration to GMail, you need to have the right flags.
Simple generator of relay recipient map for basic secondary MX
A common problem with a secondary MX server for simple mail domains is the back-scatter spam. The spammer sends a mail to the secondary MX of a domain, using a non-existant username. If the secondary MX is configured to accept everything for the domain (which is usually the case), it will accept the mail and then try to transmit it to the primary. The primary will see that the username doesn’t exists and bounce the message back to the spoofed FROM, hence spamming it.