This data structure seems efficient and interesting

A single authentication layer for your entire platform. Integrate any identity provider through OpenID Connect — without touching your application code.

his web app will send you a confirmation email to make sure you own the email address. In that email there will be another link. Click that link and you will be taken to a page where you can trigger test emails to be sent to you. Those test emails are specially crafted to use a variety of techniques, to attempt to send information back to this server when read. It will then display the results for you.

The project is available at https://gitlab.com/grepular/ept3

JavaScript Patterns Patterns focused on plain Javascript and Node.js

Why benchmarks should be carefully used as arguments

The maintainer retires, so there are many projects going unmaintained without help

Paste the raw source of an email into the form on the front page. The email will then be parsed, decoded, separated into its various MIME parts, and displayed in an easy to view fashion. Image attachments will be displayed as images. HTML parts will be rendered in Chromium (with javascript and plugins, disabled) and then also displayed as an image. IP addresses in headers and message bodies will be identified, classified, and highlighted along with a flag representing their origin country. Hostnames and email addresses will also be identified and highlighted.

Whether you are a software engineer, a lawyer, a manager, or an entrepreneur, your value is directly correlated with how efficiently you can process new information to stay relevant in your field in an ever-accelerating world.

But there are two problems.

The first one is that today, there is simply too much information available and it's hard to extract signal from the noise.

The second problem is that knowledge ("white collar") jobs are evolving faster than the capacity of most people to learn new things. For example, today, you are a software engineer developing backend applications, and you may want to move into machine learning with all the recent and exciting advancements.

Good news: Knowledge follows the law of diminishing returns. By spending two weeks studying a topic really hard, you can assimilate the most important principles and become better than maybe 90% of the people on this plane

The cost of indexing: it uses more storage to use the data structure. A table with eight indexes has nine things to keep warm in cache, not just one. The more indexes you have, the more options the query planner must weighs.

Why index is not working?

• composite indexes care about order
• functions defeat the index: case-insensitive does not match an index created on the fly. It applies to any function wrapping the column.

How to avoid these pitfalls? Measure.
There is the tool EXPLAIN in Postgres telling how it plans to run a query. Using it before the query explains it :) The Index Scan instruction is what is looked for.
EXPLAIN ANALYZE runs the query and reports what happened.

Things nobody shares:

functional indexes
CREATE INDEX ON pokemon (lower(name));
but why are the data not stored in lowercase in the first case

partial indexes
avoid a full index
CREATE INDEX ON pokemon (name) WHERE is_legendary = true;

covering indexes
If the index already contains every column the query needs, the database can answer the query from the index alone, never touching the table.
CREATE INDEX ON pokemon (name) INCLUDE (base_attack);. INCLUDE is a way to say “carry this column along for the ride, but don’t bother sorting by it”. Use it if the columns whose data types don’t have an appropriate operator class for the index type, or add columns to a unique index without changing its uniqueness semantic.

"stateless" authentication simply is not feasible in a secure way. You must have some state to handle tokens securely, and if you must have a data store, it's better to just store all the data.

The reason to avoid JWTs comes down to a couple different points:

• The JWT specification is specifically designed only for very short-live tokens (~5 minute or less). Sessions need to have longer lifespans than that.
• "stateless" authentication simply is not feasible in a secure way. You must have some state to handle tokens securely, and if you must have a data store, it's better to just store all the data. Most of this article and the followup it links to describes the specific issues: http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/
• (Yes, people are doing it, and yes, their applications are flawed, and you should not repeat that mistake.)
• JWTs which just store a simple session token are inefficient and less flexible than a regular session cookie, and don't gain you any advantage.
• The JWT specification itself is not trusted by security experts. This should preclude all usage of them for anything related to security and authentication. The original spec specifically made it possible to create fake tokens, and is likely to contain other mistakes. This article delves deeper into the problems with the JWT (family) specification.