Holiday Link Roundup

Over the holidays I did quite a bit of reading, and found a few articles that may be worth your time.

Bullying

If you only read one article this week, make it this one.

I have a bully.

Not a sexual harasser or a rapist or a men’s rights activist. A good old fashioned playground bully. I have mostly kept this story to myself for over a year, but I don’t feel I can continue to do so. It is destroying my peace of mind and making me feel terrible. I tried to ignore my feelings about this, hoping they would go away, but they have not. I need to share my story in order to move on from this.

I’m not posting this because I want anyone to do anything about this specific incident. I just want people to listen and to understand.

Open Source migrates with emotional distress

Armin Ronacher is a developer who’s been involved in Open Source for many years, starting in Python and most recently in Rust. He’s the guy behind some of the most popular Python open source libraries like Flask, Werkzeug, Pygments, Sphinx (which we use for our WOPI docs!) and many more. This article discusses what migrations/upgrades look like in the Open Source world.

Every few years a library or the entire ecosystem of that community is thrown away and replaced by something new and support for the old one ends abruptly and arbitrarily. This has happened to the packaging ecosystem, the interpreter itself, modules in the standard library etc. How well this works out depends. Zope for instance never really recovered from it’s Zope 2 / Zope 3 split. Perl didn’t manage it’s 5 / 6 split either. Both of those projects ended up with two communities as a result.

Many open source communities behave exactly the same way: they are replacing something with something else without a clear migration path. However some communities manage to survive some transitions like this.

This largely works because the way open source communities are managing migrations is by cheating and the currency of payment is emotional distress.

I’m not feeling the async pressure

A great article about back pressure, again from Armin Ronacher.

How good this async business works depends quite a lot on the ecosystem and the runtime of the language but overall it has some nice benefits. It makes one thing really simple: to await an operation that can take some time to finish. It makes it so simple, that it creates innumerable new ways to blow ones foot off. The one that I want to discuss is the one where you don’t realize you’re blowing your foot off until the system starts overloading and that’s the topic of back pressure management. A related term in protocol design is flow control.

What are micro-front-ends?

This is a podcast, but it has a transcript that you can read instead. The basic gist of this article is this: scaling can be more about scaling humans than scaling tech, and how might we address the human problems with some technical solutions? “Micro front-end” is the term coined for architectures that try to solve the same problems micro-services help address on the front-end – namely that complex apps are broken apart into constituent elements that can be revved and shipped independently. If you read the transcript, I think you’ll find that the Fluid app/component model is an example of a micro front-end architecture.

But the real challenge is how you scale the teams working on the same platform, because sometimes the challenges that are faced by one team could be completely different from the challenges that are faced by another team, and usually what you do is you try to find a lot of tradeoffs between the things. Because if you think, let’s try to think on a normal use case. So usually when you start a platform you’re starting small. So you try to create that quick single-page application, as well you have your monolith, so you just set up everything in your CICD just once for front end and back end, and then you start to iterate on your logic. But the reality is when you have success, you need to evolve this part, and it’s not always maintaining the same architecture that could, let’s say, create the benefit for your business, because maybe you can find some bottlenecks.

So now going back to the single-page application part. So if we want to scale a single-page application part, the challenge is not technical, it’s with humans if you want. So how we can scale teams working on the same application. So what I did a few years ago is, was the starting to look at a possible architecture that and principles that would allow me to scale the front end as well as the backend. So working on the backend principles so that you can find the microservices. I started to look at the different solution and they came out with the micro-frontends that at the beginning we didn’t even call it that way because obviously for years ago there wasn’t the, let’s say, that name for that specific architecture.

But the reality is taking a monolith, so a single page application and slicing it in a way that will allow us to focus ourselves in a tiny problem. So a smaller problem than the entire application and trying to solve that in the best way possible. Technically speaking. Obviously that lead to have independent pieces of your frontend application that could be deployed in production without affecting all the others. So the challenge basically for Micro-frontend is trying to figure out their way to take a single page application or server side rendered application and create a artifact of these, let’s say, as close as possible to a business domain, and can be deployed independently.

“Link In Bio” is a slow knife

As someone who loves the Web and has built his career on it, I care very deeply about staying true to the principles that make the Web such a powerful platform.

Links on the web are incredibly powerful. There are decades of theory behind the role of hyperlinks in hypertext — did you know in most early versions, links were originally designed to be two-way? You’d be able to see every page on the web that links to this one. But even in the very simple form that we’ve ended up with on the World Wide Web for the last 30 years, links are incredibly powerful, opening up valuable connections between unexpected things.

For a closed system, those kinds of open connections are deeply dangerous. If anyone on Instagram can just link to any old store on the web, how can Instagram — meaning Facebook, Instagram’s increasingly-overbearing owner — tightly control commerce on its platform? If Instagram users could post links willy-nilly, they might even be able to connect directly to their users, getting their email addresses or finding other ways to communicate with them. Links represent a threat to closed systems.

Here’s the thing, though: people like links.

Page Up, Page Down, Home and End in Catalyst apps

Catalyst is Apple’s new tech for cross platform iOS/macOS development. It’s pretty rough, from what I can tell. This article is about some basic functionality that is inconsistent. No big surprise there. But what I found interesting is that because WebKit is open source, this developer was able to create a library that patches over the problem – using undocumented APIs that the open source WebKit code calls. This is one reason developers love open source.

What’s going on here is that Apple did not add support for Page Up and Page Down in UIKit: They added this in WebKit/Safari. Fortunately WebKit is open source so we can see how they did it. Developers need to use the undocumented input strings UIKeyInputPageUp and UIKeyInputPageDown and write their own code to scroll up or down by the correct amount in response to those input events. While WebKit doesn’t support Home and End it’s possible to do some guessing: The strings UIKeyInputHome and UIKeyInputEnd do in fact work.

My open source KeyboardKit project aims to fill this gap in functionality from UIKit. It already implements correct behaviour for scrolling with arrow keys, option + arrow keys, command + arrow keys, space bar, Page Up, Page Down, Home and End. There’s a whole lot more in there, such as selecting items in lists using the up and down arrows, and I’m adding more every day.

This is a document of the future

This article about the New York transit map is fascinating, but the presentation is even more interesting. I’ve said before that “documents of the future are web sites/pages,” and this is an example. I argue that is a document, but it feels different. Sort of like a deck, but richer.

Read the “article” too; this quote was particularly interesting: “He rode the length of every train line with his eyes closed, feeling the curve of each track and then drawing the path he perceived in his drawings.”

A distributed meeting primer

Useful for us since we are a very distributed team!

As a leader who primarily values team health, I place great value on the weekly 1:1 because it’s where I assess health. It’s my highest bandwidth meeting, and historically the slight to significant lag omnipresent in video conferencing impeded that bandwidth. It stilted the conversation. The micro-second of lag was an omnipresent reminder of the distance.

Combined with the incredibly predictable audio-video gymnastics that accompanied the start of these meetings with the equally predictable quip, “There has got to be a better way.”

In the past three years, my perception is video conferencing is a solved problem. The combination of mature networking infrastructure and well-designed software (I primarily use Zoom) has mostly eliminated the lag of video conference and significantly decreased A/V gymnastics. We still have work to do.

Twitter announced an effort to make a standard, and I like Loren Brichter’s suggestion. Loren Brichter is the author of Tweetie, one of the best iOS Twitter clients I ever used, and was the very first app I paid real money for on the app store. He invented the pull-to-refresh gesture.

What’s the downside to letting the Twitter API as it stands be v1.0? Let third parties implement it, clients could connect to any compatible service, communication between services would evolve as needs evolve, you end up with something designed naturally (see HTML5 vs XHTML).

Prague mayor: Why we fly the Tibetan flag over City Hall

This is a bit random, but whenever I see the word “Prague” it jumps out at me now. 😊