Good Morning!
@dharrigan seeing your avatar and your exclamation mark really makes me think you’re a morning person :)
I am. 4:30 this morning.
Morning :)
I woke up blurry eyed today. Not very often that happens.
Morning!
morning
morning
Morning
Morning
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!)
Good morning!
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?
morning
I don't have a sore throat all winter (live in Scotland have lived in Chicago and Philadelphia where the winters were harder)
@ordnungswidrig kondo can do this using its analysis output
@ordnungswidrig See https://github.com/borkdude/clj-kondo/blob/master/analysis/README.md
But you can also use (binding [clojure.core/*loading-verbosely* true] (require 'something))
and it will print on every require
e.g.:
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])
@ordnungswidrig I have a thing for that.vizns. https://github.com/SevereOverfl0w/vizns
oh nice. thanks a lot
aaarrrrgghhhhh I had some untracked files... and lost them with git stash
😠 😠 😠 😠 😠 😠 😠 😠
git stash pop?
also git stash list
(I often have so many stashes that I need to clean up regularely)
my understanding is that untracked files are not stashed.
exactly.
Unless you do a -f
command git won’t touch any unstracked file anyways.
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...
Btw if you're on a mac, Time Machine might also still have it somewhere
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.
I’m sure there are other findings as well, but that was my main take-away.
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
Diversity requires a lot of psychological safety as well (tho I don't have a citation to hand)