[-] Lodra@programming.dev 7 points 3 months ago

Took me a while to figure it out. I believe there’s a fourth person in the back who’s almost entirely hidden. Their hands are above her hips. And I think you can a kneeling leg or something down low on the ground

[-] Lodra@programming.dev 6 points 7 months ago

I recommend Minus33. Seriously high quality stuff (especially socks) that are made in New Hampshire, USA. They don’t offer Darn Tough’s warranty but the socks cost half as much when I last checked.

Disclaimer: I know the family that runs the business. I also know they actually take care of their employees.

[-] Lodra@programming.dev 7 points 2 years ago

Oh ok. I didn’t realize it’s specifically for soup. But also, it’s probably tasty in some soups like a carrot or butternut squash soup 🤣

[-] Lodra@programming.dev 6 points 2 years ago* (last edited 2 years ago)

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.

[-] Lodra@programming.dev 6 points 2 years ago

No. There are good landlords. They’re definitely small scale. Normal homeowners that are able to scale their efforts to a few rental units. There’s also a real need for renting rather than owning.

The real problems are all large scale landlords and also bad landlords (of all sizes) that overcharge, abuse tenants, forgo maintenance, etc.

[-] Lodra@programming.dev 6 points 2 years ago

An interesting idea but it’s not possible with all languages. E.g. golang. But probably not the case with worlds adrift. I’m guessing it’s more of an incentive problem for the other company. No more revenue = why bother?

[-] Lodra@programming.dev 6 points 2 years ago

I think “server” or “waiter” are more commonly used words but they’re all roughly the same. It’s usually a person working in a restaurant that take orders, gets drinks, delivers food, etc.

[-] Lodra@programming.dev 6 points 2 years ago

In my recent experience, that wasn’t the case. Ultrasound at the ER was $370 for the contracted radiologist. And a whipping $1700 for a 5 minute use of the machine.

[-] Lodra@programming.dev 6 points 2 years ago

Ha yes! It's within my ability to research and choose... but that would cost more time than I want to pay. I'm definitely appreciating the input from the crowd.

[-] Lodra@programming.dev 6 points 3 years ago

You can also take a look at open telemetry. It's a huge open source project with lots of functionality. Handles logs just fine and also can provide metrics and traces too. Might be overkill for your needs but it's an excellent tool.

[-] Lodra@programming.dev 7 points 3 years ago

Lol yeeesssss. It's not exactly the healthiest mentality in my opinion... But I 100% sympathize with you here. "I have energy and opportunity today to fix a thing so let's do whatever I can do today to solve it." Unfortunately, that does lead to some "creative" solutions like a Faraday cage around your modem (ahahaha 😂). But it sometimes you just any solution!

Let it be known that I have provided your 2nd upvote.

[-] Lodra@programming.dev 6 points 3 years ago

Personally, I'd take it a step further. Firewall rules should be defined as code in a git repo. So if you're building rules in a gui, you're simply doing it wrong. While a cli and/or api should be used, that should be automated and invisible to a human.

view more: ‹ prev next ›

Lodra

0 post score
0 comment score
joined 3 years ago
MODERATOR OF