This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-05-23
Channels
- # aleph (9)
- # beginners (30)
- # boot (42)
- # carry (1)
- # cider (148)
- # clara (2)
- # cljsrn (13)
- # clojars (2)
- # clojure (90)
- # clojure-dev (1)
- # clojure-dusseldorf (2)
- # clojure-italy (7)
- # clojure-madison (1)
- # clojure-quebec (1)
- # clojure-russia (19)
- # clojure-sg (1)
- # clojure-spec (14)
- # clojure-uk (90)
- # clojurebridge (1)
- # clojurescript (70)
- # clr (7)
- # core-async (24)
- # cursive (26)
- # data-science (2)
- # datascript (3)
- # datomic (46)
- # devops (2)
- # emacs (6)
- # events (1)
- # figwheel (2)
- # hoplon (200)
- # klipse (2)
- # ldnclj (1)
- # lein-figwheel (4)
- # leiningen (3)
- # off-topic (44)
- # om (70)
- # other-languages (6)
- # pedestal (5)
- # protorepl (1)
- # re-frame (17)
- # reagent (14)
- # schema (2)
- # spacemacs (1)
- # specter (3)
- # test-check (38)
- # unrepl (38)
- # untangled (19)
- # yada (16)
Do you have a good tutorial for simple buddy integration?
@leontalbot perhaps https://lambdaisland.com/episodes/buddy-authentication ? - but it's not free. you can still look at the source code: https://github.com/lambdaisland/booklog/tree/ep28-start. However, if you're interested in more than one episode consider subscribing - it's really worth it.
Saw it, thanks! It uses component. Was curious about a ring integration
it’s not possible to use buddy without ring as far as I know
component and ring do completely different things, and are often used together
oh, ok
(Testing in CLJS 1.9.542), I get an error "could not find tag parser for :user ..." trying (cljs.reader/read-string "#:user{:a 1 :b 2}")
. What is the correct way to read a namespaced map?
Seems like CLJS 1.9.542 should know how to read namespaced maps, shouldn’t it? I thought that was added a while ago.
not sure. tools.reader, which the cljs reader uses supports namespaced maps. I’m not clued in enough to know the difference between that and cljs.reader/read-string.
So I have a db query that returns me a keyword :ov@@prev When I filter with that, it gives me symbol prev unknown error. Is there an escape char or the like to make it work, or do I need to rename my result?
@fingertoe I prefer to not keywordize, but you can just use (keyword "ov@@prev")
also
it’s not a valid keyword according to the reader rules, but you can make a keyword out of anything that can fit in a string (for better or worse)
it might be that it’s cumbersome to turn off the keywordizing (depending on your db library) but I recommend just not turning random garbage into keywords in the first place
I am using clojure.java.jdbc with “com.ibm.as400.access.AS400JDBCDriver” Not sure how to turn that keywordize switch on or off.. The (keyword “ov@@prev”) does make my filter work.
that would work too - I’m surprised there’s no easy way to just get the keys as strings
Random question of the day. When does it make sense to not use a single hashmap as the argument to your function. It seems like the typical thing to do in most languages is to expect an ordered list of arguments.
def full-name(first , last):
...
but do we really care about the order? When would using a list be better then a hashmap with validation checks?great question. for me list vs hashmap is about extensibility. If you choose a list, and make a change where you need to require more arguments, now you have to change every single calling signature. Hashmaps are associative and represent an open information model... you can just add a key and choose to use it or not.
and makes the default values super simple. in c# this is nice but requires a language feature.
Method(arg3: val3, arg2: val2)
vs (method {:arg3 val3 :arg2 val2})
I can only think of two cases where an ordered list is better: 1) when efficiency really matters. (and these cases are increasingly rare; and I'd imagine that any half-decent compiler can optimize most real cases anyway). 2) when the function is so simple that the mental overhead of typing/reading the argument keywords is greater than the flexibility that they give.
If there is a set of required args, I will always want to see them as explicit args, in order from the most general to least general, or least variable to most variable
but the clojure compiler doesn’t do those kinds of optimizations
And then there are obvious cases: can't imagine map
taking {fn: #(inc %) :coll [1 2 3]}
or addition taking a map of things to add rather than just a list
just to point out the simple case to "when does it make sense to not use a single hashmap as the argument to your function".
Thanks for all the feedback! 👍