This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (40)
- # aws (15)
- # babashka (76)
- # beginners (39)
- # calva (6)
- # cider (3)
- # clj-kondo (3)
- # clojure (89)
- # clojure-austin (1)
- # clojure-australia (4)
- # clojure-europe (42)
- # clojure-italy (9)
- # clojure-nl (27)
- # clojure-spec (8)
- # clojure-uk (17)
- # clojurescript (9)
- # conjure (1)
- # data-science (1)
- # datomic (19)
- # deps-new (4)
- # docker (9)
- # emacs (5)
- # events (1)
- # fulcro (36)
- # kaocha (31)
- # lambdaisland (5)
- # leiningen (3)
- # membrane (3)
- # nrepl (10)
- # off-topic (31)
- # pedestal (7)
- # reveal (47)
- # shadow-cljs (35)
- # sql (9)
- # test-check (1)
- # tools-deps (24)
- # uncomplicate (12)
- # xtdb (5)
@dharrigan seeing your avatar and your exclamation mark really makes me think you’re a morning person :)
Is it common in Northern Europe to just accept that you’ll have a sore throat for the winter or was my doctor messing with me? (They mentioned Danish winter cough, that was before COVID but now I have it again!)
Does anybody know about a tool (lein plugin, kondo, whatever) that would report using a namespace (e.g.
require it) from a library which is only a transitive dependency?
I don't have a sore throat all winter (live in Scotland have lived in Chicago and Philadelphia where the winters were harder)
But you can also use
(binding [clojure.core/*loading-verbosely* true] (require 'something)) and it will print on every require
user=> (binding [clojure.core/*loading-verbosely* true] (require '[babashka.impl.cheshire])) (clojure.core/load "/babashka/impl/cheshire") (clojure.core/load "/cheshire/core") (clojure.core/load "/cheshire/factory") (clojure.core/in-ns 'cheshire.core) (clojure.core/alias 'factory 'cheshire.factory) (clojure.core/load "/cheshire/generate") (clojure.core/in-ns 'cheshire.core) (clojure.core/alias 'gen 'cheshire.generate) (clojure.core/load "/cheshire/generate_seq") (clojure.core/in-ns 'cheshire.generate-seq) (clojure.core/refer 'cheshire.generate :only '[tag JSONable to-json i? number-dispatch write-string fail])
aaarrrrgghhhhh I had some untracked files... and lost them with
git stash 😠 😠 😠 😠 😠 😠 😠 😠
git stash list (I often have so many stashes that I need to clean up regularely)
I develop a lot of my open source projects on Dropbox. It sounds crazy, but I always have an extra backup. It has served me well when I deleted an entire .git folder while having in progress work only locally...
Yes, Time Machine has save my butt ac couple of times, when I accidently delete an uncommitted file or
git -f-ed over my changes.
@slipset isn't it a truism that people held up as heros in productivity books, and this author has produced many, suffer from survival bias? Quite literally for groups of elite military kill teams. In other words, I really don't care what they say cos it's highly unlikely to be useful in my situation
and that's not say that I don't think that they can make for interesting reads - but just not as something which I would treat as a model for my organisation / life
ie how many TODO apps are we currently using ... at least 10 for me and they're all terrible 🙂
I would argue that “The culture code” seems to have done some sort of research. Its main finding is that psychological safety seems to be very important if you want to create a winning organization.
As in, if you feel that you’re allowed to say “stupid” things within your group, that’s a good thing. Much like I feel in this channel.
ok ... not sure how that [ can we agree somewhat ineffable? ] concept is related to learning how to organize coders better from people operating in the Iraqi kill zones
I’ll try. People operating effectively in Iraqi kill zones seem to form groups in which it is psychologically safe to ask the stupid questions/make “honest” mistakes. The same people have debriefs after missions to make sure they learn from any mistakes done during the missions. I know that I work better in orgs where I feel safe enough to ask the stupid questions. I also really enjoy working in orgs which are constantly trying to get better. To pull in another one from the killing fields, “Extreme Ownership” by, wait for it, Jocko Willinck. Basically, the main idea in that book is that everyone on a team (of killers) take total ownership, basically, the buck stops here. You could look at the from a devops perspective: You write the code, you deploy it, and you fix it when it breaks production. Also the kind of org I want to work in.
But, as I think the Culture Code says, these are traits of highly efficient teams, of actors, thieves, sports people, and Iraqi killer squads.
Organisations that contain such teams have many gatekeepers to ensure entry to those teams fit certain profiles. What we are learning is that those functions often serve to limit diversity of people and thinking. I prefer putting risk on diversity than alignment