Indeed, I've visited via Mobile. So with tongue in cheek: "are mobile users not entitled to those informations?" :D
That would require another account but I'm reluctant to create one since:
Risk is in quotes since it's more of a "why bother?" than "oh no my info got stolen"
The code shown contains an error. Instead of multiply by seven, you probably mean divide by seven.
Faulty code example: Math.floor((Math.random()* 7)+1)
And half of them are "curated list of X"
Hmm, I see. The perfectionist in me would want to shed that processor load though ^^
Without any judgement: why are your servers running X11? Just because you dislike SSH'ing to them?
I know that we specifically don't use the snapshot feature for a reason. I think it has to do with how snapshots are restored. But I would need to ask my colleague why exactly we're not doing it.
We do full dumps and data-only dumps in regular intervals.
Review is done before code gets into main, but that’s inefficient for most of the non-mission critical projects out there. A better approach is to optimistically merge most changes as soon as not-rocket-science allows it, and then later review the code in situ, in the main branch.
Assuming you have a project with continuous delivery, that is an absolute foot gun. Optimistically merge the change and then realize in situ that you forgot the WHERE part of your SQL command (or analog statement of the query builder)? No fucking thanks.
There are some good points in it but the list feels poorly written as it contains very general tips which feel like fluff to increase the article length like:
Protect the client-side against attacks.
Or just wrong stuff like:
Validate all server-side input data.
If you can trust someone, it's the server. You should validate data coming from the client on the server side.
Some things even contradict each other like
Implement strong authentication, such as two-factor authentication (2FA).
And
Use secure authentication mechanisms such as OAuth.
Assuming your app is an OAuth client, you have no say in how the identity provider identifies the user.
Good point, but even better than
Monitor file and source code integrity.
is having the application source code read-only, ideally owned by another user to avoid the confused deputy problem.
If all of those servers are yours (which they likely are, since you get ssh access), you can use one key for all. Using different keys would make one compromised key less problematic. But if someone was able to copy one file of your system, they can copy multiple files.
That resolves keeping track of things as well 😄
absolute galaxy brain moment
The stalebot is most times useless. The only scenario where I can see use of it is a maintainer waiting for the reporter to add information. But closing issues because no maintainer checked on them? That's garbage and discourages bug reports.
Ducking Medium again. No I don't want an account with you. The article can't be that interesting.
You forgot the package hollywood.
I use the cookiebro extension for that. Allows whitelisting domains or single cookies and can clean up all others with a few clicks.
I would recommend key based authentication for SSH connections. For the normal connection, the key pair is enough, if you want admin (root) access, you would use the command sudo which in turn requires a password. For creating a default admin account: Linux does this for you, it's called root. You should create a personal user to work with in daily business and add it to the sudoers group (permits using the sudo command)
I too consider that if err != nil a bit complicated to type. Most times, I wrap it away in a function like your Check0. I know that the major "framework" for command line applications (cobra) has a similar logic with its checkError function.
Since when is hiking in torch light proof of fascism fantasies?
Turns out this technique has a name. I've seen them in terraform provider templates and thought "nice idea".
This post resonates so much with me. Fuck "unique style", adhere to conventions and don't surprise the user by "being clever".