Skybus closed for business - ah, bankruptcy
Posted by jonchase
Skybus is officially closed - as of, well, right now (thanks for the advance notice). I bet they wanted to do this April 1st but were afraid that no one would have taken it seriously.
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.
April Fools Roundup
Posted by jonchase
I just had a blast catching up on RSS feeds over lunch - except I couldn’t tell what news was real and what was fake.
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
Amazon EC2 now offers STATIC IPs
Posted by jonchase
This is great news for any Amazon EC2 (Elastic Compute Cloud) developer - up until this point, hosting web sites on EC2 has been a little tricky due to the fact that EC2 instances used dynamic IPs - making it tough to set up reliable load balancing and failover in the face of ever-changing IP addresses.
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
Programming with Amazon’s Web Services? Buy this book.
Posted by jonchase
I know I’m going to, just for the cool fish on the cover and the unbelievably long title: Programming Amazon Web Services: S3, EC2, SQS, FPS, and SimpleDB.
Revisit Your Design Ideas
Posted by jonchase
Sometimes (a lot of times) I’ll design a screen or some code and I think “not bad”. Since it’s not bad, it gets my approval and gets moved into production. Thankfully, I often realize that it’s not a bad idea to revisit those designs and see if there’s something I can improve upon. That just happened (Ricky Bobby, anyone?) with SendAlong’s upgrade confirmation page. The differences were drastic enough that I figured they merited mention, if only so that you can learn from my mistakes.
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?
Groovy Micro Benchmark Revisited (Groovy is fast…)
Posted by jonchase
Alright, no more Groovy posts for a while after this one. In fact, I hadn’t planned on posting about this again, but I thought it was worth mention.
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?
Groovy Micro Benchmark
Posted by jonchase
Following on from the previous post (and here’s the last post), here’s a very quick and dirty, completely unscientific, prone to error, your mileage may vary micro benchmark I did using the code in the last post.
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.
Groovy is Coming…
Posted by jonchase
I’ve been trying to slowly integrate some Groovy into my normal Java coding. Here’s just one of the reasons why:
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).
SendAlong got picked up
Posted by jonchase
Today was a very exciting day for SendAlong - it’s release was picked up by several sites (mostly the US and parts of Europe). I was absolutely blown away this morning when I checked the system and saw the number of sign ups - let’s just say it was a bit more than I expected! If you’re interested, I posted about some of the reviews on SendAlong’s blog.
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:).
SendAlong 1.0 is out! More info coming soon…
Posted by jonchase
Just a quick bit of news that makes me very, very happy to be able to announce:
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.
Subscribe to Jon's Blog