Clojurians Log v2

> kick would take care of rebuilding sass for you Ah this would be nice. My hack is to run a node-sass process in the background.

> More current thinking is to define in the config.edn. But how granular to go in config.edn is still under consideration. Awesome I think this answers my question

i’ve been thinking about this for a while and would love to hear someone else’s input: originally per-resource based authorization seems really cumbersome and error prone. it can get a little “better” if you define various roles w/ granular permissions in some config map, then attach role-based access to resources. at least everything is in one place at this point. i keep thinking there must be a more generic way to allow/deny access to a resource based on a request’s intent — perhaps introspection on the verb+noun and current session. i’m not sure how this would work, but it seems less finicky. then i thought, at the end of the day, so long as you can detect changes to access patterns and it’s fairly human readable, that’s probably as good as you’re going to get. in this respect i think yada wins because it’s just a giant blob of data describing at the per-resource level who can touch things. :thumbsup:

Data wins out. We were discussing esoteric use cases for yada earlier, and nothing seemed impossible, although a few models seemed like they could be nicer.