This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-09-05
Channels
- # beginners (45)
- # boot (2)
- # cider (2)
- # cljs-experience (1)
- # cljsrn (6)
- # clojure (67)
- # clojure-brasil (1)
- # clojure-dusseldorf (47)
- # clojure-finland (7)
- # clojure-italy (81)
- # clojure-portugal (2)
- # clojure-russia (12)
- # clojure-sanfrancisco (1)
- # clojure-serbia (1)
- # clojure-spec (22)
- # clojure-uk (27)
- # clojurescript (49)
- # clojurewerkz (3)
- # code-reviews (3)
- # component (19)
- # core-async (3)
- # cursive (16)
- # events (7)
- # fulcro (20)
- # graphql (7)
- # immutant (1)
- # jobs (2)
- # juxt (44)
- # leiningen (7)
- # lumo (35)
- # onyx (31)
- # portkey (31)
- # portland-or (8)
- # random (1)
- # re-frame (82)
- # reagent (35)
- # sfcljs (1)
- # spacemacs (5)
- # specter (7)
- # unrepl (4)
- # yada (2)
@grierson I'd say that if your function has an "obvious" and fairly straightforward property that holds across all inputs and outputs, then it's a good candidate for :fn
, as long you plan to have explicit process (or code) to perform stest/check
on that function (since instrument
does not check :fn
specs).
If the property is complex or has some non-obvious exceptions to it, then I'd put it in several unit tests instead (and perhaps still have some generative property testing in place as well).
But as @eggsyntax said, having :args
alone can be very valuable -- both for documentation and development/testing with instrument
ation in place.
Can someone tell me why the first form works but the commented one doesn’t?
(ns interop.seed
(:import [com.github.javafaker.Faker]))
(com.github.javafaker.Faker.)
;; (Faker.)
I thought :import [com.github.javafaker.Faker]
would allow me to use the Faker
class without its prefix.
you want (:import [com.github.javafaker Faker])
or (:import com.github.javafaker.Faker)
Didn’t know about that, thanks, it worked.
Hey @alexmiller On a stylistic issue, I always seem to see :import
with a list, not a vector, but :require
with a vector instead. Any historic reason for that?
Like Stu says in the article, using list instead of vector on :import is the most contentious, I prefer vector, visually, I find it easier to parse.
@seancorfield not sure if it helps, but I've found some info in https://stuartsierra.com/2016/clojure-how-to-ns.html
@jumar I remember reading that and wondering how canonical it was... it's fairly recent and Stuart is fairly authoritative 🙂
I will tell you that Rich read Stuart's post and disagreed with the import bit. :)
Good to know, thanks. Also good to hear a few people saying they use vectors instead of lists in :import
. I might switch now since the difference has always bothered me although I understand Stuart's reasoning.
I always just use vectors in both always so I don't have to think about it. But opinions vary.
Hi guys, pardon my novice! Can I use Datomic(which I will need to build capacity on) as my primary datastore or I might need to incorporate it with RDBMS(which am familiar with) like MySQL, and do I use them together(of which I read is a possibility). Or is it like a bridge like druid provides? And why?! Also where does a library like Onyx and manifold come into play. BTW, I intend on building a fault tolerant, high traffic(hopefully 🙂 ), low latency REST based engine with re-frame on the front.
@U5ZAJ15P0 is correct that Datomic works on top of a backend — but I worry that might give the wrong impression. With the exception of basic DB admin (installing, configuring, etc), the backend is essentially invisible — all your interactions are with Datomic. For example, I’ve been working full-time on a large, Datomic-backed project for about a year, which is backed with a SQL DB, and I’ve never once written or looked at a SQL statement while working on the project.
@eggsyntax @simon ah yes, I should have specified. Datomic makes very few assumptions about the storage backend. Basically it only requires it to act as a key/value store with the ability to compare & swap (afaik).
Onyx and manifold are probably not necessary for what you describe. Manifold is just a wrapper around different concurrency primitives, so you can use them together. Onyx is a distributed computing platform for data-processing.
@simon For your use case, you probably want Pedestal, or Liberator, or Compojure, or Yada for your REST backend. You should check out Riemann for monitoring, and logback/tools.logging or timbre for logging. Bolt or Buddy for security. Diehard and Again or Safely for retries, circuit breaking, rate limits.
Is there a left-to-right variation of comp
?
Something like (pipe (partial map inc) (partial filter even?))
instead of (comp (partial filter even?) (partial map inc))
?
@simon Hi! Datomic does not handle persistence, so you will need some form of backend for that
@simon regarding Onyx, there are one or two episodes of the Cognicast talking about it
Don’t go too crazy on Onyx etc if you are new to Clojure though. Make sure you map out your requirements and keep it simple stupid at first
I am new to Clojure myself and haven’t tried Onyx yet, but I do know distributed systems are hard, and from what you are saying I suspect you won’t need it
and also, like ->>
, I think that omitting the partial
at every step makes it much easier to write and read
(->> val (map inc) (filter even?))
is much easier than (comp (partial filter even?) (partial map inc))
,
but it doesn't return a function
it will appear to compose the opposite way, but once you look into transducers you'll see it's not
or, broadly speaking what would a good e-shop framework be at this time? not necessarily Clojure related
@dimovich for the most part, the Clojure/script community has chosen small composable libraries rather than large frameworks. But for a substantial web app, I’d personally suggest looking at Luminus as a good way to get started: (http://www.luminusweb.net/