This week’s pre-beta updates

A few small updates have been deployed this week to chartpart in preparation for calling it “beta”.

  • The API (that is, the URL you construct to generate a chart) has been cleaned up and has no more major breaking changes planned now. Many of these changes were about getting the URLs to be as short and human-readable as possible.
  • Some other rendering, labeling, and default-options handling bugs have been fixed
  • The default chart shows off multiple series and series labels

Any feedback on the site’s look or functionality are very welcome. If you want to be an early adopter — posting charts to a blog, wiki, or whatever that you own — I’d love to flesh out the “examples” page before beta with a link to your work. Please go for it! When any feedback has been incorporated, and chartpart has been deployed to its dedicated server, I’ll post here with the “public beta” announce. Thanks.

Chartpart pre-beta updates

Chartpart is not ready for a wide beta — if for no other reason, it’s still on a shared host, limiting it to a few hundred hits/hour. I’m also not ready to lock the API in concrete, and a wide beta sends that slurry mush down its hardening process.
But if you’re curious, a new pre-beta version was deployed this week, cleaning up some of the front-page layout problems among other things.

Changes include

  • Better application of CSS techniques. See my tags for some of the CSS tutorials I used.
  • Better colors & layout that doesn’t jump around as images refresh. You see, I’m terrible at graphic design. It’s time consuming and painful. So, I adopt the best response I can: keeping layout, colors, and the like as minimalistic and simple as possible. Any suggestions for better applying that philosophy to the site?
  • “About” and “Examples” pages — What’s there is just a start, but any particular questions you’d like to see answered there?
  • Chartpart is now using wufoo for the feedback survey (try it out). Wufoo is another example of a nice fremium web service (up to 100 entries/mo free). I’ve found the response time a little slow. It would be nice if wufoo provided some performance assurance, at least for paid accounts.

A future posting will have more on the importance of creating feedback loops, which applies to several aspects of what is being done here.

Rails, Textdrive, and Capistrano

The development box for chartpart was down for almost a day earlier in the week. Textdrive (aparently) had trouble with the shared host box on Sunday, and ended up having to take it down, reinstall the OS, etc. My rails app didn’t come back up after their reboot, and I couldn’t kick it back to life. Some of the hazards of shared hosting.

Since doing the original setup a few months ago using Geoff’s nice shovel cap script, a nice official guide to setting up Rails on Textdrive has been written, and things are in different locations, different mechanisms, etc. I ended up having to go through this process for chartpart, and it worked nicely.

I posted some earlier updates to shovel, but it looks like some more are needed if it’s going to reflect textdrive’s recommended config. Anyone done this work already?

This comes as our aplus.net value ($49/mo) dedicated server just came on-line. This is where chartpart will move for its “official” beta (can’t wait for Amazon’s hosting).

High-level Design

With any new idea, we look at customer, technology, and business aspects of whether it’s something that can work. It takes time (often, a lot of time) to explore all the ideas and tradeoffs involved. Feedback of any kind is a great way to make this process of settling on the specifics go more quickly, and the decisions better-considered and longer lasting. So we’ll look again at technology.
Chartpart component diagram

For chartpart, the high-level design should be simple — making use of existing components as much as possible. The actual application is a stable, well-thought out API for requesting a chart (A URL which fully describes it), the code to transform a GET request into a chart image, plus a nice helper form to create those URLS, and other information.

The Gruff library is where the heavy lifting of charting happens, and a few small changes were done there already and passed back to Geoff Grosenbach, Gruff’s author. The chartpart app (as thin as it is), is not open source. But enhancements to all the libraries under it will be (and must be, in the case of GPL or other licenses) passed back.
Partially because of Ruby’s dynamic nature and good cross-platform tool and library support, there’s another interesting thing to note about this diagram — there are a lot of fundamental components at the bottom of the stack (e.g. what OS it runs on), that can be entirely substituted. In fact, chartpart has been developed on a mix of Windows, Linux, and Mac platforms as I’ve played around at finding an environment that I like best (I’ve settled on a MacBook). And the actual hosted environment of chartpart.com is Linux today, but might be Solaris tomorrow.

Anything wrong with the approach or diagram? Any thoughts or concerns about mixed license models?

Naming that Internet Business

Choosing a name for a business, especially an Internet business, is an important but often frustrating step. I’m kind of obsessed about the process of choosing a name that will help, not hurt, the business. My wife can, unfortunately, testify to the obsession, since I pester her with outbursts of “oh, here’s another good one” all the time. Unlike other types of businesses, where you can have many “AAA Auto Service”, each in their own locality — you have the clarity of knowing that only one person can get that particular .com name (and the other .endings are still disadvantaged in most cases).

Some I’ve selected over the years include veriteam.com and cosource.com (both now defunct), Vistasource (funny enough, several years before Windows Longhorn was renamed Windows Vista). Now leancode and its stable of small web projects, including this first project, a web charting service.

What we’re shooting for is a name which is short, memorable, a reminder of what the company or tool does, BUT one that’s not so specific that we can’t make small or large changes in direction without changing names. Combined with the inherent uniqueness requirement of domain names and the gold rush for them, this is difficult to triangulate.

The best tool I’ve found for helping this process is Instant Domain Search by Beau Hartshorne. His tool keeps a cache of the current WHOIS records and provides a wonderfully quick AJAX-style interface to try out lots of domain names, getting instant feedback about what’s taken. I’ve used it lots over the last year — I hope the adwords on the site have made Beau some bucks.

So what’s a good, available name for a charting service? How about chartpart.com? A little rhyming never hurt. And these web services are not destinations unto themselves — rather they are some part of a larger whole. Seems appropriate. What do you think? And check out the site for a taste — mind the remaining beams and scaffolding.

Load balancing several cheap hosted accounts

A key concern with providing hosted charts is the ability to scale up — if successful, I’ll have to serve out a potential torrent of chart images (which are appearing on other people’s web sites, but which are hosted on chartpart).

And I’ll get no direct revenue from all this activity — only from those drawn to subscribe to premium services. So delivering high performance (to the client) at low cost (to myself) is a big challenge.

Since this is a very partitionable problem (more on that later), caching is a key part of how I’ll try to achieve this.
But, beyond that, load balancing is another aspect. So I wondered — are hosted services available such that I can start with a cheap account (shared host, or dedicated box if not), and load balance several of them as I grow?

I could not find any shared hosts that offered load balancing. Please comment if you know of any — I would think that’d be a benefit to clients and the hosting company. But I did find several that offered load balancing with dedicated servers.

One promising one appears to be aplus.net — they offer “value” dedicated servers at $49/mo, to which load balancing can be added after the fact. Their current standard pricing for load balancing is $159 setup and $220/mo for up to 5 servers. I like this, because I can start with a single $49/mo server, then grow to a $500/mo 5-server load balanced setup. Anyone have experience with this kind of setup, and have anything good or bad to say about aplus or another host?

Selecting a Platform

I’m using Ruby on Rails for the charting service. How to make this kind of technology decision?

  • Maximize reuse — choose the technology that leaves you with the shortest distance to your solution
  • Consider the cutting edge — take the opportunity to gain the competitive advantage of a next-gen technology
  • Use what you know — temper the first two, knowing becoming a pro in a new technology is a huge investment

The last time I did any real web work was 1999 — building cosource.com on Linux, Apache, Mysql, and Perl (no PHP). Basically a big app running under mod_perl, which queries SQL and spits out HTML. So use what I know, or go cutting edge?

The decision was easy. The world has moved on in the last 7 years. Rails is an amazing platform — for getting something running quickly which minimizes batch size and encourages incremental development; for aligning with known design patterns so as not to reinvent the wheel; for integrated testing (TDD) and inline documentation which enables higher quality, lower-risk, pay-as-you-go development. Ruby is an amazing language — clean, dynamic. And the crowd creating and adopting these technologies are the best in the industry — from brilliant new stars to respected veterans. So these technologies continue to get better fast, to the benefit of anyone else adopting them.

So, over the last few months, I’ve bitten the bullet and tried to move through the knowledge curve from nuby towards ruby pro. And this charting web service is a good first project (in terms of size and technology risk) on which to learn.