Thanks for asking the question. Apparently I need to check out opensuse!

It’s clear that you don’t agree with my original opinions. And that’s ok. But it really doesn’t seem so simple and clear. Take a look at the ratio of up to down votes.

https://programming.dev/comment/10313390

Thanks for pointing this out. I keep looking back at this thread as new people grow annoyed at my comments 🙂.

At the time I writing this, there are currently 15 upvotes and 28 downvotes on my original comment. That’s clearly negative and that’s ok. But that also makes it the third most voted on and the 4th most upvoted comment in the entire post. Seems there’s a very split opinion in the community here. This is now officially entertaining!

Thanks for the happy comment. But it’s all good. People are allowed to not like my comment. I’m not exactly swayed by the downvotes but maybe I could be just wrong here.

I am not

deleted by creator

Potentially. See my edit shove

Ok that is an impressive number but it feels a little disingenuous. You still need to something on your machine to interpret the js code, right? Is that included in the 13k? How much storage does that take?

EDIT: Well this is by far my most negative comment here. That’s almost entertaining. I’ll share a few more of my thoughts here rather than respond to individual comments. Maybe the context will make this more palatable.

First, I expect that the js language is doing most of the work here. Which makes sense. But having a browser installed as a prerequisite is an enormous dependency.

How would that stack up against other languages? Can I build a 13k binary using C? How about C#? I think Go is maybe the most interesting because the binary is entirely self contained by default. No external dependencies aside from the OS. I don’t think this or a similar game is viable with only 13k. Which is fine! I just that I find 13k is disingenuous.

That brings up the question of whether or not we should include the OS in the storage size. I would think not. But that’s only because the OS is (usually) the least common denominator when we talk about developing software. It’s generally assumed by default. But if someone wants to compare with a game that interfaces with hardware directly, then yes, we should absolutely include the OS as a dependency.

Now that I’m giving this more thought, I suspect that the devs wrote 13k of code + assets to make the game functional. Still impressive. But the more I think about this, the more meaningless that number gets. Does pre or post compiling matter more? What if we compress the thing as tarball? There’s just too many ways to manipulate this number.

Ya… being paid to perform isn’t immoral. Honestly, I hope he took a ton of cash from Amazon for the show.

Amazon is the crowd doing evil crap. Their immorality doesn’t automatically spread to everyone they interact with. Especially, people that aren’t actually aiding their efforts. This one is corporate waste

Unfortunately, I’m not familiar with installing Bitwarden so I can only offer general advice.

Port conflicts happen at runtime, not when software is installed. In general, you should be able to install as much software as you’d like that all relies on port 443 but only run one at a time.

If you’re seeing port conflicts when installing Bitwarden, then I suspect that something is starting the app after the install is done. If this is right, then maybe you can disable the automatic start. Or maybe you can ignore the error at install time, then configure the app, then start it.

Test coverage is useful to measure simply because it’s a metric. You can set standards. You can codify the number into ci/cd. You can observe if the number goes up or down over time. You can argue if these things are valuable but quantifying test coverage just makes it simpler or possible to discuss testing. As people discuss test coverage and building tests becomes normalized, the topic becomes boring. You’ll only get thoughtful discussions on automated testing when somebody establishes a new method, pattern, etc. After that, most tests are very simple. That’s often the point.

Even “testing on autopilot” has high value.

You can build lots of useful front end tests. There are tools for it. But it’s just not possible to test everything because you can’t codify every requirement. E.g. ensure that this ui element is 5 pixels below some other element, except when the window shrinks, and …

I haven’t seen great front end tests. But the ones I’ve seen mostly focus on functionality and flow rather than aiming to cover all possible scenarios. Unit tests are different in this regard.

Integration testing makes sense but I find it hard to do in the time I have.

This is a red flag. Building tests should be a planned part of your work, usually described as acceptance criteria. If you need 4 hours to write a code change, then plan for 8 or whatever so you can build tests. Engineering leaders should encourage this. If they don’t, I would consider that a cultural problem. One that indicates a lack of focus on quality and all of the problems that follow.

Edit: I want to soften my “red flag” comment. That’s a red flag for me. That job isn’t necessary bad. But I would personally not be interested. It’s ok to accept things like, “we don’t write tests and sometimes we deal with issues”. Especially if it’s a good job otherwise.

Here’s my random collection of thoughts on the subject.

I have no idea how common it is in general. Seems like some devs build tests while others don’t. This varies plenty on a team level as well as organization wide. I’ve observed this at small to very large companies, though not FAANG where I generally hope and expect that tests are a stronger standard.

I will say that test are consistently and heavily used in every large, open source project that I’ve reviewed. At some point, I think quality test cases become a requirement.

Here’s the big thing. Building automated tests is almost always a wise investment, regardless of the size of the org. Manual testing is dramatically more expensive and less effective than running unit and integration tests. I’ve never written unit tests and not found issues.

More importantly, writing unit tests forces you to write code that can be tested. This is important. IMO, code that can be tested is 1) structured differently and 2) almost always better.

Unit tests protect you from your own mistakes. Frequently. Integration tests protect you from other people. E.g when your code depends on an api and that api unexpectedly introduces a breaking change.

Everybody likes having quality tests. Nobody likes writing tests.

Quality tests are basically a strict requirement for fully automating ci/cd to production. Sure, you can skip tests and automate prior deploys, but I certainly don’t recommend it. I would expect people to be fired for doing this.

Chasing 100% test coverage is a fools game. Think about your code, what matters, and what doesn’t. Test the parts that add value and skip the rest. This is highly related to how writing unit tests change your code.

Building front end tests is inherently hard. It’s practically impossible to fully test front end code. Not even close.

Personally, I like the idea of skipping tests when you’re building a POC. Before the POC is done, you may not know if your solution is viable or what needs to be tested. The POC helps you understand. Builds tests for MVP and further iterations.

Quality ci/cd tests are complimented by quality observability, which is a large and independent topic.

/ ramblings of a tired mind

Ethically, it should apply. In practice, it doesn’t because the rich make the rules.

This is an especially tragic case. IMO, Gitea has one of the best names in software.

I ditched chrome (chromium + google propriety spyware) some years ago in favor of Brave browser (chromium + Brave stuff). It was a decent user experience but Brave also does some shady stuff, which you can google easily if interested.

Last year, google poisoned chromium with DRM stuff. They rolled back the changes after a few months but the damage was already done. I, and many others, jumped ship to Firefox and other non-chromium based browsers. Firefox isn’t perfect, but it’s an excellent browser. I’m sticking with it for the foreseeable future. And absolutely use uBlock Origin. Between that and proton VPN features, I don’t see ads anymore. It’s fantastic.

Strange. I’m not exactly keeping track. But isn’t the current going in just the opposite direction? Seems like tons of utilities are being rewritten in Rust to avoid memory safety bugs

At first, I found this funny. Then I realized how scary, sad, etc. the reality is.

Companies typically prefer users to use a native app for two reasons. First, the software is sometimes easier to build. Second, they are capable of scraping a vastly larger and more valuable set of data from the user.

Browsers can hit many differs sites, many of which are dangerous. Thus, web browsers have to be as secure as possible to protect users from malicious sites. This includes Facebook, TikTok, every medical site you’ve ever logged into, etc.

I know a lot about software. Personally, I view every installed app as a means of attacking my privacy. If you have the choice and your experience isn’t diminished, use a web browser instead of a native app.

Edit:

Something else to note. The larger companies are almost always much worse. Take a look at Facebook on the Apple Store: https://apps.apple.com/us/app/facebook/id284882215

Go down to App Privacy and View Details. It’s absolutely terrible how much data they collect. Unethical at a minimum. Now compare to Voyager for Lemmy: https://apps.apple.com/us/app/voyager-for-lemmy/id6451429762

“Data Not Collected”

I recently discovered k3d. It’s a light wrapper around k3s, which is kubernetes on docker. It’s amazingly easy to use! If you have docker installed, you can learn the commands and create a k8s cluster in under 5 minutes.

For anyone like me that likes k8s, k3d is a fantastic alternative to docker compose!

This is regulated. And there are penalties for violating those regulations. But it’s just not enough. Even a class action lawsuit won’t help the victims. Most of that money goes to lawyers.

Honestly, I don’t expect any of it to change until the penalties are so severe that major companies go under. Aka a corporate death penalty (which the US used to have). But even then, good software security is extremely hard. Almost everyone screws up something.

Well that’s an interesting take! What aspects are you opposed to?

IANAL but I did read through the patents agreement that you linked. It basically says do whatever you want with Go as long as it different infringe on Google patents. Which is pretty much backed by US law anyways and I assume other countries as well. The sketchy part is that your license is revoked as soon as they file a lawsuit rather than win it. Honestly, I’d be surprised if Google ever used this in a legal dispute because there would be a huge community backlash.

That also only applies to Go developers. You would only be a user for a tool written on Go. How does your using a tool written in Go translate to support for Google and its bad practices? Do you not use any software written in Go?

Sorry if this is sounding argumentative! I’m generally a big fan of Go and definitely opposed to Google and using its products. This is a topic that I haven’t considered before so my questions represent my sincere curiosity.