201–210 of 291 posts
Earlier quoted context omitted.
Software engineers are mostly aware of this. There is just little market demand for this level of robustness.
there was no market demand for building codes, either. that's why they're laws
Earlier quoted context omitted.
I'm not any of those guys, and of those 3 rust is by far the least garbage. Garbagicity is a spectrum.
I was sure reading your first post that you will propose rust. Rust users never cease to amaze me.
Earlier quoted context omitted.
> Java need standard logging with slightly improved ergonomics That's exactly what JDK9+ java.lang.System.Logger is. See https://stackoverflow.com/questions/59976828/difference-betw...
It seems to be mainly intended for use internally in the JDK, though. From the JEP[1]: "It is not a goal to define a general-purpose interface for logging. The service interface contains only the minimal set of methods that the JDK needs for its own usage." And from the motivation section: "The proposed service enables applications to configure the JDK to use the same logging framework as the application: It would on…
When are they going to release Log5j? Or even Log4k to address these issues?
The log4j author already did this about a decade ago. No one could understand log4j back then, so the replacement is much, much simpler, and API compatible for 99+% of use cases. Few projects seem to have bothered moving to it, probably becuase log4j is such a collosal pain to set up or modify.
If you're scoffing at this, I want you to do an experiment. Imagine yourself at 26, when you just knew enough to be dangerous. Or as the person you're currently mentoring/would like to mentor. Now go into your application code, set a breakpoint on one of the moderately complex `logger.info()` calls, run your application and step into log4j. All the way down, until it writes to disk.
If you don't say "what the fuck" out loud at least once, you're a soulless monster and should go live in a cave.
If your application has a pretty good architecture, you may well discover that the code leading up to the `logger.info()` call is substantially less complex than the code below it. Just to write some text to the end of a single-writer file.
It chaps my ass that log4js, which claims specifically not to be a javascript port of log4j, has the same pattern of layers and weird indirection (some of which are avoided by monkey patching, which is in many respects even worse from a legibility standpoint, and absolutely from a discoverability standpoint). Much of this is chasing after not implementing the same 1 line function 6 times, which is made weirder by the fact that you have to write individual unit tests for each of the log levels, so you've already written 95% of the duplicated code.
Logging frameworks are a nearly canonical example of DRY as an antipattern.
If you automatically update your dependencies all the time, you will constantly get new bugs, issues and sometimes even malware. If you don't update your dependencies all the time, you will be vulnerable to old bugs and issues. The current software engineering paradigm has no meaningful answer to this , no matter what "security experts" tell you. In a sane industry this realization would lead to a change of the parad…
If you don't update your dependencies all the time, you will be vulnerable to old bugs and issues."
>has no meaningful answer to this...a sane industry this realization would lead to a change of the paradigm
This sounds like gene mutation and evolutionary selection pressure. It's sort of a fundamental aspect of the universe no? There may not really be a meaningful "answer" to this in principle just various half-measures to muddle along and adapt to this reality, survival of the fittest in a sense.
If you automatically update your dependencies all the time, you will constantly get new bugs, issues and sometimes even malware. If you don't update your dependencies all the time, you will be vulnerable to old bugs and issues. The current software engineering paradigm has no meaningful answer to this , no matter what "security experts" tell you. In a sane industry this realization would lead to a change of the parad…
Aren't we already doing that, to some degree, by watching for notifications of vulnerabilities, and then manually patching or updating? Sure, with this method, we have the ability to decide to ignore a vulnerability, but I'd guess most people aren't great at assessing risk (and may not fully understand the severity of a vuln, or if their use of the software makes them exploitable), and should probably just update whenever a fix for a vulnerability comes out. So you might as well automate this.
> So the exact software you compile will depend on whether or not you can connect to a 3d party service?
Anyone who builds against public package registries (Maven Central, npm, pypi, crates.io, etc.) already has this problem. Some people will go to the effort of putting their own proxy cache in front of these registries to insulate themselves from downtime, and I expect these sorts of people would do the same for a 3rd-party vulnerability updater service.
Regardless, I wouldn't expect this to be a "pull" model, wherein you wait until the next time you'd build before getting security updates. More likely you would get a notification or even an automatically generated pull request (like GitHub's dependabot does) when a security update is available. Then it's up to you whether you want something else to automatically apply those updates, or you can review them yourself and apply manually.
I think you're just making a mountain out of a molehill. There are several existing options to automate or partially automate this, depending on your trust of the relevant third party. And you can still do it manually, if you so desire.
If you automatically update your dependencies all the time, you will constantly get new bugs, issues and sometimes even malware. If you don't update your dependencies all the time, you will be vulnerable to old bugs and issues. The current software engineering paradigm has no meaningful answer to this , no matter what "security experts" tell you. In a sane industry this realization would lead to a change of the parad…
It'd be cool if devs didn't suck ass at writing code but that's the world we live in.
Earlier quoted context omitted.
>"Use a build tool to do dependency checks!" > >And then what? > >"Only update libraries if they have vulnerabilities." > >So, should this be a manual process where I have to dig through obscure warnings every time I build something? > >"No, you can automate it!" > > Congrats, you've just outsourced the decision making process about which versions of libraries to use to some 3d party. You've also made your build proc…
I don't see how you have really fixed the break much. Especially if you can "push back" and say no to an update, you are just setting yourself up for when the update is even harder to accept. (That is, the further behind on an update you are, the harder to take it. Typically.) And then there is the "I want the fix, but I don't want the added attack vector of features that comes with it."
If you automatically update your dependencies all the time, you will constantly get new bugs, issues and sometimes even malware. If you don't update your dependencies all the time, you will be vulnerable to old bugs and issues. The current software engineering paradigm has no meaningful answer to this , no matter what "security experts" tell you. In a sane industry this realization would lead to a change of the parad…
On the contrary, I believe we do. The answer is ongoing maintenance.
The basic problem is that people persist in looking at software as a fundamentally mechanistic artifact you finish and ship in a static environment. Then you move on to the next thing. This is fundamentally incorrect. Software engineering is a process that takes place in an adversarial, human-driven environment. There is fundamentally no automating this away because human decision-making work is required.
Any security expert worth their salt will tell you this. As long as you persist in trying to view software as a fixed artifact in a static environment, you will find there is no meaningful answer. Those who come to terms with the dynamic, human-driven reality will find that there's a well-understood - if inconvenient and expensive - answer.
Earlier quoted context omitted.
Lets not forget that promotions are for those who build new stuff and those who maintain old stuff don't get promoted. To add further insult to injury, colleges send SWE/SDEs to the work force to learn to 'actually code', while companies have no time to train jr developers so they are just thrown in the fire and hope for the best.
At most companies I've worked for, mentoring and training junior engineers is a requirement for promotion. Also, you might not get promoted for maintenance but 1. keeping it running with a healthy userbase and demonstrating high impact does, and 2. if you know how to spin it, then maintenance work can look like "building new stuff".
You've worked for some great orgs, then! My experience is mostly the opposite. One company I worked for did value mentorship, at least somewhat, and it was a factor in promotion decisions, but not mentoring others didn't really stop people from getting promoted.