Using common functional tools can be a great way to simplify code like the example here, but as with most programming techniques, it can easily backfire in real-life scenarios.
There have been a number of times I've seen junior developers who are high on functional/immutable paradigms commit mazes of mapping, filtering, rolling and unrolling, resulting in something that's hard to understand and hard to debug.
Even in the example here, while it's obvious what the replacement code _does_, it's less clear what it's _intending_. I actually had to refer back to the original code to understand that the thing we were trying to generate were IDs of some sort.
It feels to me like something a motivated open source project could do well, too. What's the thing that will get people to pay for this? Slick team/enterprise features?
Got stuck at the paywall -- Do they link out to or otherwise name the dataset? When my kids start thinking about what they want from their post-secondary education, this is the sort of thing I wouldn't mind having on hand.
It hadn't even occurred to me that there were serious academic attempts at visualizations of this sort. In addition to OP, this whole discussion is full of great alternatives to d3-force (my usual go-to). Kudos to all!
I believe you're incorrect, Johnny five supports both runtime models.
Was playing with Johnny Five yesterday (while they were releasing 1.0, fun to watch), and was deploying my node project code to my Tessel 2, which then ran independently of my laptop.
I was amazed at how easy it was to go from 0 to deployed code running reliably on the (detached, untethered) dev board. At least when working with the Tessel 2, they really think through the dev experience end-to-end.
For those who aren't familiar, Gerrit (the code review system used by Android at this point, think GitHub Pull Requests but better/worse) uses "Anonymous Coward" naming for those users it doesn't otherwise have a good name for.
Others point out this usage probably finds its origin in Slashdot culture, which is likely true, but also probably a ternary relationship in this instance.
Longtime D3 (even Protovis) user here. I think you're very correct in that D3 itself is not a good choice for "a simple chart or graph". If that's all I needed, I'd stick with HighCharts, or ggplot, or any of dozens of other libraries that do simple charts well, and often with a lot more batteries included. My unsolicited advice would be to consider staying away from D3 until you need it.
But if you're doing anything remotely bespoke, with any sort of custom interaction or transition, or anything in which you need to multiplex several datasets in a single set of visualizations, this toolkit is hard to beat.
My favorite personal D3 use case so far is modified animated scatter plots/beeswarms using force layouts. Immortalized for me in the "Four Ways to Slice Obama’s 2013 Budget Proposal" ( https://archive.nytimes.com/www.nytimes.com/interactive/2012... ), I've found that set of techniques useful for visualizing business processes in my own work over the years.
I've yet to encounter anything else that comes close to enabling those kinds of data visualizations. It's the "funky abstractions" some folks have trouble with that enable me to swap out X or Y scales with intuitive animations by literally replacing a single object and then re-invoking an idempotent render() function. Working with D3 is the most productive I've ever been in my life from a data visualization standpoint, and I suspect that will continue to be the case for some years.
I read this question as "How would one go about quantifying the level of stress at work?", which is what I was hoping I would read about after the click.
In a world where metrics are useful for everything, I feel like a time-series graph showing relative stress levels time would be really illuminating.
UrbanCode is an enterprise DevOps solution creator acquired by IBM in 2013. Since then, we've grown tremendously, and need more smart people to take us to the next level.
We're looking for all types of coders, from frontend UI/UX ninja to backend sensei, from experienced product team leads to ambitious fresh-out-of-college types.
Fairly Agile-ish. Automated Build / Test. Monthly Release. Pseudo-sprints w/retrospective. Kanban board. Free food is common.