Kilg.us – Fantasy Stat Tracker …Tracker

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.

I got an email today pointing out that homeruns allowed were not showing up on Team pages even if they had been selected to be displayed for the given team. After a quick peak, I noticed a typo (“HRA” vs “HR”) in the table cell classes. I’ve corrected the typo so HRA should now be displaying properly for all teams.

While clicking through my team stats today on Kilg.us, I noticed that the stats display layer seemed to be out of date. After a little investigation, I found that the XML feed for the stats had not been updated since June 16. A little more digging turned up what looks like a change in the way MLB is storing their data. The format of the data itself seems to be the same, but they moved its home on the server. After updating the path to the data, all seems to be well and cumulative stats are up-to-date again.

In other news, I resolved an issue that yesterday’s IE7 “fixes” introduced. In the mega-drop-down, the new JavaScript set a negative top-margin for IE browsers. Turns out IE8 is enough better than IE7 for this to be a problem. So that method has been updated to only apply the margin to Internet Explorer version 7.

And lastly, some new language throughout the site. The Account Info page now displays an alert message if the User’s profile is set to Public but they don’t have a first or last name defined. Obviously it is difficult to find people in a search if you can’t search on their name(s). The new language encourages the inclusion of a name to help other Users in their searches. The Account Info and Sign-up pages now also have note text added to the password sections indicating that passwords must be at least 6 characters long. Previously the only way to know this would be to enter a password that was too short and try to submit it. At that point an alert would pop-up identifying the shortcoming. Now the User is informed up front.

No new functionality today–just incremental improvements to Kilg.us. I started by trying to clean up some IE7 display issues. No surprise, I was quickly reminded why Internet Explorer is the bane of every web developer’s existence.

IE7 was totally breaking the mega-drop-down team switcher. For some reason, it insisted on forcing the second column of the drop-down vertically below the first column. No margin overlaps. No width issues. No clearing/float issues. IE is just a piece of shit. After trying a half-dozen elegant solutions, I resorted to a JQuery work-around. Each time the mega-drop-down is opened in IE7, the height of the left column is calculated and the right column is given a negative top margin equal to that value. Ugly, but it works.

Next up was the odd top spacing of the right column on the Select Stats page. Not surprisingly, this was also an IE joke. Not a margin issue, not a float, clearing, line-height, or any other reasonable issue. So I decided to ignore it. If you are using any version of IE and experience functional or display issues–it’s almost certainly your browser. Try a real one.

After becoming exasperated with IE, I went back to legitimate fixes. I navigated through the site running each page through the W3C HTML Validator. This is something I do from time to time, but hadn’t for a month or two so there were a number of issues to fix. I’d gotten into a bad habit of giving my form elements a name attribute (shame on you!) as well as not placing my hidden input elements within a block-level container. In addition there was a nesting issue (un-closed un-ordered list on the Find Users page) and a couple labels with improper for attributes. All-in-all I fixed a dozen or so validation issues.

Because I removed some attributes and manipulated some forms a bit, it is possible I broke something. I tried to test all the flows I could think of to ensure their performance, but if you notice something that isn’t working please let me know.

While testing a new User account, I noticed that the Kilg.us page layout was “blown-out”–spreading across the entire page–if a User had zero or 1 teams associated with their account. This was an error in the nesting of the logic in the new team selection mega-drop down. This should be resolved for all pages.

In hopes of better regression testing in the future, I’ve defined a new test User account that only has 1 team associated with it so I can test changes with what is probably the most common use case. Kind of seems like a no-brainer…not sure why I wasn’t doing it before.