andrewallbright

I've really enjoyed learning about all aspects of creating software. Whatever we decide to call it, I'll always enjoy doing things that don't always fit into a neat little job description.

I do think they should pay the folks whose code they used to train the AI. Something like how Spotify pays artists based on how much their music/content is listened to.

This has probably been talked about but...

If most code is "bad" code (any definition works) and this AI was trained on all/most code on GitHub, does that mean that this AI mostly helps to produces bad code?

We should choose our technology stack like a hermit crab chooses it's shell. The shell shouldn't be too heavy to move around in but with a little room to expand in.

When it's time, we work to find a new shell.

I like to imagine white noise listeners would be like wine connoisseurs in your scenario.

"Mmmmmm, this one features a nice static base noise livivified by a hint of perlin noise."

As a hobbyist game dev of ~1 year what I really want is a "multiplayer: the hard way" guide so I can learn how to do multiplayer on my own. My mental model of how multiplayer games actually work is basically full of holes and question marks. I haven't found that something yet.

I've been focusing on single player experiences because I haven't found that comprehensive guide that explains the nuts and bolts of multiplayer for video games. If I knew more then I could pull in more of my software engineering knowledge.

I fear that there is more incentive to create projects like this to hide that knowledge away from game developers than to thoroughly explain how to build one's own multiplayer solution.

I post this here in case someone knows of such a comprehensive guide for multiplayer.

It could just be that as a technology community we collectively are still currently getting our heads around what containerization is really essentially about. Maybe as most of us in the technology herd grok it at a deeper level, it will later become more obvious how tools prior to containerization can achieve the qualities we think we can only get from containers.

As a brain collective it may be before that we weren't conceptualizing our systems at an atomic enough level that containers introduced. Containers in service to our isolation mental models may be the true benefit of the trend. Even if the underlying technology dies or falls out of trend, the ideas will surely survive.

For my career I have learned to appreciate GNU/unix more by using containers.

Webassembly as a desirable server side technology... I suppose I need to recontextualize what I understand webassembly to be. Hmm.

In this critique of unity they say that the back half of making a game is the half of suffering. In my experience, it highlights something else that is a massive problem in the game dev space. The game dev community is stuck in software practices of 2005, leading to naive implementation patterns.

As a hobbyist game developer of ~1year, one thing that struck me was how I have not found many good sources of teaching that explains how to make a maintainable game. How does one make a code base for a video game that has desirable the non-functional qualities like maintainability? That question doesn't really have an answer...

I think it doesn't have an answer because those teaching game development haven't really asked. I'm sure it's due to many factors.

For anecdotal, I've asked about testing and CI/CD for unity in online spaces. There isn't much content on these critical subjects in the video game education space. I usually get a mix of responses but one that stuck out to me is that video games aren't appropriate for tests and it just slows down game creation.

I think that thought process more than anything is what leads to back half issues. I think that the video game industry has lagged behind the rest of the software industry and there is a huge opportunity for disruption.

In 5-10 years people should think it's absolutely outlandish to start a complex software project such as a video game project without a CI/CD engine running a suite of sensible tests. I think today that is true for most software projects, although as a community were still wrapping our heads around "what is a good test?"

My 2cents

The most surprising thing to me about DDD is how bounded contexts (BCs) is a linguistic boundary, and how we talk about things is dependent on where we are in the system. It feels very human, which intrigues me greatly.

To craft a metaphor; the software system is a like Europe and each BC is a country like Spain, France, Italy, and Germany. Each country can be said to have its own culture and language. During trade or tourism, the countries interface in a more limited common language/interaction. But when in Rome, do as the Romans do.

The most thrilling thing for me is seeing how one tests in hexagonal architectures. I am attracted to testing and I really love seeing how folks approach testing. The core (domain) remains the same, but observable side effects come from what you plug in. Want to send an email given some scenario? Plug in the production code. Want to test it? Plug in a module to create test assertions.

Singletons make it hard to write tests for my programs so I try to avoid them. Being able to run tests simultaneously without them interfering with each other is important to me.

This hits too close for comfort. I'm 31 now (oh my god). If I want to do the things I want to do, I just need to start doing them.

I wish self hosting was a bit easier. Right now it seems you need to know so much. I've always wondered if there was a way of making self hosting products that were easy to set up and secure by default.

I'd love to spend $100 for a mail server that I just plug into my router, as an example.

Reading this article and reading the comments I am reminded that writing automated testing is still an art and less of a science.

I highly value testing and it does eat up project time in weird ways. I believe as I get more experience it won't eat as much time. My hope is for productivity gains in the future.

I hope in the future most documentation is written with a testing focus. Maybe then I would not have to understand as much as I do now before finishing testing.

I get a little suspicious. Are we comparing both solutions at scale, or just one at scale and the other at a smaller scale?

The question boils down to: how many people are both systems currently moving. What would it take to build up the other system to operate at the first system's scale?

I think so. The dev team are modeling clients and client needs. I think it helps from being open world. Maybe it isn't the ultimate format but it's an interesting idea.