spectre256

It's definitely worth repeating the warning that, while very useful, Strict-Transport-Security should be deployed with special care!

While the author's example of `max-age=3600` means there's only an hour of potential problems, enabling Strict-Transport-Security has the potential to prevent people from accessing your site if for whatever reason you are no longer able to serve HTTPS traffic.

Considering another common setting is to enable HSTS for a year, its worth enabling only deliberately and with some thought.

Yeah, this definitely is a way to break the filter bubble.

But thinking about it a bit more, it might be one of the worst ways to do so.

For example, assuming roughly that both favorites and retweets represent general agreement, using those mechanisms to surface new tweets to people makes sense. If someone you follow (and presumably respect) quote retweets someone you don't follow with "Yes this!" or something similar, then you're already primed to agree with the person you follow.

But, often at least, replying and not faving/retweeting could very well bais for DISagreement. Now instead you're going to see someone you follow and respect arguing about something, and you're primed to agree with them, and potentially pile on to the original tweet author even though you might not have cared about the topic a minute ago.

Twitter ALREADY has a way to signal that you want all your followers to see a tweet you saw: retweet. And even showing your followers things you favorited at least means they'll see things you probably like. But it seems there's at least a reasonable argument that showing your replies to your followers is setting up a situation where pile-ons to the original tweet are likely.

The missing piece which the Twitter thread author only touched on is that how a tweet is received by a reader depends a lot on whether or not they come from similar communities and have similar context to the author. By surfacing tweets to people that the author doesn't know at all, it's likely the responses will be more negative in general.

Anyone with a large twitter following knows roughly what the makeup of their follower base is, and they compose tweets accordingly. While always necessary to some extent, it's usually hard to contextualize every single tweet as if it could be read by anyone, so it often isn't done.

As a silly contrived example, lets say I am a software developer that focuses on operating system performance and I tweet something like "I'm working on an algorithm to make killing children an order of magnitude more efficient". (note to real twitter users: never tweet that)

My followers know I'm talking about killing child _processes_ on a computer. So they reply things like "oh, that would be great, it would make this one shell script I have a lot faster to execute" or maybe even "personally I'd rather you encouraged users to use threads rather than forking lots of processes". There might be a heated discussion, but it will be with a HUGE shared context of information.

Now the Twitter algorithm picks it up, and the tweet gets seen by lots of people who don't know anything at all about operating systems. They are, understandably, completely appalled. They start responding with anger. Threats, abuse, etc.

So, Twitter changing the dynamic from "your tweets will primarily be seen by your followers" to "your tweets will frequently be seen by your followers followers" can actually have a big impact on the platform. It will at minimum take some adjustment. Operating with the assumption of one dynamic when there is in fact the other will be...painful.

Its a really nice idea, but I wonder if it would work in practice:

1. Would a significant amount of real humans who actually cared about the content cast a vote (up or down)?

2. Would it be even remotely possible to protect against fraudulent voting at Google scale? (remember they can't even prevent fake business listings on Google Maps, which is at least theoretically closer to verifiable from, for example, business records)

I'm a pilot, and absolutely this is a crucial difference.

It also reminds me of a time years ago when a team I was on had to extend a Memcache client library, as it couldn't differentiate between the following two conditions:

- "I tried to retrieve a key from cache but was unsuccessful (due to connection error, etc)"

- "I tried to retrieve a key from cache but determined conclusively that key does not exist in the cache"

If it was important for a caching layer on our silly social game, the same thing is clearly important in aviation.

I thought we got both, which is the best possible outcome: no one is wrong and there are more black hole photos.

Yeah, with all the research about how well correlated legitimate academic achievement is with family wealth, what does it say about you when you have to pay extra for one of these "consultants"?

I'm exactly the same way. If I can get a few things checked off my todo list early, I'm nearly guaranteed to at least feel like I had a good day.

Maybe, but that actually provides at least a little lasting value.

The ultimate example of toil, which I'm sure Google has automated away at this point, is truncating old log files that would eventually take up all remaining disk space. Simply truncating the file does not solve the inherent problem, but buys you more time before you'll face the exact same situation again.

The Google SRE book has an excellent description of toil and, unexpectedly, discusses that some amount of toil is beneficial.

In short, the authors of that section claim that it's not really possible for the SREs at Google to spend all their time solving novel problems through automation.

This makes sense: constantly solving new problems is hard. It takes lots of time, mental energy, and the outcome is inherently uncertain.

Google found that some amount of toil (roughly defined as repetitive tasks that are not particularly challenging and do not solve long term problems) is essential for the health of their engineers. Toil is boring yes, but can be relaxing, and as work that is inherently easier to accomplish, can help keep confidence that working on solving unknown problems can deplete.

I would have expected that Google would have absolutely minimal toil, given that they are leaders in the automation space, but if they've found that some amount of easier work is necessary, then it's probably true for anyone.

It really makes sense that something like this would be the case.

All the experts say "oh, Ruby uses lots of memory for [reason] and it can't really be fixed", so no one even tries.

Until someone comes along who is either motivated, smart, or ignorant(!) enough to try to fix it anyway, and finds that the commonly accepted answer was wrong.

This happens all the time, especially in science. Trust, but verify, I suppose.

Years ago I worked at a large online casual gaming company who's name ended in -ynga. Our web tier was split into two: one for serving static content required to load the HTML, Flash app, assets, etc. The other was for actual communication regarding actions taken in game.

Whenever we had any sort of issue we could generally get a good idea of what was happening by looking at changes in traffic in those two web tiers.

If people couldn't play for most reasons, game action traffic would drop to near zero, but the static asset tier traffic would usually at least triple.

So yeah, there are a lot of F5 buttons being hit out there when pages don't load.