blog.8-p.info

Crossing The Runway, who is making high-fashion look in Animal Crossing created this music video for Slyvan Esso.

Speaking of Slyvan Esso, Rooftop Dancing is also good.

I have installed Ubuntu on MacBook Air in… August? It was a long time ago.

Surprisingly it works mostly flawlessly. Even all proprietary keyboard buttons (Keyboard Backlight, Volume Up, Volume Down, …) works out of the box.

There are a few things I don’t like about;

  • Keybinding: I’m used to macOS’s keybinding which uses Cmd for GUI/macOS stuff such as Cmd-x for Cut, and Ctrl for Unix/Emacs stuff such as Ctrl-a for moving a cursor to the beginning of a line.
  • Battery: It seems shorter than macOS.
  • Display: This MacBook Air simply doesn’t have an Retina display.

So I still use my 2017 MacBook Pro as my daily driver.

testify package provides assert package and require package. Some people only use require whereas others intentionally mix assert and require.

I thought I’m the one who care the difference, but Jacob pointed out that I wasn’t careful enough at that time;

nit: please prefer to use assert if the tests allow it. Preferring assert, over require, helps extract as many relevant failures in a single test run.

Yes! For sure :)

But why?

testify’s README explains the difference of the behaviors but doesn’t explain “why”. Instead it mentions;

See t.FailNow for details.

However, t.FailNow only says;

FailNow marks the function as having failed and stops its execution by calling runtime.Goexit (which then runs all deferred calls in the current goroutine). Execution will continue at the next test or benchmark. FailNow must be called from the goroutine running the test or benchmark function, not from other goroutines created during the test. Calling FailNow does not stop those other goroutines.

Yeah. But why does it provide Fail() and FailNow()?

I think Google Test Primer is probably the best reference regarding “why”.

The assertions come in pairs that test the same thing but have different effects on the current function. ASSERT_* versions generate fatal failures when they fail, and abort the current function. EXPECT_* versions generate nonfatal failures, which don’t abort the current function. Usually EXPECT_* are preferred, as they allow more than one failure to be reported in a test. However, you should use ASSERT_* if it doesn’t make sense to continue when the assertion in question fails.

Unless it is coming from Plan 9, I think Fail() and FailNow() are coming from Google Test.

Topshelf Records is an record label in Portland, Oregon. Many so-called “math rock” Asian bands belong the label in the West, such as toe, tricot and Elephant Gym. While I’m happy to see tricot has signed a deal with avex, apparently that means no more tricot from Topshelf Records, which is a bummer.

Anyway, Topshelf Records recently made a brand-new website. I do like the vivid and bold design. And then this manifesto;

We built this website while pondering ways that we could, at every turn, focus on discovery by bringing music we released years ago relevantly back into the present. By hand curating similar artists within our roster and meticulously sorting every album we’ve ever released by genre, we’ve spent hundreds of hours building this robust website experience to hopefully challenge how we collectively talk and think about music. New music discovery is exciting—to be real, it’s a large part of why we run a label—but so is discovering music that’s simply new to you.

This is beautiful. The designer, Kevin Duquette actually works as “A&R / Advertising / Creative” in the label. So there is more than a client-designer relationship.

One of the development EC2 instances I wanted to collect some logs has ssm-agent instead of sshd. While this seems perfectly reasonable in 2020, how do you copy large log files from there? I initially did cat /some/large.log | gzip | base64 and carefully copied the base64-encoded output in System Manager’s in-browser terminal. It was stupid.

Instead, you can

  • Create an S3 bucket in your account.
  • Make a pre-sign URL to upload a file to the bucket.
  • Use curl to PUT a file to the pre-sign URL.

But there are a few caveats.

First AWS CLI cannot create a pre-sign URL with PUT. There is a PR since 2019, which hasn’t been merged. I ended up writing my own in Go.

Second curl’s -d parameter is removing \r and \n.

If you start the data with the letter @, the rest should be a file name to read the data from, or - if you want curl to read the data from stdin. Posting data from a file named ‘foobar’ would thus be done with -d, –data @foobar. When -d, –data is told to read from a file like that, carriage returns and newlines will be stripped out. If you don’t want the @ character to have a special interpretation use –data-raw instead.

I really don’t know why. I’ve been believing touching these characters is a Windows thing.