douglashunter

Cool! I notice that you have both lil brother and google analytics enabled on bits.shutterstock.com. Do you have any kind of a read on how they stack up against each other?

When I first saw camlistore (http://camlistore.org/) it jived with much of how I pondered the foundational bits of "the cloud I'd like to see". Private by default, distribut(ed|able), share-able, index-able, version-able dumb content blobs who are described by other dumb content blobs of the same nature.

They might be getting some of the programmer interfaces right enough to give folks a chance at getting some user interfaces right.

That's surprising. Is it the example here (http://code.shutterstock.com/rickshaw/examples/extensions.ht...) that is slow? How is it slow (when you click on controls to customize the view, drag a slider, mouse over plots)? When it's slow for you is there something else on your computer chewing up a bunch of CPU?

A lot of the hard work is being done by d3, which is pretty well optimized for the tasks its doing. I'd be surprised, even on a 4-5 year old commodity desktop, to see laggy or jumpy behavior with fewer than a million or so plot points.

[full disclosure, I used to work with the fine folks at Shutterstock, who created Rickshaw]

Rickshaw has been talked about here before, when it was released (original thread: http://news.ycombinator.com/item?id=3340089)

It's nice to see Rickshaw getting some love with the new scatterplot renderer based a subclassable base renderer, a test suite, and an updated home page.

Nice work!

> Shutterstock are legendary round the perl community for being a hive of badly written ancient code that never gets significant refactoring effort though

I like to think that we're legendary for choosing a sane upgrade path to a services based approach built on Modern Perl. For our help debugging Dancer's (https://github.com/sukria/Dancer/issues/642) and Feersum's (https://github.com/stash/Feersum/issues/12) header parsing troubles. For our continuous sponsorship of YAPC (http://yapcna.org/sponsorship/our-sponsors).

Heh, we're legends in my own mind! [grin]

> Both above spot the undef gotcha.

The builtin open() even tries to spot when it's not intentional. The documentation puts "undef" in quotations in the section where it introduces the feature (suggesting it has to be the literal), and the implementation goes to some effort to agree with it. For example, the following code dies:

  my $config = { file_paht => "/opt/config" };
  my $path = $config->{file_path};

  open (my $fh, "<", $path)
    or  die "can't open $path: $!";

In the case in the article it's a bug in the implementation, combined with a typo, which introduces the little known feature.

Using Path::Class obfuscates the open, to my eyes. Using IO::File is a nice suggestion. Your lock_keys suggestion below will probably be our update to the code for future protection, though.

In the cases in the article, strict and warnings won't save you.

This is what Kris Arnold (https://twitter.com/wka), one of the other hackers here at Shutterstock recommended. I like it.

Well, that's embarrassing. I fat-fingered those while I was transcribing code into the article. "Surprise Two" was supposed to be about the autovivification surprise, not me mistyping things (article updated).

Even still, your point about using objects and encapsulation stands. If the session were being assigned to via setters, and read from with getters, the grep aliasing wouldn't do its damage.

Cheers.

"I'm confused about what the smoothing is supposed to be doing"

If you have, for example, 300 data plots collected once a second for 5 minutes, and that looks too noisy when you paint your chart, you may choose to smooth the lines by aggregating the data into buckets that are larger than a second. For instance, you might choose to sum all the plots in a minute, and divide that sum by the number of plots that were in that minute, thus reducing 60 plots to one while retaining an accurate representation of your data.

When you drag that slider, you are aggregating data into larger buckets.

Good luck in your travels finding a chart library that works for your application, and if you try Rickshaw and hit any stumbling blocks, hit us up on github.

Cheers!

It isn't an intentional workaround, and is an artifact of typing the least amount of markup possible to make something render.

We'll fix that, thanks!

"Ok, that example has a slider"

It has two. There is one below the legend on the left hand side. That smooths your data by aggregating the plots.

It also has the zoom slider under the graph. Or chart, rather.

When you mouse over the series items on the top left corner, the data of the item you are mousing over is highlighted on the graph.

You can uncheck some of those series items to focus on particular data, e.g. look at New York and Tokyo and London.

You can re-order them by dragging them.

You can switch the view between stacks, percentage, stream and lines.

"Pretty awful choice of UI"

There are some nice things that come with the slider across the bottom of the graph. When I grab an end of the slider and move it, I can see exactly what is happening to the data as I move it, and I can let my eye determine where I should settle.

The question of "how do I get back" isn't on my mind. I know how to do that.

I can pin the left hand side somewhere and watch new data come into view, or pin the right hand side somewhere to make the view momentarily static.

"Also, what about fetching of remote data of variable resolution"

You can fetch your data however you want to.

Edit: I forgot to mention that the zoom slider there is just a DOM element. You can dress it up any which way.

dygraphs is lovely, nice work there! One of the pieces that I particularly like is how you handle CSV data.

"A truly interactive chart would let you zoom in and out ... and so on."

dchester's comment (http://news.ycombinator.com/item?id=3340609) links to http://shutterstock.github.com/rickshaw/examples/extensions...., which demonstrates some of Rickshaw's interactions.

Thanks! Most (read "all") the credit there, as well as the credit for the other useful parts of the code, belongs to David Chester.

But I'm louder on the internet and have been working with Rickshaw for a while, so I get to say "thanks" [grin].

Let us know of any roadblocks you hit if you take it for a spin!

Thanks for giving it a whirl! When you say the controls don't work, are you talking about the controls in the extensions example (http://shutterstock.github.com/rickshaw/examples/extensions....), or something else?

Yes, tons of credit due there. In my post (http://bits.shutterstock.com/?p=74) I linked to Jonathan Corbet's coverage (http://lwn.net/Articles/427104/) of the topic on LWN, which is also a good jumping-off point for reading on the topic.