231–240 of 333 posts
I am not sure how this advice is supposed to work though : the number of problems that are solvable "in an afternoon" is very small.
Especially the problems I know will take only an afternoon to solve and won't need to be maintained afterwards.
It's a matter of judgement, but here's a few observations: - With a little experience, you know what gets fiddly and what doesn't. Today for instance, I needed a way to remove tags in an SVG document, which looks a lot like HTML tags. I quickly ended up finding that Regex is not the solution (a well known guy on SO wrote an answer that looks like a huge warning sign). I also couldn't enumerate all the corner cases. S…
Agree ! it irks me a lot that I often see update bots tracking new releases.. it is just begging to be exposed to regressions.
We need to find a happy medium though. Otherwise whenever you actually need to update something (e.g. you need add a new dependency which only handles one of your other dependency if it jumps 20 releases ), you have a huge version gap to cover.
Earlier quoted context omitted.
Less code is (in general, to certain limits) easier to understand and requires less maintenance.
If I am using code that someone else writes and maintains it is easier to maintain. But I can maintain code that uses Entity Framework (or Dapper) much easier than I can maintain code based on a custom ORM that the “architect“ wrote.
BRB, going to go roll my own AES -- what could possibly go wrong?
Probably not much more than picking an AES library written from someone else.
It's fairly unlikely that your custom AES would function at all unless it was functionally correct.
Your bespoke AES will likely have timing sidechannels, but so will most AES you go pick off the shelf. (in fact, if you happen to need CBC mode, virtually any AES you pick off the shelf will end up having timing side-channels, because most code that doesn't is GCM only)-- particularly because it's hard to be both high performance and side-channel free without using SIMD, and to do that you need to operate on multiple blocks at a time.
In fact, since you happen to know your environment is targeting only hardware with AES-NI (in my hypothetical), you'll just use that and you'll even be free of side-channels too.
The "abstinence only cryptography" advice was originally about inventing your own blockciphers and such, not implementing existing ones.
Okay so you're smart and so you'll want to go take your AES from some highly reviewed sourse with lots of smart people. You pick.. say.. the Linux kernel. Welp if you picked the plain C implementation in it, congrats, you just got yourself a bunch of timing side-channels.
There are, of course, plenty of things that can go wrong in making your own implementations-- so it's not entirely misplaced to apply it to implementations-- but sadly you are not more likely to avoid them by simply picking one written by someone else. If you understand the domain then you can select a good library and evaluate it, but if understand that you could likely also write your own. :(
On the plus side, a simple blockcipher isn't the sort of dependency that is likely to have a substantial on-going cost either. It won't randomly change its behaviour (we hope, at least not until haxors take over the upstream repository), its functionality is simple and well specified, etc.
So it is probably fine to use one from a library and the OP's advice doesn't apply. But all the reasons why the code you wrote would probably be broken? They probably still apply to the library.
Never use store-bought bricks if you can replace them with an afternoon of brick making. https://youtu.be/D59v74k5flU
I knew which video it would be before clicking... But to your point they're often not really "store-bought" bricks though. More like bricks someone was giving away on the side of the road, you're free to use them to build your house but with no guarantees they work and the instructions are missing or incomplete. Oh and they're the wrong shaped brick but you only figure that out later.
Earlier quoted context omitted.
There are fully correct JSON parsers you aren't going to beat, even if you implement a subset. [1] [1]: https://branchfree.org/2019/02/25/paper-parsing-gigabytes-of...
No, I won't beat them. But if it a limited subset that I can implement with twenty lines straightforward code, that will often be cheaper. I've been on projects where they imported xml-parsers many times bigger than the rest of the whole codebase just to send a well formatted order number.
By using a third party library you are writing twenty lines less code, so it's cheaper in that aspect.
There are probably libraries that are faster than your twenty lines of un-optimized code, so it's cheaper as far as computing resources are considered too.
The only time it could matter is when you ship the code to the client through the wire (such as a Javascript bundle).
Earlier quoted context omitted.
Then you reevaluate the situation. YAGNI is true here too.
YANGI is nice but when the PM asks you why it would take two months to accept a new JSON format from a client and you’ll answer well because we didn’t want to use an industry standard fully functional and vetted JSON parser so we essentially wrote our own edge case parser we both know how that conversation will end. And YANGI doesn’t have anything against dependencies.
When there are new requirements you do a quick estimate if you should add four new lines to the existing 20 or if it is worth to switch to an external library. 4 new lines to the 20, just add them to the core. But if this is regularly occurring that you have to add things, or requirements affecting this particular little parser that was supposed to be simple and static isn’t, then you should probably change your decision and use the library.
But you do that only then. Because chances are that with your approach you are going to drag along a large generic library that you only use a tiny fraction of. And that also has costs. In particular if your immediate impulse always is to add another library instead of writing things yourself.
Earlier quoted context omitted.
No, I won't beat them. But if it a limited subset that I can implement with twenty lines straightforward code, that will often be cheaper. I've been on projects where they imported xml-parsers many times bigger than the rest of the whole codebase just to send a well formatted order number.
What do you mean by cheaper? By using a third party library you are writing twenty lines less code, so it's cheaper in that aspect. There are probably libraries that are faster than your twenty lines of un-optimized code, so it's cheaper as far as computing resources are considered too. The only time it could matter is when you ship the code to the client through the wire (such as a Javascript bundle).
Here is something that has happened to me more times than I care to count: I have a dependency on some library. It's working well for me. I build some sort of small project with it, like the info website for my mother's business. Doesn't need to be updated very often, just needs to be there and have her contact information. A year later, I get some automated email telling me some dependency of a dependency of my dependency has some kind of obscure security issue. I'm busy. This project isn't supposed to be a core, constantly making project. I don't really have time to evaluate if the problem is an issue for me, so I go to just upgrade everything and appease the squawk box. Oh, turns out that in the time between when I used the library and the security issue was discovered, the developers have completely redesigned the whole thing and the only version that includes the security fix is a version that isn't compatible for my config scripts anymore.
All because I didn't want to spend the time to write some stupid simple string concatenating code for writing an HTML template, I now have to spend time completely relearning this library. And probably rebuilding the build scripts, too, because nobody can just leave well enough alone.
"Oh, but if you wrote the code, you might have written a security bug, too". And I could fix it on my own, too.
When did programmers stop programming? Most of the arguments I see for ridiculous levels of package integration come from a place of devs not trusting themselves to write stupid simple code. Like left-pad. "Someone smarter than me has figured at all the edge cases". You don't need all the edge cases. You need to just learn how to do your job.