SGMLXML.net A place for SGML and XML application developers.

I'm moving further into the cloud. The internet cloud. Wikipedia is defining Cloud computing as a style of computer "where IT-related capabilities are provided as a service".

I started with Google Docs. Storing my checkbook register (an excel spreadsheet), some Power Point presentations and some PDF white papers I always find myself looking for. I want access to these documents quickly and easily from any and all computers I might happen to have available to me even if only for a few minutes.

My move further into the cloud happened when I had to decide if I was going to put additional Network storage on my home network or lease secure disk space somewhere in the cloud. We're at 2 terabytes and climbing at home already. Some of the disks have been spinning for a few years so I wouldn't trust critical or archive data to them. Truly archiving data means having it mirrored on at least two different disks if not on a DVD as well.

I decided to roll with the Amazon S3 service instead of buying more disk that I have to maintain. Amazon S3 is a simple web service that can be used to securely retrieve any amount of data, at any time, from anywhere on the web. Amazon does not provide a front end to the S3 web service. It is intentionally built with a minimal feature set.

For a front end to the S3 service I decided to use Jungle Disk. Jungle Disk supports Linux, Max, and Windows (including Vista) platforms as well as USB sticks. It makes the Amazon S3 service appear as a network drive on your machine where you can drag and drop or copy files.

One of my major complaints with approaches like this in the past has been that passing lots of info or large files over the network takes time and can be process intensive depending on your OS (this is really the kindest way I could put this without saying Windows slows to a crawl). Jungle disk has solved this. It caches the files local on your machine and slowly feeds the bits to the S3 service as CPU and bandwidth are available (configurable). To the end user it makes the copy to the Network drive look instantaneous. The software also comes with a backup routine where you can backup selected folders. The software is 20 bucks with life time upgrades.

You pay for the Amazon S3 service monthly. The rates are reasonable. Storage is $0.15 per GB-Month of storage used. You also pay a small data transfer fee for incoming and outgoing data transfer. Amazon provides a fee calculator to figure out your approximate costs. If you think about what hard disk space costs to install and mirror (for a true archive) as well as administer, the fees keep looking better and better! I'm willing to pay for good service and zero headaches!

So what's left on my Network Storage at home? VMware images. Lots and lots of VMware images. Large files that are I/O and bandwidth intensive are not the type of thing I'm looking to store out in the cloud.....at least not yet. Next thing on my list to explore is Amazon EC2. The topic of a future post I'm sure.

-Charles

Entropy is defined as "A measure of the disorder of a system."

While entropy got it's start in thermodynamics, it applies equally well to software development. Specifically late changes to the system design or bug fixing after a release.

Theoretically if you have a small system with only a few developers and you designed your architecture well, the initial version of a system is fairly clean. No nasty patches, no hacks to keep the thing limping along. Yeah right. Either way, the original development team has probably poured their guts also know as energy into the system to create order from disarray (like the socks in your drawer).

As additional releases with new features and patches are applied to the system entropy increases. The system starts to break down. The system requires more and more developer energy just to keep it going as the patches and new features take away from some of the original elegance. What's the smart developer to do?

I advocate that certain releases of a system introduce no new features, stop attempting to fix bugs and simply get the house in order. Allow modules to be rewritten taking into account all that has been learned since the original release. In short decrease the systems entropy again.

I like the way this is summarized by Frederick Brooks, JR in "The Mythical Man-Month"

..program building is an entropy--decreasing process hence inherently metastable. Program maintenance is an entropy increasing process, and even its most skillful execution only delays the subsidence of the system into unfixable obsolescence.

Charles Angione

The 12 questions were originally developed by Joel Spolsky a former program manager at Microsoft that worked on Excel. Under each question additional observations from my experiences.

1. Do you use source control?

   If not you are out of control. Even with a single developer.

   All code, support programs, build files, help files, etc, should be put into the repository. Code should be checked-in frequently once it is in a state that it is not likely to cause problems to other developers. A private branch can be used to check-in intermediate work without affecting other developers, to be merged into the main project branch once it is in a stable state.

2. Can you make a build in one step?

   This is the only efficient way to make sure you are not introducing human error into the build.

3. Do you make daily builds?

   Computers are only too happy to work overnight. Continuous integration helps make integration weeks a non event.

4. Do you have a bug database?

   MS Excel doesn't count. Resist all attempts by the program manager to export the Bug List to Excel! Anyone (including customers) should be able to log a bug. Don't stick the bug database behind your corporate firewall. It leads to MS Excel documents.

5. Do you fix bugs before writing new code?

   Important ones anyway.

6. Do you have an up-to-date schedule?

Vacation schedules. Agree upfront that vacations are sacred. The project team should be able to do without a team member for awhile. Release schedules are also important although problematic.

The word just should NEVER enter a schedule discussion....just means it should already be done.

7. Do you have a spec?

   Not a novel. A spec may be a cocktail napkin, UML diagrams, UI Mockup whatever is useful. Define useful as someone actually reads it and comments on it!

On UML

UML gets a bad name from Use cases. All those little bubbles and stick figures. Who cares? They are really the beginning not the end. Use cases should turn into activity diagrams etc.

One of the things that I find amazing is that you can write a hundred page spec and get no comments but you can present a series of UML diagrams and get everyone to actually read them! A picture is worth a thousand words.

8. Do programmers have quite working conditions?

   Quite conditions for coding. You also need a team area for integration and testing.

9. Do you use the best tools money can buy?

   Money isn't everything but it sure helps build and infrastructure. Lots of applications don't cost money these days but hardware and infrastructure do. Don't skimp.

10. Do you have testers?

    Should be familiar with things like virtualization.

11. Do new candidates write code during their interview?

Spend time interviewing candidates. New people are disruptive.

12. Do you do hallway usability testing?

Solicit others input.

Comments (0)