Fork me on GitHub
#clojure-uk
<
2017-09-25
>
dominicm06:09:43

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.

thomas07:09:04

moin moin morning

Rachel Westmacott08:09:35

I might be a bit late to this news - but did Java 9 get released?

dominicm08:09:50

I thought it was just in a pre-release stage, or for general public testing, or something like that.

thomas08:09:22

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.

glenjamin08:09:01

because it’s better, or because it’s worse?

thomas08:09:25

better... they dropped the patent bit of the previous license

glenjamin08:09:36

so now you get no hint at all about patents

glenjamin08:09:55

but if they existed and were relevant, the same is true today

dominicm08:09:34

I thought they only dropped the part where you lost your license to React if you sued them

thomas08:09:01

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

thomas08:09:12

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.

jonpither09:09:51

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).

yogidevbear11:09:16

@U050DD55V I was really hoping to come, but I'm completely snowed under with work this week 🙁

glenjamin09:09:26

React used to be BSD + patent grant, which had some clauses people didn’t like

glenjamin09:09:39

now it’s MIT with no patent mention at all

glenjamin09:09:53

so no grant, with no conditions that cause the grant to go away

dominicm09:09:57

Oh really? Ouch.

dominicm09:09:07

How do they keep getting it so wrong 😂

dominicm09:09:28

I guess, the lawyers have to be careful about React containing patented code & such

glenjamin09:09:29

you only ever lost the patent grant in the old system, never the licence itself

dominicm09:09:34

& now React is so big, it's worthwhile.

glenjamin09:09:26

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

thomas09:09:39

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)

thomas09:09:57

so the new (MIT) license doesn't say anything about patents?

glenjamin09:09:14

I think the Apache license does have patents clause

glenjamin09:09:48

i can see why people would be unhappy with the old one, but as best I can tell, MIT is net-worse

glenjamin09:09:57

and people are mostly happy to use MIT

rorygibson10:09:58

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.

thomas13:09:31

I have never user an Uber... nor am I planning on using one.

thomas13:09:41

interesting read nether the less though. thank you

conan15:09:34

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?

sundarj15:09:30

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

sundarj15:09:52

that's how i would approach it

conan16:09:51

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?

conan16:09:20

rather than the component that needs the value being the one who owns the spec for it

conan16:09:01

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?

conan16:09:05

i can't figure out what i think about this one

sundarj16:09:38

the latter

sundarj16:09:53

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

seancorfield17:09:28

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.

conan17:09:44

great, thanks!

conan18:09:02

i've encountered a problem

conan18:09:37

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

conan18:09:48

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.

conan18:09:56

good one to watch out for in the future.

seancorfield20:09:34

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

conan20:09:14

No, because I want to validate the full path into the config

seancorfield20:09:16

(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.

conan20:09:16

Oh ok sorry I guess I got that bit wrong - an error which is hidden by the web spec failing

conan20:09:05

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

conan20:09:16

(In each component)

conan20:09:42

I think maybe I'm thinking about it wrong

seancorfield20:09:30

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.

conan20:09:33

I can just pull out the bit I need, as you pointed out

seancorfield20:09:57

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.

conan20:09:32

Is there a way to specify which specs to use, or will it always use everything in the registry?

seancorfield20:09:57

If there are specs that match the keys, it will always use them.

seancorfield20:09:13

Your only choice is (s/explain-data :config/db (:config/db conf))

conan20:09:42

Yeah ok, that's my lesson for today. Thanks, that's really helpful! I thought I'd missed something

seancorfield20:09:50

Then it will get just the sub-map and check that -- which will have the right keys for that spec

seancorfield20:09:07

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 :required or not.

Rachel Westmacott20:09:21

you could (select-keys ...) if you really want a subset of conf, but with the full path to the bit you’re checking

conan20:09:08

I basically didn't want any code that interacted with the conf until I'd validated it

conan20:09:30

I can live with one get

Rachel Westmacott20:09:02

it’s an immutable data structure

Rachel Westmacott20:09:47

you can interact as much as you want, as long as you still have the original reference to it

seancorfield20:09:36

@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]))

chrisjd20:09:56

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.

chrisjd20:09:27

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.

seancorfield20:09:43

So far we've handled this by nesting configuration in our EDN files (and continuing to use unqualified keys): {:database {:dbtype ... :dbname ...} :paypal {... credentials ...} ...}

seancorfield20:09:48

Then we can use differently qualified specs for the different parts we care about (with :req-un / :opt-un).

seancorfield20:09:10

(so the maps have unqualified keys but the specs have qualified names)