ttj - Tom Jones

At the risk of bending a term, one wants transactions over the web to be "as atomic as possible".  You know what I mean. Say for something like a payment:  Client and server line everything up, then "wam commit with tiny data", "bam commit worked with tiny data b", and with proper feedback to user at each stage. What actually happens is that devtards create a sprawling, heavy mess with all sorts of back-and-forth.  It pulls in garbage from all directions.  When it's on a perfect internet connection, such as the devtard's dev box, it just about works, most of the time.  That's the level they get it to.  If there is the slightest connection glitch, packet loss, slowness, it just sort of fizzles out in undefined ways.  Maybe the thinger spins round for ever, or something just remains greyed out or doesn't load.  Occasionally some sort of error message will be produced. A payment or other online transaction should work with a 9600 bps connectio...

Repeatability is a perennial software engineering concern, so it may worry the team at interrail that their web site, in failing to sell seat reservations, does so in a slightly different way on different browsers. This morning, on chrome, we have this: The button has not been pressed.  It is never activated and says "Please wait", and is permanently in a faded state indicating non-activeness. On firefox, and with encouraging consistency, we still have: The "Please wait" on this was also never working. But, I should warn you, this is no time for complacency.  On the Android browser (also "chrome"), the login worked, and it was not until a subsequent stage that it became impossible to complete the reservation: In this case, the search button has been hit, but the results never come.  Plenty of effort has been put into the "user experience" that happens while the results don't come.  There are whizzy things going around, and gray templates, jus...