> we do this using Graph
Could you show a simple example of this? I think this might be a good topic
for a blog post.
On Thursday, September 12, 2013 6:35:20 AM UTC+2, Jason Wolfe wrote:
>
> At Prismatic, we do this using Graph:
>
> https://github.com/Prismatic/plumbing
>
> I really try to avoi
At Prismatic, we do this using Graph:
https://github.com/Prismatic/plumbing
I really try to avoid global vars, but passing through the seven parameters
or resources you need through four layers of intermediate functions is also
a hassle. Graph makes it easier to define your service in a functi
Thanks for sharing the various options you guys are using, much appreciated.
I'm thinking I'm going to go with a function returning a map of configs
(potentially memoized) with the option to overwrite certain keys from a
separate map for testing etc. Should be good enough for my use cases.
On We
Euh... our local config would require loading a top level map with more than
twenty keys and a dozen levels deep of maps.
I am not sure I would like to carry a local copy in all workers.
Freezing the app somehow when a config change occurs is mandatory.
Each node in the cluster runs at least a d
2013/9/11 Softaddicts :
> We load configuration data once from zookeeper and conceal it in a name space.
> Changing the context is quite simple, we reload resources in this name space
> using a minimal list of properties which says where the configuration data
> should be
> pulled from in zookeep
We load configuration data once from zookeeper and conceal it in a name space.
Changing the context is quite simple, we reload resources in this name space
using a minimal list of properties which says where the configuration data
should be
pulled from in zookeeper.
This is doable from the REPL
As far as possible, I think it is best to try and minimise mutable global
state (like mutable configuration data) and implicit context (like dynamic
vars). My preferred approach is to pass the configuration data (as a value)
to a higher order function that constructs the configurable object /
f
I like the dynamic var approach. It even allows to enforce that submodules
won't see some keys (using select-keys or dissoc). It tests nicely too.
Christophe
--
On Clojure http://clj-me.cgrand.net/
Clojure Programming http://clojurebook.com
Training, Consulting & Contracting http://lambdanext.eu
I have gone the dynamic var before, played well with ring handlers.
Why ?
Because I wanted to ensure consistency between "reads" to the
configuration map for the duration of the ring handler call.
So just having the configuration and read the root value at different
times would not suffice.
I ju
I do a hybrid in Bulwark.
github.com/bitemyapp/bulwark/
Defaults to accepting a closure of a config map for nice testing and
hygiene, with a fallback to a global atom map for configuration for muggles.
Works well for me.
On Tuesday, September 10, 2013 12:19:35 AM UTC-7, Alexandr Kurilin wrote:
This presentation is funny from Stuart is interesting and funny to watch as
usual :)
The "mud ball" issue is not new and you can face it in other languages than Lisp
that lack a single straight jacket with which anything needs to be defined
(like classes).
Freedom comes with a price, you cannot
This Clojure/West talk deals with many of these concepts.
http://www.infoq.com/presentations/Clojure-Large-scale-patterns-techniques
Timothy
On Tue, Sep 10, 2013 at 6:35 AM, Philipp Meier wrote:
>
>
> Am Dienstag, 10. September 2013 12:58:46 UTC+2 schrieb Luc:
>
>> I agree more or less, I hat
Am Dienstag, 10. September 2013 12:58:46 UTC+2 schrieb Luc:
>
> I agree more or less, I hate having my configuration data spread
> everywhere.
> I prefer to dedicate a name space to maintain/access configuration data.
> I usually split access to resources using bundles.
> A bundle can reflect
I agree more or less, I hate having my configuration data spread everywhere.
I prefer to dedicate a name space to maintain/access configuration data.
I usually split access to resources using bundles.
A bundle can reflect anything you want in your design, including a controller...
This allows you
Am Dienstag, 10. September 2013 09:19:35 UTC+2 schrieb Alexandr Kurilin:
>
>- Something in the middle where perhaps you agree to never directly
>reference the configs map from your models (again, thinking MVC here) and
>instead only ever access it from controllers, and pass the neces
15 matches
Mail list logo
