Holy Dev Newsletter January 2024

👓 dandavison/delta: A syntax-highlighting pager for git, diff, and grep output [tool, productivity]
If you'd like to see syntax-highlighted output from git diff then delta is something for you.
Note: A colleague prefers difftastic, which works hard tominimize and highlight the changes shown. (May be slow on large diffs.)

👓 ParadeDB - PostgreSQL for Search [database, search]
I have just found this on the net - an ElasticSearch alternative built on Postgres (not there yet completely, but seems very capable already). As they write and we have ourselves experienced, "Postgres’ native search features, which are pleasant to use but nowhere near as capable as a full search engine". They have released two Pg extensions: products: pg_bm25, which enables full text search in Postgres (and uses the same algorithm, BM25, as E.S.), and pg_sparse, which enables sparse vector search using HNSW in Postgres. Their full-text search can search by keyword or phrase with configurable tokenizers, stemming for 17 languages, and an extensible SQL-based query language. Written in Rust, open source.
They are also working on a hosted solution.

👓 JSON Web Tokens are actually great, just not for sessions [security, best practices]
An experienced security expert shares his tips for a good use of the popular JWTs. Summary: The specification is large and complex, but it has good parts you can leverage. Do not use [stateless] JWT tokens (typically from Auth as a Service) for sessions or as api keys - since you have no way to revoke such a token. But they are great for authenticating specific, short actions, such as a download or password reset. Read the whole article for all the tips, if you plan to implement JWTs.

👓 What I'd like to see for Async Rust in 2024 🎄 · baby steps [rust, opinion, future]
Async Rust and what happened in 2023 and is possible in 2024. A good progress on async functions in traits but still limitations (e.g. not being generic over what kind of executor is used).
2024 hopes: async closures. Explore "maybe async" - a function that can be compiled as either sync or async. Generators, i.e. async iterators.
Further away: "Many of the nastiest async Rust bugs come about when users are trying to manage nested tasks. Existing APIs like FutureUnordered and select have a lot of rough edges and can easily lead to deadlock. I would like to see us take a fresh look at the async APIs we offer Rust programmers and build up a powerful, easy to use library that helps steer people away from potential sources of deadlock."

👓 czan/stateful-check: Stateful generative testing in clojure [clojure, library, testing]
Property-based testing for stateful systems. Start the system, generate a random sequence of "commands" (with, among others, optional postconditions). Shrinking included.

👓 Announcing Mutative 1.0 - A New Era in Efficient Immutable Updates | Mutative [javascript, library, data]
A JS lib for efficient immutable updates, boasting being 2-6x faster than naive handcrafted reducers, and even more than 10x faster than Immer. Via J.S. Weekly.

👓 Automerge CRDT | Automerge CRDT [library, collaboration]
"Automerge is a library of data structures for building collaborative applications.", providing a a Conflict-Free Replicated Data Type (CRDT), which allows concurrent changes on different devices to be merged automatically without requiring any central server. There are JavaScript and Rust (with C bindings) implementations.

👓 JSON:API — A specification for building APIs in JSON [api, best practice, standard, design]
Building a REST/Json API? Look here for inspiration! With pagination (via links section) . "designed to minimize both the number of requests and the amount of data transmitted between clients and servers. This efficiency is achieved without compromising readability, flexibility, or discoverability."
The document structure's top keys are data, errors, meta, links plus few other that may be there. Every "resource object" must have an id and type and may have attributes (a map of all its other properties), relationships (to other json:api resources ~ foreign keys in SQL; must have 1+ of links, meta, data: {type, id} (or array)), links, meta.
Related resources (e.g. an article's author) may be also included in the response alongside the primary resource, in the top-level included array (I'd have preferred type -> id lookup). The client requests this, with a list of relationship paths to include. Ex.: ?include=comments.author. Sparse Fieldsets allow clients to request only selected fields for a type. Ex.: fields[articles]=title,body&fields[people]=name. Support for sorting (e.x.: ?sort=-created,title - desc. by created, then asc. by title). Specification of response codes and contents for CRUD. Spec of various query parameters.
There is also a whole section about returning errors (a top-level errors array, each may have id, links, status, code, title, source, meta). There is also a few profiles and extensions, extending the spec.

👓 grzm/uri-template: Clojure implementation of URI Template (RFC 6570) [clojure, library, standard] - Clojure implementation of URI Template (RFC 6570)
I had no idea there is a standard for URI Templates and a clj lib for it. It enables you to describe a range of URIs and then create a concrete one by supplying a map of variables. It is smarter than just string interpolation - query params will be properly separated by ? and &, variables without provided values are removed from the template, and there is a number of parameters to control the expansion (e.g. to insert only a substring of the value), values are url-encoded, lists comma-separated, & more.

👓 Design Systems Database: Surf among top‑notch Design Systems [webdev, ux design]
Design Systems Database: A Database of Best-in-Class Design Systems, Organized and Sorted by Components and Directories — Useful for studying the public design systems of well-known technical teams (Adobe, GitHub, MailChimp, Shopify, etc.), divided into systems, directories, components, and blueprints. Handy stuff. Via Frontend Focus.

👓 Why did you stop using React? [discussion, webdev]
An insightful discussion of why some ClojureScript devs stopped using React, and what they adopted instead. The main arguments are the growing complexity of React and the churn in the ecosystem, due to the constant changes. A good way forward seems to be a pure cljs implementation of the core ideas of React, without all the ballast. Such as the (under-documented) shadow-grove by Thomas Heller and early stage Replicant (though it isn't clear yet whether the authors will continue with it, or adopt shadow-grove instead).

👓 Rocks, Pebbles, Sand: How to implement in practice [project management, process]
A great article about the three categories of tasks (the large, 3-6(-12) month strategic "rocks" with multi-year impact, tactical, 1-4 sprint "pebbles", and <_ _1="_1" sprint="sprint" team-driven="team-driven" sand="sand" about="about" their="their" em="em">different goals, and about the different planning and prioritization processes they need. The names remind us that we need to plan the largest ones first, just as when fitting rocks, pebbles, and sand into a jar. Be aware of their differences, and schedule and prioritize accordingly.
Sand [scheduled by devs] - "tiny" tasks with immeasurable impact, which adds up to a great product. Mostly comes from Engineering. optimizer for throughput (=> do minimize process). Prioritize with intuition and desire, not math and metrics. many never will get done because we always have more ideas than time. Since delivered-value is near-nil, why not choose things people have desire / energy for? This increases happiness, morale, and often quality.
Rocks [scheduled by exec, but PM drives] - strategic (=> winning over the next few years) , 3-6(-12) month, optimize for impact, which must be huge. Powers up the product.
Pebbles [scheduled by PM] maximize ROI, i.e. effort vs impact. Between sand and rocks (1-4 sprints), not strategic but tactical wins with impact in the next few months. "It is difficult to craft great Pebbles, because impactful things have a tendency to explode in effort. Anything longer than four sprints invokes the Hofstadter problem of time and impact, and therefore must be analyzed and prioritized as a Rock." If it starts expanding," you often discover that the impact is no longer big enough. Either this means the team needs to get more creative in how to deliver more impact with less effort, or maybe this idea simply isn’t a good-enough use of your time. " If Rocks maximize strategic impact over the long-term, Pebbles maximize immediate impact in the short-term. Said another way: They are the “most effective use of the team’s precious time.” Beware impact & time estimates mostly off by tens of %.
Many great points about prioritising, handling conflicting priorities, and ensuring that none of the three categories is starved. I especially appreciated "Starting a new Rock or Pebble too soon, rather than creating more quality and value from the ones that just “completed".