walls.corpus

By Nathan L. Walls

  • Sunset, Jan. 2, 2021/Williams Township
  • On Bougher Hill/Williams Township
  • Sunrise, Dec. 19, 2020/Williams Township
  • Sunset, Dec. 27, 2020

2020 books

One of the things I like at the end of each year are seeing folks list of books.

My list for the year is here. My easy favorite was Ta-Nehisi Coates’ Between the World and Me. By subject matter, the book has been timely from publication, I was just late to pulling it off the shelf. As prose, it is one of the most astonishing written works I’ve ever read. The lines filled with spirit, not one wasted. It is a book I expect to return to often.

Group f.64, by Mary Street Alinder has also been out for a bit, but was another favorite. Alinder is Ansel Adams’ former assistant and biographer. Here, she turns her attention to the photographic community and broader spirit Adams helped found. It is deeply researched, taking the better part of two decades of work to get to publication. The endnotes and references are about one third as long as the book itself. Worthwhile.

Elsewhere, here are some end of the year book posts I appreciated:

I’ve started my 2021 books page. I have two books in flight presently, and I’ll add them to the page once I finish the books.

🔗 Links for Dec. 30, 2020

Cryptocurrency Start-Up Underpaid Women and Black Employees, Data Shows

Nathaniel Popper reporting for The New York Times:

The fast-growing cryptocurrency start-up Coinbase has been rattled in recent months by tensions between executives and employees who said they were being treated unfairly because of their race or gender.

While management at the company has argued that the complaints were limited to a handful of employees, Coinbase’s own compensation data suggests that inequitable treatment of women and Black workers went far beyond a few disgruntled workers.

The Coinbase figures arrived at by Ms. Marr took account of the job level of all employees, as well as their status as an engineer and manager. It is possible that if the analysis took account of more factors, the pay disparity would shrink.

In the 14 job categories at Coinbase with at least three women, the average woman earned less than the average man in all but two job categories.

Black employees earned less, on average, than white employees in all but one of the eight job categories that had any Black staff members, the analysis by Ms. Marr shows.

The wage disparities are compounded by the fact that women and Black employees were concentrated in the lower-paying jobs at the company.

It does not surprise me in any way to read this about a company whose CEO made loud noises about staff being “mission-focused” and apolitical at work.

It’s Peak Season for Tamales in Los Angeles

Tejal Rao, reporting for The New York Times:

The Mesoamerican dumpling, made with nixtamalized corn dough and a variety of fillings, has been around for thousands of years. Called tamalli in Nahuatl, a language spoken by Indigenous peoples in Mexico and Central America, it’s still referred to in its singular as a tamal, or tamale.

It can be a source of deliciousness, comfort, cultural connection or income, but the tamal is not a monolith, and there’s no single, correct way to make it.

Dr. Jeremy Littau: “I miss Christmas tamale season in California.”

Maybe You Don’t Need Kubernetes

Matthias Endler:

Kubernetes is the 800-pound gorilla of container orchestration.

It powers some of the biggest deployments worldwide, but it comes with a price tag.

Especially for smaller teams, it can be time-consuming to maintain and has a steep learning curve. For what our team of four wanted to achieve at trivago, it added too much overhead. So we looked into alternatives — and fell in love with Nomad.

We use Kubernetes at work. We’re a decently-sized engineering organization with several teams each supporting two or more applications. The complexities are worthwhile for us since our infrastructure team has a common framework for supporting applications deployed with Kubernetes.

For side projects, or a small shop, I would not start with Kubernetes.

The Frightening State of Security Around NPM Package Management

David Bryant Copeland:

I take GitHub’s new security vulnerability notifications seriously, and try to patch my apps whenever something comes up. I recently had trouble doing so for a JavaScript dependency, and uncovered just how utterly complex management of NPM modules is, and how difficult it must be to manage vulnerable packages. And I’m left wanting. I’m also left more concerned than ever that the excessive use of the NPM ecosystem is risky and dangerous.

The problem stems from three issues, each compounding the other:

  • NPM’s management of transitive dependencies that allows many versions of the same module to be active in one app.
  • Core tooling lacking support to identify and remediate the inclusion if insecure modules.
  • Common use of the same package.json for client and server side bundles.

This is an article from 2019, focused on NPM and JavaScript. More broadly, it’s a reminder to truly own your software dependencies. GitHub’s Dependabot is really helpful for getting automated updates, where they’re possible. It is insufficient to rely on it alone and so, the responsibility remains with project maintainers to stay aware and on top of security updates. Choose the your dependencies conservatively and wisely.

Russia’s SolarWinds Attack

Bruce Schneier:

The US prioritizes and spends many times more on offense than on defensive cybersecurity. In recent years, the NSA has adopted a strategy of “persistent engagement,” sometimes called “defending forward.” The idea is that instead of passively waiting for the enemy to attack our networks and infrastructure, we go on the offensive and disrupt attacks before they get to us. This strategy was credited with foiling a plot by the Russian Internet Research Agency to disrupt the 2018 elections.

But if persistent engagement is so effective, how could it have missed this massive SVR operation? It seems that pretty much the entire US government was unknowingly sending information back to Moscow. If we had been watching everything the Russians were doing, we would have seen some evidence of this. The Russians’ success under the watchful eye of the NSA and US Cyber Command shows that this is a failed approach.

And how did US defensive capability miss this? The only reason we know about this breach is because, earlier this month, the security company FireEye discovered that it had been hacked. During its own audit of its network, it uncovered the Orion vulnerability and alerted the US government. Why don’t organizations like the Departments of State, Treasury and Homeland Wecurity regularly conduct that level of audit on their own systems? The government’s intrusion detection system, Einstein 3, failed here because it doesn’t detect new sophisticated attacks — a deficiency pointed out in 2018 but never fixed. We shouldn’t have to rely on a private cybersecurity company to alert us of a major nation-state attack.

Schneier has the most level-headed, thorough, and considered write-up of the SolarWinds incident that I’ve seen so far.

Using Drafts

I was turned on to Drafts listing to the Back to Work podcast with Merlin Mann and Dan Benjamin, back when Drafts 4 was current and before there was a Mac client. If I recall correctly, Merlin was talking on the fact that Drafts was a good dumping ground for random bits of text that he could then decide what to do with.

It took me a bit to really grasp the promise.

Ordinarily, I work with BBEdit and Vim when I’m at my computer. Both are great for handling established lists, text manipulation, editing and so forth. But now, most things I write on the iPad, iPhone, and a fair amount of what I write on my desktop starts in Drafts.

BBEdit has some provision for temporary text in the form of its Scratchpad, something I use frequently. There’s a global Scratchpad and one available for each BBEdit project. I set-up a different BBEdit project for each codebase I use. Actively, I have snippets of text in two or three different scratchpads.

What’s harder, though, is starting a new document in one of these programs, because, pretty quickly, in wanting to save this text to disk, there’s a decision about what to call the thing I’m writing. Surprisingly, there’s some friction there, because besides giving the piece of writing a name, there’s the aspect of where it goes.

For ephemera, I don’t need the text I write to end up in a permanent file. I do need the text to appear across my devices and be easy to locate. Drafts does just that.

If and when I am ready to save an entry to a file, Drafts gives me that option. It’s plain-text. It supports Markdown. It syncs nearly instantly and it gets out of the way. Drafts also has Workspaces functionality, and wow, is it nice.

The iPad, an external keyboard, and Drafts, is a pretty idealized writing environment. It’s full-screen, (mostly) distraction free, when I let it be.

Here are the tasks I use Drafts for:

  • Building up shopping lists
  • Creating workout plans
    • This was more of a thing before gestures broadly all of this
  • Drafting tweets
  • Saving URLs for link posts
  • Writing blog entry drafts
  • Taking notes for work meetings
  • Writing most anything I haven’t figured out any particular structure to just yet
  • Composing emails, Slack messages, or anything i might paste into a web-based textarea
    • I find dedicated text editors drop words, letters, punctuation or flat out lose everything much less often than webforms textareas do
    • As with drafting tweets, there’s an added benefit in that composing offline means fewer opportunities for a hasty autocorrect or dropped error
    • On Slack, I avoid “Nathan is typing…” for minutes while I gather my thoughts, I’ve already done it once I send something

Once I’m done with the above, Drafts gives me several options of how to act on what I’ve just written:

  • Preview Markdown text as lightly-styled HTML
  • Save an entry as a text file
  • Send a tweet directly from Drafts, which is nice when I don’t want to open the hellsite directly
  • Send a tweet thread
    • The hack here is by writing in terms of a tweet thread, I will veer into just writing. At that point, I’m working on a blog entry and, as a goal, I would strongly prefer to publish more here than on Twitter.
  • Archive or delete the entry once I’m done with it, particularly ephemeral lists

It’s a valuable tool.

By any other name: What to call similar things

On a recent code review, one of my teammates was adding a new branch of code behind a feature flag to adjust how our site search weights potential results.

The existing code had a constant I’ll call RESPONSE_WEIGHT. The new branch added RESPONSE_WEIGHT_NEW. Both would co-exist while the feature flag was present.

Given this is a temporary feature flag that should be retired once the code is determined to be steady-state in production, going back through the code and taking out the feature flag and the old branch will leave RESPONSE_WEIGHT_NEW.

In a few weeks or months, I or another teammate are going to look at RESPONSE_WEIGHT_NEW and wonder what new means. If, we decide to further adjust search result weighting, RESPONSE_WEIGHT_NEW is an outright misleading name.

Appending a name with _new or _old is tempting because it doesn’t require a lot of creativity. It isn’t a great idea, because the new or oldness of it quickly loses context.

If there’s a need to separate functionality or naming by a feature flag, use a suffix like: _2020_Q1, which ties the name to a point in time.

This will also likely leave an earlier name around, and, context dependent, those can also change with a suffix _PRE_2020_Q1, if there’s not already a data quantifier on something.

Then, if and when it comes time to remove the feature flag, the code isn’t populated with now contextless _new entries. Similarly, the code won’t be looking at _new2 or _new_new.

In this case, the pull request feedback resulted in RESPONSE_WEIGHT_2020_Q1, which is more likely to remain an accurate name as long as it lives on in the codebase.

Ruby Standard Gems

At work, I’m upgrading my team’s Rails application from Ruby 2.5 to 2.6. In the course of tracking down test failures between the two versions, I’ve found the following site helpful: stdgems.org/.

In short, it describes the gems that are shipped with Ruby and the versions that shipped with each version, which is helpful in tracking down behavior changes that might not be described by the language changes themselves.

In a case specifically relevant to how the application handles invalidly formatted CSV files, I learned that for the CSV gem, Ruby 2.5 shipped with version 1.0 while version 3.0, started shipping with the 2.6 series. That detail was helpful in determining that the way we structured the test for a failing case was no longer going to work, and I needed to restructure the test. Yay!

← Previous