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.

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.

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.

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)

Chelsea Troy: How do we get a tech team to make a big technical change?

…when individual contributors understand how a system currently works, changes make some part of that understanding obsolete. And the obsolescence of that understanding means an initial investment in rebuilding the understanding to restore one’s ability to maintain the system. To restore one’s power on the team.

I went down a Wikipedia rabbit hole recently and found the profile of Sophie Wilson, who somebody should make a movie about. This section on the development of the Acorn Proton is a great story of smart, competent people getting stuff done:

Hauser employed a deception, telling both Wilson and colleague Steve Furber that the other had agreed a prototype could be built within a week. Taking up the challenge, she designed the system including the circuit board and components from Monday to Wednesday, which required fast new DRAM integrated circuits to be sourced directly from Hitachi. By Thursday evening, a prototype had been built, but the software had bugs, requiring her to stay up all night and into Friday debugging. Wilson recalled watching the wedding of Prince Charles and Lady Diana Spencer on a small portable television while attempting to debug and re-solder the prototype. It was a success with the BBC, who awarded Acorn the contract. Along with Furber, Wilson was present backstage at the machine’s first airing on television, in case any software fixes were required. She later described the event as “a unique moment in time when the public wanted to know how this stuff works and could be shown and taught how to programme.”