Clojurians Log v2

https://practical.li/clojure/clojure-spec/ covers how I use clojure.spec along with practical examples and coding videos I've also recently been using spec with Reitit to validate API requests and responses (which I will be writing up this month)

Spec can be used in a lot of different ways so I wouldn't expect any single project to be a good exemplar of it... Is there some specific aspect of Spec that you're seeking guidance on?

Just basics, how do I spec parameters on a function best. What are typical project setups, i.e. are the specs in the code or the tests. Do you instrument specs in prodcution or not (or when)? Just all the things that make the idea workable.

I think any well “spec-d” code base woudl be a good starting point. I just don’t know how to google for one.

Those are all good questions. http://grep.app is pretty good for finding code in the wild, https://grep.app/search?q=s/def.

Thank you,. I will give that a try.

https://corfield.org/blog/2019/09/13/using-spec/ talks about the various ways we use Spec at work. Happy to answer any follow-up Qs.

Sean, I did read your blog. Great content. For me it isn’t obvious how to get from the concept to the practical implementation.

I suspect there's a lot more use of Spec in large application codebases and those are nearly all closed source.

I would love to see the Nubank code base 🙂

I work with a lot of FSI customer and I am trying to figure out if we can simplify some of those problems.

> Do you instrument specs in prodcution or not (or when)? I personally wouldn't use instrumentation outside of development. If you use spec for API/request validation, or generally stuff that comes from the outside of your program, then you want to be somewhat rigorous with it and nail it down to sufficient detail. Otherwise I would say just use it when it helps, incrementally. For example it can be useful as a thinking tool, to design the shape of your data. Or you can use conform to parse things into a richer structure. But it's really just that, a tool. I played around with it a lot and looked at how people use it in OSS projects. It's very nice and composable, and you can do a lot with it. I think playing around with it is a good way to get familiar with what you can do. Then forget about it, just write code and it will introduce itself naturally.

Here's are more involved specs (tools.deps): https://github.com/clojure/tools.deps/blob/master/src/main/clojure/clojure/tools/deps/specs.clj Specs can also be small and informal, basically just a set of names https://github.com/cognitect-labs/anomalies/blob/master/src/cognitect/anomalies.cljc

Another example from a library: https://github.com/seancorfield/next-jdbc/blob/develop/src/next/jdbc/specs.clj -- all about instrumenting library functions during development

Fantastic just what I needed. Thank you so much.

> Generative scenario testing This is a very interesting section. I've been thinking about something similar in the back of my head for a while. I named them workflows, but I like "scenario" very much as a term here! > Deriving code from specs I've been struggling with something similar for quite a while and was never quite happy with my results. Have you been using form and conform to parse the specs themselves?

I'm not in front of my work codebase -- I'm taking every Friday off this month -- but I'm pretty sure we use form and walk the result to find the s/keys definition and "parse" that to derive everything we need. If you remind me on Monday, I can provide more detail.

Ah right, its a specific subset of possible specs that make sense in that context