Fork me on GitHub

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.


moin moin morning

Rachel Westmacott08:09:35

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


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.


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


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


so now you get no hint at all about patents


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


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.


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 🙁


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


now it’s MIT with no patent mention at all


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


Oh really? Ouch.


How do they keep getting it so wrong 😂


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


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


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


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)


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


I think the Apache license does have patents clause


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


and people are mostly happy to use MIT


There’s a concept called the Implicit Patent License, which is generally assumed to apply to open source. Never been tested in court AFAIK. There is lots to Google on this topic…. IANAL.


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


interesting read nether the less though. thank you


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


that's how i would approach it


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?


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


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 can't figure out what i think about this one


the latter


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.


great, thanks!


i've encountered a problem


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.


good one to watch out for in the future.


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


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


(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


(In each component)


I think maybe I'm thinking about it wrong


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.


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


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 :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


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


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


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