This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-09-25
Channels
- # aleph (15)
- # beginners (65)
- # boot (46)
- # chestnut (3)
- # cider (1)
- # clara (11)
- # cljs-dev (5)
- # cljsjs (4)
- # cljsrn (13)
- # clojure (180)
- # clojure-dev (2)
- # clojure-italy (10)
- # clojure-russia (62)
- # clojure-spec (6)
- # clojure-uk (85)
- # clojurescript (45)
- # community-development (11)
- # crypto (3)
- # cursive (10)
- # datomic (94)
- # defnpodcast (2)
- # fulcro (4)
- # heroku (1)
- # hoplon (4)
- # jobs (3)
- # juxt (10)
- # leiningen (1)
- # luminus (4)
- # mount (13)
- # music (1)
- # off-topic (10)
- # onyx (2)
- # portkey (15)
- # proton (2)
- # re-frame (16)
- # reagent (10)
- # shadow-cljs (194)
- # spacemacs (2)
- # specter (2)
My girlfriend is back at university today. I just watched my dog look between us, unable to move, from the sheer confusion that she is feeding him, not me. Dogs are great. Sometimes.
morning
månmån
I might be a bit late to this news - but did Java 9 get released?
I think so @peterwestmacott
I thought it was just in a pre-release stage, or for general public testing, or something like that.
I saw some headline somewhere and didn't even bother to read it at all... Personally I have found the change Facebook made to the license of React more important.
I thought they only dropped the part where you lost your license to React if you sued them
so my understanding is that previously, if you used react (and others) and sued FB for patent infringement (unrelated to React) you directly loose your license to react
so if FB moved into your area of business and you happen to own patents in that area, FB could infringe because you wouldn't go after them.
more details here: http://www.theregister.co.uk/2017/09/22/facebook_will_free_react_other_code_from_unloved_license/
We are having a new office open day on thurs in Milton Keynes at 11 if people fancy working from somewhere different for a day (or just being a tourist in the delightful new city).
@U050DD55V I was really hoping to come, but I'm completely snowed under with work this week 🙁
in the old model, as far as i could tell from reading legal summaries: If you used react, you got a grant to use react patents. If you sue facebook for patent stuff, you lose the rights to react patents, so you could be countersued for use of react patents - but only if you started it, not if facebook sued you first
and for some companies that is a no go @glenjamin Apache foundation was one for instance (and I wouldn't be surprised if Big Blue didn't like it either) (unless they have a patent deal with FB)
i can see why people would be unhappy with the old one, but as best I can tell, MIT is net-worse
There’s a concept called the Implicit Patent License, which is generally assumed to apply to open source. Never been tested in court AFAIK. http://en.swpat.org/wiki/Implicit_patent_licence There is lots to Google on this topic…. IANAL.
https://www.londonreconnections.com/2017/understanding-uber-not-app/ And now I get it
i have a question about code structuring. i'm using spec, and i'm validating my config. typically, each component in the application will have its own bit of config, which is a key in the config map - :db/port
, :db/url
, :web/port
and so on.
my question is: where should i define the specs for these values? do i define those specs in the db
and web
namespaces, or in the config
namespace? the config
component is a dependency of the others (for obvious reasons), so it doesn't seem right to put the specs in there, but it's a bit weird to have the config
component using specs that are defined in namespaces it cannot depend upon. that means it's reliant on some other namespace (`core`) which loads all the specs before it runs.
thoughts?
i don't think the config
component ought to be aware of specs that may or may not be in the web
or db
components. whether they want to spec stuff on their end is their concern, not config
's
so you think the spec for an api token or a db url should be defined in the config
component, because that's the thing that loads the data?
or are you saying the config
component should not be responsible for validating config at all, it should be done in the components that use each value?
i mean if there's universal config that the config
component is in sole control of, then it could be validated there, but if it's component-specific config, then the relevant component should validate it
As someone who's been using spec heavily in production, I'd agree: the specs belong either with the primary namespace that uses that data or in a ns alongside it. We mostly spec data, not functions, but we typically have a ns for the specs along with core functions that operate on that data. So we have ws.billing.specs
and ws.api.specs
for example. Like you, we have a Configuration
component and it's unaware of the shape of the configuration data.
i'm trying to get each component to validate the config to check that the values it needs are there. the problem is, when spec validates, it uses all specs in the registry, not just the one you give it
so in this example, the :web/port
value is wrong - it's a string instead of an int. but i haven't asked for that to be checked - the explain-data
on line 7 only checks the :config/db
spec, which doesn't mention :web/port
- nevertheless, validation fails.
You're checking the whole conf
against the spec for just part of it -- I think you mean (s/explain-data :config/db (:config/db conf))
? @conan
(s/explain-data :config/db conf)
is going to check conf
-- which has keys :config/db
and :config/web
against a spec that says :db/url
is a required key.
Oh ok sorry I guess I got that bit wrong - an error which is hidden by the web spec failing
Essentially I want an error that explains the full path in the config map when something is wrong, but I only want to check one top-level key
The first problem says your value #:config{:db ... :web}
does not contain the key :db/url
-- which is correct: it does not contain that key.
But then spec reads the keys you do have, assuming them to be optional, and applies the specs that it can find that match those keys (again, expected behavior) so it will validate the whole conf
hash map as a side effect of finding those "extra" keys.
Is there a way to specify which specs to use, or will it always use everything in the registry?
If there are specs that match the keys, it will always use them.
Your only choice is (s/explain-data :config/db (:config/db conf))
Yeah ok, that's my lesson for today. Thanks, that's really helpful! I thought I'd missed something
Then it will get just the sub-map and check that -- which will have the right keys for that spec
A fundamental assumption in spec is that namespaced keys are unique across your whole application and therefore if there's a spec with the same name, it applies -- regardless of whether you say it is :req
uired or not.
you could (select-keys ...)
if you really want a subset of conf, but with the full path to the bit you’re checking
it’s an immutable data structure
you can interact as much as you want, as long as you still have the original reference to it
@peterwestmacott Good suggestion on select-keys
-- but then the specs would need to reflect that extra nesting level: (s/def ::db-config (s/keys :req [:config/db])) (s/def ::web-config (s/keys :req [:config/web]))
and you'd write (s/explain-data ::db-config (select-keys conf [:config/db]))
Interesting to see this discussion. 🙂 I find it a little awkward to just have one central registry for specs; it'd be useful if they behaved a little more like hierarchies in that respect. E.g. I want to write my config files as just :server
, :port
, etc. instead of qualifying them as :config/server
, :config/port
to avoid namespace collisions.
My solution at the moment is to map the keys, essentially. So read in config as EDN, map the keys to :port
-> :config/port
, etc., then do spec validation against the result.
So far we've handled this by nesting configuration in our EDN files (and continuing to use unqualified keys): {:database {:dbtype ... :dbname ...} :paypal {... credentials ...} ...}
Then we can use differently qualified specs for the different parts we care about (with :req-un
/ :opt-un
).
(so the maps have unqualified keys but the specs have qualified names)