Microservice from the start may be a lot of overhead, but it should at least be made with that scalability in mind. In practice to me, that just means simple things like make sure you can configure it via environment vars, run it out of docker compose or something because you need to be able install it on all your dev systems and your prod server. That basic setup will let you scale if/when you need to, and doesn’t add anything extra when planned from the start.

Allocating infrastructure on a cloud service with auto scaling is the hard part imo. But making the app support the environment from the start isn’t as hard.

Skilled in asking a chatbot how to job.

AWS has so much documentation, and yet it never has what I’m looking for ☠️

In our testing, the VPN always continued to report as connected, and the kill switch was never engaged to drop our VPN connection.

This is the only place they mention kill switch. I feel like it needs a slight clarification on whether it was enabled and didn’t work, or if was just disabled and therefore not “engaged”.

Just switch to GNU/Hurd

/s

This is what I was thinking. For a first iteration to get out the door immediately it could just be windows with a “game browser” that launches full screen when you turn it on 😂

They change it all the time for funsies

You’re right, I’m not representing the merge correctly. I was thinking of having multiple merges because for a long running patch branch you might merge main into the patch branch several times before merging the patch branch into main.

I’m so used to rebasing I forgot there’s tools that correctly show all the branching and merges and things.

Idk, I just like rebase’s behavior over merge.

I like flutter’s design where you do your markup and styling as code, and then it gets rendered via opengl. So you get that native performance without having to deal with the whole browser stack.

I don’t like how almost all software these days is just web apps masquerading as native apps, but they’re just so damn easy to write compared to anything else.

It probably won’t get rid of js’s dominance, but it’ll give people options. I already see some front end python and rust frameworks thanks to wasm. But for some reason I really don’t like the idea of writing html / css in my rust. But I don’t like the idea of html / css in my rust.

I feel the opposite, but for similar logic? Merge is the one that is cluttered up with other merges.

With rebase you get A->B->C for the main branch, and D->E->F for the patch branch, and when submitting to main you get a nice A->B->C->D->E->F and you can find your faulty commit in the D->E->F section.

For merge you end up with this nonsense of mixed commits and merge commits like A->D->B->B’->E->F->C->C’ where the ones with the apostrophe are merge commits. And worse, in a git lot there is no clear “D E F” so you don’t actually know if A, D or B came from the feature branch, you just know a branch was merged at commit B’. You’d have to try to demangle it by looking at authors and dates.

The final code ought to look the same, but now if you’re debugging you can’t separate the feature patch from the main path code to see which part was at fault. I always rebase because it’s equivalent to checking out the latest changes and re-branching so I’m never behind and the patch is always a unique set of commits.

Is it that bad?

For real, I might get it to try it out. I’m learning about it from this post.

Here I’ll add some context

It is pretty easy not to think about this game, it does not live rent free in my brain. I bought the promise of a space ship over a decade ago when there really was no game. The “game” then was here is your spaceship in a garage, stare at it and marvel. That was the whole game.

Over time i’ve seen bits and pieces of it in my feed, I remember when they added being able to fly the spaceship, idk when that was, but again that was the whole game. You could see pretty space but still no substance.

That was really my last experience with it because I think somewhere around this point is probably where I started working full time and stopped really following game news.

Flash forward to today I see this post to see the game is still a work in progress, I shared my opinion.

So if there is a decent game by now with a plot that would be great, I would give it a shot. But if it’s still just a fancy tech demo where you can run around for a bit but there’s really nothing to “do” then I’ll wait another decade.

I “bought” this game when I was in high school. I’ve graduated high school, college, and I’ve been in the workforce for 7 years. Still no game.

So yes, they should figure out this game is going to be, set a launch date, and work towards that schedule. This forever-in-development thing they have going on is ridiculous.

Edit: Alright, it’s not fair to say “still no game.” There is a game you can download and play, but the question I have is does it have all the bells and whistles you expect from a complete game, or is it a technical demo with some game features? See my other comment in this comment chain for why my opinion is what it is.

I could be wrong, but I’m pretty sure a lot of open source software is volunteer based and unpaid.

There might be cases where orgs will lend developers to work on a project, but with the org’s interests in mind, so if the patch isn’t in their interest, then those devs won’t look at it.

You never do

I hope lemmy gets some super interesting posts that become core lore for the entire user base like this one was for reddit.

The more I learn about web3/crypto, it is increasingly getting closer to real life financials with all the same pitfalls and extra crypto problems