RobbieStats

So those two phrases can never be used together? Read any of those posts with the same phrases and tell me if the full posts sound the same.

Can you tell me more about "robot CEO"? :-)

Not quite that easy I'm afraid :-)

And it should be there! We have a lot to do and integrating the team site content within statsheet.com is a top priority.

I agree that we aren't replacing anything. There will never be one source for a particular topic (although our content is significantly less expensive to produce).

But I wouldn't underestimate the potential for automated content to be even better than what the best journalists can produce. We are at the infant stage of automated content. We have a long way to go and it will only get better.

Actually we generate game recaps for EVERY division I college basketball team. Which one did you not see it for?

Here is Duke: http://bluedevildaily.com

It's a big day for us at StatSheet!

Thanks!

That's just your limited view of an advisor and one reason I suggest we call them something else. Why can't they provide "execution support". I've had several advisors work in that capacity.

I look forward to this meetup and meeting any hackers that are interested in sports.

I'm the founder of StatSheet (http://statsheet.com), a newly VC-backed startup in RTP. It is possible to raise money in the Southeast, but it is definitely more challenging than Silly Valley/Boston/NYC.

There is a growing influx of new startups in RTP, especially in the American Tobacco District (LaunchBox and Joystick Labs just launched there).

Good point ;-)

Most of the content will be seeded from stats, which means less emphases on qualitative content. But I do get feeds for things like injuries so I'll be able to automate injury reporting.

I'm getting the full NHL HITS feed now, so it's just a matter of time!

I agree with you on many things, but your stance on "workaholics" is not one of them. Often "working a lot" = "workaholic". I'm not talking about people that are addicted to work and follow the same patterns of other addictions. That's rarely the case. I'm talking about the people that enjoy working because it isn't like "work". Why should they be made to feel bad about it? The workaholics you speak of (that get burnt out) generally have motivations beyond enjoying the work. They are trying to "get ahead" or make more money. What if you actually like your "work"?

Some people like to knit in their spare time. I like to code and do things that resemble work to many people. Maybe I'm not in the majority, but I refuse to believe that I would be happier or healthier if I went on a hike instead.

StatSheet (http://statsheet.net) is "One Person Profitable"

A little off topic for HN, but I'm been working to make the standard basketball boxscore more visually appealing and information rich. Appreciate any feedback.

Thanks! I launched statsheet.com two years ago. Since then I've talked to several big sports media companies as well as a dozen TV/news, sports betting, and other sports-related website owners. They all liked the content I was creating on statsheet.com and was interested in getting it on their site(s). Embed StatSheet is my solution for that. If someone says: "I wish my sports site/section had some of the stuff statsheet.com has", now there is an app for that :-)

This also fills a gap in the current sports data provider market today. Small content creators (ie bloggers) are completely priced out of the market. Second, you either need to be a programmer (to consume XML feeds) or use a white label hosted service. Embed StatSheet enables website owners to maintain control over their website without needing to hire programmers to do the integration (for many deployment scenarios).

But what do you consider a short-cut? How much testing is enough? Doesn't the situation dictate what is enough and what is really a short-cut? What needs to be tested at a startup IS NOT the same as what should be tested inside a large corporation.

And what "risk" are you referring to? As I've stated, I decided to side with "more features" than "100% test coverage". Sure there is "risk" that there are bugs, but a) there are bugs regardless of how much testing you do and b) I've decided I'd lose users because I don't have features that stand out above the competition rather than because a minority of those features have minor bugs. So to me, the bigger risk is not developing more features.

Why doesn't it constitute advice? There are lots of entrepreneurs that are strapped for resources. I don't find this as an "exceptional circumstance". My point was simply that it is ok if you don't have 100% test coverage or any automated test coverage. I think that is a waste of resources in a very small startup in many cases.

You are missing the point. At a small startup with limited resources you have to make tradeoffs. The tradeoff I've settled on is more functionality in place of 100% quality (if there is such a thing). I think people early on waste a lot of time trying to nail every single bug when some bugs just don't matter in the grand scheme.

Also, I'm not a junior programmer that needs someone looking over my shoulder to make sure I've implemented a spec correctly. Saying it doesn't do what I think it is doing is like saying that I may not exist even though I think I exist.

Actually I do because I'm the one that developed those pages. Why would I put NASCAR stats on a NBA page? ;-)

Also, as a last resort users will tell me if something is off.

Sure, but the point is that when resources are very low you may need to get by with the minimal amount of testing required.

The options are either to spend a bunch of time trying to squash every potential bug, or know that some bugs will get through but at least users will benefit from having a bunch of new features to play with.

Thanks for the kind words. I get the data from a variety of sources:

1) I pay for some data (and it is expensive!) 2) I calculate/derive some data using existing data 3) Users have submitted some data to me directly 4) I've collected some data from open sources around the web

There aren't any/many open sports APIs because sports data is very expensive. I'm going to be launching my own sports data service in the coming weeks: http://embed.statsheet.com

Unfortunately I have to agree with you ;-) My experience has been so good with them that my default option is to shell out more money and keep using them.

You make it sound like this is a highly differentiated market. We are talking about hosting hardware. Sure Slicehost (and others) throw some software in to the mix, but the main thing everyone buys is access to hardware (and not specialized hardware at that). So yeah, price does matter. I think it makes them vulnerable to new entrants into the market that can base their prices on today's hardware.

Also, I don't think this is a "small" shadow price increase. Hardware gets cheaper by 50% year-over-year. Even if you cut that in half, a 25% yearly decrease in hardware costs is pretty good for them.

1) I understand, but unless people raise this issue publicly maybe they won't ever change ;-)

2) I can dump it on my home drive just like i could dump it on S3, but I do a lot of parsing on the files and copying them back and forth when needed is a headache I'd rather avoid. And then there is my front-end server that caches large portions of the website dynamically which I can't move to my home drive

I looked at Linode and their offering is pretty competitive with Slicehost (slightly higher price but more storage).

Any positive/negative experience with them?

Too bad there aren't more visualization tools for sports stats...oh what, there is and I developed one: http://statplot.com :-)

Possibly, but wouldn't know without testing that.

Still doesn't address the global queue issue.

Anyone seen Passenger leaking memory?