I call it "business as usual".
Jaime
@Jaime
Best posts made by Jaime
-
RE: How do you call this fairly common anti-pattern?
-
RE: In Log4J WTF news today…
@Carnage said in In Log4J WTF news today…:
And even more, why the fuck is it running code that is returned?
Here is the exact why... https://issues.apache.org/jira/browse/LOG4J2-313
These things are always cases of components using other components and then those other component gets new functionality that has unintended consequences.
This is the opposite of "secure by design".
-
RE: Why is programming complicated?
@jinpa Here's a quote from Fred Brooks in "The Mythical Man-Month":
I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation. We still make syntax errors, to be sure; but they are fuzz compared to the conceptual errors in most systems
So, fifty years ago we knew that programming wasn't conceptually simple. Why do you believe it is?
-
RE: Nope
@boomzilla That flame is there to burn off the excess gas. Without it, it would be a safety hazard.
-
RE: How not to CV
How hard is it to join MENSA?
I would never join an organization who's standards are so low that they'd accept me.
-
More Driving Stuff
Here we go again with people equating speed limits with safety.
Unfortunately, one child was killed and another injured when a car drove off the highway and into a park.
The facts:
- The accident was caused by driver of the car falling asleep.
- The park being so close to a highway has been a concern for many years.
- Fifteen years ago, a survey was done that recommended that a barrier be placed between the highway and the park.
- Neighbors have been bitching regularly to get the barrier installed, but the city has been slow figuring out who would be responsible for paying for it.
The response:
- Lower the speed limit of the highway.
- Place speed-check signs.
- Place four cops permanently along the park edge to write tickets.
All this ignores the fact that if they did exactly this last week, the kid would still have been killed. The sleeping driver ran a stop light, he wouldn't have obeyed the speed limit sign. I'm pissed for two reasons. First, that they didn't actually do something effective, like put in temporary barriers as the first remediation. Second, that lowering the speed limit is seen as any part of the solution. It's a stupid design to have a naked park border next to a highway. Fix the border, don't destroy the highway by turning it into a city street.
-
RE: Just... I don't know anymore man.
Who let the piss-poor C programmer use Java?
-
Why, oh why, do we return empty things on error
I reviewed another commit today and saw this pattern repeat for the zillionth time:
public SomeType SomeMethod (int arg1, int arg2) { var retval = new SomeType(); try { // use the arguments and attempt to fill the properties of retval } catch (Exception ex) { LogError(ex); } return retval; }
Nothing ever errors, every call succeeds. Sometimes, it succeeds and you get an empty object... if so, the actual problem (probably) got logged. If you forget to take a deep look at the return value, you'll probably get an NPE at some point later in the code when you've assumed that you have an object in a valid state.
The worst part about this particular bug is that the code would be better if it simply "didn't". Take out the try/catch, take out the bogus new on top. Our programmers spend a lot of time writing code that makes our lives harder.
-
RE: Supermarket Self-Checkout
My local supermarket just replaced their self-checkout kiosks. The new new version has two similar voice prompts:
-
Please wait for attendant. This means that you need to wait for the person at the little station overlooking all of the kiosks. Typically this is for something like an ID check for alcoholic beverages.
-
Please wait for cashier. This is you. It's a self-checkout kiosk, so you're the cashier. It does this when there is a problem with the card and it wants you to do it again. The card reader says "please try again", but it has already sent a reject signal to the kiosk. At this point, the card reader is ready, but the kiosk has gone back to "select payment method". Nothing you do on the card reader gets you beyond "please try again". It is literally telling you to wait for yourself to choose the payment method.
-
-
RE: Beyond CodeSOD
@BernieTheBernie I'll bet my phone team is worse than yours.
A few days ago I attended a meeting where the manager of the call center was presenting ideas of how we could improve the "reset password" feature of our site. During the meeting, I found out we are here because the most common cause of a call is that someone needs help resetting their password.
Within five minutes, I discovered that the "text me a password reset code" part of our system stopped working in November of 2020.
So, we are in a meeting where the call center isn't aware that no one, and I mean no one, is getting a code to continue with the reset process. They are actually out there doing usability research to find out how to make a "better process" while being oblivious to the fact that the current problem isn't a bad process - it's a broken process.
BTW, we never get log files as well. We also get problems reported days or weeks after they happen with no time or even date of occurrence to go look in a log file.
Latest posts made by Jaime
-
RE: Is there a guide to certificate algorithms?
@pcooper said in Is there a guide to certificate algorithms?:
It's also worth knowing that ECDSA uses curves that have parameters hand-picked by NIST
Fifty years ago, NIST hand picked S-boxes for DES, and it turned out that they tweaked them to be resistant to attacks that only NIST knew.
Today, there's not so much trust that they will be as ethical, especially after they were already caught breaking Dual_EC_DRBG in exactly this way.
-
RE: Nope, you eat it
@Arantor said in Nope, you eat it:
Just seen an influencer try to sell a bottle of hydrogenated water because water isn’t hydrated.
A simple way to hydrogenate water is to add hydrogen chloride to it. That won't bubble out like gaseous hydrogen, and has the added benefit of leaving your insides nice and squeaky clean. It does smell a bit bad, however.
-
RE: Is updating dependencies frequently still good advice?
@dkf said in Is updating dependencies frequently still good advice?:
I was thinking about that platform at the beginning of this week, whe the xz affair blew up. Is it immune?
I only said "maintained by grown ups". Grown ups can't solve hard problems by snapping their fingers, but children just pretend they don't exist. Or at least pretend that the invulnerability of youth will protect them.
I agree that we are all doomed. As in, we are all doomed to the fate that we very well might be a victim of a cyberattack due to no fault of our own, even if we make all of the right choices.
But that doesn't mean to give up. Rather it means to minimize our risk to the best of our capabilities within the means of our organizations. Either stay the hell away from npm, or do the work - update your dependencies and fix the bugs that are caused. That's not a guarantee or a panacea, but it's the responsible thing to do.
It also forces us to understand the hidden costs of an ecosystem. If you actually do the work - and it turns out to be more costly than you expected, then you have learned something. Use that new information next time you select a package to be a dependency.
In @Applied-Mediocrity's situation - well, someone else made the bed and you have to sleep in it. Does it really matter if more of your eight hour's pay goes to keeping up to date? If your employer insists that you don't spend that time, then it's just a time bomb waiting to explode. You decide if you want to be there when it does.
Electrician's don't run fewer circuits just because their bosses tell them too. Engineers don't specify smaller trusses just to bring in more profit. Doctor's don't skip treatment because the patient is probably going to die anyways. All of the things occasionally happen, but in these case, we don't blame the external pressures, we blame the people making the choices.
-
RE: Is updating dependencies frequently still good advice?
@Arantor said in Is updating dependencies frequently still good advice?:
This to me indicates something very, very wrong with the ecosystem.
Of course it is. The only thing you can control is your participation.
You have two choices:
- Deal with the mountain of dependencies.
- Choose another ecosystem
You are complaining about the fact that an environment that encourages public participation and moving fast creates conditions where things are always changing all around you and much of it is maintained by a teenager working part time without pay. That's what anything from the npm ecosystem is if you don't impose a curation layer.
Your alternative is one of the many enterprise focused platforms. J2EE gets picked on a lot and deserves much of it, but it's pretty comprehensive and is maintained by grown ups. I've mentioned .Net Framework a bunch of times, but you get get a long way with .Net Core using only Microsoft's packages. You still have breaking changes and abandoned packages, but your life will be better than what you have described. I'm sure there's thirty other suitable choices that have yet to be mentioned on this thread.
-
RE: Is updating dependencies frequently still good advice?
@Arantor You're simply asking for someone else to solve your problem. There are plenty of instances where things are left out of languages that shouldn't have been, your left pad example is a good one, but those aren't the majority of our dependencies.
At the end of the day, you either have to write on a monolithic platform (which there pretty much haven't been any of for a long time now), or deal with dependencies. The mature approach is to have a formal dependency vetting program. The organization has to live with the fact that a package updates a lot, introduces bugs a lot, makes breaking changes a lot, or gets abandoned, so the organization is allowed to reject a dependency as too much debt.
-
RE: Is updating dependencies frequently still good advice?
@Bulb said in Is updating dependencies frequently still good advice?:
is still called Asp.Net
Yes, you are correct. However, it's usually referred to as AspNetCore to differentiate it in technical contexts. And lo and behold, the reference I was referring to was a Microsoft.AspNetCore component and it part of modern rest apis, razor, and the like.
-
RE: Is updating dependencies frequently still good advice?
@LaoC said in Is updating dependencies frequently still good advice?:
what Microsoft told you
Look here: https://learn.microsoft.com/en-us/lifecycle/products/microsoft-net-framework
If I had an app that was on the latest build of .Net Framework 3.5 and I was concerned about the effort to move to 4, Microsoft is giving me nearly five years from today (January 2029) of support so I can plan my move.
If I build a brand new product on .Net 8, they give me support until November 2026.
-
RE: Is updating dependencies frequently still good advice?
@loopback0 said in Is updating dependencies frequently still good advice?:
Update frequently for the sake of updating? No.
I'm the guy at my company that determines what is required to comply with regulation and to make our customers comfortable sharing with us what they share with us.
For both, the absolute minimum that they want to hear is that we scan for vulnerable components every 30 days, address critical flaws rapidly, and get off of any unsupported component within 90 days. Of course if something turns out to be a lot of work we document the exception and create a project to track it. No one is going to sue or jail us for exceeding 90 days if something is a lot of work, but they don't want to hear that we haven't even assessed it yet at 90 days.
My industry is more heavily regulated than most, but a lot of corporate development is performed under these conditions.
I'd much rather have Microsoft waggle their finger at me for using .Net Framework than board the update train that is .Net Core. We do it some now and will do more in the future, mainly because getting supported components for .Net Framework is getting harder and harder. But I'm neither excited nor pleased about the changes.
-
RE: Is updating dependencies frequently still good advice?
@LaoC said in Is updating dependencies frequently still good advice?:
I wonder why anyone would think that?
Never trust marketing. They also told us that Silverlight was the future. Everyone who believed them was left an abandoned platform just a few years later.
-
RE: Is updating dependencies frequently still good advice?
@izzion Also, installing .Net stuff has been just a file copy for like twenty five years now. Anyone that needs technology to help them with this is pretty helpless.
.Net Core added more complication by locking in use files more vigorously then .Net Framework did, so some of the things that have been introduced solve some of the new problems that were created.
Either way, having an image with the right framework, a container with the right framework, or a push install of the right framework are all really easy things for a competent team to pull off.