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.

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.

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.

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)

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.

- Founding and running a small company

- Working in/with/around the video game industry (good and bad)

- Health, work life balance

- Identifying and reducing bias in all sorts of situations (work, social, online, etc)

- Tasty, healthy food to cook with vegetables

She's well worth a follow: https://twitter.com/sehurlburt

Comments URL: https://news.ycombinator.com/item?id=19614585

Points: 2

# Comments: 0

> Exact matches always come first.

One place this very first rule doesn't work is autocomplete for geocoding.

If you are typing "London":

- There is a village called Lon, Pakistan [1]

- There is also a village called Lond, Pakistan [2]

- There are numerous places called Londo all over the world [3]

So its necessary to determine that some places are more likely to be typed than others (population is a commonly available number that can help, but doesn't always work), or autocomplete becomes useless.

[1]https://spelunker.whosonfirst.org/id/1209616309/

[2]http://www.geonames.org/1370290/lond.html

[3]http://www.geonames.org/advanced-search.html?q=londo&country...

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.

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.

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.

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.

- If you want the AWS dashboard metrics to have 1 minute instead of 5 minute granularity, that's $2.10 per instance per month. 5 minutes is pretty useless, so either you set up other monitoring or you pay a tax on the number of instances you have.

- If you use AMIs (which you probably should) to launch EC2 instances with all your software baked in already, you will probably end up with dozens or hundreds of old, unused AMIs. Furthermore each of these AMIs is linked to a snapshot, which is stored on S3. S3 pricing is very cheap but it's a significant amount of work to determine which AMIs are no longer in use and to delete both the AMI and the corresponding snapshot. Every 100 AMIs you have at the standard 8GB root volume size costs you $18/month.

What's the joke where someone fixes some machine and charges $1000? Their cost breakdown was:

turning a knob: $1

knowing which knob to turn: $999

I listen to podcasts while doing all sorts of things now.

RedHat makes, for example, patches for kernel vulnerabilities, but they actually give that away for free. What they sell is a promise that when there's a new vulnerability, you can get a patch from them quickly.

They also spread this service across MANY different open source packages. Like you said, a company that just offered services around a smaller package would have to run a lot more lean and would probably be a risky venture.

If you look at their website, Mapbox is all about "live" location data, insights, etc. The days of them just being a provider of nice services built around (mostly) open data are probably over. They have a huge userbase and can leverage all that data to do powerful things.