Technical

Time Machine Backup Lessons

Last week, I came home and noticed a really loud clicking noise coming from my MacBook. That’s never a good sound, particularly when you aren’t actively using it. The hard drive was toast.

While I wasn’t completely thrilled, I figured I would at least find out how well my backup strategy worked.  I use Time Machine for my home computers and have apparently been completing their tasks successfully.  However, I had never tried to restore from it before.

While I am now back up and running, I did learn about a few problems with my backup strategy that didn’t work seamlessly which I will pass on along with things that did work.

Perform Regular Backups

This is a no brainer, right? If you don’t backup routinely, you’ll lose data.  The aspect of this I never really thought much about is that psychologically, you will be most concerned about the data you were working with most recently. This also happens to be the stuff you will lose if you don’t regularly backup.  For me, this is the best part about Time Machine.  When it is enabled, you get hourly backups and you can’t configure it with any other frequency. Until you have a failure, this may seem overkill. When the failure happens, you will be very happy about this feature.

Make Offline Storage Part Of Your Backup

While your computer is down for the count and in need of restoration, you may need access to certain documents while this is occurring. Dropbox is a great solution for this and they offer 2 GB free storage. This amount of space is typically enough for document syncing. It also doubles as a convenient way to use these documents any time you are away from your computer.  A bonus is that since you get a chance to utilize your synced content before a failure happens, you can feel more confident that restoration will work.

Do NOT exclude your iTunes Library Files From Your Backup

If you have chosen to exclude your media from backup because you have stored it elsewhere such as a network share, etc. make sure to backup your iTunes library files. I made this mistake while choosing to exclude my Music folder from my backup and found out the hard way that this also means your iPod can’t sync files back to your library.  Apart from the hassle of re-importing the files, you lose playlists, ratings and more.  Further, if you exclude like I did, you may  lose apps you have as well.

Exclude VM’s From Backup

When configuring Time Machine, you have the option of excluding files from the backup. You might do this if you have a different backup strategy for certain files, and in the case of virtual machine disks, you really want a different strategy. Time Machine will determine if a file needs backed up based on modification date. Since virtual machine disks modify this date at every use and they are in the many-gigs size category, they would quickly fill your hard drive, unless of course you never used them.

Include System Files In Your Backup

I had read in some  articles the notion that it made sense to exclude these from your Time Machine backup, and I did. The idea was that you would save space because you had the installation disks. Big mistake. Firstly, relative to everything else they don’t take up that much space. Secondly, if you don’t back these up, you lose out on a very nice feature of the Leopard/Snow Leopard installation process, which is to restore from a Time Machine backup.  As it was, I needed to go through the installation process and then do my restore, which takes longer and is more manually involved.

It’s OK to Backup iPhoto/Aperture Libraries

Due to the same reasoning about backing up VM’s, one might be led to think that a large iPhoto library or Aperture library might not be a good idea to backup since they end up being large over time and change frequently for the typical user. While these look like very large single files to you in Finder, they are actually bundles. This means they may be expanded by you for examination and Time Machine does this too. The result is that it makes incremental updates within the bundle.

Secondary Backup For Important Stuff

When faced with a hard drive failure, you really reflect on what files are important. This is the stuff you should have a second copy of — just in case.  Redundant hard drives and optical are fine for this, but I found that while I was re-installing things, I considered how if a fire or theft occurred, I would need something offsite.

There are many offsite backup options such as Mozy, Carbonite, JungleDisk and DropBox that I suppose fill this purpose.

For me, the big thing is photos. I store my photos on SmugMug that offers unlimited storage with their plan. Unlike the other solutions, this is geared also for photo sharing, so the bonus is that I get some value out of it even before using it to restore photos.

If interested, use this code for $5  off at SmugMug: Z072MKPtbXNgA.

In short

  • Time Machine works wonderfully well — don’t try to over think it to save disk space. Using the default settings would have worked much better for me.
  • Complement your local backups with remote storage for immediate access and redundancy.

Floating Field Fun

Floating fields in Adobe LiveCycle Designer allow you to create text in a form that contains variables such that the text wraps around these variables according to the length of the variable text. Using them is mostly straightforward in situations where they aren’t expected to change as a result of form interactions. If you do, however, the solution is less obvious.

The examples shown below were done in Adobe LiveCycle Designer 8.2.

The Scenario

  1. We have a ‘legal’ document that is created, as in a LiveCycle process, that contains boilerplate text which is a combination of static and dynamic information like the user’s name and a corporate name.
  2. We’d like the boilerplate text to dynamically size itself around the dynamic portions to account for different length names.
  3. We also have a few editable fields in another portion of the form, which also includes the users name. If a user needs to modify their name, we’d like the boilerplate text to update itself as well. One of our customers might be Prince, as in ‘The Artist Formerly Known As Prince’.  We honestly don’t know what his legal name is at any given time, so we’ll allow him to change this as needed.

These aren’t unusual requirements, nor do they seem at first glance difficult to achieve.

  1. If the floating field hasn’t already been created, we’ll do that first in the appropriate location of the form. No problem.

    Floating Field Creation

    Floating Field Creation

  2. Next, we’ll add some JavaScript to the initalize event of this floating field(‘floatName1′) and set its value to that of the matching field that has been merged. No problem.
    this.rawValue = subMatchingField.txtName.rawValue;
  3. We’ll define the value for the corporate name as a script element on the form itself. No problem.

    Storing a variable in a script object

    Storing a variable in a script object

  4. Now, let’s test that if the user updates the editable field, the floating field would update as well. Problem. Changing the Name from ‘Prince’ to ‘Prince Rogers Nelson’ did not also update the boilerplate text.

    Changing the name does not update the floating field

    Changing the name does not update the floating field

Once the form is rendered in the client( Reader, Acrobat, etc.), some trickery is required if we need modify a floting field in conjunction with an interactive event.

How do we do this?

There are at least 2 different ways I have discovered:

1.Force a Form Re-layout

Below, is the same script we had used in step 4 above. Only now, we are invoking xfa.layout.relayout() prior to updating the field. This forces the form to go through the layout process again, and will now be able to adjust the floating field.

xfa.layout.relayout();
subBoilerPlate.floatName1.rawValue = subMatchingField.txtName.rawValue;

2. Modify the floating field on the layout:ready event

While this works, I can’t recommend this approach several reasons.

  • Firstly, the event fires quite often when working with an interactive form, so this script will be executed quite often, not just when the specific field in question is updated. Recall that the layout:ready event fires as a result of any ‘substantial’ changes on the entire form, not just the field we have attached the script to.
  • Secondly, I discovered something quite interesting that I don’t know if it is a feature or a bug.  In either case, I don’t quite understand it, so can’t recommend it. It turns out that setting the value of the floating field to equal the matching name field on the layout:ready event instead of the initialize event doesn’t work for the reasons I thought it would .  In fact, if I leave my script to fire on the initialize event of the floating field and then add even something as trivial as a commented line of code in the layout:ready event on any field, the floating field will again update as we want it to.  It’s as though just going through the effort of trying to interpret any script during the layout:ready event is enough time to allow the update to happen.  To me, that doesn’t feel trustworthy. If anyone can explain this better, please leave a comment.

Summary / Sample

The attached XDP file below demonstrates the situation described above and how we might address it.

For ease of demonstration, I have two buttons on the form to attempt to trigger the update in the boilerplate text section as well as to update another text field. This allows you to see how the floating field behaves differently. In a real world scenario, you might actually see the script on the exit event of the field ‘txName’.

The first button will attempt to to the update without using xfa.layout.relayout() whereas the second button does.

Hope this helps — good luck!

Download Sample:  Floating Field