I particularly like the groupdate concept, and might send you a pull request adding 2.X support, if that fits in line with the project goals. I should have rolled my own years ago rather than repeating the same code at 100 places.
Assuming the data for the graph shown is the dots, then the lines between them should be straight, not curved, because othrwise the graph is pretending to have higher accuracy than it actually has, which is a lie.
I agree that in this case it's stupid, but for some data it can make sense. But I think people use bezier curves and higher order interpolations on these types of demos because smooth lines look more visually appealing somehow.
If anyone's looking for similar functionality for PHP (Database-level time-grouping, time-ranged drilldowns, charts), you can check out http://razorflow.com
(Disclosure: I am the developer of RazorFlow, and am only posting here because I feel it's relevant to this particular story)
Not entirely sure if this is on-topic, but why do so many graphs when told to "smooth" results simply apply a bezier curve to the data points? It results in some maximum and minimum vertices appearing at values that don't exist.
If you want to "AJAX" an image onto the page after the initial page load, why not just use an <img> tag? You may be surprised to learn that it's even part of the HTML spec!
I was pretty surprised when I got to the ChartsController and saw it returning JSON. Seems like the hard way to go about it. I just assumed it was generating SVGs.
Depending upon the number of data points you are representing, images may take less bandwidth and transfer time than the data itself. For example suppose you have a chart showing network latency; if you sample once a minute and show a month's worth of data you could easily transfer around 500KB for the raw data (assuming 12 bytes of json per sample), while an image file would be 20KB. If you have a dashboard full of images like this, the time to download all that data could become pretty significant to the end-user.
I see your point, but that's a somewhat contrived example: If you display per-minute data for an entire month you won't have the horizontal resolution (43200 to 44640 data points) to plot them all!
If you want zoomable charts to allow for increasing resolution, then the chart lib should ask the controller for a specific resolution and range on demand.
Even then, 500KB of numeric JSON data compresses really well (I tested with 1 month of real-world per-minute data: 92KB).
Highcharts, Google Chart, groupdate, jQuery (for AJAX), and iso8601.js (date parsing) definitely do the heavy lifting.
My favorite part about the library is you don't need to worry about getting the data in correct format. It just works with existing Rails methods, like ActiveRecord's count.
Also, Google Charts look a lot better with a little bit of custom styling.
The title seems to lead on that it's possible to create beautiful charts with just one line of Ruby, when really it's 'Create beautiful charts with just one line of Ruby (if you use these libraries).'
The original title is 'Create beautiful Javascript charts with one line of Ruby', which is more accurate.
Well, it's true: You can create charts with just one line of Ruby. The fact that it uses libraries to provide such a service is irrelevant to the assertion.
The groupdate lib's really handy for quick visualization of data. Nice!
For more complex visualizations, might want to check out GoogleVisualr which I created http://googlevisualr.herokuapp.com/ but that only works with Google Visualizations.
It's not dependent on SQL. @pixel.hits is returning an Array, and there is no method group for Array in Ruby. You could try group_by if you really want to group an Array, or use the Mongoid syntax for grouping.
Looks really good, will definitely use this when charts cross my path the next time! Is there really anything in life that isn't replaceable with one line of Ruby? Got to love that pile of gems.
I particularly like the groupdate concept, and might send you a pull request adding 2.X support, if that fits in line with the project goals. I should have rolled my own years ago rather than repeating the same code at 100 places.