Signing Up for Google Fi

I recently signed up for Google Fi, Google's mobile phone plan offering. Before signing up, I was using two traditional carriers – one in Japan, one in USA. I also had a separate mobile hotspot plan in Japan as a backup and "on-the-go" Internet connection for work. The hotspot has proven itself useful many times, especially during visits to my wife's hometown in the countryside.

A few weeks ago, I started rethinking my plan for global data coverage. After a good bit of research, I ended up choosing Google Fi for the reasons below.

  • I often faced SMS 2FA issues in Japan. For example, some of my online shopping accounts are tied to my USA number. If I try to log in to buy something in Japan, it send a verification code to my USA number. Since Google Fi gives me a single number that's accessible from around the world at no extra charge, I can use that phone number to solve this problem.
  • Having a separate mobile hotspot feels a little redundant. With Google Fi, I can add additional data-only SIMs for free! Since I do most of my writing for work on my iPad Pro nowadays, I can put the SIM card in my iPad directly. Hopefully future ARM Macs have built-in LTE capability as well. Best of all, Google Fi gives me unlimited data in both Japan and USA, and it's cheaper than the mobile hotspot I was paying for.
  • Google Fi is compatible with my iPhone's eSIM. This means I can have two voice/data plans in one phone. This is very convenient because I don't need to carry another device around for the second phone number. Furthermore, it allows me to use my iPhone as a mobile hotspot in case I need to connect to the Internet with my MacBook Pro on the go.

I'm all set up with Google Fi now, and I've been loving it so far. My iPhone 11 Pro Max has a physical SIM for my USA carrier and a Google Fi eSIM, and I also have a data-only SIM in my iPad Pro. Just today, I walked to a local park to get some work done on my iPad. It felt pretty awesome to be able to connect to the Internet on my iPad Pro without any kind of tethering setup. When I get back to Japan, I'll swap out my USA carrier's SIM for my Japanese carrier's SIM.

Nice and easy!

The Best Audio Interface for Podcasting

Over the past few years, podcasting has grown from a niche content format that no one took seriously to a mainstream content channel ripe with top notch shows and sponsors, and millions of listeners around the world. In 2020, the podcasting industry has evolved to the point where anyone with a microphone and an idea can start a podcast with almost zero friction.

In fact, it’s a three-step process – hook up a mic, record your episode, and distribute it. In this article, we’ll discuss the first step. Specifically, you’ll learn how audio interfaces help you connect a microphone to your computer, and which audio interface is the best option for podcasting.

Continue Reading →

Terminal Stuck at "Login 80x24" in macOS 11 Big Sur

I recently upgraded my primary computer to the developer beta of macOS 11 Big Sur. I know what you're thinking, but what can I say... I like to try the latest and greatest even if it means risking system stability. Also, let's be honest – macOS Catalina wasn't exactly the most stable version of macOS anyway.

The update to macOS 11 Big Sur went pretty smoothly. I downloaded the beta profile from my Apple developer account, and was able to get everything installed shortly after that. I was half expecting my various Python automation scripts to break, but all of them continued to work fine after the update.

macOS 11 Big Sur.
macOS 11 Big Sur sports a fresh redesign.

The one thing that did stop working was Terminal and iTerm2. After a while, Terminal would randomly go blank and display "login 80x24" in the menu bar. The strangest part of this behavior was the fact that there weren't any rogue login processes in the Activity Monitor, so I wasn't sure why Terminal was getting stuck trying to login – not to mention why it logged out in the first place.

I tried a variety of fixes including rebooting, deleting Terminal preferences, rebooting again, and a few other things. In the end, the following steps worked for me to get iTerm2 working again.

In iTerm2 preferences, I changed the Command setting in the Profiles tab from "Login Shell" to "Command". For the command, I specified /bin/zsh.

Command setting in iTerm2.
Command setting in iTerm2.

After that, I deleted com.apple.Terminal.plist in ~/Library/Preferences, and restarted my MacBook Pro. After going through this sequence of steps, I'm no longer getting the "login 80x24" issue in Terminal or iTerm2 – YMMV.

Submitting Changed URLs to Bing Webmaster Tools with Python

One of my biggest pet peeves with Google Webmaster Tools is its lack of a complete API to programmatically submit updated URLS for indexing. At the moment, Google's Indexing API only allows submission of pages with specific kinds of structured data – JobPosting or BroadcastEvent embedded in a VideoObject. Hopefully Google will open up the Indexing API for all pages in the future, but I'm not holding my breath.

Continue Reading →

Apple Music vs. TIDAL on a $30,000 Stereo System →

I saw this post in a Twitter thread this morning. Upon my first readthrough, I honestly thought it was a parody, but I soon realized it wasn't after checking out some of the comments on the post.

The premise of the post revolves around testing Apple Music and Tidal, two music streaming services, on a $30,000 stereo system powered by McIntosh equipment – yum.

The three of us were unanimous: Apple Music was the clear winner. It sounded the cleanest, the least compressed, really crisp. Spacious. Vocals that were mixed well were front and center, floating into the space above our heads as if the singer was in the room. The midrange never got lost in the mix. Bass was deep and wide but not muddled. In short, everything sounded like it was intended to sound, as it was engineered.

Apple Music streams are encoded in AAC format – a lossy format that strips out data in a destructive manner. TIDAL uses FLAC, a lossless format. By definition, Apple Music can't be the "least compressed" when compared with TIDAL.

For some songs, we couldn’t hear a difference between Apple and Tidal. For others, Apple sounded better than Tidal, less compressed. Tidal claims it’s lossless but in other places cites a 1,411 Kbps FLAC compression rate. In any case, it certainly isn’t CD or vinyl quality.

Lossless compression simply means the compressed data can be decoded back into the original source. The "compression rate" isn't really relevant when discussing Flac compression from a quality perspective. The CD audio standard specifies a 16-bit stereo stream with a 44.1kHz sample rate, which comes out to 1,411 kbps – that means, bitrate-wise, TIDAL is literally CD quality.

Besides being 60% cheaper, Apple has a larger music library. We couldn’t find about 10% of the playlist on Tidal.

I agree with this. TIDAL still doesn't have a large collection to this day.

I’m not a recording engineer by any means. But my theory about why there was such a noticeable difference is this: Apple’s audio compression codec is better. Somehow AAC beats Tidal’s “lossless” FLAC encoding. How else can you explain it? Maybe there’s a crucial difference in specific app implementation? Or maybe Apple is favoring its own service on its platform?

Objectively speaking, Apple Music's AAC codec is not better. That would be impossible since TIDAL uses a lossless codec. With that said, I can think of a few reasons why Apple Music may sound subjectively better than TIDAL.

  1. Apple works with record labels to make "Apple Digital Masters". The idea here is to master a song with the shortcomings of the AAC format in mind. If the test songs were Apple Digital Masters, that could explain why the author thought they sounded better.
  2. Apple apps and products may have some sort of special data prioritization. A modern example of this is the W2 chip in AirPods, which communicates with Apple devices using a specific protocol for better sound quality.
  3. The author could simply be an Apple fanboy.

I probably should have mentioned that we were streaming from an iPhone 6, an iPad Pro, and an iPad Mini to an old Airport Express connected to the preamp with an optical cable.

Yikes, this disclaimer should've been at the top of the post because it effectively undermines the entire test. When performing tests like these, it's important to have "controls" – parameters that you have absolute control over.

  1. There was no reason to use multiple devices. Stick with one device to remove device variance from the equation.
  2. The setup above isn't actually a test between Apple Music and TIDAL – that's the secondary test. The primary test here is actually the streaming quality of the Airport Express. If the devices aren't streaming to the Airport Express in full-resolution, then you're not listening to lossless audio from TIDAL. This test should've been performed without any wireless streaming.

Posts like this one really make me cringe because they are extremely misleading. Tech writers should understand the level of influence they may have on normal consumers. Publishing an audio comparison without understanding the basics of digital audio is simply unacceptable.

Now, can someone buy me a $30,000 stereo system to do a proper test? 😃

« Permalink »

HEY Email – An Initial Review

HEY is a new paid email experience designed and developed by Basecamp. I say "experience" when I describe HEY because I don't think "service" or "platform" do it justice – it's a complete rethinking of email. HEY takes an extremely opinionated view on email with its core features including the "Imbox", "Screener", "Feed", and "Paper Trail" – more on that later.

In this article, I'll give you my initial thoughts on HEY after using it for a week. I plan on following up with a more in-depth piece in a few months, but hopefully my first impression can help you decide if you want to give HEY a try.

Continue Reading →

A Little Subscription Purging

Today, I went through my credit card statements from the past few months in search for unnecessary subscriptions to purge. As a technology lover who's always keen to try the latest and greatest, I don't always remember to cancel subscriptions before the end of their respective free trial periods.

After half an hour of purging, I was able to remove $80/month worth of subscription services I don't really use anymore! Most of the subscriptions I got rid of were related to servers, server management, and server monitoring.

What a surprise...

With $80/month of savings achieved, I dug further to see what else I could cut. I found a few more server monitoring services that I actually use for monitoring my block production node on the ICON network. Between UptimeRobot and NodePing, I was paying close to $30/month for monitoring.

I've been on a serverless function kick recently, so I decided to try writing a script to replace the core functionalities of UptimeRobot and NodePing. I ended up with the Python script below that makes two requests to the node with a 30 second gap in between, and messages me on Telegram if the node is offline. I'm going to add some more code over the next few days for error and timeout handling, but it works pretty well for now.

import json
import requests
import time
from multiprocessing import Process

def node_check(t):
	time.sleep(t)
	node_url = "http://...:9000/api/v1/avail/peer"
	r = requests.get(node_url)
	json_data = json.loads(r.text)
	is_service_online = json_data['status']
	is_service_available = json_data['service_available']
	if is_service_available == False or "is online" not in is_service_online:
		send_tg_message()

def send_tg_message():
	tg_bot_url = f"https://api.telegram.org/bot.../"
	chat_id = "..."
	response_message_data = {
        "chat_id": chat_id,
        "text": "RHIZOME P-Rep node (...) is offline.",
    }
	requests.post(f'{tg_bot_url}sendMessage', json=response_message_data)

def main(request):
	p = Process(target=node_check(0))
	p.start()
	p2 = Process(target=node_check(30))
	p2.start()
	p.join()
	p2.join()

I deployed the script to Google Cloud Function, and scheduled it to run once per minute with Google Cloud Scheduler. While this solution obviously doesn't cover all the features of paid monitoring services, it's definitely good enough for my needs – and it's completely free.

Google Cloud Platform's free tier allows for 2 million Cloud Function invocations and three Cloud Scheduler jobs per month. This monitoring system will cost me ~45,000 function invocations per month with a single cron job, so I'm well within the free tier. Yay for saving money!

5 Reasons Why I Love Hugo for Blogging

Late last year, I migrated my WordPress-powered blog to Hugo, and I still think it’s the best decision I’ve ever made with regard to my blogging workflow. Switching to a static site generator like Hugo has expanded my knowledge and perspective on modern CMSs and their associated technologies.

Ironically, I feel that exploring non-WordPress tools like Hugo has actually made me a better employee at Kinsta – a managed WordPress hosting company. In this post, I'll share five reasons why I love working with Hugo, and elaborate on how it has impacted my personal and professional development.

Continue Reading →