Quote:
Originally Posted by AltonKelsey
Someone suggested we look at the underlying html code and see how 'complicated' it is in order to excuse batch betting being 'out of service' for an extended period.
Only problem with that , it has zero to do with the issue.
I'll make it simple.
I send a batch bet that tells them , in simple ascii, to bet $100 to win on the 5.
This completely bypasses any web based coding.
All they have to do is convert it to the same coding that they would use if I went to the web page and clicked 100 win , #5.
Rinse repeat , for 1000 trifecta combinations or exactas.
Since their normal betting platform is in full operation, and parsing the upload is trivial, then I can find no reason for batch being down other than sloth.
There's a 50 cent word for ya.
|
There's a legitimate gripe for TS failing to test basic functionality across the common platforms. But what you perceive to be a simple click or two, is often many lines of code and interpretative functions underneath the covers. Even "simple" ASCII commands are at the mercy of whatever Google, Microsoft, Mozilla and others are up to when it comes to updates, as well as whatever add-ons you use and how they are configured. Since a web interface is used to upload batch wagers, they are always using web based coding on the front end of the transaction.
On the back end, that simple ASCII file of course has to be parsed, translated to a SQL insert, confirmed with the transaction ID# with the tote, and linked to your account - and probably a few other things I'm not thinking of off the top of my head. That functionality needs to be integrated with numerous tools and levels of code, (O/S patches, DB APIs, user ids, permissions and security, network connectivity and ports, etc.). There are many places where the functionality can break.
Even with the batch upload disabled, the web interface in Chrome displays 331 lines of HTML to present the menus to me, including one ginormous line that wraps several dozen times.
As for the batch processing being down because of "sloth", well there's certainly the view (once again) that testing across the functions is coming up short. But I would venture to guess that batch processing is used by a relatively small number of users, and is certainly a subset of the entire Twinspires account holders. Considering web and mobile are probably the big hitters, the priority to repair functionality used by fewer users is of course lower - pretty much like folks up in the hills and hollers of the county are last to get the road out front plowed after a blizzard. Sloth maybe, being lower on the totem pole, most probably.
I'm not making excuses for TS - it's obvious to me they need to upgrade the quality of their IT staff, and the corresponding departments of development and support, if they want to maintain the same or improve the user experience. But as one who works in IT myself, I can tell you the bean counters are firmly in charge - and the trend has definitely been to pay less, staff with fewer people, and keep the stock price up. And I don't see that trend changing.
