stream_fusion

React and jsx constructed dom using inline-styles brings the disparate technologies together in a composable way.

> Also, I don't think 23&Me's test results have enough medical value to be used for evaluating health risks.

Insurance companies would have another view.

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.

There's an intention is to transition ethereum from proof of work, to proof of stake, to avoid some of the mining centralization and waste.

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 the same drive in a laptop. There were lots of trim errors in the kernel logs, with debian so I ended up disabling trim.

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.

An argument behind not increasing the block size, is that miners can price-ration the inclusion of transactions in blocks.

During periods of high network contention, an ordinary user can include a higher-fee to prioritize their transactions.

Correspondingly, the cost for attacking the network using spurious transactions will increase.

> 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).

Reverting a commit is trivial. There is zero opportunity of destroying a repo. From my notes,

# revert a commit

git revert dd61ab32