Skip Navigation

Posts
11
Comments
319
Joined
3 yr. 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.

  • 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.

  • 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??

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

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

  • 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 !vscode@programming.dev

  • lol got it. Definitely not email then

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

  • 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

  • Well that’s cool. Sounds like the workspace extensions are inspired by the tools.go pattern. Something that I recommend any go developer dig into!

  • Anyone know why?

  • Proton is obviously promoting their own product: proton pass. I tried it and found that it needs a little more development time. Just a little polishing.

    In the meantime, Bitwarden is fantastic. I also hear good things about onepass. Don’t use chrome’s password manager.

  • I’m generally not a big fan of big social media like e.g. Facebook where you might have many thousands of followers, purposefully grow the numbers, etc. I personally think these things are an everyday evil. Yes, it’s a bit melodramatic 🙂but that’s how I feel. Reddit, and now Lemmy are about as far as I like to go with it.

    So the isolation of geo-local-only federation is a feature. The feature, actually. I want an entire social media platform that isn’t capable of focusing on single accounts. Where you are near guaranteed to interact with your local community only. Where it would take a dramatic effort for a single actor to influence global opinions. I want a social media platform that isn’t so easy to manipulate. I could go on and on.

  • After reading your responses, it seems like we’re describing two different methods of building this system.

    Your ideas seems to depend on having many instances for various regions, where all instances are federated with each other. So my local instance somewhere in the US would still be federated with for example, an instance in Germany. But the content I receive would be heavily focused on “nearby” content. Interesting

    My ideas are based on an important difference. An instance for my town would only federate with instances for the surrounding towns. Maybe one or two more “hops” away. So sharing content between my local instance and one in Germany would be impossible. Content on my local instance would only be accessible to users in nearby instances. Local content enforced by local federation.

  • I spent several weeks thinking about this exact idea.

    Federation is cool. You could set up each instance to only federate with instances for nearby towns and cities. Maybe a “2 district” radius. Users would only see content for their local communities. Local news stays local. Local government could officially participate if they wish. People you talk to are actually neighbors you might see in person. Larger regions like counties, states, provinces, or even countries, could also have dedicated instances and federate similarly. I think this is the big appeal and it sounds awesome!

    There are a few problems 🙂

    First is a little bit of confusion with posting. Let’s say that I see a post about a cool new restaurant in my town. I share it with a friend who lives a few towns away and that’s outside the “federation radius”. I can’t share the post with that friend very easily. Maybe the tools could be enhanced to make this viable?

    Second is a matter of privacy. How do you know that new accounts belong to people associated with the geographic location of each instance? If you don’t validate, the system will certainly be abused. If you do validate, then users need to supply some real info! Home address, ID, etc. that’s a big deal for users and instance admins.

    Third. What happens if you move? Do you have to abandon your old account and start over? Again, the system itself can be developed further to solve this. But that’ll take time and money.

    Next is the operating costs. You would need to build thousands of instances to build this system up. And each one would have to be tied to a geographic region. You need new features to handle signups this way. You have the simple cost of running these servers. You probably need a lot of staff to manage it all. This is an expensive platform for one party to run. Alternatively…

    It doesn’t have to be one party running this entire system. That’s the point of the Fediverse, right? The operational costs go way down if anyone can run their own instance. But how do you enforce the rules of federating with instances for geographically nearby locations? I don’t see a reasonable way to solve this one.

    I could probably keep listing issues. But these are the big ones IMO. If you solve these, the system is viable and could be amazing.

  • Unfortunately, I don’t remember the source so we may need to go digging. But I recall reading that something like 1/3 of all bugs are related to memory safety. And those bugs translate to things like buffer overflow and privilege escalation attacks.

    The proclaimed advantage is that by making the entirety of Rust memory safe, that entire class of bugs simply won’t exist for projects written in Rust. When they do happen, the bugs will be addressed by the language rather than many thousands of downstream projects. It should be an enormous gain in development performance for the world.

    I think the idea makes sense. Time will tell us how well that works.

  • 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.