This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-05-10
Channels
- # announcements (4)
- # beginners (111)
- # boot (34)
- # cider (67)
- # cljdoc (10)
- # clojure (90)
- # clojure-dev (37)
- # clojure-europe (3)
- # clojure-gamedev (3)
- # clojure-italy (18)
- # clojure-losangeles (2)
- # clojure-nl (27)
- # clojure-spec (24)
- # clojure-uk (59)
- # clojurescript (41)
- # cursive (32)
- # datomic (31)
- # emacs (21)
- # figwheel (1)
- # figwheel-main (2)
- # fulcro (43)
- # graalvm (6)
- # graphql (3)
- # jobs-discuss (3)
- # kaocha (1)
- # nyc (1)
- # off-topic (22)
- # pathom (10)
- # pedestal (11)
- # re-frame (9)
- # reitit (17)
- # shadow-cljs (15)
- # spacemacs (13)
- # sql (6)
- # testing (5)
- # tools-deps (3)
- # vim (13)
- # yada (1)
Does anyone happen to have a gist or example of a web app without using routes as a global? I’m curious now
hi
can someone explain me, please, why this line of code is not working
(map #(str "bla") (range 5))
while this is working
(map #(str "bla" %) (range 5))
yeah, it expects a function with a single argument
Is there a place to discuss improvements to the beginner experience of Clojure lang and tooling? Thanks!
I don’t think anyone would mind a discussion starting here at least.
Yes, I think a discussion about the "beginner experience" is appropriate for this #beginners channel!
What do I lack wrt beginner experience? 1. I just discovered that the out of the box experience of clojure.test is disappointing, outputting a single long line with two large maps when (is (=..)) fails. Not very impressive for my colleagues :( I guess Kaocha is much better. 2. We should have a web site about beginner-optimized setup, including Kaocha for test, this project I don't remember that replaces the default docstrings with better ones, something like Pretty for less scary error reports...
is there any support for setting up and testing a mock database with SQL queries using the java.jdbc
wrapper?
@nicholas.jaunsen What are you looking for? We use SQL migrations and wrote our own little function for that, but as @robertfrederickwarner notes, there are specific migration libraries. Assuming you're asking about migrations?
no, I just wanted to setup a mock database to test if the queries I've written work as expected with mock data
Sounds like migrations to me: you want your test suite to be able to start with an empty DB and build all the tables/metadata your code needs, and populate it with test data.
I would strongly advise using the same database locally for testing that you'll be using in production. SQL -- and DDL in particular -- differs across databases so trying to substitute an in-memory database or local one (SQLite, H2, Derby, HSQLDB) is a difficult path to take. Docker makes this easy.
Happy to discuss how we do this in #sql @nicholas.jaunsen
Yes, I think a discussion about the "beginner experience" is appropriate for this #beginners channel!
@holyjak What would you like to see improved? (It's already a lot better than it was a few years ago 🙂 )
That's really hard to read @kari.marttila -- can you edit the message and surround the code part with triple backticks?
is there a reason to use type dispatch as opposed to passing the config around as a map?
Wait a sec, I try to reformat...
If I need a configuration protocol and two distinct types that implement that protocol (in order later to dispatch in another protocol based on the types), e.g.:
(defprotocol ConfigP
"Configuration protocol."
(get-config [this] "Gets configuration"))
(defrecord SingleNodeConfigR [my-config]
ConfigP
(get-config [this] (:my-config this)))
(defrecord AwsDynamoDbConfigR [my-config]
ConfigP
(get-config [this] (:my-config this)))
Is there some way in Clojure to make some kind of "base record which would implement ConfigP and then SingleNodeConfigR and AwsDynamoDbConfigR would just extend the "base record" without needing to implement the get-config function?It may just be that after 20 years of Java programming my mindset is still too object oriented. 🙂
Sounds very OO
Yes. Sorry. 🙂
No, Clojure frowns on inheritance for reuse like that (and it's generally a bad pattern in OOP as well).
What would then be a Clojure idiomatic way if I have a domain which needs to operate with two different data stores (SingleNode and AwsDynamoDb). I'd like to create some kind of configuration record (either SingleNode or AwsDynamoDb) and then pass that record to domain protocol which would dispatch to two domain record implementations based on those types?
Maybe multimethods?
Yep. I guess I need to read more my Clojure books to get my mindset to more functional...
What's wrong with just using hash maps?
I somehow thought that you need types to dispatch in protocols?
+1 for maps > records
Configuration is generally "just data".
You should think about the protocols of the data stores themselves -- higher-level.
You'd have a DataStore
protocol for that... Assuming you really need/want to go down the protocol path in the first place.
This is how I approach these kinds of problems:
(defmulti get-product-groups :domain-type)
(defmethod get-product-groups :aws-dynamo-db [{:keys [products]}]
;; Do aws-specific stuff here
(conj products :AWS-behavior))
(defmethod get-product-groups :single-node [{:keys [products]}]
;; Do single-node-specific stuff here
(conj products :single-node-behavior))
(get-product-groups {:domain-type :aws-dynamo-db
:products [:a :b :c]})
(get-product-groups {:domain-type :single-node
:products [:d :e :f]})
My idea was to create a domain protocol like this:
defprotocol DomainService
(get-product-groups []
"Gets product groups")
(get-products [pg-id]
"Gets products for a product group, returns list of items: [p-id, pg-id, name, price]")
...
... and then make two defrecords:
(defrecord Single-node []
DomainService
(get-product-groups ...
and
(defrecord Aws []
DomainService
(get-product-groups ...
... and then in server to call the DomainService protocol with the configuration and the dispatching would happen based on the configuration (either Single-node or Aws...).... I guess this is the next major step in my Clojure study path - learn to think in Clojure. I have studied Clojure the language but I feel I still cannot think in Clojure.
For me, it's been about shifting my thought process from "objects with types that have state and behavior" to "data flowing through functions"
mostly in idiomatic clojure we don't make new protocols
Aha, that's interesting.
So, I have really misunderstood my Clojure books...
defining records / deftypes with no fields is a code smell
what helps me is writing it like a really simple imperative process, to get all the OO/interface-y stuff out of my brain, and then adding clojure-y stuff back in by refactoring
So, what would be an idiomatic Clojure solution to this kind of problem: - I have two datastores: A and B. - I need to create separate implementations for A and B how to interact with those datastores (in "domain layer") - In "web layer" I want to be able to call "abstract" domain functions without knowing which datastore actually is used.
Per my example, multimethods are often the tool of choice for that kind of polymorphism
When the server starts it reads the configuration and the configuration says whether to run in mode A (single-node) or B (AWS).
if you only have two use cases, is polymorphism required? you could cond
on a keyword
Yes, I could just cond but this is a learning project and I'd like to find some more "generic" "open" solution.
cond plus functions is more generic and open than a protocol
I think DomainService
as shown above is fine, but I agree that having no fields in the defrecord
is "odd". I would expect both to have a config
field, at least -- a hash map containing configuration. Given that your services probably have a lifecycle -- some sort of start
and stop
-- it might make sense to use Component
here and then the start
could read the configuration from whever (and assoc
it into the component).
Ok. Sounds good.
If you really only expect to have a few implementations and they all implement the same API, then protocols probably are the way to go.
The key there is that all implementations are expected to implement the entire API.
Yes, that's the idea for the domain. There are N functions and every implementation (A and B) needs to provide implementation for them.
But how do I dispatch to either A or B? I though that I need a type for that?
You seem to have already answered that: https://clojurians.slack.com/archives/C053AK3F9/p1557511379252000
That has two types. You don't need additional types for config as well -- just use a hash map for config.
That's the reason I thought I'm going to make ConfigA and ConfigB...
Agreed. I've yet to run into a situation where I've actually had to define a protocol for anything. 99% of the problems I encounter are just data and functions on the data.
Ok. It's really great to ask "stupid" questions here. Maybe I didn't get the answer I wanted but I learned something else.
No such thing as a stupid question! A lot of us went through the same process of unlearning
Yep. 20 years of Java - the unlearning of OOP is probably the hardest thing in learning Clojure.
Damn. The discussion here is so interesting but my wife calls me. It's Friday evening in Finland and time for our traditional Friday evening movie. 🙂 But many thanks to all of you. Tomorrow I think again whether I need protocols or something else.
Peace
Is there a way to get data.json to recursively apply the :key-fn function?
or is Cheshire's version recursive?
user=> (json/parse-string "{\"a\":{\"b\":42}}" keyword)
{:a {:b 42}}
user=>
That's with Cheshire.
What do I lack wrt beginner experience? 1. I just discovered that the out of the box experience of clojure.test is disappointing, outputting a single long line with two large maps when (is (=..)) fails. Not very impressive for my colleagues :( I guess Kaocha is much better. 2. We should have a web site about beginner-optimized setup, including Kaocha for test, this project I don't remember that replaces the default docstrings with better ones, something like Pretty for less scary error reports...
Can we call this the intermediate experience? I had a couple happy years of hacking Clojure before I even thought to use clojure.test . My beginner experience was a lot of learning a more functional style and testing things in the repl.
in my project (https://github.com/slifin/beeline) if I run
lein run "{\":select\" [\":b\"]}"
I get ["SELECT b"]
as I expected but if I do lein native-image
and run ./beeline-0.1.0-SNAPSHOT "{\":select\" [\":b\"]}"
I get no output, though I know my program is running because if I change the input I get errors that make sense for my program, what's stopping it from printing?@holyjak with certain additions, like https://github.com/nubank/matcher-combinators, you can get a pretty nice testing experience. I agree that the vanilla experience is lacking.
I also use the autotest
feature of https://github.com/marick/Midje, although my tests are written in clojure.test
There are a huge number of options for testing in Clojure but I agree the OOBE is poor for failures with complex data in clojure.test
. I don't really think that's a "beginner experience" issue -- as @ericcervin says. There have been discussions about splitting clojure.test
out into a separate Contrib library that can evolve at its own pace (like spec, tools.deps, etc), as well as a number of improvements that could be made. I took a snapshot of that wiki page (before Confluence is shutdown): https://github.com/seancorfield/clojure-test
There's also been a big improvement in error reporting in 1.10 and 1.10.1. Could it still be better? Sure, but it's vastly better than it used to be. I think it's more important to guide beginners to stay with what you get out-of-the-box rather than pointing them at a vast array of libraries that supposedly "improve" the experience. That's how beginners get into a mess with lein
and profiles.clj
-- some of those "helpful" plugins cause all sorts of weird dependency conflicts and strange behavior.
I think it's important that beginners learn how to navigate a Clojure stacktrace. We'd definitely benefit from some http://clojure.org guide on how to read stacktraces I think.
I feel thats also dependent on programming language philosophy. For example Pythons philosophy says that it comes “batteries included”. I don’t personally feel that applies to Clojure in the same way. Its more of a mix-and-match kinda deal 🙂!
I think thats a good thing! Means that there are test framework to your liking
and build tools to your liking
.. etc. But makes it slightly harder to find what is where 🙂
the problem is it takes time and experience to find those...
Eric Normand's REPL-Driven Development course is something I would highly recommend to beginners, since it focuses on getting the most out of simple tooling and becoming really productive in the REPL https://purelyfunctional.tv/courses/repl-driven-development-in-clojure/
@lennart.buit Yeah, Clojure != Ruby for example (and, in particular, there's nothing like Rails). And I have a much harder time dealing with Ruby, gems, rake, bundle, and all that stuff. My Ruby environment is always breaking for no apparent reason. Drives me insane. I'm just glad I pretty much only have to use it for Jekyll/Octopress these days!
yeah, we do Clojure and Ruby at work. So, I am doing the bundle dance still
I don’t actually know how any of it works, my rvm is complaining since a few months that I am running some strange configuration
but it still works, so I am not touching it
Clojure doesn't include batteries, but it is simple to see where I can attach my own power supply (exercise bike/ water mill / etc)
hey folks, into is used for putting one collection into another.
according to clojure documentation. but why this error?
user=> (into {1 2 3 4} [1 2 3 4 5 6])
Execution error (IllegalArgumentException) at user/eval132478 (form-init595175356905984918.clj:1).
Don't know how to create ISeq from: java.lang.Long
you are into’ing into a map, is that your intention? Or did you mean a set
if you want to put your collection pairwise into the map, there is hash-map
:
(into {1 2 3 4} (apply hash-map [1 2 3 4 5 6]))
@seancorfield Good point about libraries messing up the environment. And thanks for the REPL course tip!
I agree people should learn to navigate Clojure stack traces. But I think they don't need to start with that from time 0. As a person evangelizing for Clojure, this is one of the things that detract people in my experience.
Similarly with the unhelpful test output. Who thought it was a great idea to put two data structures on a single line?? Anyway, I think most decent test runners in most languages provide better experience (at least not outputting a single line :)) so we should not lag behind (too much). I would believe that using (is (= expected-data actual-data))
is quite common though perhaps with smaller data than I had.
I'd love to see clojure.test
improved. If it does get split out of core into a Contrib, I've already said I'd be happy to take it on as a maintainer and try to bring some of the improvements from Expectations (which I maintain) in terms of failure reporting.
As for stacktraces, there's no reason for tooling to display them by default at this point. Here's the basic clj
tool handling an exception:
user=> (/ 1 0)
Execution error (ArithmeticException) at user/eval1 (REPL:1).
Divide by zero
And while that didn't get into clojure.main
in 1.10:
(! 1092)-> clj -e '(/ 1 0)'
Exception in thread "main" java.lang.ArithmeticException: Divide by zero
at clojure.lang.Numbers.divide(Numbers.java:188)
at clojure.lang.Numbers.divide(Numbers.java:3901)
at user$eval1.invokeStatic(NO_SOURCE_FILE:1)
at user$eval1.invoke(NO_SOURCE_FILE:1)
... more stacktrace elided ...
it is part of the 1.10.1 experience: (! 1093)-> clj -A:1.10.1 -e '(/ 1 0)'
Execution error (ArithmeticException) at user/eval1 (REPL:1).
Divide by zero
Full report at:
/var/folders/p1/30gnjddx6p193frh670pl8nh0000gn/T/clojure-5985290963305616578.edn
I use Atom/Chlorine and it shows just the first few parts of the stacktrace inline and greys out the .java
parts so it's pretty easy to read just the .clj
pieces. I'd still prefer it to collapse more out of the stacktrace -- but this is all about 3rd party tooling at this point, rather than core Clojure. 1.10.1 will allow for tools like lein
to use a JVM property to control error reporting so it won't even need to hook into the new functions (which would require version testing/feature flagging).