I do use scripts for more complex things. But even then I have a few very frequent one liners in my history that are 3-4 commands chained together that I have not bothered to convert. It tends to only be when they start to have logic in them that I will write a script for. Or more one off commands that are easier to edit in a multi line editor then trying to get everything right in the shells prompt.
I used to know a guy that would put everything into aliases or scripts in order to avoid remembering them. It worked well most of the time but when something went wrong or was not covered by his scripts he would struggle a lot. He avoided learning the underlying commands and what they did and so could not adapt to things when circumstances changed even a little - which does happen quite a lot.
Which is probably another reason I don’t use them. I don’t like to set them up straight away while I am learning the tool and once I am comfortable with it a reverse history search is good just as good/quick as a true alias anyway and means I never forget what I am doing and can edit it on the fly easily when needed.
TBH, not quite the same. You have to know which one you want. If you don’t quite or get it wrong you need to clear the line and start again. I quite like that I can reverse search and keep typing, or undo what I had typed and still see a list of the most recent things and can select from that list once I see what I want. This works for any command I have previously typed and dont need to setup specific key sequences for it - just any part of that command will find it again. Also works for complex chains of commands or pipes which I do not think aliases do work for.
I seem to be one of very few people that does not use shell aliases. I much prefer just using the reverse history search for previous commands instead. That way I don’t have to remember what letter I picked for different things, just ctrl+r then partially type out the command and I can see what it will execute. Bonus that I don’t need to set them up before hand and that I can edit them before executing them for those times when I need to do something slightly different.
SIGINT is sent when you press Ctrl+C. SIGTERM is sent in just about every other situation - basically when the system wants the program to end. For instance when systemd wants to stop the service or the default signal with programs like kill pkill htop etc. You should catch both of these signals.
But it applies to features, not coding practices
I disagree. It applies to everything. I would argue it applies to SOLID most of all. I do not find SOLID principals to be good ones to follow most of the time. Situational they can be useful but I have seen so many projects that strictly follow SOLID that becomes an unmaintainable mess.
If you struggle to understand the SOLID principles or think they are too general, then I would suggest you follow my SOLID Training Wheels until you understand them better.
I hate this excuse. If the answer to the problem is you are just not doing it right then it is a terrible answer. But lets look at some of this advice:
Summary: 1 piece of code has 1 responsibility. The inverse: 1 responsibility of code has 1 piece of code
Training Wheels:
Follow the 10/100 Principle
Do not write methods over 10 lines
Do not write classes over 100 lines
No. Just no. Making everything as small as possible is exactly what is wrong with the single responsibility principal. I agree that everything should have one responsibility, but that responsibility might be complex and require a lot of code. Hiding the code behind other functions does not make it easier to read, only means you need to jump around a lot in order to understand what it is doing which IMO makes things harder to read. Every time I jump location it gets harder to remember where you came from or what the wider context is. Keeping related code together is more important then creating small function.
Just take a look at the stdlib of almost any mainstream language. Like the ArrayList in Java, or Vec in rust. These classes are thousands of lines long with many methods being 10-20 lines of code with some even longer then that. Is this code bad or hard to read? Not for what it is doing. And code like this is not atypical in stdlibs, you can jump to almost any class/struct in a language of your choice and see similarly structured code. And in all cases the classes represent one thing and its methods do one thing on that object regardless of how many lines of code they contain.
If you have to change a class that already breaks the 10/100 Principle:
take your code out of that class and put it in a new class first so the original class is smaller
Check-in this refactor without your new code
make your changes in the new class
Check-in your new code
IMO this breaks the single responsibility rule. If new code is mostly related to a single class then it should be added to that class as that is what the class is responsible for. Adding a new class for every bit of logic just splits up the responsibility and makes it far harder to find what is responsible for something.
I could go on about the rest of that training guide - which this whole post seems to be an advert for.
YAGNI, will ruin your code base if you apply it to how you code.
It applies just as much to how you code as to what you are coding. If you added every programming paradigm and principal to your code base it would be a unreadable mess. Not to mention impossible to do as loads of these conflict with each other.
Pick the right tools for the right job. Don’t blindly apply anything to every situation. There are times when the SOLID principals can help but there are also times where they make code worst. Instead always ask yourself if there is a simpler way you could be doing something and if when applying a principal if it actually made the code easier to read (ask someone else as well as it can be hard to tell yourself). Don’t be afraid to break a principal if it is not helping.
If that were the main goal why not just ban them from the extension store? Or why allow manifest v3 extensions to block requests at all? Ad blockers still work and this did not kill off any of them. Just forced them to change some of their functions. I don’t doubt the executive overlords are happy about the turmoil that this has done to ad blockers but they would be pissed if that was the only or main goal of this as there are still loads of effective adblockers about.
That is a more complex story then that. The manifest v3 changes primary give a lot of security and privacy changes that stop extensions from doing a lot of questionable things in the background on all your page you visit. But that does stop ad blockers from doing a lot of what they currently do - blocking in page elements and modifying the pages you visit. But it does not block them from blocking page requests so ad blockers like ublockorigin lite can still function in a more limited capacity to block ads.
I do think the teams outside of the chrome team are happy for this change - but I don’t think the chrome team set out to do this purely or even mainly to block ads.
Besides even if they did it does not change my argument - whom ever buys chrome will likely want to squeeze it for more money then google currently are doing and will likely do far worst things like including ads directly in the browser. Or trying to monetize it in some other way.
I would love it if chrome where maintained by some non-profit foundation. But how likely is that going to be from a court order sell off?
I would rather they split up google in other ways first.
TBH I am not sure this will end well at all. Google needs to e broken up but splitting off chrome? What will that achieve? Chrome does not directly make any money for Google really, they don’t sell it, they don’t sell ads in it, they don’t even collect much personal data though it. No where near as much as they really could if they really wanted to. Google have not been terrible at managing chrome or pushing as much profit out of it as they could.
Instead they are using it to create a good platform for all the rest of their services where they actually make money. So what will selling off this loss leader do for chrome? Most likely it will get bought up by someone else that will want to see a return on investment that wont be using it as a loss leader. Which I can very well see it getting en-shitified like everything else that is purely driven by profit.
Best case it is gets bought by a non profit foundation that can develop and take care of it - but lets be real, they wont have the money to out compete anyone wanting to buy it to make more money.
I personally don’t really trust google with my browser either - hence why I avoid chrome. But I would trust anyone seeking to buy it for profit far less and can very well see this as a overall negative if the wrong people buy it (which I see as more likely).
That being said, I don’t keep one in my car.
Now is the time to change that.
Documentation is generally considered one of the stronger points of rust libraries. Crates.io is not a documentation site you want https://docs.rs/ for that though it is generally linked to on crates.io. A lot of bigger crates also have their own online books for more in depth stuff. It is not that common to find a larger crate with bad documentation.
They refuse to make changes to their C code, so it can cooperate with Rust code via bindings.
I don’t even think the rust devs where asking for that. They are refusing changes by rust devs that help with rust while making the c code clearer and even refuse to answer questions about the semantics behind the c code. At least as far as I can see from the outside.
Can when the specific situations are reached in very micro benchmark situations. But overall on aggregate you find even JIT languages don’t strictly outperform pre compiled languages for general workflows when looking at languages of a similar class. When you compare them to compiled languages like C/C++/rust/zip (aka ones without a GC or much of a runtime at all) then JIT languages fall behind like all other GCed languages.
Of these 25 reasons, most apply to a lot of languages and are far from Java exclusive or even java strong points. Pick any mainstream language and you will hit most of the benefits it lists here. With quite a few being almost meaningless. Like this:
Java/JVM/JIT can achieve runtime optimization on frequently run code, especially on something that’s running as a service so that you avoid the overheads from JVM startup times.
Compiled languages generally don’t need a JIT or to be optimized at runtime as they are compiled and optimized at compile time. And most language that don’t have a runtime like Javas already run faster than Java without its heavy startup time. Language with JITs are generally interpreted languages which have these same benefits as java lists here. Though do often suffer from other performance issues. But really at the end of the day all that really matters is how fast the language is and how good its startup times are. Java is not ahead of the pack in either of these regards and does not do significantly better then other languages in its same class (and often still drastically sucks for startup time).
Or
Much of a company’s framework can be stable Java, with Scala or Clojure-backed business logic.
Many languages you can embed other languages inside. Nothing really special about scala or clojure here except that they work well with java. And I don’t really see this as a major benefit as most places I see dont separate their core code and business logic into different languages.
And the remaining issues that are more java specific are:
Java was one of the first mainstream GC strongly typed OOP languages. So it got its niche.
Java has been one of the main programming languages taught in colleges and universities in the last few decades.
Java’s Legacy Migration: Many banks in particular migrated legacy systems to Java in the early 2000’s when it was getting a lot of popularity and the industry was collectively in the midst of a huge OOP fever dream.
Which all paint a picture - it was popular long ago and taught in universities and lots of business pushed it when back in the day. And now it is hard to move off it.
And lastly:
Oracle
What? How is this a point? If anything this should be a massive negative.
Not exactly 25 reasons to pick java in financial enterprise.
Did you read the article at all?
“Putting all new code aside, fortunately, neither this document nor the U.S. government is calling for an immediate migration from C/C++ to Rust — as but one example,” he said. “CISA’s Secure by Design document recognizes that software maintainers simply cannot migrate their code bases en masse like that.”
Companies have until January 1, 2026, to create memory safety roadmaps.
All they are asking for by that date is a roadmap for dealing with memory safety issues, not rewrite everything.
Or refactored at a later date.
Creating functions is IMO not the first thing you should do. Giving variables better names or naming temporaries/intermediate steps is often all you really need to do to make things clearer. Creating smaller functions tends to be my last resort and I would avoid it when I can as splitting the code up can make things harder to understand as you have to jump around more often.
Comments are not always a waste of time, but comments that repeat or tell you what the code is doing (rather than why) are a waste. For legacy code you generally don’t have comments anyway and the code is hard to read/understand.
But if you can understand the code enough to write a comment you can likely refactor the code to just make it more readable to start with.
For code that does not change generally does not need to be read much so does not need comments to describe what it is doing. And again, if you understand it enough to write a comment to explain what it is doing you can refactor it to be readable to begin with. Even for mathematical equations I would either expect the reader to be able to read them or link to documentation that describes what it is in much more detail to name the function enough that the reader can look it up to understand the principals behind it.
And they were arguing the same - just renaming the property rather than reusing it. You should only have one not both but naming them differently can make it clear which one you have.
But here I am arguing to not have either on the user object at all. They are only needed at the start of a request and should never be needed after that point. So no point in attaching them to a user object - just verify the username and password and pass around user object after that without either the password or hash. Not everything needs to be added to a object.
Protip: Don’t write 600 lines of code without ever testing it at all. And by testing I mean anything, manual testing included or even just compiling it or running a linter over it. Do things incrementally and verify things at each step to make sure you are not drifting off course by some faulty assumption you made near the start.