offbyone

joined 2 years ago
[–] [email protected] 2 points 2 years ago* (last edited 2 years ago) (2 children)

I feel like you ignored their chief issue, which is that if your original server (IE. lemmy.world) goes down then nothing works for you. In that situation you have to switch to a new server to be able to view anything, and likely need to create a new account on that server. There's some other catches to this as well that makes it more problematic than just that.

They were definitely told the "it doesn't matter what server you choose" line when they looked at lemmy, but in reality that's not entirely true if a server isn't that stable.

[–] [email protected] 2 points 2 years ago (1 children)

Generally speaking the use case is writing tests. If your tests just call all the dependencies and new directly then it's harder to write tests for your specific component while avoiding setting up a whole bunch of stuff (to make all those other classes work). By requiring all the dependencies to be provided to the class, you can swap them out at test time for something else that's easier to work with.

That said, IMO it's a symptom of problems in language design. Using DI is only necessary because languages like C# don't make it easy to mock out new or classes used directly, so we resort to wrapping everything in interfaces and factories to avoid those features and replace them with ones that are easier to mock. If the language was designed such that those features were easy to replace during testing then DI probably wouldn't be a thing.

[–] [email protected] 1 points 2 years ago

My point is that the data on here is purposely shared with every other federated instance, there's no semblance of privacy and your data is shared with hundreds or likely thousands of admins by the time it's done (more and more as the network grows). There's no reason to trust that every admin will keep that information private, some people are already talking about putting up services to expose all the hidden information (in the name of "transparency"). It's simply trivial for Meta or anybody else to get copies of the data because there's no real protection from it unless you're making your instance an island (and that's an island from everybody, not just one specifically known to be Meta).

[–] [email protected] 1 points 2 years ago

What's the point of downloading a game if not to experience it?

[–] [email protected] 0 points 2 years ago

"Nobody deserves to get paid for creating the games I enjoy".

[–] [email protected] 18 points 2 years ago

Ehh, you might as well waste as much of the admins time as possible.

[–] [email protected] 9 points 2 years ago (3 children)

Fundimentally none of the data on here is private, it's not designed to be private.

[–] [email protected] 4 points 2 years ago

I haven't used Zig myself but I think it could have its place. IMO Rust has moved too far away from C to be something many existing users will move to (and using both in the same project is messy), but Zig seems to integrate well enough that it might.

[–] [email protected] 1 points 2 years ago

Lol the funny thing is that this isn't even close to my longest project :P I have one with a first commit close to 10 years ago (and I of course started it a while before the first commit). It's my favorite just for how fun the result is. IMO the best projects tend to be ones you actually like to use when you're done.

That said I also wouldn't put too much stock in that 1 year, I think I worked on it a lot for about a month and then moved onto other things after having trouble with it. I came back about a year later and managed to more or less finish it. It's definitely a long time to devote to a project, but if you stayed focused on it you could do it in a couple months I think.

[–] [email protected] 0 points 2 years ago (2 children)

Starting with Gameboy might be a bit daunting but if you're reasonably comfortable with C then I don't think it's too bad. If you're not too familiar with the hardware side of it then that might be a challenge, but the advantage with the Gameboy is that there's tons of documentation and tutorials out there which can probably help you work though the details. Really the big thing is to just be ready to do lots of reading XD You need to get a base-level of understanding of the system before you start coding. git says it took me around a year to get it functional and playing most ROMs, but that was with some big breaks in-between.

Also, that's a very good question. For performance, it was never an issue. I started it with a focus on keeping the code clean vs. worry about performance and it turned out fine, I've run it on a cheap 1.6GHz machine and it didn't even reach 25% CPU usage, so IMO I wouldn't worry about it. This also doesn't vary that much ROM to ROM.

For the ROMs I tested, for the most part every ROM tended to uncover something new, but the Gameboy has a pretty nice progression of "easy" to "hard" ROMs if you just sort by the MBC type, and also the BIOS is a pretty good test of basic functionality. Additionally there are a few different test suite ROMs out there that are fantastic, they'll run through every instruction or piece of functionality and check for the correct results, they saved me tons of time.

[–] [email protected] 6 points 2 years ago

I totally agree with you that a typical CEO would not put up with this at all, but then I don't think this is a very typical situation :D I would assume she knew what she was getting into. He named himself CTO so it's not like he's no longer involved in the company, and the CEO can't really 'overrule' him on any product decisions or anything else since he's technically also her boss.

Now, if he's smart he will hopefully at least take her opinions/guidance into consideration, but 🤷

[–] [email protected] 9 points 2 years ago (2 children)

He still owns the company so it doesn't matter who the CEO is, he is their boss. If he wants to continue making big business decisions then he still can, and if the CEO doesn't agree he can either fire them or just go over their head.

view more: ‹ prev next ›