If you haven’t heard, Amazon’s EC2 service provides cloud-hosted virtual machines. Initially, they just supported Linux machine images, but recently have allowed Windows machine images. This means that you can create on-demand hosted virtual machines accessible from anywhere.

I decided to do some simple, informal performance testing. To do development performance testing, I like to run a build process and time it, since compiling is typically the bottleneck on a development machine (other than the IDE and the developer).

I downloaded the source code for SharpDevelop, since I knew it would be a fairly large, yet automated build process. The only thing I needed to install was .NET 3.5 SP1. As a baseline, I ran the build on my personal laptop, with these specs: 2.0GHz Core 2 Duo, 3GB RAM, 250GB 5400RPM hard drive. To test the performance of the build, I ran it once, ran a “clean” operation, then ran the build a second time, timing it only on the second run.

• My laptop:  1 minute, 37 seconds
• EC2 Small Instance: 2 minutes
• EC2 Medium Instance: 41 seconds

As you can see, the EC2 “medium” instance, was over twice as fast as my local machine.

To continue my testing, I installed Visual Studio 2008 Professional, ReSharper, TortoiseSVN, and the Silverlight toolkit. My initial impression was very positive, and I could certainly see myself using it on a regular basis. From a professional standpoint, I would probably prefer a dedicated development machine. However, for an occasional hobby development environment, this might be a viable alternative.

EC2 has many advantages over running VMware or Virtual PC on your own computer:

• Can take snapshots of drives
• Doesn’t use resources from your computer
• CPU can be upgraded/downgraded as needed
• Theoretically ultra-stable host
• Very fast Internet connection (I downloaded 800mb in less than 30s!)
• Theoretically updated virtual hardware as time goes on
• Potentially faster (especially if you use a laptop)

However, there are a few obvious disadvantages:

• Pay-per-hour can get expensive if you use it full-time
• Can’t drag and drop in and out of the VM like desktop virtualization can
• Need to remote connect using something like remote desktop so graphics performance isn’t the best
• Only available when you have access to the Internet
• Not necessarily great multi-monitor support
• Virtual machines take a while to start and snapshot

Pricing

Right now, Windows based machines are priced starting at $.15/hr (medium for $.30/hr). For a machine that runs 24/7, this can get expensive compared to dedicated hosting. However, for a machine that’s used for only a couple of hours each day, the pricing is very reasonable.

As an example, if you run a medium instance machine for 8 hours/day, 20 business days/month, you’ll end up paying $48/month.

Conclusion

Having virtual, dedicated computers available on-demand for pennies per hour is very exciting. This is half of the cloud computing equation, and I believe it’s going to be an important part of the future of the web.

I’m going to describe a methodology that will help you save time by writing better classes, and will help simplify your life by allowing you to solve problems with a top-down approach.

Developers such as myself often have a tendency to just focus on the class we’re currently working on. Of course I believe this is a good thing, because we all know the importance of focus. However, you should never forget the reason you’re actually writing that class. It is because other code will be consuming it.

There have been far too many instances where I would figure out which pieces I needed to build, and then build each one, from the bottom up. The problem is that I would write the class in the most short-sighted and easiest way possible, which is usually not the best way to use it.

Now, when there is a question of what a class interface should look like, I ask myself what it should look like to make the life of the consumer as easy as possible.

Sometimes we can even take code usability to an extreme. For example, Fluent interfaces, which allow you to chain together multiple calls. In many instances, this makes the code much easier to call, potentially at the expense of making the called code more complicated.

I’ve come up with a simple example to help illustrate. Suppose I need to process a list of x,y coordinates. Here are a couple of potential signatures:

• ProcessData(double[] xData, double[] yData);
• ProcessData(PointF[] points);
• ProcessData(IDictionary<double, double> points);

For now, just ignore the performance implications (they’re going to be linear in this case, or close to it anyway). To choose the correct signature, we need to know who the caller is.

Of course there is a good chance that we’ll have a slight intentional leaky abstraction. In the previous example, we may have been able to use the IEnumerable generic to be more flexible. That’s a topic for another day.

Thankfully, this problem is minimized, although not always eliminated when you follow the single responsibility principle. The better you can follow that principle, the simpler each piece will be. That tends to minimize the potential for the consumer to need the interface to look different than it would naturally be.

Another way to look at your classes from the consumers point of view is to practice test-driven development. In fact, I see this as one of the strongest arguments for test driven design. For each layer in your code, you’re creating code by consuming it before writing it. Every layer acts as an API to the layer above it.

In conclusion, I’m simply recommending that you don’t lose sight of why you’re writing that piece of code. You’re not just writing code for the sake of writing code, you’re writing it to be used!

Today’s tip is a hack for getting awesome tech support from a company for a product that you may or may not have purchased. It may not be polite, but it may be a method of last resort.

We all knows what happens if you buy a product and then call for support. If you’re lucky, you get put on hold. If you’re unlucky, you’ve called outside of their business hours of 1am to 3am. When you do talk to someone, you’re treated like an idiot (in their defense, it’s a learned behavior).

If you want great service, call their sales department. Tell them you’re evaluating their product, but ran into an issue. You’ll be talking to someone that actually wants your business. They’re typically very helpful, and remind us of the benefit of good customer service.

Just today a coworker sent me a link (unrelated site) that had a link to a page called "Pre-Sales Questions". They’re openly distinguishing between potential customers, and paying customers. The problem is that they make the pre-sales question form easy to use, but the paying customer form is not. Customer service is in a bad state.

My official recommendation is to to fully try out their product during a trial, so that when do you do talk to their sales team, they can at least earn a sale from it. Like I said, this is a method of last resort.

One of your goals as a developer should be to make your code as readable as possible, both for yourself, and for the other developers you work with.

One great way to determine if your code is well written, is to ask yourself if the code you’re writing is readable by itself. Another developer should be able to jump into a module, and have a fairly easy time seeing what’s going on. They shouldn’t have to sift through thousands of lines of interweaved code to figure out what’s going on.

Of course, what I’m talking about is simply a test for the single responsibility principle. If you’ve written a huge "do it all" class with thousands of lines of code, you’re ensuring that you’re the only one that will be able to maintain it. That that type of code usually suffers from high coupling to the other modules in the program.

I used to organize code into classes based on the type of functionality being provided. I used them more as containers for related functionality. At the time, I didn’t see a reason to split it apart. I was very wrong.

In a recent article by Jimmy Bogard, he walks through creating classes with a separation of concerns. In the conclusion is my favorite part:

Now we have many more classes (4 vs. 1) and interfaces (3 vs. 0).  For those who don’t like more classes, GET OVER IT.

That is an excellent point. Why should you be afraid of creating more classes and interfaces? It’s really not more code to write, in fact, it’s often less. Refactoring tools remove many of the obstacles of maintaining the interface, class, and method structure

When someone looks at your code and you have 4 classes instead of 1, and those classes are very specific and short enough to process by our tiny brains, it will be much easier to maintain and modify (or even better, extend).

I’ve been really trying to use the Single Responsibility Pattern in all of the classes I design. Recently, I needed to create code to query a list of holidays from the database, and then create a method that allows you to get the number of holidays between two given dates.

Here was my first stab at the constructor:

public HolidayCalculator(IEnumerable<DateTime> holidays)

It’s simple and easy to understand. Then I started thinking about some of the dependency injected examples I’ve seen. For example, one of the Spring.NET IoC quickstarts has a similar example, except that they’re trying to list movies. In their example, they use an IMovieFinder interface. That interface has a single method that retrieves a list of movies. Using this concept, my constructor would look like (and what I ultimately changed it to):

public HolidayCalculator(IHolidayRepository holidayRepository)

That example originally seemed unnecessarily complex to me. Why separate something so simple and disconnected into an interface? Well, it turns out there are a couple of good reasons that you might want to do this.

Delay loading

With my original constructor, I had to load all of the holidays from the repository (ultimately a database in the production environment) to even create an instance of this class. This is certainly less than ideal when I want to use this class as a singleton that may get created early in the application.

Single Responsibility

In my original design, I was accepting in a list that would get cached in my holiday calculator. My class now has two responsibilities. It has to calculate holidays, and it has to cache the holiday list. What if I wanted to change how the list was cached? I would have to change the class, which is not ideal.

Ideally, this class would load the holiday list each time it needs to perform a calculation. The implementation passed into the constructor would be responsible for caching. In fact, we can now easily separate out the caching feature, and the holiday loading feature. Both classes would implement the IHolidayRepository interface and would be chained together. The caching class would take an IHolidayRepository.

Incremental Coding

Following the Agile philosophy, I can now deliver code faster. I don’t need to add a caching layer. I can have a working application in less time, and then later evaluate if I need to cache the holiday data.

Conclusion

Overall, this design is a little more work, but I think the benefits outweigh the extra classes and interface I needed to create. This design makes it easy to test, and each class has almost no code in it. Reading it and understanding it is extremely simple.