Kilg.us – Fantasy Stat Tracker …Tracker

A blog about the development of Kilg.us – The Fantasy Baseball Stat Tracker

Posts Tagged ‘code’

Email Box Score Issue

Thursday, March 18th, 2010

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.

2010 Launch

Tuesday, March 16th, 2010

Tomorrow (3/17) evening I plan to launch the 2010 updates for Kilg.us. Launch will probably commence around 10pm Mountain time. The launch will replace the entire Kilg.us code base with a new iteration. This will likely result in at least a few minutes–and as much as a few hours–of downtime.

I will blog and tweet (@kilgusTracker) updates to announce when the launch is completed.

In addition to the Kilg.us updates, I will be publishing a series of blog posts to describe the changes and how to use the new features of Kilg.us. For current users, you will find the interaction mechanisms to be very familiar. A new visual style is the most disruptive change. As the season progresses I’ll be getting back to refining the functionality of the tool

Chrome Player Layer Layout

Sunday, March 14th, 2010

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.

Incorrect layout of stats table in Google Chrome

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.

Proper layout of stats table in Google Chrome

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.

2010 Updates

Saturday, March 6th, 2010

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!

Pitching Homeruns Allowed

Monday, June 29th, 2009

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.

Scoreboard

Sunday, June 28th, 2009

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.

Code Architecture

Sunday, June 28th, 2009

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.

Validation Improvements

Monday, June 22nd, 2009

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.

Blown-out Page Layout Fixed

Thursday, June 11th, 2009

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.

Drag-and-Drop

Sunday, May 31st, 2009

It is now possible to change the order in which your Kilg.us Industry teams display on your Dashboard and team-selection drop-down menu. Both displays use the same ordering. To change the order, click the “Select teams to Display” link from the “My Industry” section of your dashboard. This will open a page that lists all the teams your Industry friends have exposed for you to view. In addition to selecting to show or hide the teams, you can drag-and-drop to change the order of list. After making all the show/hide and ordering changes, click the “Save Display Selections” button to save your changes.

For a team to be visible on your Dashboard and team-selection drop-down, they must have the “Show” option selected. All teams (whether shown or not) can be re-ordered on the page, but only teams marked to Show will be visible to you elsewhere in Kilg.us.

The new drag-and-drop functionality is done using a JQuery plug-in–TableDnD. It should work across all modern browsers, but if you have any difficulty with it, please let me know.

In other developments, I tweaked the display of the Find Users page to utilize avatars and look more like the Owners list on the Dashboard. Doing so removed the “+” that used to be the activator to request an Owner join your Industry. You can now click anywhere (their avatar, name, email, etc.) on the Owner to make the request. There is still a confirmation dialog before the request is actually make so you won’t accidentally add people you don’t know to your Industry.

I also did some tuning to the logic behind the process of requesting Owners to join your Industry and the acceptance/denial flow thereafter.

Lastly, some style tweaks for all elements that use avatars and contain links. To identify hover-states, those elements will now display a gray border. The style uses the border-radius attributes from CSS3 that Webkit (Safari, Chrome) and Firefox make available. Those of you using less capable browsers (ie, IE) will have to suffer through square corners on your borders.