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.

Needless to say, I went to the website quickly and downloaded a fresh copy of the beta. The entire package clocked in around 2.7MB and downloaded very quickly. My very first impression of the app was the giant flower they have as an icon. I normally don’t fuss over icons, but this thing is gorgeous. I’ll include it here, for the sake of including.

Ok, on to actual experience with the application…

When I first opened the application, I was greeted with screen that presented me with three options:

1. New Repository Bookmark
2. Free Online Repository (Powered by Beanstalk)
3. What do you think of Versions?

I selected the first option, because I don’t need any svn hosting, but it’s a nice idea to include a link to an svn host in the app.

When you select “New Repository Bookmark”, you get asked for a few simple pieces of information: repository name, repository url, username, passsword, and optionally a link to a ticket system which links #123 in an svn comment to http://url/of/tickets/123. Neat!

I decided i’d enter the repository information for jQuery Lightbox, hosted with google code. This is where I ran into my first problem with Versions. It threw a subversion error related to the certificate on googlecode.com

I wasn’t entirely surprised by this error, as I got a similar error in svnX. My guess is that other folks have the same trouble with google code. I decided to set up the http version of the repository. This means I wouldn’t be able to commit from versions, but i’d still be able to get a feel for everything else in the project. After changing the protocol to http and clicking “Create”, I got my first real taste of the Versions interface.

Let’s see what we’ve got there. Some of the standard controls for any svn app, update, commit, diff, etc. In the main interface, it looks like I have a list of my repositories, and the meat & potatoes of the app is in the main content view. There’s some interesting controls in there that i’d like to explore. First off, on the left of the main view, there’s a button that reads “Select” and what appears to be a depressed button next to it labeled “REV HEAD”. Clicking there allowed me to view any previous revision. The three large buttons in the middle of the view, “Timeline”, “Browse”, and “Transcript” also need to be explored. Browse looks like it’s a standard filebrowser, showing what revision files are at, date modified, who modified them. Clicking on timeline brought me to a view filled with a Trac-esque timeline view.

The timeline viewer is a great addition to an svn client, because it gives you an instant overview of project activity. Who’s making what types of changes, and when. I’ve always relied on Trac, cvstrac, and custom written timeline viewers to give me an overview of this type, but having it directly in the client makes it a good deal easier to have access to.

Now that I had the repository added, I wanted to see how Versions tracks changes through a project. To do this, I was going to have to checkout a working copy. I selected the project, clicked the “Checkout” button at the top of the window, and I was off to the races. I just needed to tell Versions where the repository was going to be checked out to, and it did everything else without issue.

With a working copy successfully checked out, it was time to make some modifications. I looked for a simple edit to make based on the project’s issue tracker. After a minute or two of reading I found my edit, and made a change to one line of the main .js file. It was time to switch back over to Versions and see where my changes showed up. At first, I didn’t see any changes listed in the file browser, and that was a little discouraging. I noticed a little refresh glyph in the top right, and decided to click it. Sure enough, my changes showed up after clicking that. While that works, it’d be great if I didn’t have to click refresh. In any case, my changes were there, with an icon appearing next to the file I had made changes to.

Also, above the file browser, I had the option to toggle between “All” and “Changed”. Changed lists just the changes files in your working copy.

So far so good. The one last thing I was worried about in this little walkthrough was how Versions would handle diff’s. I’d read on their website that if you had Xcode installed, that it would automatically use FileMerge for diff’s. This is the same behaviour that svnX uses, and i’m a big fan of it. I selected the changed file in the file browser, and clicked “Compare Diff”. Sure enough, FileMerge was there listing my change.

That was just about everything I needed to see to work with this app on a day to day basis. There’s still the regular headaches that come with svn, but this app looks like it is going to make version control a whole lot nicer to work with. I’m already sold on the app, and I haven’t even started using it with any of my work projects yet. That’s what this weekend is going to be for.

To sum it up:

The Good

• Simple, Clean Interface
• Integrated timeline
• svn+ssh:// support
• Integrates with Xcode’s FileMerge

The Bad

• Need to refresh file browser for each change
• Still In Beta!

This time apparently php was building as i386, but httpd was running as x86_64 (I’ve got a SR MacBook pro as my build environment, your mileage may vary.) So, instead of figuring out how to cajole php into building as x86_64, I fell back on my friend lipo to make sure httpd was running i386. Here’s what I did:

sudo apachectl stop
cd /usr/sbin
sudo mv httpd httpd_old
sudo lipo -thin i386 httpd_old -output httpd
sudo rm -f httpd_old
sudo apachectl start

This looks like it solved all of my problems. I might keep this in mind for when 10.5.4 drops, to make my life a good bit easier.

In the mean time, if you can tell me how to convince php to build x86_64, I won’t mind. ./configure detects the following about my system:

checking host system type... i686-apple-darwin9.3.0
checking target system type... i686-apple-darwin9.3.0

Maybe i’m destined to run as i386, which I don’t mind, so long as it runs.

Cheers!