Do not trust "localhost": It is just a name

Like any other domain name or host name, "localhost" is yet another name. It needs to be resolved first when it is used. Usually, the entries needed to resolve it are already in the `hosts` file when the OS is installed.

$ ping localhost
PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.140 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.147 ms
64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.148 ms
64 bytes from localhost (127.0.0.1): icmp_seq=4 ttl=64 time=0.126 ms
^C
--- localhost ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3059ms
rtt min/avg/max/mdev = 0.126/0.140/0.148/0.008 ms

$ ping6 localhost
PING localhost(ip6-localhost (::1)) 56 data bytes
64 bytes from ip6-localhost (::1): icmp_seq=1 ttl=64 time=0.099 ms
64 bytes from ip6-localhost (::1): icmp_seq=2 ttl=64 time=0.175 ms
64 bytes from ip6-localhost (::1): icmp_seq=3 ttl=64 time=0.221 ms
64 bytes from ip6-localhost (::1): icmp_seq=4 ttl=64 time=0.161 ms
^C
--- localhost ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3074ms
rtt min/avg/max/mdev = 0.099/0.164/0.221/0.043 ms

The pitfall here is, if you simply use "localhost" in your application, it could behave differently when deployed in different environments. In extreme cases, I have seen "localhost" get resolved to its IPv4 and IPv6 entries (i.e., "127.0.0.1" and "::1") randomly within a single integration test run. Think about it! What if the service, that your application is trying to connect to, ONLY listens to its ports on the IPv4 address? In such a case, a connection request sent to "::1" will be refused.

Tips

1. If you see "connection refused", always check if the ports are open on both "127.0.0.1" and "::1". Do not preclude this possibility even if the error is intermittent.
   
2. Docker containers' forwarded ports might be open on "127.0.0.1" only on the host.
3. If you cannot solve the resolving issue in the environment, there might be workarounds where you can configure your application to prefer the IPv4 stack when resolving host names.
   

I am closing my old unused online accounts

If you do not manage it, you do not own it.

For some reasons, I registered a lot of online accounts in the old days, on many websites, and sometimes many accounts on the same website. When the total number increases, it eventually became impossible for me to frequently check through all of them.

The lack of maintenance could lead to severe security problems.

1. The online accounts that I created earlier are more likely to have weaker security settings, like passwords and security questions. At the same time, without frequent checkup, many security settings expire, like recovery emails and phone numbers; some credentials may simply get lost, like answers to the security questions. This means that I may be locked out of my own accounts indefinitely, not being able to improve the accounts' security.
   
2. Data breaches are happening way more frequently than I assumed in the old days. Once the databases are dumped, weak passwords are highly vulnerable and will eventually get cracked, then the accounts will be compromised. Do not underestimate this chance. In the past 5 years, 2 of my major online accounts were once hacked. Those accounts were associate with email boxes, which contained a lot of personal data. In order to gain access back to those accounts, I had to contact their online customer service and upload even more sensitive personal data to prove my account ownership. If these uploaded data are not handled appropriately by the websites, they could lead to bigger security issues in the future.
3. Attackers are much more capable than us. They know the vulnerabilities of online services and can get access to our accounts much easier than ourselves. While a piece of missing security information can lock me out of my own accounts, the attackers might leverage the exploits to circumvent the security checks, claiming ownership of my accounts. In the most recent hack, the attackers seemed to have leveraged an obsolete and insecure security path, which allowed them to override my recover phone number, without triggering even a single alert that was supposed to be delivered to my old number.
   

The lesson is, close unused online account when you still can, especially if they contain sensitive person data, like past email conversations. Depending on the security implementation of the websites, this might not make your data completely secure, but it is supposed to be more secure than if you do not do anything.

This is not a simple task for me due to the amount of data that need to be migrated, but I have added it to my TODOs.

Becareful when you transfer your Blogger site to a different Google account

It appears that the images I upload and use in my Blogger posts are stored within either my Google account, or my Blogger account, which is now just one part of my Google account.

The key point is, when I transfer my Blogger site to a different Google account, like what I have recently done to this site, the uploaded images do not go together. After deleting my old Google account, these images are just gone and the links are broken. Since the posts are so old, there is nowhere I can find the original images back. I have no choice but delete their links completely to make the posts look slightly better.

Therefore, be careful when you transfer your Blogger site to a different Google account, and be even more careful when you delete your Google account data.

One way to workaround this is to use a third-party file hosting service or online album that supports external links. However, it is obvious that if you plan to go in this direction, you will need to start as soon as possible :-)