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.
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.
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.
Thanks. I'll probably end up creating an unprovisioned partition. It's frustrating, exactly because of the uncertainty re future performance. Especially given the price premium for pro/enterprise level hardware.
I have one of the affected drives mentioned in the article in my development laptop - the Samsung SSD 850 PRO 512GB.
As one of the most expensive SSD drives available on the market, it was disconcerting to find dmesg -T showing trim errors, when the drive was mounted with the discard option. Research on mailing lists, indicated that the driver devs, believe it's a Samsung firmware issue.
Disabling trim in fstab, stopped the error messages. However it's difficult to get good information about whether drive performance or longevity may be impacted without the trim support.
> In the real world there is always a discord between requirements and reality, skillsets and the problem space, change management and the need for rapid change, scope creep, and on and on.
We follow Agile. At the beginning of iteration planning, the dev-team, has to task-out the items and score the complexity, and then decide the cut-off point as to what can and cannot be achieved within the 2 week iteration.
It's taken us several years, but this ruthless cycle of feedback, and responsibility has led us to a point, where we scope it right about 75% of the time.
Having also been involved in projects that have overrun deliverable dates by years - I wouldn't have believed it possible for a software-management process to work so well.
Of course it helps, that there is genuine philosophical buy-in, and that our revenue is derived from our software (eg. we're not a cost-centre).
Almost all languages have an escape-hatch to do dangerous stuff.
The key insight about Rust is the set of programming abstractions (linear types to manage resources) that enable one to get systems-like programming tasks done, without needing to fall back on very low-level coding techniques.
My experience playing around with KD trees is that they are super effective for multidimensional indexing (including spatial) and range search so long as the data is relatively static. The difficulty comes when trying to update and re-balance them dynamically, which is where other structures perform better.
Everyone who needs 'upsert' is forced to go and read those discussions (and probably a few more articles as well), and then implement their own version of the same thing many times over.
The fact that it's complicated is precisely the reason this ought to be solved for the general case.
Otherwise, Postgresql is still an awesome product.