chaostoolkit
Rework and clean up modules
This PR is related to issue #39
- scope actions and probes
- (re)write actions and probes tests
@dustinfarris I'm curious what others think about this because I actually feel mixins are dead/not idiomatic ember anymore. My (personal) vote is to not add this, limiting reuse to the functional paradigm by design.
If someone wants the redux experience but in a more "ember-y" wrapper/api I'd truly suggest they give https://www.npmjs.com/package/ember-redux-helpers , https://www.npmjs.com/package/ember-cli-redux or even https://github.com/foxnewsnetwork/ember-with-redux a look instead.
I believe the opinion(s) around how you "connect" to the redux service in this project are indeed it's strength. Simplicity is something I value (in addition to the small api surface area) and I feel others using this addon would agree.
Thanks for the quick feedback. I was not aware that mixins are on their way out. What have been the driving designs/discussions behind this? I am out of the loop.
Sent from my iPhone
On Nov 5, 2016, at 4:52 PM, Toran Billups [email protected] wrote:
@dustinfarris I'm curious what others think about this because I actually feel mixins are dead/not idiomatic ember anymore. My (personal) vote is to not add this, limiting reuse to the functional paradigm by design.
If someone wants the redux experience but in a more "ember-y" wrapper/api I'd truly suggest they give https://www.npmjs.com/package/ember-redux-helpers , https://www.npmjs.com/package/ember-cli-redux or even https://github.com/foxnewsnetwork/ember-with-redux a look instead.
I believe the opinion(s) around how you "connect" to the redux service in this project are indeed it's strength. Simplicity is something I value (in addition to the small api surface area) and I feel others using this addon would agree.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
@dustinfarris short of asking Lauren Tan to define that already fuzzy term "idiomatic ember" :)
- watching the more popular addons of late 2015/ 2016 I've seen a trend away from them/ and in turn a rise in functional programming. If you look for the word Mixin in some of the more recent addons you use, it's likely you won't see it used much (unless the addon is a ember 1x port/ long lived).
Here are a few that show the migration away from mixins/ toward functions and functional programming for reuse.
https://github.com/DockYard/ember-changeset https://github.com/cibernox/ember-power-select https://github.com/cafreeman/ember-object-update https://github.com/dgeb/ember-engines
- during my day-to-day work I've found that more often I reach for functional composition when it comes time to reuse code. If I'm honest, my c# and java background (read: bias) provided more than enough bad experiences with deep inheritance chaining. Mixins just don't get a fair shake with me these days (for better/worse).
Ignoring my subjective bias, the functional approach in software does lend itself to more clarity in my experience. When I call a function, I get a result - no side effects (predictable/repeatable). With mixins (from my experience using them in med/large ember projects) you quickly start reaching for some shared state on the component/controller or you introduce some -that others tap into. Over time it's easy to lose trace-ability regarding "why" something changed/or what one mixin might have assumed about the given state of another (especially because this is all shared mutable state we are talking about)
- a few months back I started to see both 1 and 2 above as general patterns/trends in the ember ecosystem so I took the question to slack (general channel). A handful of people responded saying they never use mixins/ prefer to share code with anything but. One fairly big name in the ember community (unnamed to protect the innocent) said they were something of an anti-pattern these days.
Although my initial response seemed to focus in on "no mixin -they are dead" the main point I wanted to share was that keeping this addon constrained to "one look" is it's strategic advantage/ or what sets it apart from the other redux ember addons. I realize not everyone will be happy with constraints /opinions like this but they are at the heart of what people tell me they love most about using it.
I've tried 2 of those other libraries before. After flipping through them again:
- ember-with-redux is coupled to ember-data
- ember-cli-redux doesn't really do anything except hide combineReducers, has no tests, hasn't been touched since March.
- ember-redux-helpers is kind of interesting, but...
The beauty of ember-redux (which as far as I'm concerned is the best damn Ember+Redux addon out there), is precisely the component state-to-props/actions-to-dispatch solution. You don't need an addon to browserify redux and run createStore, but ember-redux gets you a lot further by giving you connect—a way to redux the way redux was intended.
I think we are on the same page here.
I do think, however, that enabling users to enjoy the connected component paradigm without having to do functional programming at the same time would be a plus for a number of reasons that I'd love to discuss further maybe on a call or something.
In my view, "connected" components doesn't mean "created by a function", rather it means "connected to redux state" via mapStateToComputed and mapActionsToDispatch.
@dustinfarris thanks for the discussion regarding the wider topic of functional programing (and asking if it should be required for ember devs who want to adopt redux).
I think the challenge I had with this issue originally is that as the project maintainer my preference for a refactor/or change comes 1 of 2 ways.
- Someone finds a bug with the existing api
- Someone discovers a legitimate use case I hadn't yet considered
In this situation it felt as if you were unhappy with the public connect api and you wanted to change it. And in doing so it's possible the new component we create as a result would appeal to the traditional ember developer (more generally people who don't think functional first).
This is challenging for me as I don't plan to use that api and in turn wouldn't want to maintain it. I left this issue open in hopes of hearing from others in the community who agreed/ or disagreed about its value. As someone who wants to keep the api surface area minimal and education regarding that api simple, I'm still trying to understand if having more than one way to do the same exact thing is good for the project (functional or not).
@dustinfarris closing this out for a few reasons
- you've opened a new pull request to show the connect api you prefer
- no other person in the community has said "I agree with Dustin and prefer another api for this"
- this hasn't seen any further discussion in 10+ days
Yes, we discussed that Mixins are bad and I should have closed this. Apologies for letting it sit.
Is there something to improve here ? I was thinking about moving all functions from chaosk8s/probes.py to differents folders:
- deployment_is_not_fully_available, deployment_is_fully_available, microservice_available_and_healthy, and microservice_is_not_available to deployment/probes.py
- service_endpoint_is_initialized to service/probes.py
- I don't know about all_microservices_healthy
Should I commit directly on @Devatoria repository ?
I think moving things around is a good idea.
Maybe keeping existing modules with the functiin linking to the appropriate ones but with a warning when they are used from there?
Also, the whole business of "microservice" was a stupidity of mine, it's just a top-down deployment to pod set of functions. Should they remain that way?
I've created a pull request to DataDog repository Let's hope he will find it !