Fork me on GitHub

Morning Everyone.


Ahoy hoy


Went over a 2" nail on Monday night. Not only trashed the tyre and tube, tore holes in the inside of my rim too


Ugh that sucks… I drove my car into a huge pothole in the dark and blew out a tyre last week too 😞


Potholes around Mancs are absolute rubbish at the moment. And the resurfacing they're doing is crap too. One of the roads I take for my route in got resurfaced back in October, but it was a quick cheap job so the new surface is already peeling back


Had to sand all the rough gouges down and then fit new rim tape before I could even put the tyre back on


was that a nail sticking up through a plank or something @carr0t?


Just lying in the road. It must have been exactly facing down my direction of travel so as I rode over it I forced it up into the wheel or something


@rickmoynihan goes with the old drafty rooms 🙂


Drafty == Georgian Damp Proofing


don't want to die of miasma


Morning folks! Here’s a little puzzler for anyone who likes thinking about namespaces and testing 🙂 I have a namespace with some stuff in it.

(ns uk-clj-rocks.core
  (:require [dependency :as d]))

(defn thing [x] (d/function x))
I want to test it. But, for reasons (cough datomic peer vs client), I want to test it with dependency swapped out for another library providing all the same functions as dependency. Essentially I’d like to do something like this:
(ns uk-clj-rocks.core-test
  (:require [core.test :refer :all]
            [uk-clj-rocks.core :as core]
            [different-dependency :as dd]))

(deftest thing-test
  (with-ns-redefs [d dd]
    (stuff-from-core-but-with-dd-not-d ...)))
where with-ns-redef is not an actual function AFAIK. There are the with-redefs and with-redefs-fn functions, so one option is to not redef the whole namespace, but just explicitly define vars in uk-clj-rocks.core for the functionality from dependency that I want, then use with-redefs to overwrite those. An overall “namespace injection” seems cleaner though. Thoughts? Is this just nuts?


Oooh, hold the phone, I can replace the namespace function at a time without defining them in core. That may have solved my problem.


Thanks, rubber ducks 🦆 🦆 🦆


@chrjs: You’re probably much better using something like integrant/component… or just defining a boundary with a protocol/interface, or doing

(defn thing [function x] ,,,)


and injecting a different function in to thing depending on context. Patterns like (thing (constantly {:test :data}) :x) are your friend 🙂


Hmm, I did consider function injection, but I’ve not looked at integrant or component properly. I will do, thanks @rickmoynihan!


you can also define two namespaces with the same name, and toggle which gets put on the :source-path, by e.g. having a namespace in env/dev/src/different/dependency.clj and env/prod/src/different/dependency.clj, and then toggle them with a lein (or boot) profile… but this I’d consider this more a packaging concern though. So wouldn’t recommend for your usecase; that trick is more for having extra tooling available in dev and prod… or perhaps loading different middlewares in different envs.


I think that might be the wrong thing for my particular use case, as you say (I will still want access to both dependencies in test actually: the point of the mocking is for unit tests - end to end tests should be on the real thing). Nonetheless, I had not thought about toggling namespaces using the build tool - very cool.


well it’s a bit of a hack really… but it can work well when you want to provide different code in different environments. e.g. you may want to switch off authentication entirely in a dev profile but hardcode it in production (so assuming the build is ok; there’s no way to misconfigure it in production to run without auth)


but would only use it in very limited contexts. Also regarding protocols, you probably only want them if you have java object implementations you want to dispatch on (or if you’re using component). Integrant is my personal favourite dependency injector.


Yeah, with great power …


@chrjs we generally define protocols for all our integration points and pass around an app-context, which is just a map of those protocol implementations (built with our own integrant-like lib) - pretty much hexagonal architecture. it works very nicely


@mccraigmccraig I’m going to have to look at integrant. Protocols could be exactly the right thing. Ta!


@chrjs here's our own lib which is aimed at async systems - it works happily with factory-fns which return promises of things -


Is there a clojure idiomatic way to do human-readable input validation? clojure.spec/Schema both do a good job at ensuring the data structure is legit, but aren't that great at saying "Please enter a number between 1 and 5" or "That is not a valid email address" or "that email address is in use"


@xlevus There's this one, if you're talking about humans as in end users


looks legit. 👍


Not sure about idiomatic, the spec stuff's not really settled down in general


it's certainly more idiomatic than what I'd produce :D


and yeah, I've noticed spec seems a bit, wobbly. Have to either use Schema, or upgrade compojure-api to 2.0.0-alphaX