Skip to content

Instantly share code, notes, and snippets.

@holyjak
holyjak / fulcr-ssr-test.clj
Created January 22, 2021 11:30
Experiments in Fulcro SSR with dynamic routers
(ns ssr-test
"Try server-side rendering in Fulcro where we want to display a non-default
dynamic router target.
*BEWARE*: This is an exploration. I have *no* idea what is the correct way."
(:require
[com.fulcrologic.fulcro.application :as app]
[com.fulcrologic.fulcro.algorithms.denormalize :as denorm]
[com.fulcrologic.fulcro.algorithms.server-render :as ssr]
[com.fulcrologic.fulcro.components :as comp :refer [defsc]]
[com.fulcrologic.fulcro.dom-server :as dom :refer [div label input]]
@levand
levand / data-modeling.md
Last active September 11, 2025 17:32
Advice about data modeling in Clojure

Since it has come up a few times, I thought I’d write up some of the basic ideas around domain modeling in Clojure, and how they relate to keyword names and Specs. Firmly grasping these concepts will help us all write code that is simpler, cleaner, and easier to understand.

Clojure is a data-oriented language: we’re all familiar with maps, vectors, sets, keywords, etc. However, while data is good, not all data is equally good. It’s still possible to write “bad” data in Clojure.

“Good” data is well defined and easy to read; there is never any ambiguity about what a given data structure represents. Messy data has inconsistent structure, and overloaded keys that can mean different things in different contexts. Good data represents domain entities and a logical model; bad data represents whatever was convenient for the programmer at a given moment. Good data stands on its own, and can be reasoned about without any other knowledge of the codebase; bad data is deeply and tightly coupled to specific generating and

@jashkenas
jashkenas / semantic-pedantic.md
Last active September 5, 2025 05:32
Why Semantic Versioning Isn't

Spurred by recent events (https://news.ycombinator.com/item?id=8244700), this is a quick set of jotted-down thoughts about the state of "Semantic" Versioning, and why we should be fighting the good fight against it.

For a long time in the history of software, version numbers indicated the relative progress and change in a given piece of software. A major release (1.x.x) was major, a minor release (x.1.x) was minor, and a patch release was just a small patch. You could evaluate a given piece of software by name + version, and get a feeling for how far away version 2.0.1 was from version 2.8.0.

But Semantic Versioning (henceforth, SemVer), as specified at http://semver.org/, changes this to prioritize a mechanistic understanding of a codebase over a human one. Any "breaking" change to the software must be accompanied with a new major version number. It's alright for robots, but bad for us.

SemVer tries to compress a huge amount of information — the nature of the change, the percentage of users that wil