Chartpart – Mashup of the Day

Chartpart is the Mashup of The Day on Programmable Web.

(Thank you to whoever over there is noticing the tools here on leancode!)

Chartpart gets improved axis labels

Chartpart got a few new features today.

  1. Chartpart more correctly handles the automatic axis labeling for horizontal charts.  Previously, the label was slapped down on the bottom axis, regardless of the data orientation — which was just plain wrong.
  2. There is now an “Extra Axis Label” section of the form. Select which side of the chart to label, and enter a comma-separated list of labels with which to label that axis.  One interesting thing about the Google engine is it allows multiple labels per axis.  Future chartpart features may include auto-labeling of the data axis (based on the data ranges), and ability to add an arbitrary number of axis labels (now limited to 2+category axis).
  3. The layout was modified to be more fluid.  This lets additional form fields, etc. fit more easily on the page, and make full use of the window as it is resized. But it also has some ugly aspects. Suggestions welcome.
  4. Added an HTML preview for people who want to cut/paste an img tag directly into an HTML editor, with correct formatting (e.g. ampersands are escaped).
  5. Scatter plots and Venn Diagrams still don’t have any special help or data handling — you still have look at the Google API docs to see how to enter data for those chart types. But then, chartpart helps encode that data and lay out the chart.

Thanks, Jonathan, Jeffrey, and everyone for your suggestions.

The new charpart has received visits from over 1200 people in the last 10 days.  That’s more then the previous Rails-based, no-permalink-to-chart version received in over 12 months.  The time spent updating it has proved worth it.  And, again, there’s no complex server to maintain, so I’m happy.

New Chartpart.Com uses Google Chart API

If the Internet is overwhelming us with a flood of data, then graphical summaries of that data are one way to manage the torrent.

Chartpart was created to make it easy to quickly summarize some data in a chart, and post the result as part of a blog post, wiki, or web page. Check it out to see what it can do.

Chartpart was originally created with Rails in the summer of 2007. It was created to scale well, which made for a bunch of work on the server side to be able to handle generating tens of thousands of chart images a day. Unfortunately, the site wasn’t that compelling — only a handful of users showed up daily. A great learning experience, but a waste otherwise.

One reason was Chartpart did not provide a permanent URL for the generated images (because I didn’t want to commit to keeping the server up forever). For users, it was a hassle to generate then save the images in a hosted location where you could link to them.

When Google launched their Chart API a few weeks ago, it was a great opportunity to take a fresh shot at doing Chartpart in a much simpler and better way.

Some of the benefits are

  • Every generated chart now has a permanent URL link provided by Google (formatted for you by Chartpart). Feel free to use it on any blog/web page. It’s subject to the same usage limits as other clients of the chart API — 50,000 hits/day/domain, which should do for any small/med traffic site.
  • Chartpart itself is now simply an HTML/CSS/Javascript app. There’s no server side logic, so the automagical updating of the chart image as you play with the settings is quite fast, and Chartpart itself will be much easier for me to maintain for the long term — relatively, Rails apps can be a lot of work to deploy and maintain.

The new chartpart is now up — try it out and let me know if it’s useful to you. It’s a simple 1-1 mapping of the old functionality to the new chart API. There are many additional capabilities of Google’s API that it can’t do today, but feedback on what you’d like to see is welcome.

Google’s new Chart Generation API

Google announced a new charting API that is wonderfully simple to work with. Like Joe Gregorio’s sparklines service, it’s simply a URL-based interface that you can use as the source for your HTML image tags — and this makes it wonderfully useful.

I’ve used Joe’s service for things like Feedsparks, where these services do all the heavy lifting, and the glue to pull it all together runs in the browser (Javascript). This lets me can put a useful, functional little widget out there, and know that it will still be working years from now, with no server maintenance on my part (thus making it easier for you to adopt it and know it’ll stick around).

Google’s API, which is even more rich, opens up a ton more possibilities. It definitely eclipses the charting service I launched last year, So now on my list of to-dos is greatly simplifying chartpart to make use of Google’s Chart API rather than generate charts itself. Rather than a Rails app, it can become a simple, single AJAXified HTML page to ease the creation of charts. Nice.

Reaching Beta: Feedback and Focus

“And of course they had a christening party. And of course they invited the fairies…”

They say software is never done (and everything will take 4x as long as you’d think). They’re right. So you have to call out milestones and give names to things to get your bearings. And so I hereby knight this small service called chartpart. We’ll call you “beta” and send you off.

Feedback is critical in software development, but it’s not always easy to figure out what the customer is telling you. In the case of chartpart, I got lots of good explicit feedback (thank you). I also got implicit feedback in the form of hits and general interest level.

This feedback led me to realize I was trying to do too much with chartpart. Dealing with the complexities and commitments of hosting images. Serving up flash, and sparklines, and tracking trends (all things for which there is nearly complete code in source control).

The site and the business model behind it need to be far simpler, at least to start. And so you’ll notice some significant changes to chartpart, done in the last week for beta. The site now generates images, but does not provide hosting. And the site aspires only to be a small, useful ad-supported tool. If there will be more, it’ll come later in a separate form.

Complexity builds on itself. Fortuately, simplicity is also reinforcing. For example, more than one request came in to simply allow the pasting of spreadsheet data. And it could have been done. But with a focus on being a free chart generator, not a chart hosting, we’re clearly not trying to compete with spreadsheet charting engines. The guidance would be: “use your spreadsheet if you have one at hand, chartpart if not.” So the feature is less essential with our simplified use cases.

Please use chartpart, if you find it useful. And please mention it if you find it interesting.

For me, chartpart has been a great first project to learn (and re-learn) a ton about web development, and especially Ruby and its libraries. It now needs time to bake and find its niche (or not) — collecting use and feedback over a longer period. And I need to start thinking about a second project.


Site Monitoring: Shared vs Dedicated Hosts

One thing about running servers is they’ll drive you insane with worry, unless you’ve set up a system to notify you if anything is amiss. I’ve been using the beta of site24x7 to monitor chartpart, and it’s a nice service. The service can check your site at 15 minute intervals. It can trigger an email to you on downtime, of course, but also when response time crosses certain thresholds, or content changes by a certain % (I’m not certain the last type is working correctly yet).

Here is an interesting chart I grabbed today from site24x7, showing response time of over the last week.

You can clearly see my switch a few days ago from a shared host (textdrive $12/mo) to a dedicated server (aplus $50/mo). The best case response time is similar, but the worst case on the shared host can be quite bad when other users of the same box are generating loads.

Another related change that happed at the same time: on the shared host I was running the rails app under lighttpd. In setting up the dedicated server, I switched to the hot new thang: apache mod_proxy_balancer + mongrel.

Shared hosts are great for prototyping a new site, but either a VPS/VM (with dedicated resources) or dedicated host is essential for production deployment.

The response time graph is now a thing of beauty, and I can sleep better knowing I’ll get alerted if it goes south on me. And I have nice graphs to quickly get a sense of historical performance, if anything changes.

When a DNS change is in flight

Chartpart may bounce around for the next few hours. The new dedicated server is now all configured (more on that later), and the switch over has been triggered.

The domain is registered at, but the actual DNS records for are hosted at zoneedit right now. It may take some time for all these changes to replicate around. Both the old and new servers are up and running, so while the DNS change is replicating, you also get this interesting effect where some people will be directed to the old server, some to the new, while the DNS change is in flight.

To read more about how all this works, read the “what’s going on behind the scenes” question in the internic FAQ. Many players and some non-trivial coordination.