This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2024-07-23
Channels
- # announcements (2)
- # babashka (3)
- # beginners (20)
- # cljs-dev (3)
- # clojure-europe (40)
- # clojure-nl (1)
- # clojure-norway (9)
- # clojure-uk (4)
- # cursive (18)
- # datalevin (6)
- # datomic (7)
- # docker (15)
- # gratitude (1)
- # hyperfiddle (6)
- # leiningen (5)
- # mathematics (2)
- # nbb (7)
- # off-topic (20)
- # other-languages (2)
- # releases (1)
- # remote-jobs (9)
- # ring (20)
- # rum (1)
- # sql (7)
- # tools-deps (13)
- # xtdb (1)
moien :flag-lu:
Morning
Morning
So you sing one hell of a tune as well? 😉
The kids found this juvenile thrush hiding in some shrubs in the garden. Likely still being fed by parents. Hope it doesn't get predated by the neighbourhood's cats. Can't seem to keep those buggers out of my garden.
Morning!
Morning
Excellent! Pour moi, c'est un Mardi, mais pas comme d'habitude. Il fait beau, si beau, J'ai quelques chose interessant a faire, J'ai du Haggis pour manger ce soir... À mon avis, J'ai beaucoup de la chance 😉 Et maintenant au travaille!
Good morning!
I feel like a big issue with our business application is traceability. So many decisions in code and configuration have been made and are being made over time that it's dizzying to even think of. In a sense, I'd love to have some somewhat direct line between code and some documentation. Git blame and branches named for issue tracker issue names is cumbersome, and the issues themselves each only contain partial knowledge. But littering the code with some sort of references - I line comments containing references to some documentation "Bible" is the solution I'm thinking of - would also make it way more annoying to just read the logic of the code itself. And I know the cost of maintaining even a part of such a Bible...
Kevlin Henny likes to say the code is the sum of our knowledge of the business problem It's a good line. That Bible is your code. You can add a comment (aka documentation) why a decision was made, but that can diverge from code over time. What can't diverge is assertions and tests. Document that decision in a test, explain it in the testing block, and voila. If it's an invariant, asset it
Let's play the guessing game - why did the service cross the road fail to start new pods (and as old pods were claimed by the cluster, reached zero live pods)?