Kilg.us – Fantasy Stat Tracker …Tracker

A comment yesterday brought to my attention that Kilg.us was not showing WHIP values for individual players on their Season-to-Date stats. This was an oversight in an assumption I made about the data Kilg.us was collecting and storing.

Each time Kilg.us renders stats, it checks to see if the latest stats are in the database or if they need to be collected. If the latest ones are in the database, it displays those. If not, it collects the new ones, saves them, and displays them. The XML data from MLB contains the season WHIP stat for each pitcher. So I assumed I was also storing that value in the database.

As it turns out, I wasn’t. The database stores the counting values (innings, hits, walks, etc). Kilg.us  then calculates the average stats (WHIP, ERA, k/9, etc.) based on the counting stats. In the Pitcher object, it was attempting to pull the WHIP value from the dataset returned, which works when collecting new stats from MLB. When the latest stats are in the database, though, that WHIP value doesn’t exist, so “-.–” is displayed instead.

I have updated the Pitcher object to calculate the WHIP value whenever it is needed. This means WHIP should be displaying in Season-to-Date stat views now. If you find otherwise, let me know!

Kilg.us now retains your last view state for each one of your teams. This serves as a low-complexity mechanism for allowing you to define a default view for your teams–whether it be Today’s stats or Season-to-Date stats.

Each time you switch between viewing daily and season stats for your teams, Kilg.us now makes a record. Which ever view you looked at last will be the view it presents when you return to your team the next time.

This seemed like a simpler interface than adding an additional control to toggle back-and-forth between settings. While a separate control would add slightly more flexibility, I think this mechanism will be just as effective and require less effort for both users and myself.

So if you always want to see Season-to-Date stats for your team, all you have to do is click over to that tab the first time, and for the rest of eternity you’ll see Season-to-Date stats (until you manually switch back to daily stats). If you only ever want to see daily stats, you actually don’t have to do anything (daily stats are the default until you select otherwise).

To accomplish this, the Teams table in the database was extended to include a “View” field. In addition, the Team object was extended to allow for setting and getting that View value. Each time you access a team page, the page checks for a view variable in the query-string (these are what the “Today” and “Season-to-Date” tabs use to set the view state). If that variable exists, it updates the default setting for the team. If it doesn’t exist if asks the Team object what the default state is and uses that instead.

This evening I completed work to allow Owners to track their Kilg.us teams’ season-to-date statistics. This has been a popular request throughout the past year.  Your team’s season-to-date stats are now available from each Team page by clicking on the “Season-to-Date” tab just below your team name. Clicking the “Today” tab will return you to your live, up-to-the-minute daily stats.

Season-to-Date statistics are for the players CURRENTLY on your roster. Kilg.us does not track the changes you make to your roster throughout the season. The Season-to-Date statistics center around a Strat-O-Matic scoring model. I’ve never played Strat-O-Matic, but–as described to me–roster moves aren’t allowed during the season. Rosters are locked in before the season and only change in the off-season.

For those playing in a standard fantasy baseball league, these Season-to-Date stats will be different than your fantasy team’s total stats (accumulating stats for players in your lineup on any given day). For Owners in this situation, season-to-date stats will make it a touch easier to view all your players’ season performance, but won’t be of direct use when tracking your team’s performance.

Adding Season-to-Date stats wasn’t a trivial matter. I had to make changes to more than a half-dozen of Kilg.us’ most important objects. In addition to changes to Kilg.us objects, the database was also expanded to include tables to store the season stats for players. At the moment, the objects are writing to the database via SQL statements. In the coming days I’ll update to use stored procedures like the rest of the database communications.

I have tried to test for unexpected repercussions from the object and database changes, but please let me know if you encounter any odd behavior by posting a comment or emailing me.

I haven’t posted about any Kilg.us changes for a couple days, but there has been a little going on. In my defense, I started a “Road to the Show” career in MLB 2010 The Show, so I MIGHT have been spending a little more time honing by batting skills than publishing about Kilg.us changes.

On the fixes side, there were some issues around gathering players and adding them to Kilg.us. Those have been revised now, so any player on a 40-man roster should be showing up (and then some). If you don’t see someone that you want on your team, post a comment or let me know.

There is an outstanding issue with rookies, though. I think I’ve narrowed it to the stored procedure that saves player stats, but all rookie pitchers show a blank (no zeros, no stats, completely blank) stat line regardless of their performance. This is next on the list of things to fix.

Next up, when players were being collected from MLB.com, they were added to the official “Major League Baseball” owner’s teams if they didn’t currently exist on the appropriate roster. They weren’t, however, being removed from their previous team if they had been traded or were a free agent (rather than a rookie). This never seemed to come up last year, but there code I changed to fix the problem hasn’t been touched in nearly a year, so I’m not quite sure the root of the problem. Hopefully it is resolved going forward.

On that note, keep in mind that you can follow any MLB team’s stats by adding the owner “Major League Baseball” to your friends. That particular owner has all 30 teams with rosters that are automatically updated to have all the latest players.

Among new features for 2010, there are three more items I hope to get out by opening day (or very shortly thereafter):

1. Apply the new theme to the …Tracker blog
2. Implement Lucene for Add Player searches
3. Create a Season-to-date view of a team’s stats (cumulative for the season, not respective of adds/removals during the year; this was a request from a Strat-o-matic owner–hopefully others will find use in it)

Opening Day is barely a week away!

I received an email notifying me of a second repercussion of the 2010 re-launch. When players were moved on or off the bench, the change was not being saved. Upon re-visiting the team page, the bench would revert to its previous state.

After review, the script that is intended save the bench changes to the database was trying to access a User class that wasn’t available to it. I’ve fixed the issue so you should now see the normal, expected behavior from benching and activating players.

This is the second issue that has occurred in a non-visible script where a class was not properly referenced. This is caused by the re-architecture of the objects in Kilg.us and is a bit frustrating. I’ll be reviewing all similar scripts this evening in hopes of catching any other situations where this is occurring.

I’m in the process of implementing a series of updates to Kilg.us for the 2010 season. The biggest noticeable difference will be an entire new look and feel. The new layout will allow for 1, 2, and 3-column pages that should let Kilg.us more efficiently use space.

Other changes in progress include:

• Integrated log-in/sign-up function
• User-defined backgrounds
• More flexibility in the “invite friends” functionality
• Updated log-in flow
• Drag-and-drop bench
• Integration with Zend framework

Among the other items I’m planning to get to before opening day:

• Add OPS to statistics available for tracking
• Implement Lucene search for “Find Friends”
• SSL for log-in flow

If you have other suggestions, please add a comment or drop me a long at admin@kilg.us

I’ll go into more detail about the updated features over the coming weeks. In the mean time, I’m just trying to get things done before the season kicks-off!

One of the longest running requests of Kilg.us has been to include game progress information. I can definitely see the value in knowing whether the game your pitcher was pitching in is done yet or not (will there be a win coming or is it all over already?). This is a different kind of statistic than what Kilg.us otherwise collects, so it has been low on the priority list. As I got tired of stored procedures earlier today, though, it finally sounded like an appealing project.

The scoreboard is displayed across the top of the page in the banner area. It displays abbreviated linescores: team, runs, hits, errors, and inning (or “F” if Final). The banner area only has room for 8 scores at a time, so there are left and right arrows to slide the scoreboard side-to-side to view all games.

The first draft of the implementation pulls XML data from MLB each time a page is loaded that displays the scoreboard. Currently the Kilg.us homepage, your Dashboard, and all Team pages include the scoreboard. The data is collected from the XML, looped through, and populated into a list/table combination of mark-up. Some JQuery sets up click events on the arrow buttons when the page loads (if they are needed; if 8 or less games are occuring that day, no arrows will appear) and calculates how far the scoreboard needs to slide to display all games.

I only had time to perform a very quick testing on IE8, Safari, and Chrome (in addition to Firefox, on which all my development occurs) so if you experience any problems with your browser, please let me know.

More development will be ongoing with the scoreboard. I expect I will update the process to store the game scores so Kilg.us doesn’t need to continue pulling in game scores even after all game are done. It will function similar to how player stats are collected. It will first check if the XML feed has been updated. If not, it will pull data from the database. If so, it will update the database and use those stats.

A lot of my weekend was spent making substantially un-noticable upgrades to Kilg.us. Most of the time was spent stepping through my objects and making minor improvements as I noticed opportunities. Among the changes, on-base percentages should be calculated more accurately now. Previously Kilg.us was checking for the existence of at least one at-bat before calculating to ensure no division by zero. Obviously, if a player starts off his day with a walk or two, this would result in no OBP calculation. The code now correctly checks for either at-bats OR walks before calculating.

The second collection of behind-the-scenes changes was creation of a new series of stored procedures. Kilg.us uses 8 different methods to save and update batter and pitchers statistics. The new stored procedures help streamline the process and reduce the amount of SQL (structured query language–the programming language used to manipulate databases) included in-line with the PHP code. Now those 8 methods can use the same set of stored procedures to interact with the database instead of each doing the interaction their own unique way. These changes probably won’t improve performance substantially, but they do abstract the code a little further which will help with maintenance and future improvements.

As I noted last week, making Kilg.us handle double-headers and postponements better was a priority for this week. After doing some fun work with avatars yesterday, I dug back into the guts of the app today. Kilg.us now checks for two games worth of stats for each player, each day. There is a particular pattern for the URL to gather a player’s stats, so the stat gathering process now checks for that pattern for both “_1″ and “_2″ games (games 1 and 2 of a double-header, respectively).

Checking for the second game is handled in the same manner as checking for the first game: first we check if the file exists, then we check if it was updated since we last collected it, then (if the previous two conditions pass) we collect the data. Hopefully this means we won’t see a noticeable slow-down in the performance of Kilg.us gathering stats.

At this point, all I can verify is that the code doesn’t break with the new additions. We’ll have to wait for an actual double-header before we know if the additions actually work or not. I know the Rangers have one on Friday, so I’ll be paying close attention to see how things go. Please be fore-warned, though: if something is wrong with my updates, it will become apparent on Friday. If I notice any peculiarities, I’ll post a note here on the Tracker describing what is happening.

Postponements

Postponements have been another pain-point for some users. In scanning the data coming from MLB, I believe when there is a postponement the data for players involved in the game are removed from the server. If this is true, the recent effort to schedule regular checks on player stats should, theoretically, address this issue. When stats are checked early in the morning, Kilg.us should notice that stats for any player involved in a postponed game are missing and correspondingly clear out that player’s day. This probably will happen before boxscore emails are sent, but likely won’t occur immediately after a postponement is called.

If I am wrong and MLB does not remove the data for players involved in a postponement, I’ll need to add some further logic. The Linescore file for each game notes if there is a postponement, but it is done through a text field so I’ll need to extensively research all the possible terms they could be using (postponed, postponement, cancelled, delayed, delay, etc.) before I can start checking for them. Because that will be significant work, I’m going to put off that effort until I’ve verified whether the previous described mechanism is working. Should it not be, please bear with me.

Avatars

Last night I posted briefly on the addition of avatars for Users and Teams in kilg.us. To elaborate a litte, the avatars are used exclusively on the Dashboard at this point and consist of a pre-defined set of images. My goal with the avatars is to help make Kilg.us more scannable. I think the first step (the dashboard) has been successful. I hope to pull those avatars into other areas of the application where they could be helpful. Activities around finding, approving, and defining permissions for other Owners in Industries are an obvious opportunity.

To implement avatars I added a table (to store the default Kilg.us images) and a couple of columns (to associate avatar filenames with Users and Teams) to the Kilg.us database. This structure will allow me to define avatars that any User can choose from (basically, those you see as options right now) and allow for Users to upload their own avatars without exposing them for other people to use. Until I build-out the file upload and image manipulation mechanisms, the only options for avatars will be those I draw and add. Once those mechanisms are built, you’ll be able to upload your own avatars.

The biggest obstacle to being able to use your own avatars is the image manipulation that will need to be done when files are uploaded. Kilg.us is using two sizes of avatars: 48×48 pixel images for Users/Owners and 32×32 pixel images for Teams. For the sake of consistency, all uploaded images will need to be re-sized to fit the proper dimensions. I think I should be able to handle that with manipulations and masks using ImageMagick. It is not something I’ve done before, though, so I imagine a fair bit of trial-and-error.

The new mechanism for calculating statistics that I mentioned yesterday is now in place and in use on Kilg.us. Instead of only calculating team stats on your team page, Kilg.us now can calculate the stats anywhere on the site. The Team page has been updated so it is now using the new stats calculator which might show modest improvements in page load time (previously stats were calculated client-side, which is generally slower). More interesting, the Dashboard is now displaying summary team stats for all your teams and your Industry teams. The summaries display batting average, on-base percentage, and slugging percentage on the offensive side and ERA, WHIP, strikeouts per 9, and walks per 9 on the pitching side. All summary stats are only for the players currently in the team’s lineup.

After monitoring the performance of the new calculator, I plan to implement the stat totals on the daily boxscore emails. Look for that in the coming days (but not tomorrow).

In addition to the new calculator, I also had to put in place a new engine for collecting stats. Previously stats were collected each time a Team page was loaded. For every player on the team, Kilg.us would check if newer stats were available (newer than what Kilg.us had stored in its database). If there were, they would be pulled into the system and the database updated. This process is still in place. But this method meant if nobody had visited their team page on any given day, the stats that would be displayed on the Dashboard could be out-of-date.

To solve this dilema, I added a scheduled process to gather stats. The process runs on the hour from 10am-1am Eastern time each day (March through October, anyway). It collects the latest stats for every player that is associated with a team in Kilg.us. This means dashboard stats could potentially be a little out of date, but should be reasonably recent. And up-to-the-second stats are, of course, always available on your Team page.