Automation is hard! And we are doing it wrong... a talk by Johan Abildskov

Johan Abildskov presented Automation is Hard! at GOTO Copenhagen in 2022 and it popped up in my feed while I was on the pro-leisure circuit.

If you’re on board with the practices discussed in the likes of The DevOps Handbook and Accelerate then it might be a little bit preaching to the choir, but if you’re still figuring out how to improve the stability of your software and the speed at which you deploy it, this is a bloody good talk.

The blurb:

Automation is a key part of any efficiency project and of being a successful software organization. But the way we as an industry approaches automation hinders our success and puts a stop in our track.

In this talk, I will cover some of the ways we set ourselves up for failure, as teams, orgs and engineers. Of course, you will also leave with a few sound practices to address the issues presented.

Monday Links 31

Doom Emacs is “a configuration framework for GNU Emacs tailored for Emacs bankruptcy veterans who want less framework in their frameworks, a modicum of stability (and reproducibility) from their package manager, and the performance of a hand rolled config (or better).” Why it’s named Doom is explained in the FAQ:

As a kid in the Cretaceous period (1999), the source code of idsoftware’s classic Doom was my first exposure to programming. Totally clueless about C and compilers, all I could do was peek at it from time to time and hope I’d absorb its secrets if I stared hard enough. It didn’t work, but it sure jump-started by gamedev addiction.

So “Doom Emacs” was what you got when you combined childhood, demon-carnage nostalgia, terrible naming sense, and the sneaking suspicion that Emacs is the unwritten tenth circle Dante censored for humanity’s protection.

The results of the 2023 StackOverflow Developer survey are up. Nearly half of professional devs are using AI to help them write code.

Hostile Javascript: Attacking And Defending The Browser, a talk by Todd H. Gardener

This great talk from by Todd H. Gardner at NDC London 2023 is a great reminder that we need to be deliberate about assessing what code we allow to run on our websites. My favourite bit is Todd’s realisation that he set out to make a useful targetted debugging tool and accidentally made “cross site scripting as a service”.

Here’s the blurb:

How much JavaScript is on your website? Do you know what it does? No really, have you looked at the code and seen what it does? Probably not.

JavaScript controls the client side environment, and we can use it to compromise users, consume resources, and steal data. Yet many websites continue to add scripts without review, audit, or thought.

Let’s explore what JavaScript can do to a browser, the vectors that JavaScript can get added to websites, and how we can defend against JavaScript attacks.

Monday Links 30

Via Robin Sloan comes Fabien Sanglards deep dive into the engineering behind the Street Fighter II arcade machine and the graph paper and scissors process the team undertook to ensure all their sprites fit inside the tight memory budget.

If the CPS-1 capabilities were a blessing for artists, it was a problem for project managers. In an era where ROM chips were very expensive, a game was allocated a ROM budget at its beginning which it could not exceed.

Before the CPS-1, remaining within the budget was a simple matter of a division. The number of #sprites allowed to the art team was ROM size / rectangular sprite size. But the free form factor introduced a tracking problem.

In order to make the best use of the capacity we had, we wrote the ROM’s capacity on a board, and cut and paste the pixel characters on the board.*

If there was space left on the board, then there was open capacity in the ROM. So, from there we started filling in the spaces, like a puzzle.

I very much enjoyed this short episde of the Bike Shed podcast where Daniel Nolan talked about why he likes working and fixing up existing software:

I don’t want to just know what a quick fix is or something like that. I want to actually get in. I want to read this, you know, like, an example, like, a gem that won’t upgrade, like, I want to go dive into that source code. I want to see what the source code is doing. I want to figure out the why, you know. I don’t want to just Google for, like, hey, I can’t upgrade this gem. What do you think I should do? So I’ve always been super curious. That’s how I’ve been able to sustain in software development and not really get burn out. It’s what makes me tick.

Doom meets House of Leaves in MyHouse.wad

Do you have a couple of hours spare to watch someone else play Doom II? This video is worth it.

A few weeks ago an innocuous post on the Doomworld forums announced the release of MyHouse.wad. Players expecting to find a basic 90s-style level of a suburban home instead found a conversion of the game that pushes the engine to its limits and creates an experience much more like the novel House of Leaves than your typical run and gun Doom experience.

There’s something to be admired about the time, effort, and skill that goes into creating works of art like this with old-school tools.

(via myhoye on Metafilter)