Kilg.us – Fantasy Stat Tracker …Tracker

Per a User request today, I’ve added in season stats to the Team Stats pages. Previously, clicking on a player’s name would open a new window and take you to that player’s MLB.com detail page. Now when you click on a link, one of two things could happen.

1. The preferred scenario: if you have JavaScript enabled, a bubble layer will appear that pulls in the player’s photo, name, link to their MLB.com detail page, and their total stats for the season.
2. The alternate scenario: if you don’t have JavaScript enabled, you’ll be taken directly to the player’s MLB.com detail page.

As is always the case, I’m restricted by the stats that are coming from MLB.com. I added in crude calculations for OBP and SLG for batters, but those will only be approximations and may vary by a very slight margin from the official stats. All the other stats should be official and accurate.

The goal of this new functionality is to provide a little more perspective on each player’s overall performance without needing to head off to another site. It was also requested to include the player’s last 7 days of stats. As I discussed a few weeks ago, though, Kilg.us is intended to be a live stat-tracker. It isn’t an aggregating, collecting, statistical database. Nor is it a one-stop shop for managing your fantasy teams. For the same reasons I decided against allowing Users to view stats for any specific date (see the entries about box score emails), it isn’t possible to total stats over 7 day periods.

I was able to pull in the to-date season stats simply because they are easily available. They aren’t being stored in Kilg.us anywhere. Every time a layer is generated, a new AJAX request is made to the XML data sources to pull in the stats (and the player photo). Hopefully this will be a helpful compromise solution.

Kilg.us is now tracking Holds and doing a better job harvesting win, loss, and save data. For some odd reason, in all of the MLB XML data, there is no place where wins, losses, and holds are listed with a unique attribute (ex: win=”1″). There is, however, such a listing for saves. The corresponding attributes for wins and losses, however, list the player’s TOTAL for the season–not game-day stats. Pretty worthless and definitely confusing. All that combined in the past to mean that Kilg.us tracked saves, didn’t track holds, and had categories for wins and losses that didn’t actually report anything.

Now that has changed. Buried away in one of the XML files is a “notes” field for pitchers. That notes field reports data such as (W,1) or (H,13). Basically it gathers all those outcome categories and shoves them in one place with what looks to be a standard format. Kilg.us now tracks that field and parses out it’s content looking for “(W,” “(S,” “(H,” and “(L,”. When one of those strings is found, the player is credited with a win, save, hold, or loss for the day. I’ll have to keep my eye on it to see if that turns out to be a reliable reporting mechanism.

In the meantime, you can now go to your Select Stats page and turn on Holds for your teams.

Today I built-out the mechanism for gathering players’ stats. In the original model, every time anyone loaded a Team page in the Fantasy Stat Tracker, a request was made for each player for an XML file on mlb.com with that player’s stats. It worked, but it seemed like a little overkill. If multiple Users with the same player checked their pages, multiple requests would be made for that player’s stats. If a single User re-loaded their Team page, requests were made for every single player’s stats whether the stats had changed or not.

In the new model, the Fantasy Stat Tracker gathers a player’s stats and saves them to the database with a timestamp for when the stats XML file was last updated. For subsequent stat requests the application first checks if the player’s stats file has been updated on the remote server. If it hasn’t, it simply uses the existing stats in the database. If the stats file has been updated, it will be downloaded, saved to the database with a new timestamp, and the updated stats will be used.

Theoretically this should speed up the Fantasy Stat Tracker a bit. Downloading stats from a remote server takes longer than getting them from a local database. By removing most of the requests for remote stats files, the application should be able to render Team pages quicker.

In addition, by using local stats in most instances instead of downloading them, the Fantasy Stat Tracker should dramatically cut down its bandwidth usage. With the current number of Users and requests in the application, bandwidth isn’t really an issue yet. But if the Stat Tracker becomes more popular, hopefully it’s future-proofed a bit.

One complication with this new stat gathering method is that it is very difficult to test. I can’t fiddle with file dates on mlb.com so I can’t test how the new code will work as the day rolls over to tomorrow and new games begin. If you see any errors in the application, I’d appreciate if you could copy the text of the error message and shoot it to me in an email at fantasy.stat.tracker@gmail.com. Thanks for your help in making the Fantasy Stat Tracker better!