Do they? What evidence do you have of that? Insurance companies typically reimburse for actual genetic tests, and they are legally prevented by GINA from discriminating against you for the test results.
The FDA wants them to get approval becaue what 23&Me was doing was illegal and then when the FDA informed them, 23&Me didn't respond (this is all clearly documented!). The FDA has a requirement to enforce the law.
Can anyone compare and contrast flux, reflux and redux?
I have got the hang of writing flux stores - and like the uni-directional dataflow model a lot. I also evaluated relay/graphql - which unfortunately is missing backend support for my relational db for the moment.
It feels like I need some experience with all the patterns/frameworks before it's possible to be confident about choosing and investing time writing code.
Reflux is simpler to understand and forgoes switch statements and has various ways to connect stores up, even allowing one store to trigger stuff on another. It's more easy to make a mess I think, largely dues to the multiple stores and how they interact with eachother.
Redux is more cleanly uni-drectional, has a larger community, amazing debugger, amazing hot reloading support, and a lovely concept of middlewares that can extend actions as they pass through your system. Most importantly I've found a single store/source of truth makes everything cleaner. It's also simpler code underlying it than Reflux and more of a nice design pattern.
I think Redux is clearer what is going on in my final programs and will tend to use this going forward.
I'm using React on a few smaller projects where I didn't want to over engineer the whole Flux architecture. I put together the app using Backbone (for the models and collections) and used React for the view layer.
The models and collections worked great as "stores" and I used the simple dispatcher from Flux to handle the actions being sent.
While I really like the Flux pattern, for smaller'ish apps it did seem a bit of overkill.
A couple articles I was referencing for BB and React:
Flux is just the name of the overall design pattern as well as FB's reference/example of it.
Reflux is Flux but using the environments event model as the dispatcher. It's event based, it's simple, it's easy to get started with. It's not very opinionated, but it doesn't work well on the server (not very isomorphic app friendly).
Redux is the new hotness. It's also very isomorphic app friendly. It's really a "build it from the ground up with this in mind" framework - that's not a bad thing, it just is what it is. It's very smart, but also extremely verbose. Downside - it holds all app state in one giant store. That's... fine, but it actually over-complicates your app if you have a lot of disparate data domains. It's a super opinionated framework.
There's also AltJS which is basically most of the good of Redux but with less of boilerplate. It's way less opinionated than Redux but more so than Reflux.
They all have their pros and cons. Redux is rather over-hyped right now though for what it brings, careful of the hype-train.
As someone who spends most of my time in vim/ screen/ tmux I moved to xmonad recently as well (albeit on debian).
It felt very liberating to suddenly be free of all the Gnome3 / Unity politics, developer fragmentation, and complex desktop systems that still feel inferior to the commercial OS-X/Windows alternatives.
It's arguably faster and of more benefit to learn OO in an OO language, and then work backwards to figure out ways to implement those strategies in C (eg. polymorphism using structs with arrays of function pointers, or win32 send_message constructs).
It's similar with functional programming. Figuring out folds, pattern matching and monads is probably easiest in haskell or Ocaml/F#. The decision to apply those techniques in other languages without native support then becomes a judgement about the benefit.
I thought your analogy was spot on. In React, the view is reduced down to a functional projection of the model - rather than being a complicated set of state interaction patterns (eg. mvc,mvvm). The React framework then handles the real DOM update - in the same way that a Monadic IO computation is not executed directly - but instead is passed to the Haskell IO runtime to be executed.
The problem with Java binaries on the client, was that the Java applet didn't have direct access to the DOM bindings.
Instead, the applet rendered it's own GUI via the plugin, and the look and behavior was inconsistent with the rest of the browser experience.
A similar story with activex and flash.
It's a mystery why it has taken so long to get to the point where we can target the browser with a statically-checked higher-level language that has API access to the native browser event loop and dom components the same way that Javascript does it.
> It's a mystery why it has taken so long to get to the point where we can target the browser with a statically-checked higher-level language that has API access to the native browser event loop and dom components the same way that Javascript does it.
We are already there. Compile to JavaScript (or, heck, WebAssembly if that ever becomes feature-complete enough).
I can make 20 or 30 commits during some code changes in a morning's worth of coding. This allows me to easily trace back to any point, or cross-reference changes across many local branches, etc.
At the end, it might all be squashed down into a single bug-fix commit for the devel branch.
The commit granularity that's desirable and effective for an individual is very different to the history you want in the main feature branches.
