Jenkins is not a modern CI. It is a historical milestone, but if you read an article you should see that it was replaced by other tools. Now I don’t recommend considering Jenkins for new projects. It it fast to set up but extremely hard to support and full of old bugs and legacy code. Writing Groovy pipelines is much harder than pipelines in gitlab/github/forgejo/etc. Tens of plugins you have to use even for simple tasks have inconsistent syntax, many of them are buggy, they often become unsupported or deprecated. This all consumes lot of resourses: I maintain an instance that eats ~4G of RAM being idle.
It’s not a proper fix, there are still cases when correct escaping is impossible and the function simply returns a error. I don"t know if if this possible at all to escape any string or if it is just because of lack of documentation, but anyway i wouldn’t call this a thing that is easy to fix.
Options. We’ve got lots of them. So many in fact, that you need two strong people to carry the documentation around. So many that it will be a cold day in hell before half of them are used. So many that you are probably not going to do your work right anyway. However, the number of options isn’t all that important, because we picked some interesting values for the options and called them …
Defaults. We put a lot of thought into our defaults. We like them. If we didn’t, we would have made something else be the default. So keep your cotton-pickin’ hands off our defaults. Don’t touch. Consider them mandatory. “Mandatory defaults” has a nice ring to it. If you change them and your system crashes, tough. See Figure 1.
it should be an easy fix
But it’s not. Have you read the article?
Premature optimization is the root of all evil. Implement algorithm the easiest way possible, profile your application, determine if this implementation a bottleneck or no. If yes, try other implementations, benchmark them and find the fastest one. Note that optimized go code can be faster than non-optimal code in rust, C, assembly or any other language.
Theoretical level is useless, believe me. What is useful is understanding at intuitive level. You can achieve it with or without knowing theory, but you need a lot of practice anyway. Also, different languages providing OOP actually encourage different approaches. You have to follow one that your PL is suited to and that is the best solution for your current task, not that OOP or any other paradigm dictates you.
Does it really matter? This knowledge won’t help you in writing code.
I’d better read something on the inode uniqueness problem than this. I’ve already got in trouble with GNU tar because of duplicated file identifiers in overlayed FS.
It is common that libraries have fewer stars than end user apps. Especially if they never spammed in communities.
zed has always been open source. Seems that you are just trying to squat its name, am I right?
C.
There are a lot of books describing algorithms. Most network protocols are described in RFCs as well as advices on their implementation. So you are looking in the wrong place. Source code documentation is usually enough to be understood by coders who are already familiar with common algorithms, protocols and APIs or know where to find their description. Only things that are very specific to the project can be described in details.
If this is so interesting, where’s the discussion you are talking about? And I did not say there’s nothing interesting in Wikipedia. It is easy to find for everyone who needs it.
No problems with Wikpedia, I always can go there and find what I need. There’s a problem with flood of meaningless link-only posts here.
Are you going to post links to all Wikipedia articles here?
Why not use a static site generator?
Just came here to say that on the photo is Gromozeka. He is an archeologist, not a programmer.
It’s not. It overrides a row on a punch card, i. e. one character.