TIL signed distance field. First I need to explain the concept of alpha testing. Alpha testing is a rendering technique for textures. It dictates that when rendering a texture, perform a test on the alpha value of that pixel against a threshold. Completely throw out or keep the data depending on the comparison result. Typically the alpha value for each pixel is set to the actual transparency of the pixel. This signed distance field method calculates the signed distance of each pixel to the nearest color pixels. The signed instance field is then saved in alpha channel in the texture. All the remaining alpha-testing mechanism is the same. It's claimed that this technique improves the rendering quality of low-resolution textures drastically.

Read the original paper: https://steamcdn-a.akamaihd.net/apps/valve/2007/SIGGRAPH2007_AlphaTestedMagnification.pdf

An interactive cheatsheet for the GPIO pins on Raspberry Pi.

Also check out https://microbit.pinout.xyz/ for the GPIO pins for BBC micro:bit.

What Hyperbole does is to add actions to textual patterns.

Interesting insight: A false failure is one that you fix by editing the test, while a real failure is one you fix by editing the code. Some tests virtually never have real failures, so it's better to avoid them. One principle is to test function, not code.

A clever way to implement a htmx-like mechanism of substituting the content of a node with the response of a request.

It works like this. Have a hidden iframe whose onload callback sets the target node (specified by hash) with the iframe's body content. Then use an a element to trigger the iframe load: <a target=_the_iframe href="/req-url#target-element">.

TIL: a[target], iframe[hidden], contentWindow, contentDocument, <base target=X>

This article talks about PGA (projective geometric algebra), an alternative approach to do geometric transformation that is not using matrix.

This video specifically talked about the real difference in biological neurons and its artificial counterpart. I found the part is on how to represent information and training "artificial biological neuron networks" interesting. Notes (terms: neuron := biological neuron):

• neurons accumulates the incoming charge (stateful), with charge leakage
• three ways to encode information: frequency, timing, and parallelism
• backprop breaks down on discrete signals
• the only known mechanism for neuron weight update is "neurons that fires together wires together". but it's not very useful to developing a way to train it.
• it's likely neurons interpret its input as binary.
• the firing rate limit of neurons is only around 4 ms/spike (very slow)
• directional hearing requires distinguishing 1/2 ms delay of signals. how is it possible given the maximum firing rate? answer: create a group of neurons each detecting different delay and ordering in input signal.
• neuron components:
  • loopback neuron can store a bit of signal that can be set and reset. (like an SR latch)
  • mpsc (read-write) buffer
  • mechanism that repetitively reading refreshes the memory (like DRAM)
• power efficiency. (12W for the brain) calculated result: neocortex only fires every two seconds (Wow!)

I enjoyed the puns, for example, PageRank - Larry Page, erlang - Agner Erlang, Price Club - Sol Price

xDCI is a specification that includes features to allow programming a USB port to emulate a USB device. This article talks about kernel hardware support, BIOS flashing, PCH (Platform Controller Hub), PMC (Power Management Controller), NVRAM, efivars, and finally how to use the author's Raw Gadget tools to emulate USB devices.

In this article Josh Comeau went in depth on why it matters to think of CSS as the parameter to the layout algorithms. This means for any layout problem, you must think of which layout algorithm you're using before deciding.

For example, z-index is not functioning by default. To use it you must set position: relative | relative. This is because the flow algorithm (think about Word) doesn't know about z-index. It only makes sense in the "Positioned" layout algorithm. And the position attribute is used to switch the positioned algorithm. Instead of saying z-index depends on the position attribute, it's better understood that it depends on the layout algorithm.

Another evidence is that properties are interpreted differently in different layouts. For example, width is hard-restriction for flow layout, but more fluid in a flexbox layout.

It's possible to declare conflicting layouts on the same element. But then there is a priority in which algorithm takes precedence. Two algorithms are never used simultaneously on the same element.

Identifying the algorithm:

• flow (the default)
  • the core of flow layout are inline blocks and blocks.
• positioned (when position is set), four variants: relative, absolute, fixed, sticky
• float (when float is set)
• table
• flexbox (parent is display: flex)
• grid (parent is display: grid)

There are quirks which are result of different layout algorithms. For example, when putting an img inside a box, it gets a little whitespace below it that are not padding/margin/border of either parent box or the image. This is because inline elements are aligned by baseline. And the flow algorithm adds a bit of vertical space below the baseline of inline element to ensure the bottom part of "g", "j", etc are visible. img by default is inline-block and its baseline is at its bottom edge (0). Now the problem is understood one can solve it in different ways.

Josh Comeau writes one of the best interactive css tutorial out there! I learned so much in this article. A few notes:

• margin: auto makes the child take as much margin as possible.
• width: fit-content uses all available space, but within the intrinsic size
• margin-inline: auto is a shorthand for margin-left: auto; margin-right auto;
• place-content: center is a shorthand for align-content: center; justify-content: center
• difference between place-content and place-items in grid layout - the latter aligns items relative to the cell
• the insight that css attributes are merely inputs to the underlying layout algorithm

An article on how Rust can benefit from an effect system.

The information advantage over your competitor is something you can choose to cultivate. In journalism, one can avoid large topic on key persons that everyone went about, instead focus people with just as much insight and far less attention.

This article explores how we can separate the lifetime of values in a container from the lifetime of the container structure. The author approach the problem by issuing a token (zero-sized type) with an invariant lifetime. TIL ghost token. I think the type AppendOnlyVec (Vec<Box<T>>) could make a more straightforward example.

Nice write up. Aside from these mentioned, I also wanted to point out a few problems about Protocols.

1. the implementation on struct is fine, but implementations on primitive types are very different and sometimes awkward
2. the first argument is forced to be the type that implements the protocol, making it difficult to define abstract methods on, for example, a set of values
3. there is no concept of associated type, associated constant,
4. the role of protocols mostly overlaps with a @behaviour but a behaviour is more flexible

And here are more places I'd like to see improvements (some pointed out in the article, too):

• the lack of simpler struct construction/deconstruction syntax sugar, forcing everyone to write code like %{a_long_property: a_long_property} repeatedly
• the lack of early return. the design of with discards the information about the mismatching branch.
• Ecto.Multi is not composable (I tried to fix it via https://github.com/shouya/ecto-tx)

A concise and complete cheatsheet for the format! macro.

This article talks about the default value for DefaultRestartSec is not sensible for use cases where you expect the service to restart indefinitely. Under the default setting, if your service could crash in 100ms, then it will only be restarted for around 1 second before systemd gives up.

It's a pleasurable and informative read. The nature of algebraic effect was accurately and concisely pointed out. This has been one of the best write-up on algebraic effects implementation in Rust I've read so far.

Quick explainer for ZFS caching mechanisms: ARC, L2ARC, TXG, ZIL, and SLOG.

A detailed description on the hardware architecture of Game Boy console.