Plotting Game by Game Winning Percentages

http://www.monkeyatlarge.com/projects/drillable-stacked-time-series/
Another baseball season is upon us, and fans are quick to project the results of their favorite team from the first few games. I wondered if many teams tend to arrive at a winning percentage near their whole-season results, and then oscillate around a little, versus having early results that differ substantially from the final winning percentage.

I created an interactive plot to look at the results for the 2009 season, team by team.

Take Boston. Seen below, Boston started slow, but pretty quickly arrived at their ultimate winning level.

On the other hand, the Yankees started even slower, and in fact didn’t reach their ultimate winning level until very late in the season.

See the results for the other teams on the visualization page.

The visualization was created using Javascript and the Raphaël JS library.

Livepipe UI controls for JS

I’ve been pretty pleased so far with the popup window control from LivePipe. It plays nice with Prototype and is easy to style with regular CSS. We had considered using Prototype Window but I was put off that all their default styles looks like operating system windows and restyling their windows required a table and 9 images.

I’d recommend anyone looking for a popup window solution at least consider Livepipe. There are downsides however, chiefly that the project is pretty immature – technically I suppose this is an alpha release since Beta One is being worked on, so the community remains small. While there are some folks already submitting patches, progress on merging the patches is alarmingly slow, as one can see from their lighthouse page.

If you’re doing RESTful stuff in Rails however, you will need the contents of ticket #10 which modifies the popup window to accept an option to use different HTTP verbs.

Scriptaculous docs

Every now and then my iPhone has this issue where it can’t tell time properly. I wake it up, and it shows me a time several hours ago, then as if waking from a drunken stupor, slowly tries to catch up to reality, moving the clock forward by a small, random number of minutes. During these episodes the whole UI is sluggish, and it apparently doesn’t even accept phone calls. When “phone” is 5/6 of your name one would think at least that would work all of the time!

Check out this screenshot from the missed call sheet. It recorded 3 missed calls that arrived over the course of an afternoon all with the exact same arrival time, 9:40 AM. The phone never rang.

That was with v2.01, so I sure hope this is fixed in the future.
For all the complaining I often do about the poor documentation of the scriptaculous project, I finally did something to help that today, creating (very thin) documentation for their new (if released in January is new) Effect.Tween function here on their github wiki.

I was creating a method to scroll the viewport so that the contents of an AJAX-loaded div would be fully visible on the screen – the (still undocumented) Effect.ScrollTo doesn’t quite do it because it doesn’t consider the height of the element it scrolls to, but in doing so I stumbled over Tween in the code. Once the math to figure out how much scrolling is needed, its easy to use Effect.Tween to smoothly scroll the window by repeatedly calling window.scrollBy();

This certainly isn’t rocket science, but here’s an outline of how to do it (this code only deals with downward vertical scrolling):

var elementHeight = element.getHeight();
var screenHeight = document.viewport.getHeight();
var elementScreenPos =element.viewportOffset()[1];
var amountToScroll = elementHeight - (screenHeight - elementScreenPos);
if (amountToScroll > 0){
var scrollPos = document.viewport.getScrollOffsets().top;
new Effect.Tween(null,scrollPos,scrollPos+amountToScroll,{},function(n) { window.scrollTo(0,n);});
}
}

Select part of the text in a textbox with javascript

There was a brief discussion on the Tracks mailing list over the way its autocomplete works (the project uses Scriptaculous’s nice Autocomplete widget in local mode): should it automatically fill in the entire word once enough text is entered to match one of the choices (annoying if you have to backspace because the guess was wrong) or make you hit tab or enter to fill in the suggestion. To make a long story short, I suggested a third approach – fill in the remainder of the match selected, so if its wrong, the user can type over it, like this:

textpartialselect.png

This isn’t rocket science and has been done forever, but I didn’t find a single good reference on how to select just part of the text in a text box. Scriptaculous and prototype don’t support it at the present time, and like anything good in browser-land, there’s at least two different ways to skin this cat. The IE way, and everyone else’s way (actually I don’t know which way safari and opera work, but the code here does work for them too).

I saw one of the YUI widgets supported “typeahead” so I looked through its code to find the relevent javascript calls – for IE its “createTextRange” and for firefox its “setSelectionRange”. Combine those and you get the following, which I’ve tested as working on IE 6 (or was it 7?), Firefox (mac), opera (mac) and safari.

function selectSomeText(element,begin,end)
{
if (element.setSelectionRange)
{
element.setSelectionRange(begin,end);
}
else if (element.createTextRange)
{
var range = element.createTextRange();
range.moveStart("character",begin);
range.moveEnd("character",end);
range.select();
}
}

One of these days I’ll refactor the code I wrote to test this with scriptactulous and throw that up here as well.