Disable all observers in your test suite by default. They should not be complicating your model tests because they should have separate concerns anyway. You don't need to unit test that observers actually fire, because ActiveRecord's test suite does that, and your integration tests will cover it.

Warning: Do not accept plain user IDs, such as those you can get with the GoogleUser.getId() method, on your backend server. A modified client application can send arbitrary user IDs to your server to impersonate users, so you must instead use verifiable ID tokens to securely get the user IDs of signed-in users on the server side.

Writing json_populate_record in the FROM clause is good practice, since all of the extracted columns are available for use without duplicate function calls.

Since using case insensitivity is so widespread, take their sign up email address and make it lower case. Whenever they try to log in, convert that to lowercase as well, for comparison purposes, when you go to see if the user exists. As far as sign up and sign in go, do a case insensitive comparison. If the person signs up as Steve@example.com, you'll still want to allow them to sign in later with steve@example.com or sTeVE@example.com.

But you should also keep track of the email address that they signed up with in a case sensitive fashion. Any time you send an email to them, be sure to send it with that original casing. This allows the email server to handle it however it feels like it needs to. So even though the person may always be signing in to your site with steve@example.com, if they signed up as Steve@example.com, you'll always send email to Steve@example.com, just to be safe.

If you send links with a secret login token with email, then they should be single-use and expire rather quickly.

It's usually undesirable to add a default scope. It will take more effort to work around and will cause more headaches. If you know you need a default scope, it's easy to add yourself .

Glyph 0 must be assigned to a .notdef glyph. The .notdef glyph is very important for providing the user feedback that a glyph is not found in the font. This glyph should not be left without an outline as the user will only see what looks like a space if a glyph is missing and not be aware of the active font’s limitation.

Prefer alias when aliasing methods in lexical class scope as the resolution of self in this context is also lexical, and it communicates clearly to the user that the indirection of your alias will not be altered at runtime or by any subclass unless made explicit.

a principle I use is: If you have an accessor, use the accessor rather than the raw variable or mechanism it's hiding. The raw variable is the implementation, the accessor is the interface. Should I ignore the interface because I'm internal to the instance? I wouldn't if it was an attr_accessor.

Please don't write answers in comments; we have a policy against this. If you have an answer to the question, write it up as an answer. Thanks.

For this very reason, we have the hx’s on our site dynamically create id’s. I love being able to direct people directly to a particular part of a page when I find something interesting, but the problem is that only we, as developers, know how to do this.

Write modules that do one thing well. Write a new module rather than complicate an old one.

We can certainly explain the issues snap cause without using political or religious arguments. We did so in the documentation I linked to above.

For the future, you should: Install LTS (Long-term support) versions as they have an 8-year life span (with Extended Security Maintenance) or 5 years without. The current LTS version is Ubuntu 18.04.1 LTS Bionic Beaver released on July 26, 2018 with an EOL in April 2023. OR Carefully watch the EOL of the interim / development releases and upgrade frequently.

I used to be a staunch defender of proper reply styles, even for casual emails. Insert your replies below the relevant paragraph and trim the exchange to be just about the matters of discussion.

Don’t apply caching if the process is expected to react to changes during the caching period. i.e. Don’t cache when mixing reads and writes.

there’s 3 steps to building software: Make it work Make it right Make it fast

Good commit hygiene in general is a tough thing to enforce. It requires manual labor and descipline, from both the author and the reviewer.

in the absence of an immediate need, it is simpler to leave out error handling until a final .catch() statement.

When sanitizing, protecting or verifying something, prefer whitelists over blacklists.

in order to track the always-improving upstream project, we continuously rebase our patches on top of the upstream master

it reminds me of IT security best practices. Based on experience and the lessons we have learned in the history of IT security, we have come up with some basic rules that, when followed, go a long way to preventing serious problems later.

The fact is that it doesn’t matter if you can see the threat or not, and it doesn’t matter if the flaw ever leads to a vulnerability. You just always follow the core rules and everything else seems to fall into place.

Remove upper bound in our dependencies Doing this we are only asking people to fork our gem or open issues when they want to use a new version of the dependency and we still didn't tested with it.

I usually write example code that is for both Chrome and Firefox WebExtensions.