Short answer: (if-let [balances (doto (b/list-balances (:account context)) println)]

Generally I use tap> rather than println, with Reveal's tap hooked up

https://github.com/vlaaad/reveal

reveal looks awesome tks

where can I put this `

:reveal {:extra-deps {vlaaad/reveal {:mvn/version "1.3.206"}}
         :ns-default vlaaad.reveal
         :exec-fn repl}

I have {:reveal {:dependencies [[vlaaad/reveal "1.3.206"]]}} in my ~/.lein/profiles.clj, and use with lein with-profile +reveal repl and then in the REPL (do (require '[vlaaad.reveal :as reveal]) (add-tap (reveal/ui)))

(.getAbsolutePath (io/as-file “your path”))

http://clojure.java.io/as-file

Why as-file over file?

thank you. That’s exactly what I need

I’ve tried this config

look above, it looks like you're working inside pedestal?

it is pedestal the code is here https://github.com/runopsio/sequence

(ns your.project.ns
  (:require [io.pedestal.log :as log]))

(log/info "This is a test" {:key-1 "my-value})

that will send to log4j configured w/ pedestal

this is a good trick

tks

also, the tap> function is pretty useful if you want to send a message to a backend queue, and provide different models to handle it

The (tap>) can be consumed by adding (add-tap f), where f is a function which will be called with the arguments sent to the (tap>)

thus, the function passed to add-tap can be a pedestal log, another with a console print, or into some future endpoint

decoupling the produce/consume

I’m gonna read more about tap

I’m pretty new to clojure in general

me as well

Once you're aware of tap, you'll see it used often in really useful areas

for example:

https://vlaaad.github.io/reveal/#give-it-a-try

https://clojureverse.org/t/introducing-shadow-cljs-inspect/5012

I’m stuck in how to run reveal from this lein project

what is your project.clj?

and also what editor are you using to invoke lein?

Here is how i'm using tap> with pedestal logging, while keeping the door open to additional tap consumers going forward:

(ns my.logging
  (:require [io.pedestal.log :as log]))

(defn tap->logback [content]
  (let [{:keys [level message context]} content]
    (cond
      (= level :info) (log/info message context)
      (= level :debug) (log/debug message context))))

;; Configure this handler to consume from the tap.
(add-tap tap->logback)

(ns my.handler)

(def my-handler {
  :name :my-handler
  :enter
    (fn [context]
      (let [request (:request context)]
        (tap> {:level :debug :message "" :context request})))})

thats a simple example

when you want to disable that pedestal logging, you may remove-tap.

and you may add/remove it at runtime

I’m gonna try this inspect

inspect is part of shadow-cljs, and is for clojurescript

uses the same tap mechanism though, but the implementation is something akin to javascript websocket -> browser display

I think your extract-host-project function could be a little simpler with the power of destructuring

thank you!

i'd reach for into here: (into #{} (line-seq rdr))

Thanks!

using def inside other code is very rarely a good idea

@U01UY47RD5E This works as expected for me. Did you perhaps redefine the function and then forget to re-run the instrument code?

Here’s what I get:

{:path []
                                                                :pred (clojure.core/fn
                                                                       [%]
                                                                       (clojure.core/contains?
                                                                        (:menu
                                                                         %)
                                                                        (clojure.core/keyword
                                                                         (helloworld.restaurant/slugify
                                                                          (:helloworld.restaurant/name
                                                                           (:order-item
                                                                            %))))))
                                                                :val {:menu {:kothu-parotta {:helloworld.restaurant/name "Kothu Parotta"
                                                                                             :helloworld.restaurant/price 9.5
                                                                                             :helloworld.restaurant/quantity 50}
                                                                             :chicken-biriyani ...

(when I request something that is not on the menu)

Thanks @U04V70XH6, for some reason the same code works fine for me now. I added the other validation too now in the fdef (to validate the order quantity should be lesser than the quantity in the inventory) and it works fine. I am experiencing the awesomeness of clojure and spec!

(s/fdef update-menu-item-for-order-item
        :args (s/and (s/cat :menu ::menu :order-item ::order-item)
                     #(contains? (:menu %) (keyword (slugify (::name (:order-item %)))))
                     #(< (::quantity (:order-item %))
                         (->> (:menu %)
                              ((keyword (slugify (::name (:order-item %)))))
                              (::quantity))))
        :ret ::menu)

With the function spec in place, I simplified my function’s logic to remove all nil and inventory checks and throwing exceptions and all that stuff like below

(defn update-menu-item-for-order-item [menu order-item]
  (let [item-id (keyword (slugify (::name order-item)))
        order-quantity (::quantity order-item)]
    (update-in menu
               [item-id]
               #(assoc % ::quantity (- (::quantity %) order-quantity)))))

Just bear in mind that you would normally only use instrument in dev/test, not in production so you need to think about what should happen if your code violates that contract in production with no instrumentation in place.

So, should I still have the original checks in my code so that it gets validated in production? What is the recommended approach? Maybe is it ok that only external facing API functions have such checks in production and all internal functions use spec instrumentations at dev/test?

It depends.

If this is something that you would previously — before Clojure, before Spec — written as explicit checks in production with either error handling or exceptions, then that’s how you should write it now, in Clojure — with Spec if you want to leverage its ability to validate data.

If you only want these checks in place while you develop & test your code, instrument is a reasonable way to approach it.

I can’t remember if I’ve linked you to this before? https://corfield.org/blog/2019/09/13/using-spec/

If you watch some of the talks about Spec, you’ll see there’s often a recommendation to use Spec around system boundaries and not for internal functions, on the grounds that it is not a type system.

But while you are developing functions that manipulate complex data (or have complex relationships encoded in the data) using Spec can be very valuable to help you get the functions correct, both via instrumentation and via generative testing (such as stest/check).

Thanks! I read your blog, very useful. I shall explore more. It would be great if you can send some code examples for 1. Using s/conform and s/explain-data to return user friendly error messages 2. Some tutorial on generative test generation using test.check library

“If this is something that you would previously — before Clojure, before Spec — written as explicit checks in production with either error handling or exceptions, then that’s how you should write it now, in Clojure — with Spec if you want to leverage its ability to validate data.” > Lets say I want explicit validation of function arguments in some edge function in production. Is it recommended to still define specs and then use s/conform or s/valid? s/explain-data to write the validation logic instead of regular clojure code?

If you have a non-trivial data structure and you use it in multiple functions, yes, I’d say that’s a good case for Spec.

We use Spec to validate API input arguments, so that’s a case where each function might have a different set of :params from a Ring request.

(we used to use coercions in our Specs but that is bad practice so we’ve shifted to using exoscale/coax to do the coercions — it deduces them from a Spec — and then use a plain old Spec to do the actual conforming/validating part)

Re: 1. above — we don’t have anything we can share but this is the bulk of how it works:

(defn invalid-argument
  ([req spec fail-code-map]
   (forbidden req "Invalid Argument"
              (when fail-code-map
                (->> (:params req)
                     (s/explain-data spec)
                     (problems->fail-codes fail-code-map)))))
  ([req fail-code]
   (forbidden req "Invalid Argument" (if (vector? fail-code) fail-code [fail-code])))
  ([req]
   (forbidden req "Invalid Argument")))

(defmacro with-validated-params
  [[spec fail-code-map] & body]
  `(let [~'params (s/conform ~spec (:params ~'req))]
     (if (s/invalid? ~'params)
       (invalid-argument ~'req ~spec ~fail-code-map)
       (do ~@body))))

Re: 2 — there are plenty of resources out there about test.check.

Thanks @U04V70XH6 you would need to use coercions to coerce strings in API requests (from json) to clojure types, correct? Thanks for the code on usage of s/explain-data. Will try it out

Depends on whether you’re dealing with JSON or plain URL/form parameters but, yes, mostly you need something to coerce strings to numbers, booleans, dates, etc — and then conform with Spec.

sure, makes sense