atheken

joined 1 year ago
[–] [email protected] 1 points 7 months ago

Many of the “frivolous” lawsuits you’ve actually heard about are effectively smear campaigns against the plaintiffs.

The lawsuit against MacDonald’s for the hot coffee one is a great example.

Yes, people do dumb stuff, or fantasize that a situation could be their golden ticket, but that is the cost of having a civil judicial system. You either have to allow some crazy in, or prejudge and filter out what you’d consider legitimate cases. I just don’t have the energy, or care enough to be annoyed by inefficiency in the a system that I rarely interact with.

The criminal system is a different story, because the way we currently prosecute different kinds of crimes offends my basic sense of fairness.

[–] [email protected] 2 points 7 months ago (2 children)

Is it the word “lawyer” or spending some small amount of money?

Lawyers are bound by law and an ethical code to conduct business in a particular way. They also tend to have support infrastructure and continuity plans that private individuals do not.

If making sure something actually happens is important to you, this is the best option.

[–] [email protected] 1 points 8 months ago

Douglas Crockford, author of “JavaScript: The Good Parts” has said:

“JavaScript is the only language in the world that people think they write without learning it first.”

I think this is a true statement (well, that and bash).

[–] [email protected] 2 points 8 months ago

Programming and Software Engineering are related, but distinct fields. Programming is relatively easy, Software Engineering is a bit harder and requires more discipline in my opinion.

[–] [email protected] 3 points 9 months ago* (last edited 9 months ago)

Writing fast unit tests will require some refactoring that could end up being pretty extensive.

For example, you mentioned “cloud storage” - if this is not already behind an interface one ticket could be to define an interface for accessing “cloud storage” and make it so that it can be mocked for most tests and the concrete implementation can be tested directly to confirm the integration works. Try to hone down that interface so that it’s as few methods as possible, only allow the parameters you’re actually using to be exposed and used in the interface. You can add more later if it’s absolutely necessary.

Do this for anything that does I/O and/or is CPU intensive.

So, to do tickets, I’d basically say, one per refactoring.

Going forward, writing “unit tests” should not be separate tickets, it should be factored into the estimates for the original stories, and nothing should go out without appropriate tests. The operational burden will decrease over time.

QA should have their own unit for how they want to test the application. Usually this is a suite per section of the app. If your app has an API, that is probably going to have a nice logical breakdown of the different areas that could each have their own ticket for adding QA-level test suites. The tests that developers write should only be additive and reduce the workload of QA. What you want to be sure of is that change sets are getting reviewed and through the entire pipeline without getting logjammed in any stage. Ideally, individual PRs are getting started and deployed in less than a week.

If you’re interested in more techniques, check out the book “Working effectively with legacy code.” It has a lot of patterns for adding tests to existing codebases.

[–] [email protected] 0 points 9 months ago

You should probably report this as an issue on the dotnet runtime GitHub repo: https://github.com/dotnet/runtime

I would also suggest you include information on the hardware you’re using for this (architecture, ram, cpu, etc).

[–] [email protected] 0 points 10 months ago* (last edited 10 months ago)

Considering the implications of relying on an external company as the registry, I don’t think custom domains are really “vanity” as much as reserving agency to move the code if it becomes necessary. I’m perfectly happy with GitHub, but would rather my modules didn’t break if they implement a policy change at some future date. I also don’t like the implication that “GitHub owns” my repo due to the import path stuff.

That being said, I wonder if this same thing could be achieved with a simple reverse proxy/CDN with a few rewrite rules? Ideally, the only cost to a typical maintainer would be the domain name, and the rest could be hosted on free infrastructure (cloudflare would seem like a reasonable choice).