I completed my final updates and testing to Validanguage version 0.9.6 last night. The impetus for this most recent release was my creation of a CakePHP helper for Validanguage, which I will post on my site for download shortly. If you're familiar with the MVC pattern for Web Applications, I wanted to create a CakePHP helper that would automatically translate the data validation rules present in one or more models into Validanguage API Comment tags to be printed in the view. Thus, data validation needs to be specified only once in the model and is automatically translated into client-side javascript code without any additional work.

In order to implement this without any loss of functionality, I had to make a couple enhancements to Validanguage in this most recent release. If anyone is using Ruby on Rails, .Net or any other MVC Web frameworks with Validanguage, I would love it if they can provide me with similar helper files for additional Web frameworks. I see this as a great way to get more people using Validanguage.

Another way I hope to increase adoption of my library is by adding optional support for javascript frameworks other than Prototype/Scriptaculous. A couple people have requested jQuery and Mootools integration, so that is definitely on my radar.

Also, a huge priority for me is to improve my documentation. I think the API Reference page is pretty sweet, but I definitely want to better integrate my existing Test Cases with my documentation and write some of the docs that are still missing for features added in 0.9.5 and 0.9.6.

Anyway, here's a detailed explanation of what's contained in the 0.9.6 release:

• New validations: validateCreditCard, validateIP, validateUSSSN, validateUSZipCode. The Credit Card validation runs a luhn checksum test to weed out fraudulent card numbers. See the API Reference page for usage details.
• New transformation: validanguage.toggle(). This function is intended for somewhat advanced users, as the object-based syntax for defining this is fairly complex. I haven't yet had time to write any documentation on this, but I did add a new validanguage.toggle() test case page which shows validanguage.toggle() in action. This transformation function is actually 3 functions in one:
  • Toggle Visibility: You can use validanguage.toggle() to hide and show other form fields or HTML elements based on the user changing a SELECT box or checking/unchecking a field. As an added bonus, form fields contained inside a region being hidden/shown are automatically disabled/enabled to ensure that validation is correctly handled on fields which are only shown under certain conditions. Also, any toggle visibility statements are automatically called on document.onload to ensure that the state of the UI will always match your declared rules.
  • Toggle Values: Allows you to set a value of form field B in response to changes in form field A. This allows you to set a hidden field to 0 or 1 based on whether or not a checkbox has been checked.
  • Dynamic Select Boxes: You can add/remove options to select box B in response to what a user chooses for Select Box A. The validanguage.toggle() test case page shows an example of setting up 3 dynamic select boxes which work in conjunction with toggling the visibility of each and the easy enabling/disabling of any associated validations.
• Added optional args to validateMinlength, validateMaxlength, validateRequired and validateRegex to let them be called directly instead of via the minlength="4", required="true", etc. shortcuts. This change was needed for the CakePHP Validanguage helper.
• Added support for .passedField and .failedField classNames. I removed the code in the default showError() function which changed a failed text field's background color to red. I replaced this with code which changes the class name on any fields which failed validations to include "failedField" (and the inverse for "passedField").  Existing class names are preserved; for example, a form field with a class of "styledTextarea" would become "styledTextarea failedField" following validation failure.
• Transformations are now always called prior to validations. Previously, they would either be called before validation or after, depending on your browser.
• API Change: validateAllFieldsOnSubmit setting renamed validateAllFieldsOnsubmit. After being screwed over time and time again by dojo's API musical chairs, it pains me to make this change, but the capitalization was inconsistent with everywhere else in the code.
• Bug fix: transformations defined with transformations="" in Comment API now work correctly.
• Bug fix: multiple validations in one string now all get called correctly.
• Bug fix: support for carriage returns inside functions in Comment API now work correctly. Previously functions defined with carriage returns in them wouldn't execute.
• Bug fix: Comments with transformations no longer overwritten by comments with validations.

That's it for this release. Head on over to the download page to snag yourself a copy.

I just finished a new 0.9.5 release of Validanguage, available for download on the download page. In addition, I finally brought the documentation up-to-date for the 0.9.4 release, primarily by creating a separate documentation page to list the Advanced Validanguage Features which were added in version 0.9.4.

It seems like my documentation is always running about one release behdind the actual code.  I wish I could say I'm gonna start doing a better job about this, but honestly, I think the docs will always be at least a day or 2 (if not a week) behind the new releases.  However, the API reference at least has been updated for the new 0.9.5 release.

Without further ado, here's a list of what's new and different in 0.9.5:

New Internal smartCommaSplit() method

The coolest change to me is that the method used to split up function names which are provided as validations or transformations is now smart enough not to split them on commas appearing inside of the functions.  This means that you can now provide arguments when declaring validation or transformation functions, which makes it much easier to use the validanguage.format() transformation.  For example:

onblur: "validanguage.format( '(xxx) xxx-xxxx', '()- ', /^(\\d){3}[ .-]?(\\d){3}[ .-]?(\\d){4}$/ )"

In previous versions of  validanguage, the commas above which are used to separate the arguments would have been treated as if you were listing 2 different functions (ie, onblur="func1, func2").  The 0.9.5 version of validanguage counts open parenthesis and open curly braces to know when commas are being used to separate functions and when they are being used inside arguments.  As a result, it is now possible to pass arguments to validations and transformations.

New and Improved validateDate() Function

The validateUSDate() function which I had previously been using was a pretty stupid regex.  It considered "16/99/3942" to be a valid date.  The new validateDate() method is much better, supporting true date validation, numerous date formats and a number of other options.

Customization of validateDate() is achieved by providing an options object as the second argument to the function.  Because all validanguage validations are called with the text of the object being validated as the first argument, the word "text" must be provided to validateDate() as the first argument when you wish to supply additional arguments. For example, in the comment API, you could specify:

validations="validateDate( text, { dateOrder: 'dmy', twoDigitYearsAllowed: true }"

The validateUSDate() function has been deprecated and is now functionally equivalent to calling validateDate() without any arguments.  Thus, if you are using validateUSDate() you should replace it with validateDate() as the stub validateUSDate() function will be removed in the near future.

For a full list of the supported arguments which you can supply to validateDate(), see the the API reference (the regular docs will be updated to include several examples of using validateDate() shortly).

validateTimestamp() Function

I also added a validateTimestamp() function which can be used to validate timestamp fields.  The new function supports validation of timestamps that include miliseconds and timezones and also supports all the options available for validateDate().  Again, see the the API reference for more details.

Disabling Validation for an Entire Form

You can now easily disable all validations for a given form with the following syntax:

validanguage.el.formId.disabled = true;

Bug Fix for Regex Validation in the Comment API

In all previous versions of validanguage, the regex validations never actually worked under the Comment API.  This is because I was not properly converting regexes declared using the Comment API over to the native Object API.  As of version 0.9.5, regex="regex_here" now works properly in the Comment API.

Thanks to everyone who's been using validanguage since it was released 4 months ago and to those users who have provided me with bug reports and feature suggestions.  Please keep the questions and comments coming!

I finished a new version of validanguage last night and have added it to the download page. As always, the documentation on the new features is running a little behind the actual release, so this blog post will describe the changes briefly until I find the time to update the docs more fully.

However, in conjunction with this release, I used the JsDoc Toolkit to dynamically generate API documentation from the inline comments in validanguage.js. This API reference can be found at: http://www.drlongghost.com/vd_docs/index.html.

Without any further ado, here's a list of what's changed:

Added validateForm() method -- This new method can be used to manually trigger validation on a form (without actually submitting it) and get access to the validation results and a list of any fields which failed and their error messages.

Added showSubmitMessage() -- This new method is intended to be used as an onsubmit transformation for a form. If the form passes validation, the new method will replace the submit button with a div containing the text "Loading" and can also be styled to include a spinner image. This is helpful for signup pages to prevent multiple submissions.

An example of this appears on the validanguage demo

Added ability to manually fail a form field -- This enables you to trigger an ajax lookup against a database and, depending on the results, you can mark a field as "failed" so the form won't be allowed to submit until you manually mark it as "okay" again. You can mark a field as failed by noting it as such inside the corresponding validanguage.el.formFieldId object. For example:

validanguage.el.username.failed = true; //mark as failed
validanguage.el.username.failed = false; //return to normal

An example of this appears on the validanguage demo.

Note that you can also mark a field as "disabled" in the object, which is slightly different:

validanguage.el.username.disabled = true; //Skip any validations for this object
validanguage.el.username.disabled = false; //return to normal

Added showFailedFields option to showError() -- This modifes the default showError() function to not only include an inline error message next to any failed fields, but it also populates a DIV with a list of all the fields which failed. By default, this is turned off, but it can enabled by setting : validanguage.settings.showFailedFields = true.

The names used for the form fields in showFailedFields is determined by the new validanguage.el.field setting (described below).

An example of showFailedFields (using manual CSS to style the DIV) appears on the validanguage demo

Added field attribute to validanguage.el -- This new option allows you to specify a human-readable name for a field. Thus, you can tell validanguage to refer to the field that has an ID of "email1" as the more human-friendly "Email Address". If validanguage.el.field is not provided, it will be inherited from the field ID. Note that the new field attribute is included in the failedValidations argument which is passed to onsubmit transformations and to the results of a call to validateForm().

You can specify the new field attribute using either the comment-based API or the Object API.

Added validanguage.settings.onload -- Enables you to specify a function to run after the validanguage.populate() function has finished loading and all validations have been loaded and prepared for use.

Added addValidation() and removeValidation() -- These new functions enable you to manually add or disable validations after the page has loaded and any specified validation rules have been created. In order to use addValidation(), the new validation must be present in the validanguage.el.formField.validations array, which means this will only work on validations which were loaded during the page load and later removed (which doesn't actually remove them from this array), or on validations which are later dynamically added to this array using the Object API.

To add or remove a validation, you must refer to it by the exact name/array/function definition in which it appears in this array. You can also use the '*' character in the arguments for these methods to specify *any* validation or *any* event handler. See the API page for additional details.

Bug Fix: onsubmit transformations now called in form's scope

Bug Fix: forms submitted via Enter key are now validated

Hopefully I'll be able to beef up the documentation on these new features soon. In the meantime, let me know if you have any questions.

I'm headed to OSCON 2008 in a couple days and before I head out for Portland, I wanted to issue a new version of Validanguage to release the new features I've been working on over the past couple months. Unfortunately, I haven't yet had time to update the documentation page to include all the new functionality, so in the meantime, this blog post will have to serve as a supplement to the new release.

I'll mention the two changes first which affect the APIs, as these are the most important in terms of potential impact on existing code. First off, I fixed some bugs in terms of how the Object API and the Comment API parse the validation event handlers. I don't think previous versions of the code were consistent in this and didn't always do what the documentation indicated.

The following is now the preferred way to load a custom validation as onblur only:

Comment API: <validanguage target="text" validations="customFunction" onblur="true" />

Object API:

validanguage.el.text = {
  validations: [ {
     name: customFunction,
     onblur: true
  } ]

When a function is provided without any event handlers associated with it (and this includes the shortcuts like required and maxlength) the validanguage.settings.defaultValidationHandlers setting is used to determine which event handler(s) to assign. But when an event handler is provided using the above syntax, only the provided handler(s) will be used.

Previously, it was possible to use the syntax onblur="customFunction" to define a custom validation. This has now changed and the shorthand usage of onblur="customFunction" is reserved for defining a transformation. To create a validation for onblur only, you will now need to follow either of the examples above.

Transformations

This new version of validanguage includes support for a new class of functions I have named Transformations. These are intended to be used as functions which reformat the data inside a text field, or which interact with a server backend via Ajax. Transformations are defined with the following syntax:
Comment API: <validanguage target="text" transformations="customFunction" onblur="true" />

Object API:

validanguage.el.text = {
  transformations: [ {
     name: customFunction,
     onblur: true
  } ]

Or, as indicated above, the onblur="customFunction" shorthand can also be used to define a transformation.

Like validations, transformations are executed within the scope of the form field on which they are applied. I have an example of the preset "validanguage.format" transformation (which is now provided in validanguage.js) on the validanguage test case pages. In this example, I use the validanguage.format function to reformat a US phone number to add spaces, dashes and parenthesis when the user tabs out of the field. Here is the Object API code used to load this function (note the use of .call to preserve scope):

onblur: function() { validanguage.format.call( this, '(xxx) xxx-xxxx', '-() ' ) }

See the validanguage_uncompressed.js for more details on how to use validanguage.format().

Form-Level Transformations

In addition to the field-specific transformations above, you can now use form-specific onsubmit transformations to define custom error/success handlers on a form, which provides the ability to prevent a form from submitting and instead submit it via Ajax. Because this use of transformations duplicates functionality already added via the onsubmitsuccess hook, I have removed onsubmitsuccess from validanguage. The new form-level transformations offer more functionality than the old onsubmitsuccess hook.

Form-level transformations can be defined with the following syntax:

Comment API: <validanguage target="form1" onsubmit="formHandler" />

Object API:

validanguage.el.form1 = {
  onsubmit: 'formHandler'

Both of the above examples would call a function named formHandler after all validations have been performed. The formHandler function is executed within the scope of the form and is passed 2 arguments:

1st argument / submitStatus = A boolean indicating whether or not any form fields flunked validation
2nd argument / failedValidations = An array of objects containing details on any flunked validations, including their error messages

An onsubmit form transformation can suppress or allow a form to be submitted by returning a boolean value. So, if the customHandler function above were to be used to submit a form via Ajax, it would issue the Ajax call and then return false to block the form submission. To have a transformation not affect the form submission either way, simply avoid returning anything.

In the coming weeks I will be adding several demos that better illustrate how transformations work. In the meantime, hopefully the explanation above and the commented source code will suffice.

Additional changes in the 0.9.3 Release:

• Fixed konqueror support for the Comment-based API. Since konqueror does not consider comment nodes as part of the DOM, for konqueror only, an Ajax call is issued for the document source, which is then parsed to retrieve any validanguage comments.
• To support the above, a basic validanguage.ajax() function was added and is now available for use
• An onerror and onsuccess handler have been added to display error messages inline, instead of using an alert() call. Alerts can still be used but are now no longer the default. The appearance of the error messages can be styled via CSS. The default class names are .vdError and .vdNoError, but these can be changed via a global setting.  The new onsuccess function will create a div to place the error message in.  The div is appended after the form field, unless the element immediately after the form field is a <label> tag, in which case it is appended after the label.  Thus, if you wish to use this function with radio buttons or checkboxes, define the validations on the final button/checkbox and make sure no whitespace separates the input from its label.  Otherwise, the error message div will most likely not appear where you want it to.
• A new ontyping event has been added. Ontyping is similar to onkeypress but it uses a 2 second timeout, so the user will need to stop typing for 2 seconds before the function is called. This is useful for things such as Ajax calls where you want to wait for a lull in the user's typing behavior before issuing of an ajax call.
• Multiple validanguage tags are now supported per comment. By default a given validanguage tag is expected to only span a single line, but if you always remember to close your validanguage tags, you can change validanguage.settings.commentDelimiter from "\n" to "/>" to allow yourself to have a single validanguage comment span multiple lines.
• Disabled form fields are now not validated.

I guess that's about it for now. Feel free to email me or post questions below about anything that's unclear. I should have some examples up in the next 3 weeks or so which will better explain the new functionality I've added, and I'll also update the existing documentation to reflect these changes.

I just added some nice Scriptaculous effects to the Blog page. You can now drag and drop to move President Kruger's head around. Go ahead and try it....

You could do that on the rest of the site for the past week, but the Blog page was a little harder to get it working on. To avoid screwing with the blog page layout I had to put the image all the way at the bottom of the page and then move it to the upper right corner of the screen.

Anyway, I've been pretty busy all around. On the music front, I'm almost finished with the first new Dr. Long Ghost song in years. An mp3 will be forthcoming. My friend Steve has been helping me to finish my basement . We got a lot of dry-walling done yesterday. Once all the drywall is finished, Steve's gonna help me build a bar, which will be pretty sweet.

For those who don't know, I am now engaged to my wonderful fiance Nicole. The wedding is gonna be next summer, so we have plenty of time to get ready.

And, I am hard at work on the next Validanguage release , of course. I'm gonna be adding a bunch of new features and fixing one of the more confusing parts of the API. The overall reaction to Validanguage has been pretty gratifying. A fair number of people have downloaded it thus far (thanks in no small part to the links on ajaxian and webresourcesdepot).  I now have 2 people on the Validanguage mailing list.

I've also been playing Jade Empire for the original Xbox.  It's pretty cool.  In fact, I think I'm gonna get a beer and play right now.

Update: I created a Roadmap Page to list the features and bug fixes I will be adding to Validanguage in the coming months.

After about a month of work, my initial release of my Validanguage form validation library is finally done. You can read more about it here.

I have a number of features I'm planning on adding to the next version, including:

• Add konqueror support for the Comment-based API via Ajax call to get the document source
• Add "ontyping" event handler to add realtime validation with a 3-second "typing" trigger
• Add support for "onblur transformations" -- such as stripping out all the hyphens from a textfield when you Tab out after having entered a credit card number.

The timing of my next release is really contingent on how well this initial release goes. If no one ends up using validanguage other than me, I'd be inclined to spend more of my downtime working on some new music (which I'm gonna be doing anyway).

So... if you've downloaded validanguage and think you'll be using it, please let me know via email or post a comment below. Feel free to post questions, feature requests or comments.

I cannot live without copy and paste buttons on my mouse.

When I'm working on Web Development, I find myself constantly copying and pasting text and being able to do it from my mouse is a convenience I have grown to depend on. Copy and Paste are also useful in general computing terms, when moving files around in a window manager. The mouse I use at home and at work is the Intellimouse Optical.

Intellimouse Optical:
Featuring five buttons,
including a mouse wheel button

I have had this mouse for about 5 years now and it is very solid and dependable. Microsoft may not even make it anymore, but I have one for home and one for work, and judging by the past 5 years, they aren't going to break anytime soon.

I have the left-side button mapped to paste (which I can trigger with my thumb) and the mouse wheel button mapped to paste. Since it is all too easy to accidentally trigger the mouse wheel button, I opted to map it to paste, which is non-destructive. I keep the right-side button mapped to delete, which is also extremely useful.

In Windows, the driver CD that came with the mouse makes it a snap to bind copy, paste and delete to the mouse buttons. In Linux, the task is a little more difficult, but after several hours of mucking around, I have it down to a science. Here's how I got it working, documented for posterity:

1. Replace the code referencing your mouse in /etc/X11/xorg.conf with the following definition for the MS Intellimouse:

   Section "InputDevice"
           Identifier "Configured Mouse"
           Driver "mouse"
           Option "CorePointer"
           Option "Device" "/dev/input/mice"
           Option "Protocol" "ExplorerPS/2"
           Option "Buttons" "7"
           Option "ZAxisMapping" "4 5"
           Option "ButtonMapping" "1 2 3 6 7"
           Option "Resolution" "100"
   EndSection

2. Install the program xvkbd, which is needed by xbindkeys
3. Install the program xbindkeys and place the following in a file named .xbindkeysrc in your home directory:

   
   "xbindkeys_show"
   control+shift + q
   /usr/X11R6/bin/xvkbd -xsendevent -text "\[Control]c""
   b:2
   /usr/X11R6/bin/xvkbd -xsendevent -text "\[Control]v""
   b:6
   /usr/X11R6/bin/xvkbd -xsendevent -text "\[Delete]""
   b:7

4. Reboot your computer or restart X windows to load the new xorg.conf file. Then run xbindkeys in the background (xbindkeys &) and you should be all set!

Happy copying and pasting!

I spent last weekend tagging my mp3s so I could set up some custom playlists in Xbox Media Center. We have 2 Xboxes in the house (one in the living room and one in the exercise room in the basement), both of which are connected wirelessly to my Windows PC in the office where I have about 80 gigs of mp3s on a shared harddrive.

XBMC has quite a number of kick-ass features, one of which is the ability to set up smart playlists using the id3 tags on your mp3s. My plan was to tag my mp3s by genre and include a "party" genre so I could setup a playlist of all party-friendly, danceable stuff.

I ran into some issues when I was trying to get all my party songs to show up in the playlist, so I posted to the XBMC Forum asking for help. Within an hour, one of the XBMC developers had replied to my post. After a little digging, he verified that I had located a bug with XBMC's support for multiple genres in smart playlists and he was able to commit a patch to the SVN trunk and offer me a couple suggestions for a temporary workaround.

Needless to say, I was pretty damn impressed with the response I'd gotten to my forum post. Xbox Media Center is the reason why I'd never trade my Xbox for an Xbox 360 and with the project still under active development, it's only gonna keep getting better. I'm seriously considering buying a third Xbox for the bedroom, so I can watch my downloaded Alf xvids while laying in bed.

I'm just kidding about Alf.

Or am I?

I had a bit of a scare these past 24 hours when I thought that I had fucked up my newly installed and configured Windows XP PC, which for the purposes of this blog I will refer to as Lester. Lester has a 500gig SATA harddrive, as well as an older 250 gig drive, which was a holdover from my prior computer. As a result, the smaller, secondary harddrive had 3 partitions on it: an XP system partition, an Ubuntu partition and an NTFS partition with a buttload of mp3s on it.

Last night, I decided to delete the 3 separate partitions on my secondary drive and reformat the whole thing as a single NTFS partition for mp3s. I used Partition Magic and some other partition program I had snagged off BitTorrent. I was very cautious while formatting and succeeded in deleting the partitions and wiping the drive. However, when I rebooted, Lester would not start up and displayed an ominous message about no bootable media being found.

This was pretty damn confusing, since I knew that I had formatted the correct drive and was pretty sure that all my windows files were still present on the main drive. What the fuck had happened? Was it a virus?

Well, to make a long story short, I eventually was able to restore the MBR (Master Boot Record) and boot.ini on the main drive and get it to boot into Windows again (although I ended up installing Windows on the mp3 drive just so I'd have something to boot into so I could muck around with the main drive). After I had fixed Lester, I realized what had happened. When I had originally installed XP, for some bizarre reason, the boot.ini file for XP was installed, not on the hard drive containing my Windows system, but on the hard drive containing my mp3s and the other 2 unused partitions. Thus, when I wiped this drive, it blew out my boot.ini file and Lester was dead in the water.

Even odder, when I installed the temporary version of XP on the newly wiped mp3 drive to give myself access to the files on the main drive, it put the new boot.ini file on the main drive! So, at that point, boot.ini was where I wanted it and I only had to go in and edit it to tell it to load the windows install on drive 0 instead of drive 1.

In case anyone ever has a similar issue, here are the instructions I finally found on editing the MBR and boot.ini:

1. You can try restoring the MBR in MSDOS with either the FIXMBR command or with fdisk \mbr. In my case, this didn'twork, since I was still missing boot.ini.
2. I was able to edit the new boot.ini file with the following commands, run from the commandline (I don't think boot.ini is visible within Windows Explorer, even with Show Hidden Files enabled):
   1. attrib -H -S -A -R boot.ini -- This sets the boot.ini file as editable
   2. notepad boot.ini -- Pops it open in Notepad so you can edit it.
   3. attrib +H +S +A +R boot.ini -- Restores boot.ini as a hidden, system file, after you have made your edits and saved.
3. Reboot and all is well. You can add multiple entries in boot.ini under the [operating systems] section. For me, the operative thing to change was the rdisk option. You'd think the disk option would control which harddrive is being described, but actually the physical drive is referenced by the rdisk option. Thus, I had to change:
   multi(0)disk(0)rdisk(1)partition(1)\Windows
   to
   multi(0)disk(0)rdisk(0)partition(1)\Windows

I must confess that despite the stress of thinking I had lost all my files, it was pretty damn gratifying to actually fix this myself by getting down and dirty with the MBR. Nevermind that I wouldn't have ever had this problem if I hadn't fucked up in the first place...

Nicole and I had a wonderful walk this afternoon that took us down our street to the CVS and then to the local Genuardi's, via the cemetery behind our house. During the walk, it occurred to me that although we had replaced our smoke detector batteries the prior Daylight Savings Day, our Zombie Evacuation Plan had not been updated since we had moved into our new house, almost a year earlier.

As those of you who live near cemeteries know, a good Zombie Evacuation Plan can mean the difference between life and death -- saving one from an awful brain-eating fate. Unlike some of our wealthier neighbors, we are unable to afford the high premiums charged for zombie insurance in a residential zone within a half mile of a cemetery. Thus, in the event of an outbreak, our house will be a total loss and we will be entirely on our own to make it to the nearest Army evacuation point -- Abington Hospital, or City Hall in Philly, in the event that the hospital is overrun.

Since our evacuation plan is of paramount importance, I welcome your criticism and suggestions. It is very much a work in progress which I strive to continually improve.

1. Weaponry. Although Nicole has made it clear that the cats should be our primary concern, I feel that if we cannot defend ourselves, then we will be of no help to the cats. Also, prior attacks have shown that domestic pets are generally left unmolested by zombies, particularly when human prey is readily available. Thus, our first action will be to secure the knives from the kitchen. Time permitting, we will also retrieve the gasoline from the shed and the propane tank from the deck, which can be used as a makeshift bomb.
2. Blank and Nudge. Next, we will get the cats in their carriers.
3. Shelter. If we're able, we will board up the windows and doors with the extra wood from the shed and seal up the basement door to limit the amount of space we will need to defend. If the house itself is breached, we will retreat to the upper floor. If the upper floor is then breached, we can always exit the window in the office, clamber down the roof and onto the deck, and from there jump down to the backyard.
4. Evacuation. As soon as there is an appreciable lull in the fighting, we will evacuate, preferably by car, down Susquehanna toward the hospital. Hopefully, we can make it to the hospital and be evacuated via helicopter. If the hospital is no longer safe, we will need to fight our way down 611 all the way to City Hall.

I only hope that if we ever have cause to put our evacuation plan into effect that we are able to escape with our lives. A house and possessions can always be replaced, but a brain can never be un-eaten.