Wednesday, 30 December, 2020 —
links
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.
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.”
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.
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.
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.
Saturday, 30 May, 2020 —
writing
creativity
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.
Thursday, 16 January, 2020 —
development
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.
Thursday, 9 January, 2020 —
ruby
development
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!
Wednesday, 1 January, 2020 —
cooking
New Year’s Day breakfast was scrambled eggs cooked in a 12-inch cast iron skillet, along with some whole wheat toast. I preheat the skillet over medium-high heat on our electric range, then drop the temperature to medium as I pour the eggs in. Fluffy scrambled eggs take about 90 seconds from there, folding the eggs two or three times.
A $40 12-inch Lodge skillet will last me the rest of my life. It is heavy and heats evenly.
Cooking with cast iron is a consistently better experience than I remember using non-stick skillets. Well-seasoned cast iron with some butter or oil is enough. Along the way, I monitoring as I cook. Unless I’m intentionally searing a steak, that little bit of butter or oil on top of the skillet’s seasoning is enough to keep the skillet pretty clean and food easy to release.
Cast iron seems less convenient because you generally don’t want to dry cook in them, but I’ve not found that to be true in practice. I see TV advertisements for non-stick pans being able to cook eggs without butter or oil. Friends, I’ve never had non-stick skillets work that well. Additionally, the non-stick coatings will scratch and eventually wear down. I was using either wood or high temperature-tolerant nylon spatulas to avoid scratching the coating on non-stick skillets. By contrast, cast iron is completely happy with more durable metal spatulas.
Another perceived limitation of cast iron is having to hand wash them. This is true, cast iron cannot be run through the dishwasher. I was still washing my non-stick cookware by hand, though. I cleaning my cast iron skillet while they’re still warm after cooking with hot water and adding a very small drop of dish soap placed on a chainmail scrubber. In the absence of that kind of scrubber, I’ve used both coffee grounds and salt to scour skillets.
Once the skillet’s clean and dry, put a penny-size drop of oil into the pan, wipe it around for an even coating with a paper towel to keep the seasoning fresh, then put the skillet away. You’re done.