http://rorramblings.blogspot.com/2009/12/apache-passenger-ssl-osx.html

Oh, and Happy New Year!

Somewhere, something incredible is waiting to be known.

– Carl Sagan, 1934 – 1996

Do you make use of any pear libraries, or even have access to an updated pear?  Would an open source project that depends on certain pear packages make you update your local PEAR, or choose another package without that dependency?

It’s a tough judgment call to make, but I think i’m going to leave it as a dependency in my packages.  The software benefits heavily from it’s inclusion. It depends on it.  Would you make a similar call?

P.S. First post since August 2008? I’ve been too slack.  I’ll update this place soon.

Cheers!

Download July 26th Free Sudoku Booklet

First off, “Safari” is listed as a supported browser.  Upon closer inspection, they list safari 1.2 & 2.0, no mention of 3, or 3.1, I’ll accept fault for not realizing that they don’t support the latest version of the browser that’s been out for over a year.  That means that when I came back to my machine at 9am, although their site didn’t warn me about my browser problem (or warn my girlfriend, or a few friends in town who use safari on their PC’s), I was still “in queue” with no change.  I launched Firefox  to get back in queue and try and get my tickets.

For the next hour, i’d wait through “queue” for approximately 10-15 minutes, only to have the order server time out when I got to it.  When your connection times out with the order server, you are placed back at the back of the line and forced to wait through the queue again.  I got calls from a few friends in town who were having the same problem, asking if that was “normal.” I assured them that it was not, but to keep trying.

Eventually, the order server changed from “completely unresponsive”  to  working properly & quickly.  By this point, however, there were no tickets left available to purchase.  This means that multiple folks who hopped online at 9am missed tickets due to what seems to be a “hiccup” on the purchase server.

My complaints can be summed up as follows:

• Warn people with unsupported browsers.  A simple script to verify a specific browser version is easy to implement. Hell, there’s hundreds of versions of it openly available online free of charge.  Let people know that you don’t support their browser so they don’t wait an hour for nothing.
• Abolish the “queue” after 9am.  Sell tickets first come, first serve.  The reason ticket lineups exist is because purchasing tickets is always one person at a time, handled by a person.  Online sales can be handled with hundreds, even thousands of transactions a second.  Abolish the “line up” mentality for purchasing, and you’ll kill the “camp out” advantage people get in a line up.  They’ll quickly move to buying online, making it “fair” for everyone.
• Get a better order system.  Having a server time out simply trying to check for tickets, when you’ve had days notice of “increased load” shouldn’t happen.  Up the horsepower on the server that handles it, or get more bandwidth.  Since things like Amazon’s compute cloud now exist, you could even have an order node sitting in their cloud, waiting to take orders if your in-house servers don’t scale.  Planned demand should mean little to no downtime, especially during the peak of your planned demand.
• If you keep a queue, and your order server fails, implement some method to verify that someone has waited in queue, instead of simply treating them as a newcomer to the queue.

Needless to say, I didn’t get my tickets.  I dread the next time I attempt to buy tickets via the ticket atlantic interface.  Also, this is an open invitation to anyone who makes technology choices at ticket atlantic.  I will gladly put together a small team of guys to put together an alternative to your current web solution.  It would be an improvement, because to get any worse would be incredibly difficult.