If you didn’t push your changes yet, you can use git filter-branch to remove it from all your commits. If you already pushed (or figured out that someone committed and pushed a key), you can do the same with force-push, but also revoke the key.
A bit too late. 20 years ago this would be great. (I started 12 years ago, used it for couple of hobby projects.)
That’s why I wrote this. There’s a chance that the developer will read my comment and improve animations.
sh is for shell.
Take a look at Dart+Flutter.
Python would be OK. Ruby is nearly dead nowadays. JS itself is used rarely, better consider using TS (however I don’t recommend using them for anything other than web frontend). Go is a great language but it’s unpopular in GUI development.
DEL is supposed to delete one row of text
It’s not. It overrides a row on a punch card, i. e. one character.
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.
What?