Automatic Parameter Binding to Post Variables in Yii2

I've been working a lot with the alpha of Yii2 recently and have been loving it, but have run into a few issues. I'm going to try to post them here as a help to those of you who may have the same issues down the line.

Automatic Parameter Binding

What is automatic parameter binding? If you read the Yii 1.1 guide to Controllers, you'll see that if you define an action with a parameter of $id, and then add a querystring of ?id=1 to your request, that parameter will automatically be bound to the $id parameter. It's a nice convenience. For some reason, Yii2 only automatically binds GET variables, not POST. I wanted restrict certain actions to POST verbs and pass data through and have it be automatically be bound. But it only binds GET vars. Dang.

Fixing It.

It's super easy, actually. All you have to do is intercept the runAction method in your controller of choice and do a little tweaking. Here's the code: 

public function runAction($id, $params=array()){
    $params = array_merge($_POST, $params);
    parent::runAction($id, $params);
}

You can either add this to your particular controller that you'd like to automatically bind POST vars to, or you can create a base controller and extend all your other controllers off of that.

Happy coding. 

Encrypting and Encoding Information in URLs with PHP

Necessity

 You can skip down to "Guidelines" if you don't care why I needed encrypted URLs. Similarly, if you only care about the code, you can get it on github here.

Mantis is coming along at a pretty slow pace, partially because we have a stakeholder problem. What I mean to say is that the business owners (who decide to use Mantis) really want the information and the accuracy that comes with it. The workers, however, don't want to be bothered to keep their time, they'd rather just continue guesstimating. And in many cases the person that's in Mantis day-to-day is not the business owner but more of an office admin, and therefore has less invested in ensuring that the workers stay compliant.

Bosses want it, workers can't be bothered, admins don't care so much.

We're trying a few different things to address this issue, one of which is delivering daily reports to the business owner detailing yesterday's hours worked, payroll, etc. Push the information to them and get them addicted, right? I remembered reading Thomas Fuchs's write-up about how they did this for their time-tracking tool for freelancers, Freckle. I decided to take the same route for Mantis. We are going to be sending them daily charts as images and needed a way to store secure information in the URL as opposed to the database. Thomas open sourced his code for how he did it in Ruby but since Mantis is PHP, I set off to port it over (not knowing any Ruby, mind you). It was an exercise partially for utility, and partially just to learn a thing or two.

Guidelines

I wanted basically the same thing out of my URLs that Thomas and Amy had for Freckle:

• clean: only alphanumeric characters. Looks prettier that way.
• no vowels: prevents curse words that can get caught in spam filters.
• Securely encrypted.

Let the Porty Begin

The first thing I needed to do was set up my table of allowable characters, which are the letters a-z with no vowels, and digits 0-9. This leaves us with exactly 32 characters, which is perfect for what we'll need later down the road. Below is the code used to set up the "table". Vowels are now numbers, extra numbers go at the end.

static $table = "1bcd2fgh3jklmn4pqrstAvwxyz567890";

These are the characters from which we'll be forming our "pretty URL". That's the easy part, the tricky part is condensing a character set that is much larger than 32 (the encrypted string) down to a mere 32 characters. Please note that I'll be mostly covering the encoding, as opposed to the encrypting. You can read lots of better, more in-depth articles about encryption.

Fiddling with Bits

Here's where it actually gets fun. (Yes, truly.) Once I wrapped my head around the basic premise, it actually makes a lot of sense and is particularly clever. Hats off to Thomas. We're going to loop through our string, character by character and do the following:

• convert the character to it's ASCII representation (a base 10 digit)
• convert the base 10 digit into its binary representation (0's and 1's) 
• pad the binary representation with 0's, ensuring it's length is exactly 8
• shove this 8 character string of 1's and 0's on the end of a master string
• go to the next character

Now when we're done, we're left with a master string of 1's and 0's that is 8*[Length of String To Encode] characters long. Put another way: 8 bits for every character in your original string. 

Below is me doing my best to figure out what *exactly* I was trying to accomplish. Pseudo-code is often very helpful. I suggest you try to understand the concept as well, as it's exceedingly interesting.

Trying to think. It's hard sometimes. 

Hang On, Friend.

You may be asking yourself at this point: WTF, why are you not using proper integers to keep track of all those bits? You should be bit shifting and generally doing a better job. Fair point. Unfortunately, PHP has a max integer value of either 2 billion or 9E18, depending on your version of PHP and your OS. (Ruby, seemingly, has no limit.) Either way, both of those values are quite restrictive when you're no longer using the bits to keep track of numbers, as we're not. And therein lies the rub. While it may seem obscene to using a string to keep track of "bits", that's what has to be done, as far as I can tell.

Suggestions welcome.

The Magic of 31

Remember when I said, regarding our allowable characters, that 32 was the perfect number? That's because 31 is the highest number that can be represented in 5 bits (0b11111 = 31), meaning that we can fit 32 distinct numbers into 5 bits (0-31). What this means for us, practically, is that we are now going to take that long string of bits, originally 8 per character, and chop them up into 5 bit chunks. Then we'll convert those 5 bits *back* into a decimal, knowing that it has to result in a number between 0 and 31. After we have it as a base 10 digit (a decimal), we simply go to our table and pick the character that lies at that index. If the decimal is "0", we select the 0th element from our table: "1". If our decimal is "1", then we select the 1st element from our table: "b". (Recalling, of course, that arrays are 0-based, meaning that the first element has an index of 0. The second, 1. Etc.)

Perhaps a picture would help. The example below assumes we are encoding a string "abcde", which yields the encoded string "mfrggzdf". Pretty neat.

You Cheated

It's true, my example is contrived. I picked a string that was exactly five characters long, such that 5 (characters) * 8 (bits) = 40. Forty is a great number because it can be split evenly into 8 chunks of 5 or 5 chunks of 8. What if your string is *six* characters long, leaving you with a 48 bit string, a number not evenly divisible by 5? Simple, we just pad it to the right with 0's until we reach 50, a number that is happily divisible by 5. When we decode, we work from left to right and the extraneous 0's are simply ignored. Bingo.

The Last Little Bit (Pun Intended)

Now you know how to use PHP to encode information in URLs. You can use this to encode insensitive information, or encrypt *and* encode sensitive information. (This would be a great way to generate URLs with an expiry date, for example.) It would be beneficial to be reminded that URLs should generally not exceed 2,000 characters. Since every 5 bits is converted to 8 bits, we can calculate our overhead factor to be 1.6x, meaning that our new string is 1.6 times as long as our old string (8 bits/5 bits = 1.6). 

I'm always happy to accept pull requests if you can improve upon what I've done here. This was a great learning experience for me and I'm under no delusions that the code is perfect.

Github repo: https://github.com/aarondfrancis/URLcrypt 

Remaking the Cellphone Game Snake, in Microsoft Excel

Video

Surely you remember that old cell phone game, "Snake"? The one where you had to eat the apples but not run into yourself? Gah, that game was a blast, and I spent a ton of time playing it in my younger years. It'd been a while since I had played, so I thought I would remake it in Excel. You know.. for fun.

History

I used to work at an accounting firm , so I spent a lot of time in Excel. I picked up a book about programming VBA for Excel, because it really helped me do my job much better. (As a sidenote: learn to code not to know how to code, but so you can use it to accomplish some other thing. I love coding, but I love *doing things* with code more.)

I was at a training event for the firm once, and on the flight home rather than watching TV or playing a game, I thought I'd try to make Snake in Excel.  

It's Alive!

It seemed like a good idea, just because the old cell phone screens were so grid based, and Excel is the same way. Why not just use cells as giant "pixels" and use them draw the game? So that's what I did. The first thing the game does is resize the columns and rows to make cells squares. Then it draws up the borders, drops in a snake and an apple, and you're off to the races. I had to import a few libraries to get it working, the main one is the timer library that allows the program to "run". Each time the timer ticks, it moves the snake in whichever direction it's going and see if it has collided with anything.

The snake, the apple, and the walls are simply cells that are formatted in different, defined ways. Every time the snake moves, it checks to see if it hit an apple, if so, it shows the apple moving through the snake's body and then extends the snake by one cell. If it's a wall, the borders all turn red, and you're dead.

Levels

After a while, the main level gets boh-ring. It is just a box after all.  So why don't we mix it up?

Like the walls, the snake, and the apple, the walls are just another cell that has been formatted in a certain way. The "apple" algorithm will place the apple randomly in the cage, but never on the walls. That would be frustrating, huh. But how do you make levels? Easy, I made a way for you. 

With the level editor, all you really have to know how to do is use the "Format Painter." You can add rows and columns to make the level wider or taller and then use the format painter to add walls. To place the snake, you just put an "X" in the cell you want the head to be in and choose the starting direction. (Make sure you leave enough room for the snake's body!)

You can share and import levels too, right from the front-end, no coding required. 

If you want to get really funky, you can look at the "Levels" sheet to see how all that data is stored.

Scores

The scoring is weighted based on your chosen speed, and the "softness" of the walls you choose. I used a formula to determine the points-per-apple: 

Score = ApplesEaten * (1 + (Speed-3)*.3 + (3-Forgiveness)*.2)

If you set the speed and forgiveness factors to 3, apples will be worth 1 point each. If you turn the speed all the way up and the forgiveness all the way down, you'll get a value of 2 points per apple.  The speed is weighted more heavily than the forgiveness, so crank up that speed and soften up those walls.

Updates

Every time you open the workbook, it will check for a text file on Amazon's S3 that has a version number and the URL to the latest workbook, should I ever update the thing. 

Download

You can find the workbook at https://s3.amazonaws.com/aaronfrancis/snake/snake.xlsm. The code is wide open so feel free to look at it and offer any suggestions! I will probably put it on GitHub before too long. 

Need Help?

Are you trying to write macros that actually accomplish business needs, rather than ones that waste time? I could help with that too. Reach out for my availability for your project! 

Using MySQL Triggers To Ensure Immutability

Thank goodness.

Developers are not always database admins, and database admins are not always developers; bootstrappers often have to be both. As we're building products, we're writing the code and designing the database, hopping back and forth between the two. It's fairly often that we just use the tool we know to accomplish the purpose, rather than using the optimal tool. Sure, you can pound a nail in with a set of vice grips, but wouldn't a hammer make more sense?

Let's talk about databases.

Solving it With Yii

In building the invoicing piece of Mantis, I've created a "user status history" table that keeps track of when employees change plans, are no longer employed, or are no longer hourly workers (therefore are not billed). Anytime an employee's attributes change, a new record is created in the status history table that shows all the employee's current attributes and the old record is completed by inserting the end time of the previous plan.

Take a look at the picture below to get a better understanding. 

The employee's current state is always the record with the NULL value in the `to` field, indicating that that state has not yet come to an end. Employee #1 went from hourly to non-hourly (records 1&2). Employee #6 went from active to inactive (records 5&10).

I use this data to build my invoices. If an employee got let go (went inactive) halfway through the month, I'm not going to charge them for a whole month, so I need to know when they went inactive. Because this is a historical table that I'll be basing invoicing on, I want to ensure that this data can *never* change.

My first thought was to copy the data over to another table that would separate the data from the status history table and put it in a different table that is only used to run invoices. That may seem like an OK solution, but it's not. You really shouldn't ever be duplicating data in your database. 

I kept trying to think up a way to solve the problem with Yii, because that was the hammer that I had, the one that I use every day. The solution really lies in the database itself, below the application altogether. I needed to get some advice from someone who really knows databases, so I called my Dad. He's been doing this stuff for years.

Enter: Triggers

My dad educated me about Triggers in MySQL. Triggers are like hooks that allow you to execute logic based on events, a lot like Yii has "before" and "after" filters.  These triggers allow you to keep some basic data integrity logic out of your application layer and put that burden on the database, keeping your code uncluttered and your data safe. Let me show you the SQL and then I'll walk you through it.

DELIMITER $$

CREATE TRIGGER lock_down BEFORE UPDATE ON tbl_user_status_history 
    FOR EACH ROW BEGIN
        IF old.to IS NOT NULL THEN
            SIGNAL SQLSTATE '45000'
                SET MESSAGE_TEXT = 'RECORD IS LOCKED, CANNOT UPDATE';
        END IF;
        
        IF (old.id != new.id OR
            old.user_id != new.user_id OR
            old.from != new.from OR
            old.hourly != new.hourly OR                                 
            old.active != new.active OR                                 
            old.plan != new.plan) THEN
            SIGNAL SQLSTATE '45000'
                SET MESSAGE_TEXT = 'CANNOT CHANGE RECORD VALUES';
        END IF; 
    END$$

CREATE TRIGGER no_delete BEFORE DELETE on tbl_user_status_history
    FOR EACH ROW BEGIN
        SIGNAL SQLSTATE '45000'
            SET MESSAGE_TEXT = 'CANNOT DELETE RECORD';
    END$$

DELIMITER ;

The first thing this does is set the delimiter to "$$" so we can safely use the semicolon elsewhere. We set it back to the semicolon at the end. 

The create trigger syntax is pretty straightforward: you give the trigger a name, declare the event that the trigger is based on, the table, and then the body of the trigger. In my case I've name my first trigger "lock_down", the action is "BEFORE UPDATE", and the table is "tbl_user_status_history". Now: the body. The body of the statement starts checking if the old `to` field was NULL before the update. If the old `to` field was not NULL, that means that record should be set in stone, so we throw an error by using the SIGNAL statement. So now we've taken care of the instance when the record has been completed, it can't be changed. 

Another case we need to worry about is when the `to` field IS NULL, we need to make sure that only the `to` field can be updated. We don't want the status to be changed once it has been set, we just want to be able to close out that particular row. That's what the second IF statement does: it compares every old value to every new value (except the `to` field, obviously) and if any of them don't match, we throw an error. This way, any value change creates an error, but you are allowed to update the `to` field.

The second trigger we need to create is a trigger that makes sure you can't delete a row. This is our BEFORE DELETE trigger, and it's super simple. We just throw an error, every time. Pretty simple.

---

Now our history records are truly historical records: they cannot change. I'm confident that I can calculate an invoice upon these records and the invoices will always be the same. This keeps our PHP code nice and clean, leaving it up to the DB engine to enforce these (extremely important) rules. It also gives us a sense of security, knowing that no matter what happens, these records will always be correct.

Yii and the Asset Pipeline: Part 2

A while back, I wrote a post called Yii, Heroku, and the Asset Pipeline where I tried to come up with a reasonable way to manage publishing assets with Yii on Heroku. (Note, this applies not only to Heroku, but to any host that runs on top of Amazon EC2, or Amazon EC2 itself.) What I came up with in that first post worked decently well. I had a system that would allow me to work locally with files that were always up to date and then change a version number and publish them all for my staging and production environments. There were still problems though, things that totally bugged me.

The Problems

Let me quickly rehash the problems with the basic Yii pipeline, as far as I'm concerned, and then I'll talk about the problems with the system I was using up until yesterday. 

Problems With Yii's Pipeline

The problem with the Yii asset pipeine is not really Yii's fault, but stems from the fact that Yii wasn't built with an ephemeral filesystem host in mind. The problem we run into is that an ephemeral filesystem will occasionally blow away your assets, because the filesystem can't be trusted to persist. This pushes us to an external static asset store, like Amazon S3. This, it turns out, is a good thing. Cookieless domains reduce overhead and decrease page load times. My first system fixed those problems, but it had problems of its own. 

Problems With My (First) Solution

So. much. manual. labor. 

My fist solution was far from perfect. What I hated about it most was that it left me with a lot of manual processes (which means a lot of potential mistakes) and a subpar experience for my users. 

When it came time to publish, I had to manually combine and minify all my CSS and JS. More than one time I forgot to do that. More than forgetting to do it a couple times, the painful part was having to do it every time I made a small CSS tweak. I looked at a few minifiers that minify on the fly, but I was never really that comfortable with the way they worked. I wanted everything to be done locally and not have that load placed on the server to do the minifying.

The other problem with my system was mass versioning. Any time I tweaked a CSS file or added a bit of JS code, every asset got invalidated when I incremented my version number. Way less than ideal for my end users who have their caches all invalidated when the assets go up a version. That's what I set out to fix with the Mantis Asset Manager. 

The Solution: The Mantis Manager - Overview

If you're wondering where the Mantis Manager name comes from, it's from the SaaS app I'm building for timecard management for small businesses: Mantis. I built the Manager specifically for Mantis, to hopefully solve my asset issue once and for all. (And I think I have!)

You can get all the code and a pretty technical explanation of the Mantis Manager over at the github repo: https://github.com/aarondfrancis/mantis-manager. I'll give an overview here.

The Good Stuff

Let me just first say what the Mantis Manager gets you, and then I'll tell you more about it. The Mantis Manager combines, minifies, and publishes assets based on the SHA of their contents, publishing only files that have changed. It gives you a way to work locally and remotely without muddying the waters between the two. Here's the money shot:

Look how awesome that is. Mantis is happily and automatically looping through my assets folder checking files, ignoring stuff, minifying, updating, and publishing. This is the result, let's talk about the process. 

The Two Types of Assets

In my mind, Yii has two types of assets. The first type is our  assets. The assets we use to build our sites, the CSS we write, the images we need, and the Javascript we code. This means that the second type is, obviously, not our assets. These are the Yii JS files, component CSS/JS files, or extension files. These are assets that our sites use, but we don't write or maintain. We are going to treat these two sets of assets differently, because they are indeed quite different. 

With our assets, they are likely to change fairly often as we build. When we build a new feature or fix a bug, it's likely that some of our assets are going to change. This is totally different with other people's assets , they are not likely to change. How often do the Yii JS files change? Hardly ever. Only when we update the Yii framework, I would suspect. So almost never. We'll treat these assets differently then. For our assets, we'll use the Mantis Manger, for other people's assets, we'll rely on the traditional publish() call. We'll need the two systems to work happily together.

One of my many pages of possible solutions.

The Solution: Details

SHAs

Let's take a look at how I managed to solve the problem. The first thing I wanted to do was to publish only  changed assets. I looked at using the modified time of the file, but I found that to be less reliable than I'd like. There are times when the modified time could change, but the contents haven't changed at all. I settled on using PHP's sha1_file() function that digests the file and spits out a 20 character string. This seemed to be the best method of ensuring that a file has changed.

Before I can go all SHA crazy on the files, I need a list of files. I like to store my files in  "protected/assets" because it isn't web accessible, which means I get to explicitly determine what gets published and what doesn't. If you look at the code on GitHub, you can see that this is a configurable option.

Now that Mantis knows where to look, it'll loop through every file in that folder and do it's thing. You can see from the photo above that some files are ignored; you can set ignore patterns in the config. As it loops through, it calculates the SHA of each file and stores the list in an array. When you run the command a second time, you'll see that it compares the SHAs to see if anything has changed. If nothing has changed, it moves on to the next asset.

Minifying and Combining

If you'll recall, something else I wanted was automatic minifying and combining of files so I only had to serve one file of each type rather than several. Mantis takes care of this by leveraging a few open source libraries: minify for CSS and JShrink for javascript. Mantis will create and published a minified version of your file, leaving your original (development) version of the file untouched and totally readable. To combine files, you simply feed Mantis an array of the files you'd like to combine and where you'd like this new file to be created, and the Mantis Manager will take care of the rest.

Busting Cache

It's a best practice to have a CDN sit in front of your asset server so that your assets are as close to your end users as possible, cached and ready to go. You could use Cloudfront to sit in front of your S3 bucket. With that comes a problem though, it could take a few hours to have asset updates pushed through to every node of the CDN. The best way to do this is to just change the URL of the requested asset altogether. The MM does this by sticking a version in the front of the path, your image could end up having assets/2/d4k8d33/image.png as its path, for example. That 2 represents the version it's currently on. That way the freshest possible version of each asset is being served, but we're not serving new versions of assets that haven't changed.

Referencing Assets In CSS

Having explained that, you may be thinking: "How can I reference my images from my CSS if all the assets' paths are constantly changing?". Good question. You can't just say ../images/image.png in your CSS, because you have no idea where that image is actually going to end up. Definitely not in the folder you think it's going to end up in, that's for sure. In your CSS, you can simply include this template {{asset("/images/image.png")}} and the MM will take care of the rest. Part of the processing loop is to look through the CSS files and replace references to assets with their current versions.

Referencing Assets in Yii

I've created a modified version of the standard CController that all my controllers inherit from that has an asset() method that you can call to get the appropriate reference to an asset. When you are in a view, you simply call $this->asset("/original/path/to/image.png")  and Mantis will return the appropriate URL for the latest version of that asset.

Local vs Remote

You aren't going to want to be publishing to S3 for every little development change you make, so there is an option on the mantis command to specify local or remote. (local is default)

$ ./yiic mantis --type=local
$ ./yiic mantis --type=remote

Local and remote keep their own separate caches with the SHAs, so you can publish 100 times locally and then run publish once to remote and all the files will be compared to the last time you published to remote. The local publish makes use of the standard Yii CAssetManager, while the remote publish relies on a heavily modified version of the S3AssetManager.

Post->end()

The Mantis Manager took me a couple days to write, I don't anticipate it should take you that long to implement, but I will warn you: This is not a drop-in replacement for any AssetManager class you are already using, it is much more integrated than that. There are likely things I haven't covered here that may be important, feel free to reach out or raise an issue over on the GitHub repo. I'm happy to do what I can.

If nothing else, I hope you can at least use pieces of my code to implement your own smart asset manager. 

The only thing I'd still like to do is integrate this into a pre-commit git hook, so that before I push code to my staging/production sites, all my assets are ensured to be up to date.

I'll save that for another day though!

My Aperture Backup Strategy

Something like this.

I had a bad experience when I was a kid. I was taking apart my computer to heat-shrink the cables, like all 14 year olds do.  I had taken the plastic end cap off of the hard drive power cable and was extremely careful to keep the cables in the correct order. What I wasn't careful about, however, was the orientation of the plastic cap. I put it back on upside down, reversing the order of the cables. When I plugged the cable back in to the drive 12V was sent to the board instead of the 5V it expected and the drive started smoking. I tried everything to get the data back, including expensive data recovery. All to no avail. Not a good day, I had permanently lost a lot of photos and projects. From then on, I've had a pretty extensive backup strategy that has saved me several times. 

I'm going to talk mainly about how I back up my Aperture photos, because it's a huge amount of data and they are extremely important to me.

Reference or Manage?

In Aperture you have two options when it comes to dealing with your images, you can either let Aperture manage them, or you can reference them off your hard drive. I much prefer the latter. With referenced images, you have full control over the directory structure of your master images and it makes it a lot easier to do your backups. 

First Level - Online Backup

I store all of my originals on an external hard drive that is attached to my iMac. When I first import my photos, I store them on my local drive in an "Aperture Holding" folder. I use cloud backup service Backblaze to backup my computer to the cloud. Backblaze is great because they offer unlimited backup for five bucks. Including external drives! I've got a couple of terabytes in their cloud. Thanks for all the space Backblaze!

If I ever lose any of my photos, I can login to Backblaze, hit restore, and bring down a zip. Because photos can be so big, that's not an ideal solution for restoring a whole library, but it has saved my hide in scenarios where I realize I've accidentally deleted some photos. You'd think I'd learn.

Second Level - Physical Media

Here's where it gets interesting. The second level of backup I have is DVDs. Good ol' optical media. One of the glorious, life-saving features of my optical media strategy is that failures can't cascade. I had an instance where some of my photos got corrupted and Backblaze happily backed them up (as it should have), but suddenly that backup was useless. The DVDs, however, were sitting in my closet, unaware that they should be corrupted. I popped in the matching DVD and overwrote the corrupted files and everything went back to normal.

The key to backing up to physical media is having a system. And boy do I have a system. I make use of Aperture tags, Applescript, Automator, and a little bit of bash. You can totally implement it too though. Let's take a look.

The "Not Backed Up" Album

After a photo is backed up, it is tagged with the "DVD" tag. That way I have a smart album that simply selects every photo that isn't tagged with "DVD". I know that those photos are in mortal danger and need to be backed up pretty soon. But as a geek, there's no way I'm going to do that manually every time. So how do the photos get backed up and tagged with "DVD"? Enter Automator.

Automator

Automator is an extremely powerful, underused Apple program. It allows you to automate a wide number of programs so that you don't have to repeat actions. The first automator action I use is really just an Applescript that tells you the size of all the images you have selected. The way I use this is to go into my @Not Backed Up Album and select a bunch of images, click the "Calculate Size of Selected Items" service, and try to get as close to 4 gigabytes as possible. (DVDs hold 4.6 Gb of data, I like to leave a little wiggle room, just in case.) Once I get around the 4Gb mark, I've got my selected set of images for the new DVD backup.

With all of those images selected (that total to ~4Gb).  I select the "Burn Masters to DVD" service and sit back and marvel at the power of Automator. (You can download the automator actions here: https://s3.amazonaws.com/aaronfrancis/aperture-workflows/workflows.zip. Place them in your Users > YourName > Library > Services folder.) Below is a photo of the main action. Don't freak out, we'll go over it.

Whew. Ok. Right off the bat, it's going to ask you to make sure a DVD is inserted. Everything will go horribly wrong if you try to burn a DVD when no DVD is inserted. The next thing it does is reads the value out of a file. This is just a simple text file with a single number in it. You'll need to create a .txt file and put the number 1 in it. That's all.

Once you've done this, change the reference in step two to the path of your new text file, not mine. The Applescript will read that variable and add enough zeros to make it a three character string, like "001" or "010" and then pass it to the variable "Name". This is going to be the name of your DVD and your backup tag.

The next couple of steps takes all the selected images and exports the masters to a folder that you designate, getting ready to burn them to a disk. There's an action called "Get Folder Contents" that takes all the items from that Temporary folder and passes them to the "Burn a Disc" action that actually does the burning. Once the disc is burned, we throw away the temporary folder (the masters still exist, it's the temp folder that is now gone) and eject the disk.

The last thing we need to do is tag all those images with "DVD" and the backup number in Aperture. The Applescript will go through and tag them all for you. In addition to the number (from number.txt) it will look for a file called letter.txt and put that at the front, so make sure you create a letter.txt file and update the reference to the location of that file. I just put "A" in my file, you can put anything you want. You can put "backup-" and the tag will come out to be "backup-001". Mine are "A001, A002, ....". That's just my system though. If I ever get to 999 I'll change the letter.txt to "B" and update number.txt to "1". Unlikely to ever happen though!

Once the tags are finished, a (hacky) shell script tries to increment the number in the file by one, getting you ready for your next burn. (There is probably a wayyy cleaner script for that part, but hey, it works!)

Should Something Go Wrong

I've found that sometimes the tagging part can fail, so I made another action that just does the tagging, should it fail. Don't deselect the photos until it's done so you can ensure that you can just hit the "Tag Selected With Backup #" action.  Once you deselect the photos, they'll disappear from the @Not Backed Up folder, leaving you with any other photos that need to run through the system.

The Discs

I write the name of the backup ("A029") and then the date on the disc. I buy the discs by the 100 and store them on the spools that they originally come on. I take one off the top, burn it, write on it and then put it on the bottom of the stack. Easy enough. 

Every single photo in my Aperture library is tagged with "DVD" and "A0XX". Every photo I look at, I know there is a corresponding DVD in my closet with a copy of the photo.

Third Level - Classic Backup

For the third level, I use a classic backup strategy of just replicating my external drive to another external drive. You could use time machine or any other number of back up tools like that. This is probably (definitely) the least interesting, so I won't really talk about it. 

Am I Crazy?

Maybe. But hey, I had a bad experience. Eventually you will lose something too, it will happen. I guess I'm lucky that I lost stuff at 14 when I had no kids, no serious professional work, or any client data. What about you? What important things do you have and how do you ensure they'll never disappear? You do ensure that, right?