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.
We've had a variety of CSU grads even this year come on board. That being said, there have been hiccups around things like the Netmedia site. That's one of the reasons we're seeking applications through alternative (better?) means like HN.
If you know people who have put IBM UrbanCode into the dustbin of unresponsive job postings, I'd absolutely encourage them to reach out to me.
Some common components are Dojo, Jersey, Hibernate. Git. Selenium, JUnit. A few in-house frameworks/libraries, as you'd imagine. Regular fiddling around with newer things as well. (I just wrote a simple Bootstrap chrome plugin, one of the teams here was trying react on for size not long ago, for example)
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.
I haven't used Moloch myself, so I can't judge with complete accuracy, but here's my take:
1. Use case: Moloch, with it's focus on PCAP, is a cool network forensics tool, to be sure. Our focus is not only on security, but also on performance and troubleshooting. We use the traffic data as a foundation for integration with IDS alerts and latency (and jitter) data. The ability to pivot between views and visually correlate this data is incredibly (and surprisingly) useful for IT Staff who want to know at a glance if things are correlating or not. So I would suggest that Moloch is a little more limited in it's scope, at least in it's default configuration.
2. Usability: This ties in with the point below too. Our focus is making network analysis approachable for the average IT guy. Keeping things light, visual, and easy to use is super, super important to us. It's really the top item on our list under, you know, having correct data.
3. Maintainability (or SLAs, or whatever you want to call it). When I look at Moloch, I'm reminded of Zimbra, the free email server. Last time I installed Zimbra, it involved installing a lot of different stuff, configuring it all, and groking a LOT of documentation for different components before it was working to satisfaction. This is perfect for a certain market segment, the IT guy who has the time and energy to - not really roll his own - but to be really involved in everything that's going on.
the Sentry is not for that IT guy. We market to IT staff who don't have the time to install and maintain a bunch of components for a single tool. They have a security / network vision need (sorry about the buzzword) that needs to be filled, and they don't have a month to stumble through a complex linux install. Don't get me wrong, I personally am all about complex linux installs, I love getting into things myself, but this product is pre-packaged, with batteries included.
Hi! I'm one of the developers of the Sentry. Someone suggested I do a little intro bit here, so here goes.
The Sentry stemmed from over a decade of doing traffic analysis (from a security perspective) for local small and mid-sized businesses. We had a great conglomeration of tools (ntop, cacti, snort, some custom connection indexers, etc), but it was almost impossible to use effectively if you weren't the guy who made it.
We wanted our clients to be able to monitor their own network, so we set about making the Sentry. The primary feature of the Sentry is usability. Traffic analysis is typically hard. There's no reason it needs to be.
We would love to have any feedback you guys are willing to offer. Hackernews is famed for it's frank discussion. Bring it on.