OAuth2 🔥-takes

Is it too late to do hottakes for something that’s been around for nearly a decade?

OAuth2 pros:

  • I can allow other sites to use my data with some confidence that, at least, my authentication information won’t leak
  • It has made really cool stuff possible at my current workplace and workplace-2
  • Libraries to make it happen in server-side apps are pretty good

Cons:

  • There are a bajillionty implementations and standard definitions of OAuth2 (for somewhat justifiable reasons)
  • If you want to tinker with an OAuth2 API, you’re in a bit of hurt because you can’t just grab a token and start playing (mostly, depending on the implementer)
  • Those open source libraries are the kind of thing that drive maintainers away pretty quickly 😬

Overall: would not uninvent this technology.

The emotional rollercoaster of extracting code

There’s a moment of despair when extracting functionality from a larger library, framework, or program. The idea grows, a seed at first and then a full-blown tree, that the coupling in this functionality isn’t all bad. A lot of people talk only about coupling and leave out cohesion. They aren’t mutually exclusive! When the two are balanced, it’s hard to come up with a reason to start extracting.

On the other hand, sometimes that moment of despair strikes when you start really digging into the domain and realize this chunk of functionality isn’t what you thought it was. Maybe it’s not coherent (see above!) or perhaps the model of the domain isn’t deep enough. This is a pretty good signal to hit the brakes on the refactoring, figure the domain out, and reconsider the course of action.

Feature envy rears its head in extractions too. Patterns of crosstalk between the existing thing and the new thing are a sure sign of feature envy. It’s tempting to say, hey maybe you really need a third thing in the middle. That’s probably making matters worse though.

That said, changing bidirectional communication to unidirectional is usually a positive thing. Same for replacing any kind of asynchronous communication with synchronous. Or replacing lockstep coordination with asynchronous messaging. Envy is tricky!

(I) often encourage starting a new service or application within your existing “mothership”. The trendy way to say this right now is “monorepo all the things” or build a “modular monolith”. I find this compelling because you can leverage a lot of existing effort into operationalizing, tooling, and infrastructure. Once you know the domain and technical concerns specific to the new thing, you can easily extract into its own thing if you need to. The other edge of a monorepolith is that path dependence is a hell of a thing. Today is almost certainly an easier day to split stuff out than tomorrow.

A thing to consider pursuing is a backend-for-frontend service in pursuit of a specific frontend. It doesn’t even have to serve an application. You may have services that are specific to mobile, desktop, apps, APIs, integrations, etc. Each of these may need drastically different rates of change, technical features, and team sets.

Probably don’t split out a service so that a bunch of specialized people can build a “center of excellence” for the rest of the organization to rely upon. This is a very fancy way to say “we are too cool for everyone else and we just can’t stand the work everyone else is doing”. On their best day, the Excellence team will be overwhelmed by the volume of work they have put in front of themselves to make Everything Good. On their worst day, they will straight give up.

If you split something out, realize you’re going to have to maintain it until you replace it. And you’re going to rebuild the airplane while it’s flying. If you’re not really into that, stop now. Just because you can’t stand Rails, relational databases, or whatever doesn’t mean you should jump into an extraction.

What I talk about when I talk about cars

Human design: what went into deciding how a human-facing thing is made? How did they decide to put the infotainment screen there? Why are BMW dashboard lights orange-ish? Who designs gauges and do they know what they’re doing? What the hell is going on with Mercedes dashes? When will we stop using gearshifts? When will the scourge of the PRNDL knob leave us?

Mechanical design: i.e. why is this car the way it is from an engineering point-of-view? Why is the rear-engine 911 unique, special, and kinda dumb? What makes the BMW M1 a weird BMW and yet perhaps the most special? Why do Ferrari engines catch fire so frequently? Do BMW/Audi/Mercedes design their cars as sedans, coupes, or hatchbacks first?

History: What puts some brands, e.g. Ferrari and Porsche over the others? Is Audi interesting? What is the gestalt of Honda or Toyota? How did the Viper come to have a tractor engine and a Lamborghini body? How does a BMW M car become “the next coming of BMW Jesus?”

Emotion: What makes people think a car is special? What kind of person owns a Koenigsegg or Pagani? Why own a Lamborghini? Is it practical to drive a Ferrari touring car? When does an Acura TL make sense for someone who enjoys cars? What will enthusiast cars look like once electric cars are the norm; will we finally enter a world of boring aerolumps?

…amongst other things. So many questions, so many subjective answers. That’s what makes it fun!

More ideas for framework people

A few months ago I wrote about Framework and Library people. I had great follow-up conversations with Ben Hamill, Brad Fults, and Nathan Ladd about it. Some ideas from those conversations:

  • use a well-worn framework when it addresses your technical complexities (e.g. expose functionality via the web or build a 3-d game) and your domain complexity (e.g. shopping, social networking, or multi-dimensional bowling) is your paramount concern

  • once you have some time/experience in your problem domain, start rounding off corners to leave future teammates a metaframework that reduces decision/design burdens and gives them some kind of golden path

  • frameworks may end up less useful as integration surface area increases

  • napkin math makes it hard to justify not using a framework; you have to build the thing and accept the cost of not having a community to support you and hire from

  • to paraphrase Sandi Metz on the wrong abstraction: “(Using) no abstraction is better than the wrong abstraction”; if you’ve had a bad time with a framework, chances it was an inappropriate abstraction or you used the abstraction incorrectly

The first few years of my career, I edited the wrong file all the time. I could spend hours making changes, wondering why nothing was happening, until I realized I’d been tinkering in the wrong place because I was misreading a file path or not paying close enough attention to control flow.

Fast forward to now, and I’m pretty quick to drop a raise "BLORP" in code I’m tinkering with if things aren’t working like I think they should. All hail puts debuggerering.

However, it turns out I found a new class of this operator error today. I was diligently re-running a test case, expecting new results when the test fixture file I thought was changed was the wrong file. Once I deleted the right file, I was back on my way.

Joyful and grumpy are we who can find new ways to screw up time ever day!

Chaining Ruby enumerators

I want to connect two Ruby enumerators. Give me all the values from the first, then the second, and so on. Ideally, without forcing any lazy evaluations and flat so I don’t have to think about nested stuff. Like so:

xs = [1, 2, 3].to_enum
ys = [4, 5, 6].to_enum
[xs, ys].chain.to_a # => [1, 2, 3, 4, 5, 6]

I couldn’t figure out how to do that with Ruby’s standard library alone. But, it wasn’t that hard to write my own:

def chain(*enums)
  return to_enum(:chain, *enums) unless block_given?

  enums.each { |enum| enum.each { |e| yield e } }
 end

But it seems like Ruby’s library, Enumerable in particular, is so strong I must have missed something. So, mob programmers, is there a better way to do this? A fancier enumerator-combining thing I’m missing?

I do my best thinking:

  • In the shower. I love to take long showers, and I love my tankless water heater.
  • While talking. Something about my brain is wired directly to my mouth.
  • When I’m not thinking. See also, the value of letting your mind idle, wander, or just walking away from a tricky problem.

Your thinking may vary!

Stored Procedure Modern

The idea behind Facebook’s Relay is to write declarative queries, put them next to the user interaction code that uses them, and compose those queries. It’s a solid idea. But this snippet about Relay Modern made me chuckle:

The teams realized that if the GraphQL queries instead were statically known — that is, they were not altered by runtime conditions — then they could be constructed once during development time and saved on the Facebook servers, and replaced in the mobile app with a tiny identifier. With this approach, the app sends the identifier along with some GraphQL variables, and the Facebook server knows which query to run. No more overhead, massively reduced network traffic, and much faster mobile apps.

Relay Modern adopts a similar approach. The Relay compiler extracts colocated GraphQL snippets from across an app, constructs the necessary queries, saves them on the server ahead of time, and outputs artifacts that the Relay runtime uses to fetch those queries and process their results at runtime.

How many meetings did they need before they renamed this from “GraphQL stored procedures” to “Relay Modern”?

(FWIW, I worked on a system that exposed stored procedures through a web service for client-side interaction code. It wasn’t too bad, setting aside the need to hand write SQL and XSLT.)

We should get back to inventing jetpacks

I don’t like using services like Uber, Twitch, or Favor. I want to like them, because the underlying ideas are pretty futuristic. But the reality of these services is that the new boss wants to squeeze their not-even-employess-anymore just as badly the old boss did. It feels manipulative, like buying a car. Except I’m abetting the manipulation too. :(

The New Yorker, THE GIG ECONOMY CELEBRATES WORKING YOURSELF TO DEATH:

The contrast between the gig economy’s rhetoric (everyone is always connecting, having fun, and killing it!) and the conditions that allow it to exist (a lack of dependable employment that pays a living wage) makes this kink in our thinking especially clear.

What happens when the gig economy tries to turn a profit? The race downwards will squeeze out all of their contractors until they can replace them all with automated drivers, commoditized personalities, and punitively-low ad revenue sharing rates. This sounds horribly dystopian but I’m pretty sure it’s already happening. See also: when Google kneecapped bloggers as a side-effect of end-of-lifing Reader and changing Pagerank.

The New York Times, Platform Companies Are Becoming More Powerful — but What Exactly Do They Want?

Platforms are, in a sense, capitalism distilled to its essence. They are proudly experimental and maximally consequential, prone to creating externalities and especially disinclined to address or even acknowledge what happens beyond their rising walls. And accordingly, platforms are the underlying trend that ties together popular narratives about technology and the economy in general. Platforms provide the substructure for the “gig economy” and the “sharing economy”; they’re the economic engine of social media; they’re the architecture of the “attention economy” and the inspiration for claims about the “end of ownership.”

After reading this, I started substituting “platform company” for “company building its own monopoly”. And then it all makes sense. Businesspeople say they love free markets, but give any rational-thinking business the chance and they will create so many “moats” and “barriers to entry” that they resemble tiny state enterprises more than a private business. See also: telecoms and airlines.

Anil Dash, Tech and the Fake Market tactic:

This has been the status quo for most of the last decade. But the next rising wave of tech innovators twist the definition of “market” even further, to a point where they aren’t actually markets at all.

Yes, my confirmation bias is burning. Yes, technologists are doomed to recreate the robber-baron past they didn’t study. Yes, we still have time to change this. Yes, our field needs an ethics refresher. Yes, we should get back to inventing jetpacks!

Jeremy Johnson, It’s time to get a real watch, and an Apple Watch doesn’t count:

…watches are one of the key pieces of jewelry I can sport, and while many have no clue what’s on my wrist, those that do… well do. And they are investments. Usually good purchases will not only last forever (with a little love and care), but go up or retain most of their value over time.

When pal Marcos started talking to me about watches, I realized they checked all the boxes cars do, but at a fraction of the price. If cars check your boxes, look into watches. Jeremy’s intro will get you started without breaking the bank.