Kilg.us – Fantasy Stat Tracker …Tracker

I noticed the other day that Kilg.us had recorded a save for one of my pitchers that, in fact, had blown a save. Reviewing the code that collects these stats, I think I’ve identified the issue.

Unlike most stats which come from a dedicated attribute in the XML files, saves, wins, losses, and holds need to be parsed out of a generic “notes” attribute. The logic performing this parsing was looking for “S,” to identify a save. While this matches the pattern (S,9)–a pitcher who recorded his 9th save–it also matches the pattern (BS,3)–a pitcher who has blown his 3rd save. I have updated this parsing pattern to look for “S,” in the absense of “BS,”. Hopefully this will fix the problem. I’ll be keeping an eye on this throughout the evening, but ping me if you notice any issues.

I jumped into the Find Friends section of Kilg.us this evening, planning to update the logic to auto-accept all friend requests to “Major League Baseball” (at present, I manually check the account daily and accept requests). Hitting the page, though, I encountered a Lucene search error, so that derailed my attention.

It looks like the search logic was getting confused when the page was sent an empty query (just clicking the “Find Friends” link rather than using the form on the Dashboard). This wasn’t happening a month or so ago when I set it up, so I’m guessing it has something to do with the size of the index that is being queried now.

Anyway, I updated the code to handle empty queries more gracefully. While testing that, I noticed an issue when requesting Friends that don’t have a name on their profile. When making the request, the prompt would ask if you wanted to request ” ” to be your friend. That isn’t very helpful. I updated that script to pull in the user’s email address if a name isn’t on the profile. Now when you ask someone to be your friend, you will either be prompted with their name or their email address. Much better.

In the process, my JavaScript errored out a couple times. This, unfortunately, means I requested to be friends with a couple people I don’t know. So if you got a random friend request from me, I won’t be offended if you decline!

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.

Earlier this Spring I changed the search function for finding friends and creating Industries. The biggest change was moving to a system that uses the Lucene search engine. Part of that engine requires that an index be built for the data to be searched. This was my first implementation of Lucene, so I didn’t have experience with maintaining that index of data. As it turns out, each time the data within the database changes, the index needs to be rebuilt to include all the correct information.

Initially, I wrote a short script to build the index. As more and more people signed-up for Kilg.us, though, the data became out of date because it wasn’t automatically re-indexing.

I have updated the processes for creating an account and changing user settings to display information publicly. Both processes now include a step that re-indexes user data. This should ensure that the user index is always up-to-date and all users with their information shared will be findable in the Find Friends search.

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!

When clicking on the red “X” associated with a player on a team page, Kilg.us is supposed to prompt you to confirm that you wish to remove the player from your roster then, if you accept, actually perform the removal. Due to a duplication of the class name associated with the red “X”, a duplicate prompt was being generated. Upon acceptance of both prompts, the proper player removal was being performed. This duplicate prompt has been removed.

The duplicate prompt was being generated for the first player in the table from which you tried to remove someone. For example, if you tried to remove an outfielder from your team, you would be asked “Are you sure you wish to remove OUTFIELDER X from TEAMNAME’s roster?”. This is correct behavior. After clicking “OK”, though, you would be given the same prompt for your catcher (or whichever player was at the top of the table): “Are you sure you wish to remove CATCHER Y from TEAMNAME’s roster?”. This shouldn’t happen. If you had nonetheless accepted that prompt, Kilg.us would have properly removed the player you wanted to remove and not altered the other. If you declined that second prompt, though, the player you originally requested to have removed would not be removed.

This was happening because a class used to identify the red “X” button was duplicated onto the table-cell containing that button. I have updated the script so it is more specific in where it is looking for that class. This prevents the duplicate prompt from being generated and returns us to the proper flow to remove players.

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.

Looks like last night’s 2010 Kilg.us re-launch wasn’t spotless–the script to generate and send email box scores didn’t run correctly this morning. Part of the new 2010 efforts included re-structuring the organization of classes in the file system to follow more standard practices. It looks like the script in question was missing a reference to the class it needed to determine the date for which it should be sending the box scores.

I’ve updated the script and expect it to run tomorrow without a hitch. I don’t intend to run the script to generate box score emails today because it is still spring training. If you have an urgent and dire need for a box score email, let me know and I’ll see what can be done.