Delta Air Lines operates their main website at https://www.delta.com. To the best of my recollection, for a long time the only way to login to delta.com (and before that, delta-air.com) was using a SkyMiles number and its corresponding 4-digit PIN (so you used SkyMiles number + 4-digit PIN). At a certain point, this changed such that the corresponding last name was also required (so you used SkyMiles number + 4-digit PIN + last name); presumably the reason for the change is that it was determined SkyMiles number + 4-digit PIN is too easy to crack using brute force methods and so it made sense in that situation to require providing also another piece of identification information. So that's all good.

But now using a 4-digit PIN to login has been eliminated completely; a password now must always be used when logging in. In addition, email address and user name have been added as alternatives to SkyMiles number for use when logging in. But what's strange is that while last name is not required when logging in with SkyMiles, last name is required when logging in using the 2 alternatives to SkyMiles number (so you can use SkyMiles number + password or you can use user name + password + last name or you can use email address + password + last name). I don't understand this: this implies that there is less security when using a user name or email address than there is when using a SkyMiles number and I feel that if anything, the opposite is true since a valid SkyMiles number is by definition easier to guess given that there are only 10,000,000,000 possible valid SkyMiles numbers whereas there are an infinite number of possible valid user names and email addresses. Of course, a legitimate concern is that an attacker wouldn't be guessing but rather would be using information he/she knew: an attacker may acquire information from another source (website, database, etc.) and that information may work as credential information on delta.com (users commonly reuse passwords on multiple websites). It seems that Delta can envision a situation where an attacker could gain access to user name/email address + password and not gain access to last name yet Delta cannot envision a situation where an attacker could gain access to SkyMiles number + password and not gain access to last name (if they could envision this latter scenario, they would surely require last name as a means of thwarting attackers, just as they do as a means of thwarting attackers in the former scenario). I suspect they are correct that the former scenario is more likely but the latter scenario is at least possible and since they're already asking for last name with a user name/email address and since SkyMiles number is by definition easier to guess than user name/email address, I just don't understand why, if they're ever going to ask for last name, they don't consistently ask for it. I'm loathe to call it arbitrary but it's certainly at the very least difficult logic to follow.

My pertinent experience for this blog post is with an iPad (specifically a "the new iPad" which is generally referred to as the iPad 3) but I expect that these same results would be experienced for any iOS device (iPhone, iPod Touch, etc.). No matter what your device, if you have direct experience with using this technique with a device that is slow, unresponsive, and/or crashing, please post a comment about your experience (whether or not it helped, anything you did different, etc..) as that will very much help other readers.

My iPad had become very unreliable: it crashed (or perhaps I should say it spontaneously rebooted) regularly and when it was running, it was very slow to respond and at times downright unresponsive. The condition got worse and worse to the point where I simply couldn't use it because it just wouldn't respond for more than a few seconds before automatically restarting of its own accord.

The good news is that I was able to get my iPad back working like new by restoring it from a backup; the bad news is that by the time I tried this approach, it had become very hard because the first step in the process is to do a full backup of the device and that was very, very difficult because of my iPad's propensity for spontaneous reboots (but fortunately, with a lot of patience and persistence, I was able to get my iPad to backup).

Now, to be clear, when the iPad was merely painfully slow, I had considering doing a restore from a backup but, though it's easy and straightforward enough, doing a restore from a backup does take a bit of time and so I was reticent to do it without some indication that it might help. For that reason, I searched for guidance and I wasn't seeing people prominently pointing to doing a restore from backup as a troubleshooting step to try and so I didn't jump to do it; as I said already, that that proved costly because things go so bad that I almost couldn't successfully backup the iPad. And that then is the reason I'm writing this post: my hope is that when others search in the future for what to do about extremely slow-to-respond (and even entirely unresponsive) iPads, iPhones, and iPod Touches that crash and/or spontaneously and automatically reboot, they'll find this blog post and be encouraged to try restoring from a backup--and then of course I further hope that those who do try this approach will get the same results that I did: iOS devices that work like new. Please let me know in a comment if it does or doesn't work for you.

Now as to the process of doing a backup and restore: I won't get terribly detailed here because you can find the key details on Apple's Support website. But some notes:

1. As I mentioned, this process is easy and straightforward but it does take some time; accordingly, make sure you'll be able to dedicate your device to this task for an extended period of time (in other words, don't expect to start this and be able to then take your iPhone somewhere a half hour later).
2. To do the backup and restore, I used iTunes, not iCloud and I recommend that you do the same as it will certainly be faster. However, I don't know any reason that it wouldn't work using iCloud.
3. Since what you're going to be doing is reinitializing your device from a backup, the first thing you need to do is backup your device so that the backup you're using for the reinitialization is current.
4. Then you need to erase your device; this is mentioned but not actually described in the link above. You can do this via iTunes or you can do it directly on the device. I believe these are not entirely equivalent approaches but rather a factory reset via iTunes is a more extensive reset than merely erasing the content and settings directly on the device. I erased the content and settings directly on the device and that worked great for me. Note that the information on erasing the content and settings directly on the device does not mention turning off Find My iPad (or Find my iPhone or whatever is appropriate for your device) but to keep yourself out of trouble, I recommend turning that setting off. I turned it off prior to doing the backup (step 2 above) so that Find My iPad was completely out of the picture and couldn't cause any issues.
5. Once your device has been erased/reset, you need to restore it from your backup. This part will take the longest. Fortunately, you can just let it run while you do other things.
6. Once you've restored the backup, if all goes well, you should hopefully be in really good shape with your device! Specifically, your device should work like new. If it doesn't then unfortunately, you are probably dealing with issues that this approach won't fix. But if your device is working well at this point, you'll want to go back and turn on Find My iPad (or Find my iPhone or whatever is appropriate for your device). In addition, if you're an iCloud Keychain user, check the iCloud Keychain setting (it's on the same screen as the Find My iPad setting): I found that it was off and needed to be turned on (but fortunately, so far that's the only setting I've found unexpectedly changed during this process).

So what exactly was wrong with my iPad that the backup and restore appears to have rectified? Well, I had thought all the issues I was seeing (in addition to the poor performance and reliability, I had one app update that just wouldn't finish, leaving the app in a sort of state of limbo; I couldn't remove it by clicking and holding and hitting the "x" to delete it, I had to delete it via the Manage Storage area of the Usage area of the General area of the Settings app) were perhaps because some of my iPad's solid state storage had gone bad (and I was hoping that upon the backup and restore, iOS would avoid using the bad parts of the storage) but after the restore I noticed that my iPad gained around 3 GB of additional free space. Interestingly, when my iPad was misbehaving so badly, the amount of free space reported for the iPad in iTunes did not match the amount of free space reported by the iPhone itself; however, after the backup and restore, the 2 reports matched. I checked my iPhone, which doesn't have performance issues, and the report of its free space in iTunes matches what the iPhone itself reports. This all leads me to believe that mismatches (at least significant mismatches) between the reports of the free space provided by an iOS device and iTunes may be a good indicator that something is seriously amiss with that iOS device. Certainly in the case of my iPad it seems there were some serious "cobwebs" in there that were cleared out by the backup and restore. But regardless of exactly what was going on, I'm just glad it seems to be better now and I hope it stays that way!

As they say, your mileage may vary but I very much hope your results are as good as mine have been!

Google Docs is wonderful in many ways, however, there are a couple of areas where it has limited functionality that were issues for me recently and this is the second of a two-part series of blog posts (see the first part here) on what I did to work around those limitations.

A Google Docs mail merge is not a native capability of Google Docs. Said another way, Google Docs does not natively offer the ability to do a mail merge (that is, it does not offer the ability to use a template document with special data placeholders and create a set of documents from a set of data where the data is used to populate the values for the special data placeholders in the template document). Fortunately, Google Docs does natively offer the ability to use 3rd party extensions and the excellent DocumentMerge by PandaDoc extension will allow you to do mail merges.

The instructions for how to use DocumentMerge by PandaDoc to perform a mail merge using a Google Sheet as the data source for a template Google Doc can be found at https://www.pandadoc.com/google-docs-document-merge. I won't belabor things by repeating the instructions here; the reason I'm writing this post is that for me, the DocumentMerge by PandaDoc extension wasn't easy to find when searching for a way to do a mail merge with Google Docs and I'm hoping that this blog post will bubble up in search results in the future, making it easier for others to find the extension (if this blog post is helpful to you, please take a moment to leave a comment if you're willing). To be more specific, what I was looking for was the ability to do a mail merge that produced printable documents but all I was able to find was info on how to do mail merges to create emails (which the DocumentMerge by PandaDoc extension will do as well so if that's what you're looking for, it's good for that too).

Anyway, it's a great extension for doing a mail merge with Google Docs (though for some reason it's fairly slow). You'll see that it creates a Google Doc as the output of your mail merge and from there, that document is just like any other Google Doc (meaning you can download it, print it, whatever you need to do). In addition, DocumentMerge by PandaDoc has another capability as well: if you want to email out each of the merged documents as a PDF attached to an email, you can do that directly with DocumentMerge by PandDoc which is a great feature (albeit one I haven't used since in my case I just needed to print the merged documents).

To give credit where credit is due: I became aware of this technique in the post at https://productforums.google.com/forum/#!topic/docs/m-hUu90ZGI0.

Google Docs is wonderful in many ways, however, there are a couple of areas where it has limited functionality that were issues for me recently and this is the first of a two-part series of blog posts (see the second part here) on what I did to work around those limitations.

Google Docs only allows you to create documents from a set of standard page sizes; it does not allow you to create a document of a non-standard page size (custom page size) of your choosing. Fortunately, there is a workaround that will allow you to create a document of any page size. If you're printing (in my case, I was printing envelopes), working from a document that properly represents the size of your print media is at the very least helpful, if not downright critical.

The workaround is to create a document outside Google Docs (yeah, that's bad but it's what you have to do) with the proper page size (and get your margins like you want them as well because if you try to change those in Google Docs, you'll also be forced to change the page size at the same time and of course you'll be forced to change the page size to one of the standard sizes). I had success uploading a Word-type document (both .doc and .docx worked for me) but not uploading a PDF or a Pages-type document. Note, however, if you don't have Word on your machine, you can get OpenOffice for free. In addition, if you have Pages, you can create the document there and export it as a Word-type document and that works (in fact, that's what I did; for more on how to do it, see this associated post of mine).

One special note here: I encountered a bit of a strange issue with pages with a width of 7.25" (my custom size also had a height of 5.25" but I didn't investigate whether or not that was relevant to the issue). The issue was that Google Docs for some reason was inserting a blank page between every actual page on print/download. Very weird stuff. By using a document with a width of 7.75" with an additional .25" margin on left and right, Google Docs did not insert that extra blank page and for my situation, this was a suitable workaround because what I needed to be able to do was print and on my Mac, the key for printing was the center of the content (if in your situation, you ever see an issue like this but the key for printing is the left of the content then add additional width to the page and instead of dividing the additional width evenly between the left and right margin, just add all the additional width to the right margin).