Clojurians Log v2
announcements
Hi folks, I just published a new version of https://cljdoc.org/d/org.graphqlize/honeyeql/0.1.0-alpha36/doc/readme after a one-year break. This new version adds support for https://cljdoc.org/d/org.graphqlize/honeyeql/0.1.0-alpha36/doc/aggregate-queries & https://cljdoc.org/d/org.graphqlize/honeyeql/0.1.0-alpha36/doc/attributes#one-to-one relationships. I've also added documentation for https://cljdoc.org/d/org.graphqlize/honeyeql/0.1.0-alpha36/doc/debugging-troubleshooting.
Expectations — an expressive, clojure.test-compatible testing library — has a prerelease of 2.0.0 available: https://cljdoc.org/d/com.github.seancorfield/expectations/2.0.0-alpha2/doc/readme — the main changes from the previous version (1.2.1) are:
- improve “drop-in” compatibility with clojure.test (by re-exporting several clojure.test features so you don’t need to require that as well as Expectations)
- provide cljs.test-style fixtures (hash map with :before and :after functions) in addition to the regular clojure.test fixtures
- provide standalone (self-hosted) ClojureScript compatibility (via planck, thanks to @kkinear) — previously, Expectations was Clojure-only
- moves to com.github.seancorfield/expectations (formerly expectations/clojure-test)
Follow-up in #expectations for specifics or #testing for general stuff.
Hi all, wanted to share https://github.com/nytimes/vase.elasticsearch This adds Elasticsearch bindings to Vase so that you can build out simple search systems in a data-driven manner. We currently use it to power the NYT cooking search as well as some internal search systems.
I'm a (positively) surprised Vase is still in use, I thought it had lost traction :)
@olivergeorge sure! this follows on the same basic premise as https://github.com/cognitect-labs/vase/blob/master/docs/design.md: a concise way to specify simple microservices for some business need. this library extends vase to add support for elasticsearch so that you can add search to a microservice or make a full search oriented microservice. we use this internally so that small teams can spin up search for their product without having to have deep knowledge about running the entirety of a search system. so we take care of the infra and the data sources and let product teams create these concise specifications of search for their business domain
Initial public release of snoop — use malli schemas to instrument functions and validate inputs & outputs at runtime.
• Compatible with both Clojure and ClojureScript
• Convenient schema notation or use m/=>
• Works with multi-arity functions
• Configuration options for runtime and compile-time
• Uses a custom defn wrapper macro that hopes to be easier to combine with other defn wrappers
• Alpha
I've found instrumentation to be very helpful in tracking down errors in data-heavy situations.
https://github.com/CrypticButter/snoop
Just out of curiosity, is there a reason why such functionality isn't included in malli itself yet? Future plans? @ikitommi
there are at least 4 different flavours of schematized defn macros in the wild and Rich is doing/thinking something new for this. Don't wont to make any one standard now. All anyway share m=> machinery, all contribute to same registry, get clj-kondo for free etc. The Plumatic-style will be an optional part of malli, as I like the most 😎
:)
I've updated the library to allow specifying schemas next to each parameter declaration, like you can with Plumatic. Personally, I'm not terribly keen on peppering the params vector with :- and commas, so I decided on lists instead:
(>defn fun
[(x int?) (y int?) (z melon?)]
[=> string?]
...)@luis.tn One benefit of using the Schema notation would be that the syntax is supported out of the box with clj-kondo :)
@borkdude I provided a clj-kondo config export in the repository 👍.
ah that works too :)
Added link to malli README. Congrats on the release!
Sounds interesting. Would you mind giving us the elevator pitch? For the initiated…
Out of curiosity, are you still using Expectations yourself? We recently finished migrating ~60k lines of expectations-based tests in Metabase to clojure.test earlier this year, mostly because there's better tooling around it.
This was easy to accomplish piecemeal by writing removing the dependency on expectations and writing
(expect ...) https://github.com/metabase/metabase/blob/release-x.38.x/test/expectations.cljthat expanded out to a
(deftest some-name-based-on-test-hash
(expect= expected actual))clojure.test/assert-expr impl for expect= .
The main reason I'm asking is it looks like the migration path from expectations 1 -> expectations 2 seems like it would be about the same amount of work as migrating directly over to clojure.test . So if I were to convert another project using Expectations 1 (I still have a few around actually), would it really make sense to convert it to Expectations 2 instead of just converting it to clojure.test?