Kilg.us – Fantasy Stat Tracker …Tracker

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.

Finally, after months of development (also known as “inactivity”), Kilg.us now has a mobile-optimized verion: m.kilg.us! Currently Kilg.us Mobile only allows for tracking of stats–no account or team management. With a very simple interface you can log-in, view your dashboard–complete with summary stats for all teams, and track the stats of all your fantasy teams and players.

I currently only have an iPhone, so that is what the site is optimized for. If you have a Pre, Blackberry, or Android phone I would appreciate any feedback and screenshots you can send me of how the site is rendering and performing.

The interface is still undergoing some tweaking, but it is very minor and should not impact the current functionality. After I get a feel for how the mobile version of Kilg.us is performing, I’ll start to plan out the addition of more functionality. I’m not sure if the mobile site will ever be feature-complete, but I expect it will be moving in that direction.

Luckily the object-oriented architecture of Kilg.us made the mobile site painless to implement. I would guess it’s been less than 8 hours in development and most of that time has gone into fine-tuning the interface. Hopefully future additional functionality will be as simple to add!

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.

It can’t be seen yet, but there is some ongoing work with Kilg.us. I’m currently adding in some new mechanisms for calculating team statistics. Right now all team totals are done with JavaScript on the client-side based on the numbers displayed on your team page. This made sense when I was only putting stats on that one page. Now that we have boxscore emails and a dashboard, it would be nice to have access to stat totals throughout Kilg.us. As such, I’m building statistical totaling into the object model. This will give access to team stat totals for emails, dashboards, and anywhere else they could be of value.

I have the batter stats collected and calculated. Next up will be the pitcher stats. After that, I’ll start working the output into the different locations they’ll be used. Stay tuned…

Lots of work on Kilg.us today, the result being: Kilg.us acts exactly the same as before! All of today’s work was on the back-end. I extended the PHP object model to include a User object that is now used for authentication on pages throughout the site. To do so, I had to touch just about every file in the site. I’ve since gone through and tested almost all of the functionality. If you run into something that isn’t working, though, please let me know!

The motivation for the User object was the social aspect of Kilg.us that I’ve mentioned previously. By pulling user data into an object, I expect I’ll have an easier time implementing all the new functionality that will be required to relate Users and Teams together.

In addition to the new User object, I also built out the Team object further. Previously, the Team object really only managed the overall Team information (team name, id, etc.). It now also stores batter, pitcher, and player arrays so they can be used and manipulated without needing separate SQL requests on the pages that want them. The new Team object functionality is being used on the Team statistics pages, but not implemented in the process that generates daily email box scores. Hopefully those will still fire off properly in the morning.

Today’s efforts again revolved around user feedback. The request was for the ability to select which day’s stats were viewed. Basically, the ability to dig back through yesterday’s stats…or the day’s before. I’ve been tossing this idea around in my head for a few days, negotiating with myself about how it could be handled. Ultimately, though, my conclusion was that it wouldn’t be. The purpose of Kilg.us is to be a free, live, baseball stat tracker. Being able to travel back through various days’ stats flies in the face of that basic concept (Not too mention, the entire basis of the code architecture). Also, trying to store stats for every day of a baseball season (or multiple baseball seasons) would start to get into scalability issues I don’t want to address.

That said, I understand the interest in being able to see yesterday’s stats; or the day before’s. So what I have implemented is a system to email your team’s stats to you. If you so choose, for any of your teams, Kilg.us will send you an email bright and early each morning with your team’s stats for the previous day. That way you’ll have your own, permanent record of your team’s stats over time, without Kilg.us needing to manage all that data. It seems like a win-win to me.

At this point, I have the script written that generates the email and fires it off and I have tested it for one of my teams. The next step is to schedule that script and ensure it is firing correctly each morning. I’m in the midst of that test now. Once I have confirmed it works, I’ll introduce an interface in Kilg.us that will allow all User’s to choose whether they want stats emailed to them for each of their teams. Hopefully that will be added sometime this week, so keep an eye out for it!

Today has seen substantial progress on the iPhone web app version of Kilg.us. It now allows Users to log-in, create teams, and access a Team page. As of right now, no information other than the team name is displayed on the Team page, but it’s progress. So far I’ve had to duplicate most of the log-in and user session authentication files, but both apps are sharing the same objects for teams and players.  It’s not where I would like to be, but it’s better than nothing.

I started work on an icon set for the button navigation of the mobile site. It is further evidence that I’m not a designer, but all things considered, I’m pretty pleased with them so far.

A few days ago I implemented the Dashboard discussed in the previous post. It still doesn’t do anything but provide access to all of a User’s team pages.