Fix the overflow on hover correctly

Another post about type branding.

Raw HTML and CSS?

1. It's fast
2. It's easy
3. Pure HTML is evergreen
4. I can host it anywhere, often for free
5. Accessibility and SEO benefits are automatic
6. It won’t need security patches
7. There are no build steps

I totally agree: using HTML as much as possible, then CSS, then JS to enhance it in this order.

The API can respond with HTML fragments anyway for an HTML table.

Seach content in collapsible sections.

That's great!

The problem is annoying and difficult. Also secrets can be easy to rotate, can not rotate or ones that attackers use.

You could be doing so many good data security practices, like secure-by-design frameworks, database and field-level encryption, zero-touch production, access control… but logging bypasses all of that… and ultimately degrades trust, in your systems and in your company.

It happens to companies of all sizes: X, Google Cloud, Facebook

Causes:

1. Direct logging
2. Kitchen sinks: objects that contain or hold secrets, often in opaque or unexpected ways. Errors of requests are examples.
3. Configuration changes: turning logging level to debug.
4. Embedded secrets: a token shared by URL
5. Telemetry: error monitoring and analytics are logs. They often provide the local variable context.
6. User Input: the user provides wrong but PII data in a wrong field for example.

Fixes:

1. Data architecture:part of the solution is reducing the number of data flows and shrinking the problem space so you simply have less things to worry about and protect. One logging utility!
2. Data transformation: minimization, redaction, tokenization (and the trolls: hashing, encryption, masking)
3. Domain primitives: “combines secure constructs and value objects to define the smallest building block of a domain”. new Secret("..."). They provide security invariants and guarantees that basic string primitives simply cannot.
4. Compile-time: a logging function that never accepts secrets (TS branded types helps!)
5. Run-time classes (extends String): it identifies the secrets. Overwrite the toString() method in JS to return [redacted] but an explicit unwrap() method for example.
6. Read-once objects: they throw an error or [redacted] in case of second read.
7. Taint checking: the general idea here is that you add taint to various sources (like database objects), and yell loudly if the data flows into certain sinks (like logs). Demo: https://semgrep.dev/playground/s/4bq5L It's awesome and not awesome as the same time.
8. Log formatters: redact known dangerous property names
9. Unit tests
10. Sensitive data scanner
11. Sampling (every cases instead of proportions)
12. Log pre-processors such as Vector
13. People

Strategy:

1. Lay the foundation: Developing expectations, culture, and support is a must-have. Define what a secret is. Use structured logs to allow operations on them.
2. Understand the data flow: with the foundation laid, the next best thing to do is to understand and chart out how secrets flow through your system.
3. Protect at chokepoints: CI/CD and App code first, before relying on the loggging library and other operation services.
4. Apply defense-in-depth: data transformation, read-once objects, log formatters in the library, log pre-processors, sensitive scanners, people
5. Plan for response and recovery

(via https://sebsauvage.net/links/?LscYqg)

Create a CA locally and use it to generate certificates. So it's perfect for local network requests (https, etc...)

About ?page=1 that can become /?page=1 OR 1=1

KISS for maintainability: "Nothing in Rust forces us to get fancy. You can write straightforward code in Rust just like in any other language. But in code reviews, I often see people trying to outsmart themselves and stumble over their own shoelaces. They use all the advanced features at their disposal without thinking much about maintainability."

Here an real life example.

But if simplicity is so obviously “better,” why isn’t it the norm? Because achieving simplicity is hard!

Even in Rust: abstractions are never zero cost for developers.

Often, simple code can be optimized by the compiler more easily and runs faster on CPUs. That’s because CPUs are optimized for basic data structures and predictable access patterns. And parallelizing work is also easier when that is the case. All of that works in our favor when our code is simple.

Most of the code you’ll write for companies will be application code, not library code. That’s because most companies don’t make money writing libraries, but business logic. There’s no need to get fancy here. Application code should be straightforward to keep your fellow developers in mind.

Tips:

• start small
• avoid optimization early
• delay refactoring: we have limited information at the time of writing our first prototype.
• write code for humans
• The right abstractions guide you to do the right thing

Similar to tailwind, but somehow better?

CSS anchor positioning includes many advantages!

It can be placed upon an element, origin from the center of the element, or next to it with position-area inside a 3x3 grid area. The position-area can span cells.
It can also have fallbacks with flip-blocks, flip-inline and flip-start.

Related CSS properties:

• anchor-name
• position-anchor
• position-area
• position-try-fallbacks

The post does not relate how to handle spacing though.

Some different ways to write HTML

em unit compound when value are greater or lower than 1.
Except that, they are awesome :)

Bound checking costs 0.3%

Interactive examples for CSS grid, flexbox, the edge case with absolute positioning.

I didn't know flex with safe that preserves the alignment with the scrollbar.

The table is available as PDF https://dr-knz.net/programming-levels/prog-skill-matrix.pdf