Bear Blog Trending PostsModify

2025-12-17 17:33:00

I was upgrading a project to Spring Boot 4. Multiple modules and libraries. Java, Gradle, AWS, CI, Docker... The kind of change that usually demands long-lived branches, careful sequencing, and a lot of trial and error.

What surprised me wasn't the technical complexity. It was how much the shape of the work changed once the cost of being wrong went to zero.

This is what my tree looked like:

➜  java-upgrade git:(5561fa3) ✗ jj
@    nruuvkns arnau@local 2025-12-12 20:31:20 spring4 27d4b705
├─╮  upgrade to spring boot 4.0
│ ○  rzoyrzpv arnau@local 2025-12-12 20:30:29 jackson3 d76dcecc
│ │  upgrade from jackson2 to jackson3
○ │  yyxuxnmk arnau@local 2025-12-12 20:31:17 aws-cloud git_head() 5561fa39
├─╯  upgrade aws cloud 4
○  ttusytzr arnau@local 2025-12-12 20:30:29 spring35 5a817998
│  upgrade to spring boot 3.5
○      uolmolxo arnau@local 2025-12-12 20:30:29 java-25 26dda0de
├─┬─╮  upgrade to java sdk 25
│ │ ○  yvklzspu arnau@local 2025-12-12 20:29:47 aws-sdk-2 e2045bf6
│ │ │  upgrade to java aws sdk 2
│ ○ │  mkwpqylt arnau@local 2025-12-12 20:30:18 refactor-cache 36105341
│ ├─╯  simplifies cache by removing external dependencies
○ │  qxmnvtxp arnau@local 2025-12-12 20:29:56 docker-image 49a19a38
├─╯  ci uses in-house image and new action gradle tasks
○  kpqwwnkk arnau@local 2025-12-12 20:29:42 gradle bf2b0dad
│  upgrade gradle 8 to gradle 9
◆  zzzzzzzz root() 00000000

Nothing was planned in advance.

Every change in that log became a pull request. One stacked on top of another. My team reviewed the smallest possible diff as best as Github allowed it.

There's a video of Brian Anderson reading a code review where he talks about being afraid of feedback. About needing time to process it. Brian is phenomenal. I respect his honesty because that fear never really goes away. We know we aren't the code we write. Even when you know you aren’t your code, mistakes still feel expensive.

I don't need a clean history to make progress. I don't need to get it right before sharing. I don't even need it to work. I can try something, show it to my team, and throw it away without shame. I reverted commits. I shared wip ideas. I could say "this might be stupid" and still push it.

Commands like duplicate, squash, and restore aren't just technical operations. They're psychological tools because they remove the cost of being wrong.

Understanding how your teammate thinks is often more valuable than the code they wrote. Conflicts aren't failures. They're conversations.

Many tools and methodologies encourage you to decide on a solution before you understand the problem. This way of working does the opposite. It rewards motion: thinking, prototyping, writing, breaking things, fixing them. Fearless Sledgehammer Programming. It's a creative process. Friction slows progress. I need movement.

I don't want to teach jj. I want to share what it taught me.

When experimentation is cheap, you stop optimizing for correctness up front and start optimizing for feedback. And once the cost of being wrong drops low enough, fear quietly gets out of the way.

2025-12-16 05:36:00

This is the story of three different models of design process, ways of making video games from the viewpoint of their design. They're not really all-encompassing models of game development – they're three lenses through which we might look at design.

The first model of game design is what I'd call mechanical formalism. If you studied video game design in an academic setting, you're probably familiar with the idea of a core or central mechanic – the principal interaction that a game is built around. The portal gun in Portal, rewinding time in Braid, jumping in Canabalt. Those games all have other mechanics, other elements, and other affordances; but they're all orbiting and servicing that central idea.

The game is, then, constructed very much as a study on the theme of that central mechanic. It introduces the mechanic, and then develops it – elaborating variations and hidden depths without ever abandoning it. This methodology of game design has at times been held up as Good Game Design, or simply as Game Design (the only real option), or at least as a default. It's a mode of thinking that's taught and adopted in a lot of settings, particularly in education and in game jams.

This mode of game design is about as old as video games, but it has something of a complicated history. Early video games were of course very simple; the presence of a single central mechanic is almost a necessity, and it was quickly ingrained in the medium. But as games became more complex and sophisticated, this mode of design thinking stopped being universally prevalent.

It has always been, however, extremely common in two fields: small-scale development (whether you call that "indie", "shareware", "doujin", "game jam" or otherwise) and academia. There is, therefore, a very strong pipeline that exposes almost everyone in game development to these ideas at some point of their journey through the discipline.

This style of design thinking is extremely well-suited to games that aim for three things: a neatly contained scope, a modest production budget, and a unique mechanical hook. You will see it everywhere in indie games, of course, especially around the puzzle genre but not exclusively in it. Her Story, Life is Strange, and Dear Esther are all narrative-forward games that focus more on story than mechanics, but they all are similarly built around a single central affordance for how you interact with them. Similarly, you can see this style of design process in an RTS like Darwinia or an action game like Superhot.

It is, of course, unsurprising. This is a way in which people are literally taught to think about games, and the idea of the core mechanic is very widespread in conversations about video game design.

The second approach is what I'd call market structuralism. As games become bigger and more expensive to make, design outgrows the neatness of a single core mechanic but also becomes more risk averse. This leads to what is pretty much the sole approach taken by big video game studios: designing to a genre. The video game is a product designed to fit a specific market niche, and those market niches are what we typically call "genres".¹

Conventional commercial game design seeks to deliver a set of features that are driven by genre expectations, at a level of polish and fidelity that fits the game's market positioning – Which is to say, its price point but also other elements of how it's marketed. Usually, this is complemented by one or two unique selling points meant to differentiate the game from its competitors.

This isn't exclusive to large studios. Any game that tries to fit comfortably into a genre niche is designed to its market. When Coincidence² makes an automation-puzzle game or Wadjet Eye makes a point-and-click adventure, they're designing to a market niche just as much as Ubisoft is when they make another Assassin's Creed.

This isn't even really exclusive with design formalism and designing to a central mechanic; I think many mature design processes fluidly adopt those two ways of looking at the game contextually. For some niches (again, puzzle games) the presence of a strong central mechanic is market fit, and the unique selling point is what that mechanic happens to be. Again, this is a loose mapping of a territory of momentarily useful viewpoints more so than rigid sides in an argument, if that makes sense.

So, take these descriptions as broad ways of mapping out the territory and not as definitive categories. I won't dwell too much on these first two models, because I think most people with any kind of games background are probably at least broadly familiar with the ideas here. If you've gone to school for game design or taken part in a game jam, you probably know about the idea of a core mechanic. If you've ever been anywhere in the vicinity of a publisher pitch, you probably know about market fit, genre expectations, and finding your "comps".

But these broad descriptions are needed to get at what I really want to talk about, which is the third model of design I'm discussing here.

This third way of thinking about game design that is rarely ever applied today. Before trying to describe it, let me point to an example – Cinemaware's 1989 Amiga title It Came from the Desert, a game that's essentially a pastiche of 1950s B-movies, especially Them. Here's a montage of screenshots:

Yes, this game from 1989 has dialogue trees, a driving section, a rudimentary first-person shooter section, and so on. There's some light strategy elements, there's some exploration, at one point you get into an airplane and bomb the giant ants from above.

You can think of a core mechanic as a central pillar that the entire game hangs from. You can think of a genre design as using this skeleton of connected mechanics as a supporting structure; there's no longer a singular core, but rather a mechanical identity that has a sort of expected, perhaps standard shape that the game drapes over.

In this third model of design – let's call it thematic expressionism – mechanics aren't treated as structural members at all. They're treated like actors in a play or paints on a canvas; they're applied towards narrative or thematic aims, and they enter and leave the stage as required. There's no expectation that a mechanic "develops" or that it's a "deep" version of that mechanic. The different components that make up It Came from the Desert don't individually comprise a particularly meaty version of a first-person shooter or a top-down arcade flight sim, but they are built to be sufficient to telling the story or furthering the game's thematic ideas.

This way of building games had a definite moment in the late 80s and early 90s, particularly in the PC space. Hardware was powerful enough that games could get fairly complex, but players were also willing to accept fairly simple and elementary versions of these mechanics stitched together into a quilt. Other relevant examples from this era include Sid Meiers' games Covert Action and Pirates, the latter of which is obscure today but remains a pretty influential game.

Pirates is designed entirely from the standpoint of trying to capture the milieu of fiction about 17th-18th century Caribbean piracy through this approach of stitching individual small mechanical scenes together; the entire game is a state machine of individual minigames that lead into one another. There's a fencing subgame, for example, which is very unlike any latter attempt at representing melee combat in a game; rather, it's built entirely around getting the feel of an Errol Flynn movie swordfight, with big coreographed exchanges of sword clashes.

But the fencing subgame doesn't stand alone at all; it's not really a "game mode" or something you can do over and over. You only ever fence exactly one opponent at a time, and always in the context of a broader line of events: you're boarding an enemy ship (and thus coming in from the naval battle subgame). You're storming the walls of a town you're trying to sack (and thus coming from the land battle subgame, which resembles a strategy game). Mechanics have their little time in the sun and then they go back to the box, basically, because their goal was to allow the player to interact or play-act a segment of the game's narrative.

Note the flexibility in how I talk about "narrative" here, too. It Came from the Desert has a pretty strictly linear story, but Pirates is essentially an open-world game that lets you go anywhere and do anything you want, with a world that is semi-randomized, built mostly out of broad repeating archetypes, and which can be in different starting states based on how you pick your game start.

There's very few modern examples of games that seem to be built along these lines, although we sometimes glimpse this. The rhythm game segments of Night in the Woods, for example. What Remains of Edith Finch is similarly built out of these small purpose-built mechanical moments.

We of course see some aspect of this idea in any kind of game with genre-blending mechanics, "[some other genre] elements", or "minigames", but I do think there's a distinction here. Thematic design is fundamentally unmoored from mechanics; they leave the stage completely when they're not in use. An example here is Cryo's 1992 Dune, which has elements of both an adventure game and a strategy game, and different elements are basically freestanding. They relate to one another but exist apart. When you're playing the adventure game, you're completely removed from the strategy game.

Compare this to what would be superficially similar, the modern use of narrative events in strategy games. In something like Crusader Kings 3, narrative events live in modals that overlay the ever-present strategy map. The superstructure of a strategy game can shelter and contain the event-driven narrative inside it.

Another point of comparison might be Assassin's Creed: Black Flag, a game that is a lot like Pirates in that it's about playing as a pirate and it includes both swordfighting and naval combat. But the naval combat exists in a state that is fundamentally subordinate to the free-roaming third-person action; the camera zooms out when you're at the helm of your ship, but it never fully abandons the reference point of the player character, and you can abandon the helm at any point. Black Flag also includes many things that are not about the milieu but about the series and the genre expectations (like collectibles and parkour) while setting aside things that Pirates specifically includes in pursuit of a genre milieu (like expeditions for buried treasure and romance). The genre is in the driver's seat, and the thematic ideas are influencing mostly in the form of where that game looks for its unique selling points.

Modern game development is very reluctant to create "one-off" things or to veer off from a proven, low-risk path; the biggest resource bottleneck on a typical game production nowadays is programmer time, after all. There's nothing inherently wrong with an approach that prioritizes well-understood and reusable game pieces that limit risk and scope; limiting risk and scope is in a lot of ways the only way most games get made.

But I do think that we are leaving something on the table by not engaging in these broader explorations that were a lot more common 30 years ago. Many of the established genres that we have today were born out of those experiments, for one thing, often by distilling and calcifying ideas from a shaggier, more theme-driven example. Ultima Underworld, which is generally credited as originating immersive sims was born out of this ferment.

Obviously in game development right now, there's not a lot of resources going towards any work that's fundamentally exploratory; but even when it is, in the indie side of things I think we can be very stuck on this idea of games as expressions of singular central game mechanics, or design formalism writ large. We can look at something like UFO 50, for example, and see this design methodology as the dominant one in a setting where people had quite a lot of freedom to do different things.

Now, again, this is not meant as an indictment of any individual developer for doing things one way or another; I love games that explore a central mechanic to its depths as much as anyone. This is more of an invitation: When we think about using mechanics as tools to achieve thematic, experiential, or textural aims, what do we gain? What becomes possible that was impossible previously? What do we have to change about our processes or our practice to be able to think that way? If we did adapt to that way of thinking and working, what games could we make that previously seemed improbable?

PS: If you'd like to get this post and similar ones delivered to your email inbox, consider subscribing.

2025-12-16 04:02:00

Article written by kami
Heya!
Ava recently had the idea to make a channel in the gazette discord where every message automatically gets posted on a website.
So, i went and implemented it. Introducing sg.kamiscorner.xyz, also known as chat surgery!

Everytime someone posts a message in the #auto-blogging chat in the gazette discord, it automatically gets added to the site. Without any input validation whatsoever. We already have an alert(1) about two minutes into the sites existence, and suliman changed the background to be piss-colored.

Anyways, how'd i do it?
Fairly simple, we've got a discord bot that listens for new messages and writes them to a file. I've got this bot running in the background at all times on a server i own. I've also got a webserver running php, which reads that file and puts the contents on the website. That's it. Chat surgery.

Here's the source code!

The python bot:

import discord
import csv
import os

# Define your bot's token and the channel ID you're interested in
TOKEN = ''  # Replace with your bot's token
CHANNEL_ID = 0  # Replace with the channel ID you want to monitor

# CSV file path
CSV_FILE = 'messages.csv'

intents = discord.Intents.default()
intents.message_content = True  # Enable content intent to read messages

# Set up the bot client
client = discord.Client(intents=intents)

# Create the CSV file if it doesn't exist
if not os.path.exists(CSV_FILE):
    with open(CSV_FILE, 'w', newline='', encoding='utf-8') as file:
        writer = csv.writer(file)
        writer.writerow(['Author', 'Message', 'Timestamp'])  # Header row

# Function to write messages to the CSV file
def write_to_csv(author, message, timestamp):
    with open(CSV_FILE, 'a', newline='', encoding='utf-8') as file:
        writer = csv.writer(file)
        writer.writerow([author, message, timestamp])

# Event when the bot is ready
@client.event
async def on_ready():
    print(f'Logged in as {client.user}')

# Event when a new message is received
@client.event
async def on_message(message):
    # Ignore messages from the bot itself
    if message.author == client.user:
        return

    # Check if the message is from the specific channel
    if message.channel.id == CHANNEL_ID:
        # Write the message details to the CSV
        write_to_csv(message.author.name, message.content, message.created_at)

        print(f"Message from {message.author.name}: {message.content} saved to CSV.")

# Start the bot
client.run(TOKEN)  

The singular index.php:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>chat.surgery</title>
</head>
<body>
    <h1>chat.surgery</h1>
    <?php
        $lines = [];
        $file = fopen('messages.csv', 'r');
        while (($line = fgetcsv($file)) !== FALSE) {
            if($line[1] != "Message") {
                $lines[] = $line[1]; // store messages in array
            }
        }
        fclose($file);

        // loop through array in reverse order
        for ($i = count($lines) - 1; $i >= 0; $i--) {
            echo "<p>{$lines[$i]}</p>";
        }
    ?>
</body>
</html>

I might make a more-indepth technical explanation on how to set up the kvm for all of this at some point, but i feel like this is clear enough that anyone who for some reason wants to subject themselves to hosting this can do it.

2025-12-15 23:49:00

When I was a kid, one of the most famous Swedes in sports was alpine ski racer Ingemar Stenmark. They even paused class at school and rolled in a TV whenever he competed in a big race. It’s true.

If you were born in Sweden in the 70s, like I was, you’re probably familiar with some of his quotes. One of them was “De ä bar å åk” (“Just race” in his very characteristic dialect). It was his reply when a reporter asked how to become a winner.

Another famous quote of his is:

The more I practice, the luckier I get.

Meaning, of course, that winning isn’t about luck. It’s about practicing, and practicing some more. You keep doing it whether you’re the first or the last to cross the finish line.

There are no shortcuts. There is no secret.

Want to be a good skier? Ski more. Want to be a good writer? Write more.

Simple as that. And so hard.

That’s why only a few become winners.

They don’t give up. They keep doing it. They get lucky because they don’t believe in luck.

2025-12-15 09:45:00

Thinking of a song...

2025-12-15 05:47:00

Today, I finally made the switch to Bear Blog and left Micro.blog. When I started using Micro.blog earlier this year, I was incredibly bullish about it. I even merged my Mastodon account into the platform, convinced I would never need anything else. The concept that everything I post ends up in my blog is truly amazing.

Over the course of the year, I learned the good and the not so good things about this decision.

On the positive side, I very often had a thought in my head which ended up to become a blog post as I just continued typing. I never had to switch to another app or website, just because I hit some character limit. I strongly believe this very convenient publishing workflow led to way more and longer posts.

On the other hand, using Micro.blog often felt like trying to go to the supermarket with an Airbus. There is literally a setting for everything. The product is built for technical-minded people like me, but as someone who also cares deeply about user experience, I found it hard to truly grasp the product. Sure, after a while, you get used to it, but I firmly believe the core use cases need to be delightful to use from day one.

Despite the UX flaws and some stability issues, I really enjoyed using Micro.blog and even contributed a few plugins to customize the platform. It is a great community, and I met a few cool people there whom I will take with me to my new, independent Mastodon profile.

I am now simply trading the Airbus for a bicycle. Simple, reliable, and powered only by my own input. That is why I landed on Bear Blog. The platform feels limited at first glance, but if you think about it, that is exactly what differentiates great from outstanding products.

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.– Antoine de Saint-Exupéry

And the long-term commitment of Herman, ensuring this platform lives for a very long time, is truly the icing on the cake.

That said, I am really happy to join the Bear Blog community!