StatSheet.com ChangeLog

Do you get the Wall Street Journal?

Wed, 11 Nov 2009 18:47:21 +0000

The sports section of today's Wall Street Journal mentions StatSheet (and me by name). You can see the online version here: http://bit.ly/ijrsA

New with Recruiting on StatSheet - Summary

Wed, 11 Nov 2009 03:34:27 +0000

Over the past week I've been adding new features to the High School Basketball section (under Best of the Top 100). This is my first attempt at analyzing the Top 100 player rankings since 1998. I've aggregated each player's college wins, losses, NCAA tournament games, games played/started, etc. by team and conference to determine which players have had the biggest impact, were disappointing, or were surprising. Then I could show the classes that have had the most wins, losses, NCAA games, etc. and highlight the classes that have had the biggest impact or were disappointing. You can even see which colleges were the most successful at recruiting over one or more years.

But the big question everyone always wants to ask: which programs are the best at recruiting? The numbers are clear: Duke and North Carolina with Kansas a distant third.

I'm interested in any feedback. Future analysis will go beyond wins and losses and dig into player stats during college as well evaluate player performance in the NBA.

New with Recruiting Part 4

Mon, 09 Nov 2009 04:06:20 +0000

Now we are getting to the good stuff. The latest college basketball recruiting pages I've created take a stab at showing which of the Top 100 recruits have had the biggest impact and which ones were the most disappointing.

New with Recruiting Part 3

Fri, 06 Nov 2009 21:59:04 +0000

Back for more. Now you can get a break down of how the Top 100 recruits have performed on a per-team and per-conference basis. Here is an example for Kansas and the ACC. Enjoy!

New with Recruiting Part 2

Wed, 04 Nov 2009 14:39:52 +0000

As I mentioned yesterday, I'm releasing a bunch of new college basketball recruiting features this week in honor of the upcoming basketball season.

Today, you can find my analysis on which freshmen classes have been the most impactful and most disappointing. The methodology I used was pretty simple, but the conclusions are interesting.

College Basketball season is approaching so I've got something new...

Tue, 03 Nov 2009 18:57:33 +0000

For those that have been following StatSheet from the beginning, you'll know that I started with college basketball. Now StatSheet has become the #1 site on the web for college basketball stats. With the new season just a week away, I decided I'd add some new features to mark the occasion. The theme is going to be college basketball recruiting.

You may be familiar with the HS Basketball section. Over the next week I'm going to add a bunch of new pages that analyze the Top 100 recruiting classes since 1998. I'm going to break it out by team and conference. I'll show which players went from Stud to Dud. Which classes were the most impactful, most disappointing, etc.

To give you the first taste, I just put up the "Best and Worst" page. It's a little raw, but it will give you an indication for which classes produced the most wins, losses, NCAA tournament game appearances, draft picks, etc. Expect more to follow soon...

StatSheet selected as an Internet Summit Demo Showcase Company

Thu, 22 Oct 2009 16:56:58 +0000

I'm pleased to annouce that StatSheet has been selected as one of the Demo Showcase companies for next month's Internet Summit. In addition, I've been asked to speak on the Twitter/Real-time panel, which I think could be one of the most interesting panels of the conference. I bet I'm the only panelest that's actually been banned by Twitter! I also have plenty to say on the topic of the real-time web since I'm in the middle of working on my own sports-related real-time website.

I'll do my best to man the StatSheet booth at the conference so please stop by and say hi.

Meet StatSheet's Lead QA Tester: GoogleBot

Mon, 19 Oct 2009 15:26:04 +0000

I know this post will be heretical to some in the software development community, but that's why it's important to write about it. In short: I don't do any automated testing of the StatSheet Network sites, but rely on GoogleBot to notify me of bugs.

A little background before I continue...I incorporated StatSheet in June 2007. The company has been a single person entity since (and bootstrapped). I've done all the programming and design with the exception of logos which I've outsourced using services like 99designs. A recent count shows the StatSheet codebase is well over 200,000 lines of code for all backend and frontend code. That's translated to over 1.5 million unique URLs I'm submitting to Google via sitemaps that cover statsheet.com.

Early on I had to figure out how I was going to test this beast of a site I was creating. Currently StatSheet covers College Basketball, NBA (partially), College Football (partially), and NASCAR. I have historical data for many seasons. That means lots of players, teams, coaches, conferences, etc. Lots of permutations of what stats are available with those players, teams, conferences, etc. I track thousands of stats and attributes across those sports. It is statsheet.com's job to make that information available in easy to digest ways.

Instead of writing a bunch of test code to go through all the various permutations that could result in errors on the front-end, I found GoogleBot (Google's web crawler) was doing a pretty good job of scanning the whole site in a timely manner. I set up code on the front-end to email me anytime there is a Server Error. I found early on that when I'd push out new changes, GoogleBot would find obscure bugs with infrequently visited pages much quicker than I (or even my users) could.

So I abandoned any formal attempts to automate testing of StatSheet.com (at least for now). GoogleBot is constantly scanning the site and notifies me when it finds bugs (via the email on Server Error). That means I can keep moving full speed ahead writing new code, trying to add more features and visualizations of the data without spending a lot of time writing test code. I've found this works well in the lean, single-person company mode I'm currently in. You can avoid much of the formality of software engineering if you are the only person that ever touches the code.

What about when developer #2 joins StatSheet? That will be a great! But it also means I'll need to introduce more formality. We'll likely need to introduce some automated testing at that point. And yes, it will be a bit of a pain to go back through and write tests. But unless I can get StatSheet to the point where I'm bringing in enough revenue (or if I decide to raise outside funding) it doesn't make a difference how much test code I've written. In these early days of the company, the important thing is getting the site as functional as possible and worry about testing later when it becomes more important.

Seth Davis uses StatSheet for article...but no link

Sun, 04 Oct 2009 11:24:55 +0000

Glad to see Seth Davis used StatSheet for his article on overworked refs, but this is yet another example of a traditional media outlet referencing Statsheet.com but not linking to it. In the age of the Internet, just citing a source in an online article should not be enough to maintain journalistic integrity. If you quote data throughout a whole paragraph in your article and mention "StatSheet.com" you should at least link back to the site. Even if you use "rel=nofollow" so SI doesn't give StatSheet any Google juice, they should still link back. I've never had this issue once from a blogger. Just traditional media. Perhaps one of the reasons they are doomed...

The Hosting Provider Time Machine: Paying 2006 prices in 2009

Mon, 24 Aug 2009 00:03:36 +0000

UPDATE: Good discussion over at Hacker News

This post is a rant about my hosting provider, Slicehost, but it applies to many (most?) of the hosting providers out there. But before I get started, let me say that I've been a very happy Slicehost customer. When I initially launched StatSheet in Nov 2007, I was a Joyent customer, but after months of inexplicable disk I/O problems that impacted the performance of the website, I switched to Slicehost. And I've had ZERO problems since then (knock on wood). Very easy to setup/upgrade/etc. No mysterious performance problems.

Back to my rant...one of the issues with a provider like Slicehost is that you must fit your hosting needs into one of their pre-canned "slice" configurations. You can see the current list of slice configurations. That's perfectly fine when I started out because my needs were fairly small. With Slicehost's easy upgrade process I could move up to larger RAM/storage as needed.

However, this became a bigger issue after I reached 7-2GB slices. The price increase to the next level is no longer insignificant. And I no longer need more RAM AND more storage AND more bandwidth. I just need more storage. 3 of my 7 slices could benefit from moving to the 4GB slice plan solely for the increase in storage, but that would mean an additional increase of $360/month to go from 80GB per slice to 160GB per slice. Effectively I'd be paying $4,320 per year just to go from 240GB to 720GB.

So I sent a query in to Slicehost support to see if I could upgrade JUST the storage. I knew they didn't do this kind of thing, but I wanted to ask anyway. The response I got back was what I expected...no, they don't do a-la carte type upgrades. That's understandable. They want to make everything as cookie-cutter as possible. I get that.

However, as I started looking at the price math a little more, it struck me that paying $130/month for 80GB of storage seems so...well...2006. 80GB isn't what it used to be after all. I did a little more digging and found that the price/performance curve for disk storage is still on its torrid pace of doubling density every 12 months.

That really got me thinking. I hadn't recalled Slicehost ever increasing the Slice storage requirements or decreasing their fee. Are they really charging the same thing as they did years ago for the same type of hardware? Thanks to the Way-Back-Machine, I could easily find the answer. Their Sept 2006 and Sept 2007 page shows that yes, Slicehost is indeed charging the exact same price for the exact same hardware requirements.

What does this mean? Well, for hosting providers that do not a) increase their hardware configurations or b) decrease their price on at least a bi-yearly basis, their profit margins are actually increasing over time. Why 2 years? Let's assume hosting providers purchase excess hardware capacity to handle future demand. Two years of extra capacity is probably a little much, but I'm being generous ;-) So at least after year 2, the hosting provider can start putting in the lower cost hardware and yet still charge the same-old price. At some point you'd think they'd have to either add more hardware to the current Slice configuration or drop the price. I doubt they are going to drop the price, so when will they increase the hardware??

What's a lean startup to do? I looked around and Slicehost is still mostly competitive with the other providers in their class (if you know of something better, please let me know). And if you look at Joyent, they offer only 25GB of storage for their 2GB plan at twice the price! Slicehost's answer to my query was to use something like S3 to offload unused/unneeded files and that's what I'm doing. But I don't want to. If I was talking terabytes of data, I could understand, but my home external storage is 1TB which I bought 2 years ago. 80GB seems so miniscule in comparison (because it is). I know, I know, an external disk drive isn't the same as NAS or whatever the hosting provider uses, but does it justify no change in 3 years?