Kilg.us – Fantasy Stat Tracker …Tracker

Yesterday I started receiving notes that players’ season at-bats in Kilg.us were topping out at 127, even when MLB was reporting a higher value. The reason was a simple oversight in database design. All the numeric values were defined as “tinyint” within the database. This is what is used throughout the daily stats, so it was copied over when the season stats tables were created.

Tinyint is a data-type that only allows for values from -127 to 127. This is great for daily stats (the only daily stat I could imagine passing 127 would be a pitch-count), but doesn’t work so well for season stats. I have changed the data-type to “smallint” for all fields that could exceed 127 in a full-season. Smallint will allow values up to 32767.

Season-to-date stats are collected on a scheduled basis, every 15 minutes. In the next few minutes we should see season-to-date at-bat values correcting themselves. I’ll be monitoring this to ensure it happens so I can diagnose further problems if it doesn’t work.

Thanks to all of you that chimed in with this issue and for providing details so I could correct it quickly!

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!

Has anyone noticed a problem receiving some of their daily email boxscores? If so, please add a comment or email me. I think some might be being missed, but would like to hear from any people actually experiencing problems.

Thanks for your help!

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!

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.

It was brought to my attention this morning that Chrome was not laying-out the player detail layer as intended. The season stats table was showing below the player’s photo.

Before: Incorrect layout of stats table in Google Chrome

The culprit seemed to be a lack of a width defined for the element that contained the season stats table. I do not understand why it was a problem. Depending on the player, the width needed to be set to smaller and smaller values for the layout to work properly. I have set it to what, as best I can tell, is a low enough value to work for all players. This change is only in place in the new 2010 code base, so you won’t see the fix until I launch in the next day or two.

After: Proper layout of stats table in Google Chrome

As I said, I don’t understand why this was a problem. The width values are well below the width of the actual table that they contain. The overflow is set to “visible” so that the extra width of the table isn’t hidden. All values are well less than the actual physical space available for the element.  Unless I didn’t identify the real problem, it seems that there is a flaw in the Chrome rendering engine for this.

After launch, if you encounter a player detail layer that still isn’t laying out properly, please let me know.