Email: ISP, Free, or Paid?

If you’re reading this, there is an almost 100% chance that you have an email address, and that you use email at least occasionally. It’s more likely that you use email every day, and you might even have more than one email address. But have you thought about the ramifications of where you got your email address from? Most normal people don’t really think about it, but they should. Some people might not even know that there are different ways to get an email address or account.

The most common way for people to get an email address is from their Internet Service Provider (ISP). When you sign up for Internet service, you get an email address assigned to you. You may or may not have any control over the first part of the address – the part before the “@” sign – but you won’t have any control at all about the domain name – the part after the “@” sign. For example, if you have Comcast, the email name that they provide ends with “,” and the first part is the “name” of your account. Other vendors use a similar approach, where the domain name part (again, the part after the “@” sign) identifies the provider.

These vendor provided email accounts are provided “free” and many people use them. They provide basic email with few extras, and generally they work okay. The real problem arises when you need to change your Internet provider for some reason. Maybe you move to another area of the country that is not served by your provider. Or maybe you get tired of the cost or customer service or performance of your provider and decide to switch. Whatever the reason, if you change providers, you lose access to your old email address. Not only do you then have to go through the pain of distributing your new email address to friends and family, but you also have to change the address with all of the vendors that use it to send you notifications and updates (your bank and credit card companies, among others), or that use it as an identifier ( comes to mind, but they are legion). So I generally advise people to not use an ISP provided email account.

One alternative to ISP provided email accounts is to create a free account with Microsoft ( or Google ( I recommend sticking with one of the “big two” for a couple of reasons. First, they are unlikely to go out of business and leave you in the situation of having to change email accounts (see paragraph above). Second, they handle so much mail that their malicious mail filters (for spam, phishing, and other nefarious types of email) do a pretty good job. These free accounts avoid the problem of changing ISPs, but you’re still stuck with their domain name, which also means you might not be able to use the “name” (the part before the “@”) that you want. For example is almost certainly already taken, and I’ll bet your name is, too. Still, if you can come up with a creative and clever name, you might be fine. These email accounts are fine, and I recommend that everyone create one to use as a backup, at the very least.

Another alternative to ISP provided email, and the one I recommend for people who are willing to spend a little bit of money on their email account, is to register your own domain name (again, the part after the “@” sign), and then create your email account in that domain. Domain names are relatively inexpensive – .com, .org, and .net domains are typically about $13 per year to register. Once you have your own domain, you set up an email hosting account with a provider (Microsoft and Google both offer full-featured email hosted on your own domain, but there are other vendors as well (some of whom re-sell Microsoft or Google services)). Then you can create whatever “name” you want (well, within reason), and, as long as you pay the bills for hosting and to renew your domain name every year, your email address never has to change.

Backups: Why, What, and How

“You should backup your PC” is an old refrain from many years ago. It was good advice. Of course, back then that meant buying a box of floppy disks and using a backup program – MS-DOS had a (later versions had backup.exe) that could be used to make sure that if your PC crashed and wiped out or scrambled your data, you could get it back. Some people (including yours truly) actually did this; some even did it on a regular basis. Most, however, had to experience the loss of a complex spreadsheet that they had developed, or their only copy of the great American novel, or some other similarly precious digital file before they saw the real wisdom in backups.

Of course, the next piece of advice was to store the backups “off-site,” which meant taking them to the home of a trusted family member or friend, or maybe taking them to your office (or home, if it was a work backup), or, in rare cases, perhaps putting them into a safe deposit box at a bank. This was to avoid the situation of a fire, flood, or some other catastrophic event destroying your home (or office) that would also destroy your backup. Almost nobody did this. Not even me.

As hard drives became available and, more importantly, reasonably priced (my very first hard drive was a 10 megabyte (yes – 10 MEGAbyte) Plus Development HardCard, which plugged into an expansion slot in the original IBM PC, and for which I paid about $750 back in, as I recall, 1984), it took many more floppies to back up the PC. Several options were developed to make it easier, but all of them still suffered from the “it-needs-to-be-offsite-to-really-be-a-backup” problem.

Today’s cheap, multi-gigabyte hard drives, in readily available commodity PCs, coupled with digital cameras and cell phones with increasingly good cameras mean that many people – maybe even most people – have lots of photos on their PCs that they’d really hate to lose. The size of these hard drives, the number of files, and the complexity of some of their folder structures makes backing everything up a daunting task.

Still, some people do make backups. Unfortunately, many of them are using external hard drives or USB thumb drives to back up their files on a semi-regular basis (when they think about it). That is better than nothing, but those backups will still be destroyed in a fire, or they could be lost or stolen, or the device could simply fail.

So, the “why” of backups is so that you won’t lose all of your child’s baby photos or their graduation of wedding photos, or your only copy of your digital financial records, or all the work on your novel, or whatever in case your PC crashes or your hard drive fails. And this paragraph provides the “what” to back up – anything that would be difficult or impossible to recreate if it was lost, whatever that happens to be. Now, on to the “how…”

And the “how” is continuous, online (aka cloud) backup. The best-known of these it probably (I am not affiliate with Carbonite and I do not get any kickbacks from them, just so you know), but there are several other good alternatives. This type of backup is basically a set-it-up-and-forget-it approach to safeguarding your files. They are backed up either continuously or every few minutes to a remote server (likely distributed over several geographically dispersed servers), so they are protected from the local catastrophic events described above. You don’t have to remember to make the backup and you don’t spend any time on it (other then the initial setup), which means they’re really convenient. And, starting at around $6 per month, they are pretty affordable.

So, please, you should back up your PC!

Week 10 Project, Part 2a: Back on Track

Last week, I wrote about two problems I had moving my project from PhpStorm to IntelliJ IDEA Ultimate (both from To recap (or you can read the entire post here), I could not get the deployment configuration to work (I set it up to sync the local sources with the web server on any explicit “Save All”), and I could not get the built-in web server (in the IDE) to open the site for testing – it was always opening the actual site on the web server (which works, but adds some network traffic and some latency).

The solution to the first problem, described in last week’s post, was for me to use the correct path for the local directory where the sources are located. Duh. As I stated last week, this was not in any way the fault of JetBrains or the IDE; it was all my doing.

The second problem I finally solved after I wrote last week’s post. Again, the fault lies solely with me. When I created the deployment configuration (and finally got it right), I had inadvertently set it up as the default deployment configuration. As the IntelliJ IDEA docs clearly state, if a deployment configuration is marked as the default, it will be used instead of the built-in web server (or any other deployment configuration, presumably). As soon as I unset the default, it went back to using the internal web server when I clicked the “Run” button to test the site.

Yes, I know this is a short blog post. I spent way too much time on these two issues – I should have just read the docs (or searched Stack Overflow) right away. Oh well, next time…