Lodra

joined 1 year ago
MODERATOR OF
[–] Lodra 0 points 6 months ago

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.

[–] Lodra 2 points 6 months ago

Wordle 1,066 4/6

🟨⬛⬛🟨⬛ ⬛🟨🟨🟨⬛ 🟨🟩🟩🟩⬛ 🟩🟩🟩🟩🟩

Definitely better but not amazing 🙂

[–] Lodra 5 points 6 months ago (3 children)

Wordle 1,065 X/6

🟨⬛⬛⬛⬛ ⬛⬛⬛🟩🟩 ⬛🟩🟩🟩🟩 ⬛🟩🟩🟩🟩 ⬛🟩🟩🟩🟩 ⬛🟩🟩🟩🟩

I feel cheated

[–] Lodra -4 points 6 months ago (4 children)

Open source software literally means that the source code is available to anyone. In GitHub, that just means that your repo is public rather than private. But your method technically doesn’t matter. You could publish to a forum if you wish. That’s still open source!

Free OSS just means that anyone is free to use and modify the source code for any purpose. The details are usually defined in a LICENSE file.

I feel like you’re really asking about the common practices and methods used in FOSS. Right? If so, that’s entirely up to you as the maintainer. As the project matures, you may attract other contributors which will in turn will motivate change to your tools and methods.

Start with what works for you. Model after similar projects if you wish. Adjust as change is needed.

[–] Lodra 4 points 6 months ago (4 children)

I certainly don’t have an answer for you. Sorry 🙂

I’m super curious about your motives and goals though. Why do you want to do this??

[–] Lodra 2 points 6 months ago

Lol whoops. You’ve got it right. I fixed up my previous comment

[–] Lodra 2 points 6 months ago* (last edited 6 months ago) (3 children)

The video plays for me as well but no sound. I’m using the PWA on iOS.

[–] Lodra 1 points 6 months ago (1 children)

I think you’ve had a little mixup! Looks like this community is Visual Studio, which is completely unrelated to Visual Studio Code. We can thank Microsoft for that naming disaster 🫠.

If you’re asking about Visual Studio, then the GitHub proposal link isn’t relevant because it’s for VSCode. And if you’re asking about VSCode, then come ask in [email protected]

[–] Lodra 7 points 6 months ago* (last edited 6 months ago)

This one was brutal!

I got it in 3, which is nice. But it took me like 20 minutes to solve 🫠

Wordle 1,054 3/6

⬛⬛🟩🟩⬛ 🟨⬛🟩🟩⬛ 🟩🟩🟩🟩🟩

[–] Lodra 4 points 6 months ago (1 children)

lol got it. Definitely not email then

[–] Lodra 3 points 6 months ago (5 children)

Uh email? It’s not exactly exciting but there are loads of tools available for automating emails. Definitely asynchronous. Does it fit your needs?

[–] Lodra 6 points 6 months ago* (last edited 6 months ago) (1 children)

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.

view more: ‹ prev next ›