I'll not go into a long winded argument about why you should backup your data. If you're reading this, you know it's a good idea and you like to learn how to push your data off site into the cloud for as low as $0.11 per GB per month. Note that I'm talking about the European pricing here, the US pricing is slightly cheaper.

In essence, what this blog will show you how to do is:

1. Create an Amazon EC2 persistent volume of your desired size
2. Start up an Amazon EC2 cloud machine
3. Mount your persistent volume to this temporary machine
4. rsync your data over to the machine
5. Shutdown the machine

All of this can be done more or less with a single script that you can schedule to run at any time. It will cost you around $0.11 per hour whilst the machine is running for your upload and then $0.11 per GB per month for storage.

We have been using agile development methodologies at Black Pepper for a while now and have used Mingle in the past as an online tool for managing stories and iterations.

However, we recently decided on Jira as our feature/bug tracking tool of choice and thought it would be interesting to see if we could use Jira to manage our agile projects rather than have more than one tool.

One of the cornerstones of an agile project is tracking your velocity. This is essentially a measure of how much work you are doing over a period of time. Agile projects are run in iterations, these might be a week, 2 weeks or perhaps a month. The length of the iteration would depend on the project, but 2 week iterations are a good start. Each iteration has a collection of "stories" assigned to it. A story is basically a single feature that has been defined through your analysis of the project before the first iteration. Note that as this is an agile project, you don't have to analyse the project completely up front and have everything mapped out. You just need enough to get you on your way, you will be creating and estimating more stories as you go.

At Black Pepper Software we primarily deal with Java on the server side and then various kinds of front ends, but it's usually browser based. With the release of an almost feature complete Adobe AIR runtime for Linux (to catch up with Windows and OS X), I felt it was time to experiment a bit more with what a modern desktop app was like.

Trying out AIR was a natural step for me as I've been spending a lot of time doing Flex recently, but I've never done desktop development before. This is partly because in this day and age it is so easy to keep your web app up to date without the deployment costs and versioning problems you get with desktop software. What happens when you have a desktop app that is connecting to some web services and you want to change those services? You've got to update your desktop app and make sure that your users get that update, otherwise things will break.

AIR doesn't come with an update framework built in, but there is one in Adobe Labs at the moment which works a treat called the Adobe AIR Update Framework. I will point out up front though that the Update Framework is NOT open source, in fact, no source is provided at all except for the samples of how to use it.

Giving users the option to have your application remember their login details is a simple and really useful feature for any desktop app to offer. Web browsers have had this feature for a long time now and you can even store your usernames for your Flex web app in a SharedObject...but when storing passwords, you have to be quite careful with how you store the data.

Thankfully EncryptedLocalStore comes to the rescue in AIR, but it's not available in the browser.

My test app for this is a simple two screen Cairngorm AIR app. I'll skip over some of the boilerplate of the app and just get down to the nitty gritty.

As I look deeper into Flex testing, I keep coming across little problems that are so easy to deal with in Java, but just aren't as simple as you might think in Flex.

One of these problems is testing chunks of code that call off to live services. There are two bits of technology that make this easy in Java and that's mock objects and Inversion of Control (IoC) for dependency injection. Flex doesn't natively do either of these.

Dependency injection is available via a couple of IoC frameworks that are available for Flex. Mock object frameworks don't seem to exist yet for ActionScript, which is a shame. So, what do you do?

This is part 2 of an article about testing Flex and integrating Flex into a continuous integration environment so it's worth reading part 1 first.

FlexUnit in Ant

Once you've written your unit tests for your Flex project, how are you going to run them? Sure, you can just fire up the test runner that I wrote about before, but you've got to remember to run it and actually look at the green/red bar to know if things are going wrong. Ideally you'd get your unit tests to run as part of your build so that you get the advantages of continuous integration.

With this in mind, I took a look at Peter Martin's FlexAntTask which allows you to run your FlexUnit tests from within an Ant build.

I wrote recently about a project where we had to put a Flex front end on top of a set of SOAP web services. Most server side programmers are hopefully now pretty comfortable with unit testing their server side code using something like JUnit. However, testing Flex applications isn't quite as mature yet and with a lot of Flex developers coming from backgrounds where unit testing isn't so ingrained, there isn't that much written about it.

There are three major different aspects of testing a Flex app that you might want to do.

1. Unit testing: Testing individual bits of ActionScript such as individual classes or methods
2. Integration testing: Testing how your app is actually wired together such as do the right events trigger the right commands
3. Acceptance testing: Testing the whole app, including how it behaves in a realistic deployment environment

These are ordered in terms of simplicity. Unit testing as hopefully I will show is pretty simple, but things get a lot trickier when it comes to Integration and Acceptance testing, so I'll leave those for another article...hopefully by someone else :)

Unit testing thankfully is also a good place to start because the more unit testing you do, the less integration and acceptance tests you are likely to have to write.

This is a continuation of my previous blog entry, so check out part 1 if you want to read about how to expose your Spring objects as SOAP services using XFire.

Now that we have a working SOAP web service, we can some Flex code to talk to it. In most of the documentation you'll find, people suggest using the WSDL import wizard functionality that comes with FlexBuilder3 to auto generate a bunch of boilerplate code. When I started on this project, some SOAP integration at the Flex side of things had already begun and they had indeed used this method. It gets you up to speed quite quickly, but it is very black box and incredibly verbose with the amount of ActionScript it generates.

We recently took on a project at Black Pepper which required a Flex front end that talked to a server with all of the business logic and data.

Our set of technologies for the server side was this:

• Java 5
• XFire for exposing SOAP service
• Spring Framework to wire it all together
• Hibernate for persistence
• MySql as our database
• Eclipse as our IDE of choice
• Linux or Mac desktops

So, pretty much our usual setup that we've done a load of times, except for the XFire part which was new...and the focus of this blog entry.