Mark W. Shead

I’ve been doing some work with Lucene to bring search capabilities to some web applications.  So far I’ve been pretty pleased. Lucene is very powerful and reasonable simple once you know how to make it work. I’ve published a Lucene example of the MoreLikeThis functionality.  MoreLikeThis is a great way to reduce the number of duplicate entries you get in your database. I’m using it for a quotation database. When a user tries to add a new entry, Lucene uses MoreLikeThis to see if there are any similar entries.  The Lucene example shows how these other quotations are retrieved.  They are then displayed to the user so they can see if what they are typing is already in the database.

I created a simple mortgage calculator as a test application using Cloud Bees. The app itself is very simple and uses the handy TVM Java Bean to handle the mortgage calculations.  It doesn’t do much at this point, but the main thing I was testing was the deployment process at Cloud Bees. It turns out it is pretty slick.  The mvn bees:deploy will pushes the mortgage calculator app to the application servers.  It does this using a delta so you don’t have to re-upload all of the files each time you make a change.  The maven plugin works well and made it easy to run the mortgage calculator locally for testing and fast to deploy to the server.

Cloud Bees also makes it easy to use your own domain name, so I used www.mortgage-calculator-plus.com.  It only took about 5 minutes to get the domain pointed to the server and running correctly. I didn’t see anyway to handle HTTPS.  This isn’t an issue for my mortgage calculator, but could be a much bigger deal for some of the other services I’d like to try to run on Cloud Bees.

You don’t really understand something until you can explain it to someone else.  I took some time this weekend to try to explain finite state machines.  I’m very grateful to the Reddit community for all their help editing and pointing out things that could be made more clear.

This demo shows what you can do with 10 minutes of programming in Tapestry 5.  It shows a web application built from the ground up to allow submission of links/title that users can vote on.  It also incorporates some data validation and an Ajax refresh with surprisingly little code.  The source code is also available for this Tapestry demo.

I once was offered a job at a small development shop. I asked all the right questions: Were they using version control? Did they have automated testing? etc. The answers all sounded good so I accepted the offer.

My plan for the first day was to get their software product building and running on my laptop and then start looking through the version control system to see what a typical change set looked like so I’d know a bit more about what to expect when looking at the system.

They were using CVS, but after a few queries, I couldn’t find any commits that were more than just a few days old. It was as if the source had been loaded into CVS a day or two before I started work. When I asked why there wasn’t any history in CVS I heard the following horror story.

They needed a server for an onsite demonstration, so they decided to use the CVS server. They installed the software on it and shipped it out to a customer’s location for a few weeks. I guess they decided they could just hold off on updating CVS during that period.

I never got the full story about what exactly happened–just that the hard drives “crashed”. Given the RAID setup, I doubt that hardware failure was the root problem. I’m guessing that someone reformatted it.

Anyway, when they got the server back, they weren’t too worried because they could always restore from their backup. The backup ran automatically every night and backed up all of CVS’s datafiles. Unfortunately they had never tested this backup and none of them realized that if CVS is running you can’t get a backup of its files. So all of their backups were corrupted.

In the end they just copied the contents of a developers laptop back into CVS and ran with that. Unfortunately they had several very large clients with custom installations that were built from source code that was in a branch of CVS. This meant there wasn’t anyway to give them bug fixes because their source code was completely gone.

Obviously I wanted to avoid that situation again. Since their current system didn’t really have any history I suggested we change to Subversion. Everyone was fine with this because they still thought the whole fiasco was somehow the fault of CVS.

Once Subversion was installed and running, I wanted to come up with a foolproof way to back it up. Subversion has some very nice commands for dumping the repository out to a text file, but I wanted something that would guarantee that not only had it been backed up, but that the backup was good.

Here is the subversion backup plan we eventually ended up with:

1. Dump the repository to a file.
2. Zip the file and save it with the date/time in the filename.
3. Copy the zip to another server
4. Delete the unzipped file.
5. Copy the zip file back down from the server to a temp directory.
6. Unzip the file
7. Create a new repository
8. Load the dump file into the new repository
9. Checkout the trunk to a temporary directory
10. Delete the temp directories

This entire process ran as a cron job and had the quiet options enabled everywhere. If there was a problem, data would be output and I’d get an email with the error.

This SVN backup process made it very easy to guarantee that the backup process was producing didn’t have any issues, could produce a valid repository and that trunk could be checked out without any errors.

I refined the process over the years and eventually posted it as a perl script if you want to try this svn backup process.