Kilg.us – Fantasy Stat Tracker …Tracker

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 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.

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!

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.

This evening I finally managed to get my new object-oriented player model in place. Ultimately, the functionality is only back to where I had it originally. It is, however, much more flexible and re-usable now. The application also seems to be running faster now…but I don’t have any firm statistics to prove to myself whether that is true or perceived. Having spent over a week re-architecting the code, it’s entirely likely I just want it to be faster, so I’m perceiving it as such.

There has actually been one noticeable improvement in the application with the new code: it now tabulates Innings Pitched properly. Previously the addition function was being tripped-up by the non-base-10 notation of innings (5.2, 0.1). The function to total Innings Pitched now breaks apart Innings Pitched values into full innings (base-10) and partial innings (base-3) and converts to base-10 for addition. This base-10 value is used for the calculations of other statistics (ERA, WHIP, etc.) but it is converted back to the perverse base-10/base-3 notation for display uses.

Now that the new code is in place, I can resume with building out functionality. The next steps will be to build the functionality to create accounts and teams and to be able to add players to–and remove from–teams. I’ll be starting that work tomorrow.

In the course of my day today I came across OpenID. I’d not heard of OpenID previously. Apparently it is an open-source, shared authentication mechanism. It immediately piqued my interest because I am a huge open-source advocate. I have a lot of research yet to do about how to implement and what advantages it might provide on the back-end (most of the marketing for it emphasizes how much easier it makes life for users). With any luck, though, I’ll figure it all out and we’ll see about having it implemented for authentication on the Fantasy Stat Tracker.

I need to get this blog re-skinned, too…

There hasn’t been much visible development on the Stat Tracker the last few days. I’ve been spending most of my time thinking through the code’s architecture. Because I am not sure where this application could go, I want to make it as flexible as possible.

The first round of code I wrote was mostly procedural and even just as far as I had gotten, was starting to get messy and difficult to navigate and manage. I’m moving to an object-oriented model that should provide much greater flexibility down the road. Of course the short-term drawback is that I’m making no visible substantive progress. Hopefully I’ll have my architecture finished and the code re-written this week.