The official announcement:

Skybus Airlines will cease all operations effective Saturday, April 5.

Skybus struggled to overcome the combination of rising jet fuel costs and a slowing economic environment. These two issues proved to be insurmountable for a new carrier.

We deeply regret the impact this decision will have on our employees and their families, customers, vendors, suppliers, airport officials and others in the cities in which we have operated. Our financial condition is such that our Board of Directors felt it had no choice but to cease operations.

Passengers holding reservations for Skybus flights scheduled to depart on or after Saturday, April 5, 2008 should contact their credit card companies to arrange to apply for a refund. More information for customers and others will be made available on the Skybus web site (www.skybus.com) as it becomes available.

All flights for Friday, April 4 will be completed. Passengers holding reservations on flights for Friday, April 4 should check in for their flight at a Skybus kiosk at the airport instead of the Skybus website.

*sigh* Guess it’s time to call Visa to see if we can get some of our money back.

Here are some of my favorites from today, and a few from the past. The funniest ones are in bold.

• SQL on Rails (you must watch the screencast)
• The Commentator - automatically generate code comments
• PairOn pair programming chair
• Luminotes new feature: Import -> Internet
• Stuff White People Like bought by Target
• Jesus found in Java .class file
• Gmail Custom Time
• Amazon’s DCI (Dog Computer Interface)
• PerfectBingoTablePlanMaker released

From the email I just received (below), it looks like this may no longer be an issue. Also in the email is the announcement of Availability Zones - groups of EC2 instances in different physical locations and networks, which will help ensure that if your site goes down in one availability zone, your instances in another zone won’t be affected.

Here’s the email:

Dear Amazon EC2 Developer,
This is a quick note to let you know about some exciting changes with Amazon EC2. We are happy to announce two significant new features - Elastic IP Addresses and Availability Zones - which help you to run reliable web sites and other applications within Amazon EC2.

Elastic IP Addresses are static IP addresses designed for dynamic cloud computing, and now make it easy to host web sites, web services and other online applications in Amazon EC2. Elastic IP addresses are associated with your AWS account, not with your instances, and can be programmatically mapped to any of your instances. This allows you to easily recover from instance and other failures while presenting your users with a static IP address.

Availability Zones give you the ability to easily and inexpensively operate a highly available internet application. Each Amazon EC2 Availability Zone is a distinct location that is engineered to be insulated from failures in other Availability Zones. Previously, only very large companies had the scale to be able to distribute an application across multiple locations, but now it is as easy as changing a parameter in an API call. You can choose to run your application across multiple Availability Zones to be prepared for unexpected events such as power failures or network connectivity issues, or you can place instances in the same Availability Zone to take advantage of free data transfer and the lowest latency communication.

With these two new features, it now easier than ever for you to isolate your application from common failure scenarios and host high availability web sites in Amazon EC2.

For more information on how to best leverage this new functionality, please see our Feature Guides for Elastic IP Addresses and Availability Zones.

Sincerely,
The Amazon EC2 Team

Via Amazon Web Services Blog.

Here’s the original “confirm upgrade” screen:

I look at the above screen now and it’s painful – the design is horrible. Let’s think about the goals for this screen:

• Tell the user what to expect (how much do I have to pay?).
• Reassure the user that they’re going to get what they expect (clear information, no surprises).
• Encourage the user to complete the process (click the button).

I think the above screen does a pretty lousy job of achieving those goals. Here’s why:

• It’s crowded – there’s too much going on for the user to be able to easily focus – buttons, text, blah blah blah…
• It’s too general – I used an existing template for this page – but sometimes certain pages can benefit from a bit of extra attention.

If you’re a designer, I’m sure you see more problems that just those two. My poor naïve eyes only see the most surface level problems – but the good news is that surface level usually catches 80% of the problems, as seen in the new screen below…

I like this page a lot more. Can you see the difference? It just works better, it’s more focused, and it’s tailored specifically to the goal:

• There’s a lot less information – the user can focus on the task at hand.
• The user knows exactly what to expect – the prices are printed in big bold font, not in small print.
• All of the extra navigation has been removed – this helps direct (”funnel”) the user to the goal.

Not bad for a little bit of work. Here’s the same screen before and after, but in this scenario the user has already entered his payment information and all that is needed to complete the upgrade process is clicking the button. Which of the below screens do you think will result in more upgrades?

Do you have any other suggestions for improvements?

From the last post, we saw the following results for parsing an XML dataset with about 450 simple elements in it 1,000 times:

• Java: ~9 seconds
• Groovy: ~28 seconds (with new results below…)

I decided to rerun the test for Groovy because of a comment John Wilson left on the first post. He suggested this more concise syntax for the Groovy implementation:

I reran the same benchmark, and I was very, very surprised at the results:

• Java: ~9 seconds
• Groovy: ~28 ~9 seconds

All I can say is wow. I’m not sure what is happening differently, but I’m happy:)

Any ideas what was taking up so much time in the original Groovy implementation?

Date set: a String containing roughly 450 XML elements in the form <contact name=”some name” email=”some email” />

Methodology: I wrote driver programs in both Groovy and Java to run the test. Here’s the one from Java (the Groovy one is similar):

As you can see from the code, very quick and dirty. The test iterates 1,000 times and then prints out the time consumed.

I ran the test several times on my laptop (2Ghz, 2GB ram, blah blah blah it doesn’t really matter here) and here are the general results for total execution time for 1,000 iterations:

• Java: ~9 seconds
• Groovy: ~28 seconds

Quite a difference. I suspect part of that has to do with my inefficiency as a Groovy programmer. Certainly though, you can see that there is measurable difference in performance. I wonder what type of XML parser the Groovy implementation uses behind the scenes. The Java implementation uses SAX. If Groovy were using DOM with XmlSlurper, I could see that making a very large difference. Any experts care to chime in?

Now, before you decide to write off Groovy, another metric of interest might be seconds required to develop the code. It was something like this:

• Java: ~ 1,800 seconds - roughly 30 minutes. (First I had to decide what XML library I was going to use - JDOM? Dom4J? Xstream? Then I had to search and search for documentation on JDOM…and of course I had to download JDOM, well, that is, I have to add JDOM as a dependency in my Maven pom.xml (after I looked up the current version of JDOM at the ibiblio repo), and rebuild my Eclipse classpath with the new JAR on it, and then figure out how to use the JDOM API…) I’ve been writing Java for about 6 years, so I consider myself fairly adept.
• Groovy: ~300 seconds - roughly 5 minutes. (I had to find the page on the Groovy wiki that explained how to process XML.) I’ve been writing Groovy for less than 2 weeks.

So there you have it, my quick and dirty, completely unscientific, prone to error, your mileage may vary micro benchmark.

I’m not one to reserve judgment, so here goes:

• First, this is just one example. Comprehensively measuring performance is a complex thing, and this benchmark doesn’t claim to do that. There is no such thing as saying “Groovy is slow”.
• Second, I’d gladly trade the frustration and time requirement of the Java solution for the easier to read and write Groovy solution. Servers are cheap. I’ll almost always choose to pay the price in $$$ (which I can always get more of) rather than time (which I can never have enough of).

Update: here’s the final post in this series.

Java code:

Groovy code:

Note that this reduction in complexity happens almost everywhere I choose to use Groovy over Java. Of course there are myriad other ways I could have done this in Java (I even tried Xstream but I couldn’t figure part out so I gave up). The point is that the first way I chose to do it in Groovy was natural, expressive, and easy.

Groovy is not going away any time soon. If you’re a Java developer and wish you could move faster, buy the book, read it, and then start integrating Groovy into your daily programming a little at a time. You’ll be happy you did.

And don’t even get me started on Grails…

Update: here are the second and third posts in this series (benchmarks included).

The bad news is that I might have to purchase a paid plan for CrazyEgg.com - I’ve been using the Free plan which records up to 5,000 visits per month. SendAlong’s gone through that many visitors since Monday alone! That means CrazyEgg has stopped recording statistics for me for the time being. The month rollover will happen on Saturday, so I think I’ll stick it out on the Free plan for a bit more, but CrazyEgg is definitely a service I can’t live with out, so I’ll probably wind up upgrading (no, they’re not paying me for saying that!).

I can’t describe how hard it was to make myself *not* check my email throughout the day as I worked. Talk about an exercise in self control:).

Ok, back to work. Looks like it might be a late night.

One more thing worth noting - I actually just pushed a new version out to the servers. Mainly just some UI tweaks and small bug fixes. Let me know if you like the new tour page and home page better. And if you haven’t signed up for a free account yet to try it out, you really should:).

I’ve officially released SendAlong 1.0!

It’s been a labor of love and…labor, but it’s been worth it.

I’ve got so many things planned for SendAlong - it’s exciting that I’ve finally got 1.0 out the door so that I can refocus and start implementing what so many people have been asking for.

Oh, I’m not sure if I mentioned this before, but SendAlong is built primarily on Amazon’s S3 and EC2 - they provide a very secure, reliable, and scalable architecture that’s suited quite niciely for what SendAlong is providing.   I can’t *not* mention eapps.com as well, though - part of SendAlong is hosted on there as well, and their support with getting things set up has been invaluable.